Daniel Kraft <d...@domob.eu> writes: > Hi, > > I think I got the test-suite as well as a basic macro implementation > (the compiler framework is really cool, that was fairly easy to do); > recursive macros do not yet work, but otherwise it looks fine. > > However, I want to tackle quasi-quotes (besides others) now; and in > Elisp %nil is not only #f of Scheme but also the end-of-list marker (I > guess that's why simply using Scheme's #f for %nil does not work).
[...] > It would be cool to teach Guile somehow to treat %nil as the > "standard" end-of-list value, such that both of these queries would > optimally return true. At least, is there some way to construct lists > terminated by %nil using something like the list primitive? Other > things needed would be for instance terminating rest-arguments by %nil > rather than '() and the like. Why not eliminate %nil/#nil and replace it with ... '(). This would allow elisp to reuse all (or at least most) of the Scheme list functions without having to muddy Scheme semantics with special #f/#nil handling, but would require a very tiny elisp specific truth predicate. Since everything should be compiled into an IL instead of Scheme this should be straightforward. This would have the rather nice advantage of removing all special elisp support code from libguile itself (thus cleaning up libguile a bit *and* making the elisp translator a much better example for other language translators since every language can't expect to have special support from libguile). If the Scheme value #f leaked into an elisp lisp/vector/etc. then it should *not* be treated as false to elisp because it is *not* an elisp false value; likewise if '() leaks back into data used by Scheme there is no particular reason to treat that as false and not end of list. This has the slight downside that calling between elisp and Scheme may not be so natural. Any elisp that would call Scheme must know it is calling Scheme (or simply not-elisp) and that it ought to generate Scheme false objects if it is calling a predicate of some sort, and any Scheme calling elisp should know this and use null? to check for a false return value. The only downside I can see to this is that if code were to be ported from elisp to Scheme there would now be code that assumed a '() return as false when #f would be false, but this could be fixed using a predicate like elisp-false? (or null-or-false? or ... something). Having multiple distinct false values is almost as bad as punning false and end of list and so I think the few disadvantages do not outweigh the advantages. -- Leebert: You don't listen to music. Leebert: You listen to the audio equivalent of /dev/urandom
