[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: summary: lilypond, lambda, and local-eval
From: |
Andy Wingo |
Subject: |
Re: summary: lilypond, lambda, and local-eval |
Date: |
Sun, 18 Dec 2011 12:27:42 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) |
On Sun 18 Dec 2011 08:11, Mark H Weaver <address@hidden> writes:
> So, it turns out that the best place to transform (the-environment) into
> standard scheme code is in the macro expander itself.
Are you certain that it is desirable to transform it into standard
Scheme code?
The statement that the-environment acts "as if it were the expression,
(case-lambda ....)" doesn't mean that you have to implement it that
way.
> Indeed, only the macro expander has enough information to generate an
> optimal list of "reachable lexicals", i.e. lexical variables that are
> accessible using normal symbols (as opposed to syntax objects) [more
> on this below].
Are you certain that you want to restrict the set of identifiers?
To me it sounds like an optimization, perhaps premature.
What do you think about having a <the-environment> tree-il form have a
field for the names and a field for the gensyms of captured lexicals?
> This is great news, because it means that `the-environment' will no
> longer require its own tree-il type, and the compiler will only see the
> standard scheme code that it expands into.
>
> However, we will need a robust way to either (A) specify, (B) discover,
> or (C) predict the order of the captured lexicals in a closure.
We could compile `the-environment' so that at runtime it yields a record
containing a vector of syntax objects and a vector of corresponding
variable objects. (When the compiler boxes a variable, it does so in a
variable object, as from make-variable.) Then you don't introduce
cross-cutting assumptions to the compiler and runtime.
> I have yet to decide which option to take. Suggestions welcome.
WDYT about mine? :)
> There's also another issue that has come to my attention. If we must
> support arbitrary syntax-objects to be passed to `local-eval', in many
> (most?) cases this will greatly increase the number of lexicals that
> must be captured, and thus boxed, by (the-environment).
If a tree-il `the-environment' form takes a list of names and gensyms,
then we can provide the possibility in the future to limit the set of
captured bindings.
> So, I'm thinking that (the-environment) should only capture lexical
> variables that are reachable using normal symbols.
I think I disagree here. It is strictly less useful to capture a subset
of bindings, and it would only be done for efficiency, and it probably
doesn't matter.
So yeah, I guess my arguments here depend on a tree-il the-environment
form. I wonder if that is the right thing, though; maybe there is a
lower-level concept at work. The only thing that you need that tree-il
doesn't give you right now is the ability to declare a variable as
boxed, and to capture its identity.
Maybe what we need is a <lexical-capture> form that evaluates to the
variable corresponding to a bound lexical. Then `the-environment' could
expand out to
(make-struct/no-tail <lexical-environment>
'(name ...)
(list (capture-lexical name) ...))
You would still need support from the expander to get the set of
currently-bound names, but maybe that is a new primitive that we could
add.
Could we do it all with two new low-level primitives? And then, could
we actually put `the-environment', environment accessors, and everything
else into a module?
Andy
--
http://wingolog.org/
- summary: lilypond, lambda, and local-eval, Andy Wingo, 2011/12/15
- Re: summary: lilypond, lambda, and local-eval, David Kastrup, 2011/12/15
- Re: summary: lilypond, lambda, and local-eval, Hans Aberg, 2011/12/15
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, David Kastrup, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval,
Andy Wingo <=
- Re: summary: lilypond, lambda, and local-eval, Noah Lavine, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, David Kastrup, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, Noah Lavine, 2011/12/18
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/19
Re: summary: lilypond, lambda, and local-eval, Andy Wingo, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, David Kastrup, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Mark H Weaver, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Hans Aberg, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, David Kastrup, 2011/12/16
- Re: summary: lilypond, lambda, and local-eval, Hans Aberg, 2011/12/16