> From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>
>
> The issue has come up in the discussion, but hasn't really been in
> the focus yet:
>
> 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.  I've come to
> appreciate this added layer of abstraction in PLT Scheme.

Yow!  It looks like the low traffic on this list does
not mean that nobody was reading.

In my opinion, the great beauty of this SRFI is that it
makes syntax into a list of identifiers so that we can
write macros with map, caddar, reverse, etc...
I _don't_ want to learn a whole new set, and re-write
all my utility list handing procedures as syntax transformers.

> From: =?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <xxxxxx@soegaard.net>
>
> > But wouldn't this completely break the (IMHO) rather practical
> > ability to destructure arguments passed to macros via normal
> > Scheme operators?
>
> Keeping this abstraction doesn't make destructuring significantly
> more impractical. Destructuring arguments using the pattern matching
> capabilities of syntax-case is unchanged with both representations,

Syntax-case is still available as a library procedure, if you like that.
Personally, I never liked syntax-case, mostly because I did not
understand it.  But a side benefit of working with the SRFI
system for a while is that I think I start to understand
syntax-case by seeing how it is built from the simpler components!

> and in the case were it is neccessary to use normal Scheme
> operators, most often a call to syntax->list, which turns a
> syntax-object representing a list into a list of syntax-objects, is
> enough to solve the problem.

It seems that if you did enough of that you could eventually
bust your syntax object down into the SRFI representation---
the hard way!  What's the advantage?

> Since quote, quasiquote, unquote and unquote-splicing is used to
> construct lists, one can introduce syntax, quasisyntax, unsyntax and
> unsyntax-splicing to construct syntax-objects. The abbreviation #'
> is a common abbreviation for syntax, and in analogy with this among
> others PLT uses #´ #, #,@ for the rest.

But with this SRFI you don't even need #, and #,@ !
We have quasisyntax (i.e. #` ) but , and ,@ still work
with it the same as with quasiquote.
  (hope you can parse the punctuation)

Now what about #(reverse), #(filter), ...
It seems like a losing direction to me.

> As an example of a macro written using normal Scheme operators and
> these syntactical abbreviations, I have taken the macro do-primes
> from "Practical Common Lisp" p. 94.

I do not see the point of this example.
I just ran the following through the SRFI reference implementation,
it works fine.

(define-syntax (do-primes var start end . body)
   #`(do (( ,var (next-prime ,start) (next-prime (+ ,var 1))))
         ((> ,var ,end) 'done)
         ,@body))

This is nothing more than a very straightforward substitution
of a few parameters into a fixed template.  The template
happens to be a loop, but so what?
A more interesting example would do the loop in the macro expander.
I don't have time right now to work up a prime example, but here
is one I have laying about:

(define-syntax define-count
  (lambda (form)
      #`,(let loop ((names (cdr form))
                    (k 0)
                    (result '()))
           (if (null? names)
               (quasisyntax (begin ,@result))
                  (loop (cdr names)
                        (+ k 1)
                        (cons #`(define ,(car names) ,k))
                              result)))))

(define-count zero one two three)

    -->  (expands to)

    (begin (define three 3)
        (define two 2)
        (define one 1)
        (define zero 0))

(list three one zero two)   ==> (3 1 0 2)

> A macro whose expansion uses quasiquote to construct a list can
> be hard to read (and write), if ordinary lists are used to represent
> syntax. It is not immediately obvious whether a given quasiquote
> is used to construct the expansion or is a part of the expansion
> of a call to the macro.

Indeed, nested quasiquote is notoriously mind-bending.
What part of the SRFI should be changed to fix that?
How does a lot of syntax->list help?

--
     -- Keith Wright

Programmer in Chief, Free Computer Shop
 ---  Food, Shelter, Source code.  ---