Mark H Weaver <m...@netris.org> writes: > I've been considering writing a python compiler for guile.
Great! > For python > (and others) there are several values considered to be false, such as > 0 and various empty collections, and so a different approach will have > to be taken to this problem. > > If we want guile to handle many different languages, should we not try > to find an approach to "false-ness" that handles many languages, and > not just a few? There's been loads of prior discussion on this subject. Here are pointers to some of that. http://sourceware.org/ml/guile/1999-07/msg00251.html http://sourceware.org/ml/guile/1998-07/msg00187.html http://lists.gnu.org/archive/html/guile-devel/2001-09/msg00140.html http://lists.gnu.org/archive/html/guile-devel/2001-11/msg00016.html > It seems to me that some code might misbehave in the presence of two > values which are both null? but not eq? to each other. Example? (This seems quite unlikely to me.) > Also, it seems more consistent to use the same strategy for handling > various languages' notions of false-ness. > > To my mind, we should not be changing the data (which only works for > lisp), but rather the constructs that decide whether a given value is > false. > > So how about having elisp `if' and `cond' compile not to scheme `if' > and `cond', but rather to scheme `elisp-if' and `elisp-cond'? Or > perhaps compile `(if c a b)' to `(if (elisp-true? c) a b)'. > > This approach, unlike the %nil approach, will work for other languages > too. Certainly this is a possible approach. In what's been done so far, and what we do in future, I don't think there are any arguments that trump all the other considerations. It's just a matter of balancing performance, robustness, and so on. If more non-Lisp-like languages are added, your consideration of cross-language consistency would gain more weight. On a matter of detail, I don't understand your statement that the current %nil approach won't work for other languages. As the query that started this thread shows, it is perfectly possible to code a new language (VM-Scheme, in this case) in which %nil is true. If I understand it correctly, a key point of the thinking up till now is that Elisp is a special case because it is so `tantalizingly similar' (as Jim put it) to Scheme. This similarity creates the possibility of passing data directly between Elisp and Scheme, and the fact that Guile Scheme treats %nil as both #f and '() follows from that; otherwise it would be necessary to convert data as it passes from one language to the other. In other words - a performance point. Now we have Brainfuck and ECMAScript too, but I don't know if they are complex enough to cast significant doubt on the existing balance. (To be honest, I'm not sure if that's true for ECMAScript, I need to look at Andy's code.) Python on the other hand would be plenty complex enough, and I assume it has arbitrarily complex data structures. How do you envisage data transfer working between Python and other languages? > It also means that Guile's normal `if' and `cond' won't be slowed down > by having to check for two values instead of one. That overhead may > be insignificant now, but when we have a native code compiler, it will > be quite significant in code size at least, even if the > representations of %nil and #f differ by only one bit. Do you really think so? Just because of two compare operations instead of one? Perhaps I'm misunderstanding you. > On Mon, Jun 29, 2009 at 10:44:54PM +0100, Neil Jerram wrote: >> Seems wrong to me. In Scheme #f should be the only false value. >> What's the argument for %nil being false in Scheme code? (Just for the record, my statement here was wrong, and I've since corrected it.) Regards, Neil
