Re: Elisp lexical-let

[Daniel Kraft]

Andy Wingo wrote:
> > I'll keep in mind also the lexbind idea of optionally making every
> > binding lexical.  Andy, can you give me a hint/example/pointer how
> > compiler options work?  This would be exactly the place to provide this,
> > I think.  Additionally we could add an option to remove the "variable is
> > void" error check for a further performance gain.
>
> They don't work! Well, basically they're just a value that reaches the
> compiler somehow. I think they are a keyword list: (#:foo bar #:baz qux)
> etc. They are set via the #:opts argument to compile; I don't know if
> you can set them from the command line. I was waiting for a use case :)

thanks for the hints, I did some tests yesterday, and it seems that I 
can just provide whatever value I want to (compile ... #:opts <options>) 
and get this as opts of the compiler routine called.

I've never used keyword lists before, but I'll look them up and this 
seems like what we want.  So far I'm thinking about two possibly useful 
options:

1) Declare to disable void checks for certain variables or all (for 
performance, as already written).  Stuff like makunbound/boundp will 
sill work just as before, but accessing a variable that is void will not 
give an error but rather return the special void value.  As most code 
should not really depend on this void-error anyways, it seems reasonable 
to give at least a way to disable this check happening on each and every 
variable access for no good (except debugging maybe).

2) Declare that certain variables or all should always be bound 
lexically rather than dynamically; maybe a defvar construct will retract 
this and make it dynamically bound later on again, then this should be 
like the upcoming lexbind stuff in emacs.  As lexical-let is not 
everything, but function arguments are always dynamically bound (except 
if we provide a lexical-lambda... hm, it might even be useful at times!) 
-- and this spoils tail-calls -- both of this option and lexical-let 
will probably be useful.

And maybe others in the future, but I've no ideas so far.  It seems that 
options work basically, but I guess there's not yet a way to "set" them 
for compilation happening for the elisp-repl?  This means that I can 
just keep on implementing and testing them, but for real use we probably 
want some construct to set them for real uses (besides (compile ...)) as 
well.

Cheers,
Daniel

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