Re: Opaque syntax objects

[Jens Axel Søgaard <jensaxel@xxxxxxxxxxxx>]

Andre van Tonder wrote:
> On Sat, 13 Aug 2005, [ISO-8859-1] Jens Axel Søgaard wrote:
>
> By the way, I would like to properly attribute the hash table idea.  It 
> was first suggested to me in an email by Jens and later independently by 
> Kent Dybvig on the basis of previous work with Hieb.
>
> > Andre van Tonder wrote:
>
> > > Since pairs keep their identity during expansion, location 
> > > information for every node (and identifier leaf) can always be looked 
> > > up in the hash table at any stage of the expansion.
> >
> > There is also the user written macros to consider. If source tracking 
> > hinges on the identity of pairs, then a user of the macro system needs
> > to be very careful to reuse in the output of a macro the exact same
> > pairs, he is given as input; otherwise he looses the annotations
> > on the input.
>
> It is true that if the user uses |cons| to construct his pair, the pair 
> cannot be assigned useful location information, although its components 
> still retain their location information.  There is a strong disincentive 
> for doing so, though, with the availability of [quasi]syntax.

What should I do if I want to give a piece of (expanded) syntax the
same source information as, say, the macro call?

> > >   Would you object to having compound syntax objects be specified as  
> > > a subtype of lists, so that we can use 
> > > car/.../cddddr/map/.../member/...  as generic operations on them?  Is 
> > > there something you find useful  that such a design would prevent? 

> > I would object unless you can guarantee that car, cdr and friends
> > wouldn't become more expensive to use on normal pairs.
>
> Of course.  Syntax objects are still ordinary pairs.  No change to 
> car/cdr is required.  The hash table with source information is kept 
> separately.

Hmm. How do you represent identifiers?

> > Besides the feeling that keeping the abstraction is a good thing, the
> > major selling point for me, is that source annotation (including 
> > source location tracking) works so well in PLT. The hash-table 
> > approach you
> > describe above may work, but it is not (to me) immediately obvious that
> > it does. If I annotate a normal list representing an expression with a 
> > given property, how is the property propagated to its subexpressions
> > in the hash-table implementation?
>
> I'm not sure I see the problem.  Maybe an example will help, if you 
> don't mind thinking one up...

Sorry - it turns out I thought syntax properties were treated the
same (internal) marks and substitutions were, but that was
a misconception.

> > Yes, if the result of a macro call is a list, then it implicitly
> > converts it into a syntax-object.
>
> Not quite :-)
>
> (define-syntax foo
>   (lambda (form)
>     (syntax->list (syntax (quote (a b c))))))
>
>
> (foo)  ==> return value from syntax expander was not syntax

Scratches head, I could have sworn ...

> So it appears to work only on the right hand side of with-syntax 
> bindings (and in unsyntax).
>
> Anyway, if you are willing to accept one implicit type conversion, why 
> not all of them?

I believe with-syntax behaves that way in order to be (more) compatible
with the psyntax-implementation. Note that the source location
information for stx-expr in

  (with-syntax ((pattern stx-expr) ...) expr)

is taken from stx-expr, when stx-expr is not returning a list. That
is the source location is still tracked.

--
Jens Axel Søgaard