Re: lexical mumblings

[Andrew Innes]

On Tue, 30 Oct 2001 19:50:34 -0700 (MST), Richard Stallman <address@hidden> 
said:

>     The main benefit that I think would result is a reduction in memory
>     footprint, from not having real symbols created for all the variables
>     which really are local.
> 
> What would we do for debugging, though?  It would be quite unfortunate
> if we could not get access to these symbols through the debugger.

Bytecode would have to include symbol information off to the side,
somehow.  (I imagined it would be stored in comments in .elc files, and
held in a weak hash table keyed off the bytecode object itself once
loaded by the debugger, or when generated by bytecompiling a function
in-situ.)  The debugger would have to know about that information, to
lookup the stack slot that corresponds to the lexically bound symbol.

Ideally, the debugger would be extended to be able to access the
bindings that are visible in whichever stack frame it is currently
positioned.  This is something we don't have now, but which I would like
to see anyway - it would require functions to walk-down the specpdl list
to find buried bindings for dynamically bound symbols.

>        - How to reference lexical variables in nested bindings though?  Is
>        it acceptable to "flatten" all bindings in a function?  If so, what
>        happens if multiple closures are generated that refer to an inner
>        binding that is destroyed and recreated in between (ie. the inner
>        binding is different for each closure, but the outer bindings are
>        shared)?
> 
> It is reasonable to fall back on a different mechanism for cases like
> this, if that makes the usual case simpler and faster.

Actually, this isn't a problem with Miles' proposal (or mine either) -
in fact, nested bindings are handled quite cleanly in his approach,
using nested vectors.  In his approach, the compiler can even optimize
access to nested bindings if it so desires, which I think is neat.

>      + What to do about buffer-local variables?  In particular, variables
>        that are not permanently buffer-local, but declared so dynamically
>        using make-local-variable or make-variable-buffer-local.
> 
> Making a variable buffer local should permanently make it dynamic.

That's reasonable.  I observed that people almost invariably have
defvar's for such variables anyway, which makes them permanently
dynamic.

> Miles wrote:
> 
>     I think the point of this current exercise though, is that it really
>     _isn't_ a `deep change'.
> 
> The length of Andrew's message illustrates how big a change this is.

I wouldn't read that much into the length of my posting.  The file I
attached represents my private musings on the subject, and captures my
rather long (several years) thought process as well as my final
thoughts.

There are some obscure scenarios lurking in there, which need to be
addressed, but I agree with Miles that his approach really is quite
simple (and elegant).  It is certainly simpler than mine in several
important respects.

AndrewI