guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: syntax-local-binding


From: Mark H Weaver
Subject: Re: syntax-local-binding
Date: Tue, 24 Jan 2012 21:30:29 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Andy Wingo <address@hidden> writes:
> In the spirit of diffusing tension here, feel free to imagine all of my
> words as coming from Mr. Collins for the duration of this thread ;-)

Hehe :)

> On Tue 24 Jan 2012 14:25, Mark H Weaver <address@hidden> writes:
>
>> Andy Wingo <address@hidden> writes:
>>
>>> None of the interfaces that I proposed leak internal psyntax
>>> representations.
>>
>> `syntax-local-binding' leaks the internal representations used for
>> bindings.
>
> You mean, whether something is a lexical, or a macro, or a global, or
> whatever; OK.

That's actually not what I meant, although I'm not convinced that we
fully understand the implications of exposing even that much.  One thing
that is already clear is that `identifier-syntax' and `local-eval' were
previously capable of emulating variables perfectly before, whereas in
the presence of `syntax-local-binding' they no longer are.

This is a perfect example of how added flexibility in one aspect can
lead to _reduced_ flexibility in other aspects.  I think we need more
time to consider the implications of this.

However, the more serious problem, and the one I was actually talking
about, is the _second_ value returned by `syntax-local-binding', which
exposes the representations of bindings stored in the cdrs of the
psyntax `r' alist.

> Let me offer another example of its utility: writing a macro stepper.

It's not the least bit surprising that exposing internal implementation
details enables the creation of all kinds of nifty things as external
programs that would ordinarily need to be internal.  This is perfectly
obvious.

However, as you wisely said to me when I posted my first `local-eval'
evaluator-only implementation, this stuff has a cost, and it has to
justify itself.  I assumed you meant the maintenance cost of supporting
this advanced functionality indefinitely, and the constraints that it
places on the freedom of future implementors.  Was I right?

In retrospect, based on your recent behavior, I wonder if that's what
you meant or if you were talking about something completely different,
because you seem to have completely abandoned your original restraint,
and have now gone much farther than I would ever dare to go.  Indeed, as
you can see, I am very unhappy about how far you have gone with this.

> Perhaps, though, at this point we're just going to have to agree to
> disagree;

This is a euphemism for "sorry, but we're doing it my way".  Multiple
people here have expressed grave concerns about your approach, and not a
single person has publicly expressed their support for adding all of
these new interfaces you've designed.  Even Ludovic has remained silent.
And yet you apparently intend to rush all of this stuff into 2.0.4.
After all, nothing could be worse than having `the-environment' in
psyntax, even for single release.

Is this your idea of a consensus process, which you so often advocate?

     Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]