Re: syntax-local-binding

[Andy Wingo <wingo@pobox.com>]

Hi Mark,

On Mon 23 Jan 2012 22:03, Mark H Weaver <mhw@netris.org> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> 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.

I'm not sure we're talking about the same thing here; do see Alex
Shinn's NAK on R6RS:  http://www.r6rs.org/ratification/results.html#X70

While I disagree with his assessment of the identifier-syntax tradeoff,
I think he correctly identifies it as a tradeoff.

>>>> 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.

I know I'm going to sound like Mr. Collins in Pride and Prejudice here,
but I flatter myself that I know a thing or two about managing change --
I mean, replacing the lazy-memoizing evaluator with the compiler,
retrofitting psyntax into Guile, the whole subr mess, etc.  There is
always room to improve, of course, as in all human endeavor, but for now
it does seem that Guile is getting more powerful _and_ more limpid over
time.

But frankly though, regarding change, while we do need the freedom to
modify some things, some other practical freedoms just don't make the
cost/benefit cut, for me.  For example, considering replacing psyntax,
which seems to be in the back of your mind here.  This conservatism is
preventing Guile from adding features.  And we do need features --
local-eval and syntax-parse among them.

> 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.

Apart from the fact with `the-environment' in psyntax, it's in the
default environment, of course; though with autoloads one can get around
that...

With `the-environment' in a module, in 2.0.4 we could have three
functions added to psyntax:  syntax-local-binding,
syntax-locally-bound-identifiers, and syntax-module.  The first and the
third have precedent in Racket (whose hackers have been able to do
significantly awesome stuff).  The second is strange, but seems OK.  I'm
OK with them.

But what if they're the wrong interface?

Well, then we use the normal deprecation mechanism to get rid of them,
eventually (in the 2.2 series, for example).  We learned something.
Users get warned off the code.  Life goes on.

> 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.

Hear, hear.

> 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.

I really do value your work, and your words, Mark.  Besides that
personal appreciation, I think you're doing good work for Guile.

We happen to disagree here on a matter of implementation.  OK.  It's a
feature we have worked on sufficiently that it should probably make it
into 2.0.4.  OK.  One of us will be unhappy about whatever goes in, it
seems.  I appreciate the calcification argument, but I simply think that
it does not apply in this case.

The thing that we shouldn't forget, though, is that regardles of the
particular technique, if local-eval goes in, we'll have won already --
local-eval in a modern Scheme.

Regards,

Andy
-- 
http://wingolog.org/