Re: syntax-local-binding

[Stefan Israelsson Tampe]

Hi,

1. module level macro bindings are reachable already with the api. so beeing able to reach locally
defined one as well can be seen as a way to make that feature complete.

2. (define-syntax name val) (let-syntax ((name val)) ...) etc should be aboute
creating bindings and hence the binding value should be a feature of scheme and not
something that depends on the macro expander.

3. weather a syntax object represent a lexical a macro etc. is also something that has to do
about scheme and not the actual syntax expander.

In this light my view is that this information does not expose any details about the internals. Without this
function however users may be tempted to manually look into a syntax object and the resulting code will
brake if we change the internal representation of syntax information. In short by publishing a rich set of accesssors users will be safe and less things will brake if we do the change. 

However It look to me that changing the syntax representation in racket would be a monumental task because of the extreemly rich set of features their macro framework has so it is very good to be 
careful in entering features. But note, if these features are defined in a small set of accessors that logicaly is about getting information that are defined as scheme and not as something that is internal I would say that the burden is to a large degree an illusion.

For example the use of syntax-local-binding in syntax-parse is to (define-syntax class data) or (let-syntax ((class data)) ...) with class beeing a syntax object pointing to information about a syntax class like a string syntax class that enables matching of strings only. Now It would be good and I really like to get help here, if there are any good suggestions about what I can do to avoid using syntax-local-binding (I managed to rmeove this dependency for other locis in the code). The point here is that wingo need to find arguments of code using syntax-local-binding and argue that it is the natural solution. And Mark need to suggest alternatives and depending on elegance, performance, safety etc we could agree if a feature is exoterix and perhaps not needed. For this I can help in suggesting elements from the syntax-parse code base.

This is my 2c at least
/Stefan

On Wed, Jan 25, 2012 at 3:30 AM, Mark H Weaver <address@hidden> wrote:

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