Re: summary: lilypond, lambda, and local-eval

[Noah Lavine]

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