Andre van Tonder wrote:
>
>  Hi Mike, thanks for the comments.
>
>  > I'd like to suggest that compound expressions be represented by an
>  > opaque type rather than by pairs.  This would ensure a modicum of
>  > abstraction, and would *really* make comprehensive the ability of all
>  > syntax objects to carry location information.
>
>  The current representation does allow source tracking for compound syntax
>  objects.  One would make the reader put the location of each node (pair or
>  vector) in a hash table.  Each evaluation of a SYNTAX or QUASISYNTAX form
>  can do likewise.  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.

>  > I've come to appreciate
>  > this added layer of abstraction in PLT Scheme.
>
>  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.

>  As a subtype, it would have extra operations to, for example, inspect
>  the source location.  A precedent for this kind of design exists in the
>  R%RS numeric types, where an operation such as |remainder| is specified for
>  integers but not reals (like our source location operation), while other
>  operations such as + are generic (like our car/cdr).
>
>  Since we are talking about a Lisp where programs can be mapped to lists,
>  there should be a very good reason not to take advantage of the
>  ability, which comes for free, to reuse all the builtins and large corpora
>  of library list operations on syntax objects.  Making syntax objects
>  disjoint from lists would throw this away.  Is there something sufficiently
>  major that can be gained that would justify this?

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? In the explicit representation using
syntax-objects this is done by syntax->list (and others, such as
syntax-car and syntax-cdr).

>  As we know, subtyping can be thought of in terms of implicit coercions.
>  The alternative is having explicit coercions as in PLT, the
>  use of which quickly becomes tedious when expressing simple things like
>
>     (apply append stx))
>
>  which would become, with coercions:
>
>    (with-syntax ((result (apply append (map syntax->list (syntax->list stx)))
>      (syntax result))

That particular example can be written very succintly with pattern matching:

   (syntax-case #'((1 2) (3 4 5) (6)) ()
     [((x ...) ...)
      #'(x ... ...)])

   ; => a syntax-object representing (1 2 3 4 5 6)

However, your example shows that lists in "two levels" can be a bit
tricky. The (with-syntax ((result ...)) (syntax result)) part can be
shortened though:

   #`#,(apply append (map syntax->list (syntax->list stx)))

Since apply needs a list and stx is a syntax-object representing
a list, it isn't difficult to get the (apply append ... (syntax->list
stx)) part right. If I want to call a function that works on
list on syntax-objects representing lists, I usually define a
helper function to make things more clear.

    (define (syntax-append list-of-syntax-lists)
      (apply append (map syntax->list list-of-syntax-lists)))

Then I can write

    #`#,(apply syntax-append (syntax->list stx))

>  although notice that even PLT does an implicit type conversion
>  list->syntax-object to the result of evaluating (apply (map ....)).

Yes, if the result of a macro call is a list, then it implicitly
converts it into a syntax-object.

--
Jens Axel Søgaard