Re: %nil once again

[Daniel Kraft <d@domob.eu>]

Hi Andy,

thanks for your comments!

Andy Wingo wrote:
> Reviewing (and merging as much as possible of) your elisp branch is my
> next Guile task, after taking care of that bug recently reported by
> Martin Ward. Should be short work at this point.

Cool!  But just take your time ;)

>> At least, is there some way to construct lists terminated by %nil
>> using something like the list primitive?
> 
> It would need to be something you implement as part of the emacs
> runtime.
> 
> Otoh, (cons* a b c %nil) will do what you want.

Hm, that's an interesting option!  Another comment on this subject had 
been to try without converting the list ends and see how often code 
relys on exactly %nil being the end-of-list anyways, which is what I've 
been doing so far.  But I can give it a try to convert.

>> Other things needed would be for instance terminating rest-arguments
>> by %nil rather than '() and the like.
> 
> Hmmmmm. This is a good question. I think that, on the bytecode side, you
> would have to receive the normal Scheme rest argument, then run through
> it and replace the terminating '() with %nil. So when compiling
> functions that take rest args, they'd have this operation as one of
> their first instructions. There could be a VM op for this if necessary.

Yes, at the moment I already have to do some pre-processing of the rest 
argument at function entry anyways, to handle, for instance, optional 
arguments.  So I can just do the conversion there.

A VM op might be interesting, but as you suggested I'll just write a 
runtime-function and call it; we can do perfomance optimization later on 
when we really know what the problems are.

> On the other other hand... can we enumerate the set of circumstances in
> which we'd want to change a Scheme list to an Elisp list? Call,
> obviously. Probably we want to support tail recursion in calls within
> elisp, so tail calls too. Reading, but the elisp reader has to be
> slightly different anyway. If it's only calls, we can do tricks in the
> VM to make things faster.

I think it would be lists generated by the compiler for certain 
constructs (but I think all of those are only handed to primitives and 
never seen by elisp, so they don't matter), of course the rest arguments 
already mentioned, and most notably return values from primitives that 
return lists -- those need to be converted between the Guile primitive 
and elisp, but that should also be only a call to the conversion routine 
and hopefully not result in too bad performance.

So, maybe a next thing for me will be to work on this conversion.

Yours,
Daniel

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