[Top][All Lists]

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

Re: Elisp lexical-let

From: Daniel Kraft
Subject: Re: Elisp lexical-let
Date: Fri, 24 Jul 2009 08:50:10 +0200
User-agent: Thunderbird (X11/20070425)

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.


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]