Re: syntax-local-binding

[Stefan Israelsson Tampe <stefan.itampe@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5405 bytes --]

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 <mhw@netris.org> wrote:

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

[-- Attachment #2: Type: text/html, Size: 6362 bytes --]