[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Opaque syntax objects

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. 

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