Re: guile and elisp

[Andy Wingo]

Hi!

On Mon 29 Mar 2010 10:42, address@hidden (Ludovic Courtès) writes:

>   - There’s currently no Scheme code that interacts with Elisp.  Thus,
>     code that will be written specifically to interact with Elisp code
>     can adjust to do the right thing, e.g., make explicit calls to
>     ‘canonicalize-boolean’, etc., as Mark suggested.

This is certainly an option on the table. However it would be nice if we
could avoid it, if Scheme code were "nil-safe" by default.

>   - 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.

>   - 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. 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.

Cheers,

Andy
-- 
http://wingolog.org/