Re: guile and elisp

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Andy Wingo <wingo@pobox.com> writes:

> On Mon 29 Mar 2010 10:42, ludo@gnu.org (Ludovic Courtès) writes:

[...]

>>   - Scheme’s #f/() are more expressive that elisp’s nil.  They can be
>>     easily mapped to nil, whereas it seems hard to automatically choose
>>     whether to map nil to #f or to ().  This also supports the idea of
>>     requiring Scheme code to make explicit conversions.
>
> Sure, though it's easy to map all three values to "not", "null?", and
> "boolean?", in those predicates' incarnations in both languages. For
> that reason I think we can avoid conversion of values.

Well, yes, conversions can be avoided in many but not all situations, as
the corner cases you described illustrate (notably equality predicates
and hash functions).  Maybe it’s a good middle ground, though.  I’m
wondering to what extent such a semi-transparent solution could
“surprise” programmers.

>>   - Elisp should be considered “legacy”.  Whenever something can’t be
>>     made transparent, I’d consider Scheme first-class and Elisp
>>     second-class.
>
> Hoo, that's a really broad definition of legacy.

Yes.  :-)

> Even if all elisp hackers were to stop hacking elisp today, we'd
> probably still have elisp code 10 years from now. Hopefully we don't
> have to make a "first-class"/"second-class" distinction, besides the
> obvious one that Scheme is first-class to Scheme, and Elisp to Elisp,
> and so on.

Sure.

What I meant is that Scheme’s disjoint boolean type should be considered
the Right Thing.  I’d rather keep it really disjoint, at the cost of
weaker/less trivial interop, than going the elisp road too far.

Thanks,
Ludo’.