Re: syntax-local-binding

[Mark H Weaver]

Andy Wingo <address@hidden> writes:

> On Fri 20 Jan 2012 21:26, Mark H Weaver <address@hidden> writes:
>
>> Andy Wingo <address@hidden> writes:
>>>     `lexical'
>>>           A lexically-bound variable.  The value is a unique token (in
>>>           the sense of `eq?') identifying this binding.
>>>
>>>     `macro'
>>>           A syntax transformer, either local or global.  The value is
>>>           the transformer procedure.
>>
>> Ironically, `syntax-local-binding' renders the current simple
>> implementation strategy of `the-environment' inadequate, because
>> identifier-syntax is no longer sufficient to simulate a lexical.
>
> Why do you say that?

Because it breaks your nice equivalence.  For example:

  (let ((x 1))
    (syntax-local-binding #'x))

is not equivalent to:

  (let ((x 1))
    (local-eval '(syntax-local-binding #'x) (the-environment)))

Put another way: if anyone uses `syntax-local-binding' to distinguish
lexical variables from macros in some clever macro of theirs, this means
that `local-eval' is now buggy with regard to their clever macro.

>> in particular, I was hoping to change the binding representation of
>> `syntax-rules' macros so that they are serializable.  In particular,
>> they would be represented by the `syntax-rules' form itself (the same
>> one that psyntax currently passes to `primitive-eval' to produce the
>> transformer procedure).  A weak-key hash table would cache the compiled
>> transformer procedures.
>>
>> This would allow (the-environment) to capture locally-bound
>> `syntax-rules' macros.  Unfortunately, `syntax-local-binding', as
>> currently documented, now makes this impossible.
>
> 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.

More specifically: instead of attaching procedure properties/metadata to
the transformer procedures as is currently done, that information would
be put directly into the binding.  An alist would probably make the most
sense.  The source code of the macro (whatever's currently passed to
`primitive-eval') would also be included.

This may or may not be a good idea, I dunno.  I haven't fully thought it
through.  However, that's not the point.  The point is that by exposing
these details in the API, you are constraining our ability to make
changes of this kind.  I think that's very unfortunate.

     Mark