Re: syntax-local-binding

[Mark H Weaver]

Andy Wingo <address@hidden> writes:

> On Fri 20 Jan 2012 23:03, Mark H Weaver <address@hidden> writes:
>
>>   (let ((x 1))
>>     (syntax-local-binding #'x))
>>
>> is not equivalent to:
>>
>>   (let ((x 1))
>>     (local-eval '(syntax-local-binding #'x) (the-environment)))
>
> Indeed; bummer!  I think, though, that this is simply a consequence of
> giving more power to macro writers.
>
> It is analogous in some ways to the changes that identifier-syntax
> introduce into macro writing: with identifier-syntax, one can no longer
> write a code walker with syntax-rules pattern matching, as single
> identifiers may expand out to complicated expressions, possibly even
> with side effects.

This is false.  Macros are always expanded _before_ any of their
arguments are expanded.  Therefore, a code walker sees the unexpanded
forms, including any "simulated variables" bound by identifier-syntax.

>>> Why do you think that?  The procedures do carry metadata; I understood
>>> that that was your strategy, to use the serialization of the
>>> syntax-rules form in the procedure metadata.
>>
>> Well, this was in the context of a new strategy where psyntax would
>> include a new core form called `call-with-current-local-expander' that
>> calls its parameter (a procedure or macro) with a procedure that accepts
>> an expression and returns an expanded form.  In this case, the most
>> straightforward implementation would simply serialize the (r w mod)
>> structures directly.
>>
>> Toward that end, I was thinking it would be nice to keep those
>> structures serializable.  The only part that's not currently
>> serializable are the transformer procedures for local macros.
>> Thus the change in representation.
>
> I have been staring at this empty page here for a little while, writing
> and re-writing, but I can't get over a feeling that I really don't want
> this kind of work in psyntax itself.

Your priorities are reversed from what they ought to be.

What you _should_ be worried about is making commitments in our API that
we must continue to support forever.  This is a _real_ problem, since it
constrains our ability to modify our implementation in the future.

Putting the `the-environment' in psyntax is, at worst, a stylistic
issue.  Whether it belongs there is a matter of taste, but however
strongly you may feel about that, it is a purely _internal_
implementation issue.  The really important thing is that it commits us
to _nothing_.  There's nothing stopping us from radically reimplementing
it later.  In particular, there's nothing stopping us from moving it out
of psyntax later.

Guile has been in existence for a couple of decades already, and I hope
that it will be actively used for many decades to come.  With that in
mind, please consider the long view.  One of the reasons Scheme has
lasted so long is because it tries exceptionally hard to hide internal
implementation details.  Implementations that expose too much internal
detail may derive a short-term benefit from doing so, but it comes at
the price of eventual calcification: there comes a time when
implementations that expose too much become unable to make significant
internal structural changes.

Please consider this.  I feel that your mind has become closed to my
arguments.

     Mark