This page is part of the web mail archives of SRFI 72 from before July 7th, 2015. The new archives for SRFI 72 contain all messages, not just those from before July 7th, 2015.
Andre van Tonder wrote:
> From: Jens Axel Søgaard <jensaxel@xxxxxxxxxxxx>> 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.
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 againstsyntax-case, which is a really, really useful invention. I was just noting that it is not necessarily superior to the procedural interface foraccurate 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