From: Noah Lavine <noah.b.lavine@gmail.com>
To: Andy Wingo <wingo@pobox.com>
Cc: Mark H Weaver <mhw@netris.org>, guile-devel <guile-devel@gnu.org>
Subject: Re: summary: lilypond, lambda, and local-eval
Date: Sun, 18 Dec 2011 10:32:15 -0500 [thread overview]
Message-ID: <CA+U71=M3zg9rRTE-5joXLZuqHcSPXnBMTx53eD2kX7+ivreEPQ@mail.gmail.com> (raw)
In-Reply-To: <87vcperufl.fsf@pobox.com>
Hello,
>> 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.
If I understand correctly, Mark wants to restrict the set of variables
you can access to those you could access through normal Scheme code.
This is an issue because psyntax happens to provide a way to access
more variables than standard Scheme. If this is the case, I think we
should absolutely restrict it to standard Scheme, because letting you
access everything psyntax can access a) is not Scheme and b) restricts
our future implementation choices.
> 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.
This actually seems bad to me, although I'm just guessing. Because the
thing is, it's not *really* that Scheme code that you wrote, and so
the compiler is seeing something wrong. It has the same
variable-capture properties as that code, but it's not actually that.
My instinct is that compiling non-accurate code is going to be more
trouble than it's worth, but that's just a guess.
In general, this thread has been very, very impressive. Thanks a lot
to everyone who has been working so hard on this.
Noah
next prev parent reply other threads:[~2011-12-18 15:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-15 10:21 summary: lilypond, lambda, and local-eval Andy Wingo
2011-12-15 14:46 ` David Kastrup
2011-12-15 16:52 ` Hans Aberg
2011-12-15 17:24 ` David Kastrup
2011-12-15 17:52 ` Hans Aberg
2011-12-16 7:35 ` Mark H Weaver
2011-12-16 8:08 ` Mark H Weaver
2011-12-16 8:49 ` Mark H Weaver
2011-12-16 9:16 ` David Kastrup
2011-12-18 7:11 ` Mark H Weaver
2011-12-18 11:27 ` Andy Wingo
2011-12-18 15:32 ` Noah Lavine [this message]
2011-12-18 16:19 ` David Kastrup
2011-12-18 21:24 ` Noah Lavine
2011-12-19 9:13 ` Mark H Weaver
2012-01-09 14:44 ` David Kastrup
2011-12-16 9:28 ` Andy Wingo
2011-12-16 9:59 ` David Kastrup
2011-12-16 10:33 ` Mark H Weaver
2011-12-16 12:13 ` Hans Aberg
2011-12-16 12:43 ` David Kastrup
2011-12-16 14:57 ` Hans Aberg
2011-12-21 10:32 ` Ian Hulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+U71=M3zg9rRTE-5joXLZuqHcSPXnBMTx53eD2kX7+ivreEPQ@mail.gmail.com' \
--to=noah.b.lavine@gmail.com \
--cc=guile-devel@gnu.org \
--cc=mhw@netris.org \
--cc=wingo@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).