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