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.

>>   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.

> 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...

> 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

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?

Cheers
Andre