Andre van Tonder wrote:
>  > From: Jens Axel Søgaard <xxxxxx@soegaard.net>
>
>  > So identifiers are represented as a special type. How about atoms?
>  > Can I annotate a piece of syntax representing, say, a number?
>
>  That is the one thing that I can see as being precluded by the current
>  specification.  They would indeed need to be wrapped to give them
>  separate identities, instead of being bare, as they currently are.
>
>  Wrapping constants would be a useful change for the next revision.
>  I think all the primitives for handling them are already there.
>  Given a piece of syntax, one can define:
>
>    (constant? stx) == (and (not (pair? stx)
>                            (not (vector? stx)
>                            (not (identifier? stx))
>                            (not (null? stx)))
>
>  and one may use datum->syntax-object and syntax-object->datum to go
>  back and forth between constants and syntax representing constants.

If it is neccessary to wrap atoms, vectors, the empty list etc. then
the only data structure left, that isn't represented by a special
type is lists. Wouldn't it be simpler to demand all syntax to
be represented as a separate type?

>  > Andre wrote:
>  >
>  > > it is unlikely that most implementations would keep the location of the
>  > > input subnode ((i e) ...) in the result.

>  What I meant is that the node  ((i e) ...)
>  in the result discards the original position.

Ah! Agree.

>  Writing the macro procedurally using car, cadr, ..., one is actually more
>  likely to duplicate the functionality of let3 by default, for example
>
>    (define-syntax (let4 bindings . body)
>      (check-bindings bindings)
>      (check-body body)
>      (quasisyntax (let ,bindings ,@body))
>
>  preserves more information than the pattern matching let2, since
>  the pair |bindings| keeps its identity.
>
>  Anyway, this is not important at all.  I'm certainly not advocating against
>  syntax-case, which is a really, really useful invention.  I was just noting
>  that it is not necessarily superior to the procedural interface for
>  accurate source tracking.

It wasn't as much the pattern-matching I was concerned about, but the
ability to associate information with all types of pieces of syntax.

--
Jens Axel Søgaard