[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: %nil once again

From: Daniel Kraft
Subject: Re: %nil once again
Date: Fri, 31 Jul 2009 07:03:09 +0200
User-agent: Thunderbird (X11/20070425)

Hi Neil,

Neil Jerram wrote:
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).

I don't like that at all!

In my view, the only reasonable alternative solution above is the one
that would work by translating data passing between Elisp and Scheme.
The theoretical argument against that is that such translation could
be arbitrarily complex, and so have an unbounded performance cost, but
in practice I imagine that would almost never be the case.  Also there
is the point that languages other than Elisp will _require_ data
translation, and why should we make Elisp a special case?  Hence I
wouldn't rule out the possibility of switching to this design in
future; and then we could, as you say, make nil==() and remove most
elisp special cases from the libguile core.

I agree here; though I think we should get translation to a minimum as much as possible; for instance, I still think the Guile core should treat %nil as false and empty list if asked for. This does not hurt Scheme, as %nil does not occur there, but it would allow us to just use TreeIL conditionals and the like without having to translate here.

On the other hand, if we want elisp semantics as faithfully as possible, we need to translate the way from Guile primitives to elisp code. Currently I'm already doing this for booleans; for instance, the = built-in of emacs is defined something like:

(lambda (a b)
  (if (= a b)

so that the "false" value is really %nil. On a later thought, this might be the real reason why my "tight while loop" performed worse than the Scheme version in the performance test. But I don't see a way how to get around this, unfortunatly; except if we just assume that the elisp user won't test a false value for (eq value nil) but just use it as boolean in conditionals, too, so it does not matter if the value is %nil or #f.

The same applies to lists... In general, one can write probably most elisp code without having to really care if the tail of a rest argument or the result from the list built-in or some quotation-expression is %nil or '() (and should actually check with null instead of (eq nil), I think). At the moment it is like that, there's no '() <--> %nil translation happening by now. As long as libguile/VM gets the patch to accept %nil as end-of-list (as the interpreter already does), one can still do (cons 'a (cons 'b nil)) in elisp and get the expected result...

I'm still not sure if we should actually do data translation from Scheme (Guile built-ins) to elisp user code or not... But probably we should just do it and the performance hit will not be too painful.


Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri

reply via email to

[Prev in Thread] Current Thread [Next in Thread]