Re: %nil once again

[Daniel Kraft <d@domob.eu>]

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)
     t
     %nil))

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.

Daniel

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