[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Opaque syntax objects
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
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
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
Yes, if the result of a macro call is a list, then it implicitly
converts it into a syntax-object.
Not quite :-)
(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