From: Noah Lavine <noah.b.lavine@gmail.com>
To: David Kastrup <dak@gnu.org>
Cc: guile-devel@gnu.org
Subject: Re: summary: lilypond, lambda, and local-eval
Date: Sun, 18 Dec 2011 16:24:53 -0500 [thread overview]
Message-ID: <CA+U71=PR4ec3c9z5FqiDfGvMspDspZb9hWnm45_p-6FgT9eY5Q@mail.gmail.com> (raw)
In-Reply-To: <871us1x36x.fsf@fencepost.gnu.org>
Hello,
>> 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.
>
> If psyntax accesses more than Scheme can access while doing a task that
> is worth doing, what chance would there be in giving Scheme the power to
> access what psyntax can?
Let me explain what I mean more. Here is a code example:
(let ((x 3))
(let ((x (* x 5)))
(the-environment)))
At the point of the-environment, there is one Scheme variable around,
'x', and its value is 15. The old value of x is shadowed by the new
one.
But psyntax works by assigning each of these x values a gensym, and
they get different gensyms. So in theory, you could access the outer
value of x (x = 3) if you had a handle on the right gensym.
Supporting this seems weird to me, because I view psyntax as an
implementation detail of Guile, and not something that should affect
programmers. I also think that not supporting it is fine because if
you want to be able to access both values, you can always give your
variables different names. So this isn't giving you more power, but
just a weird way to access it.
> If exporting enough of the compiler environment to be useful for
> implementing multiple compilation units sharing lexical environments is
> feasible, what are the implications for splitting a compilation into
> separate units when the extent of psyntax is not similarly involved?
>
> In short: where should one draw the line in a way that makes best use of
> already done compilations without having to redo too much to be of
> practical use?
I do not know enough to respond to the rest of your email.
Noah
next prev parent reply other threads:[~2011-12-18 21:24 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
2011-12-18 16:19 ` David Kastrup
2011-12-18 21:24 ` Noah Lavine [this message]
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=PR4ec3c9z5FqiDfGvMspDspZb9hWnm45_p-6FgT9eY5Q@mail.gmail.com' \
--to=noah.b.lavine@gmail.com \
--cc=dak@gnu.org \
--cc=guile-devel@gnu.org \
/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).