[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.

felix winkelmann wrote:
On 8/12/05, Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

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.

Representing syntax-objects using normal lists does breaks the
abstraction, and I too prefer the extra layer of abstraction.

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, 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.

What I like about srfi-72 is that I can write hygienic macros with (nearly)
the same ease as in conventional Lisp-/quasiquote-style. In fact this is what I consider the most innovative feature for SRFI-72.

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.

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.

The macro-call (do-primes var start end body ...) evaluates for
each prime between start and end the body expressions in an
environment, where the variable var is bound to the prime current

(define-syntax (do-primes2 stx)
  (let* ((form  (syntax->list stx))
         (var   (cadr form))
         (start (caddr form))
         (end   (cadddr form))
         (body  (cddddr form)))
    #`(do ((#,var (next-prime #,start) (next-prime (+ #,var 1))))
        ((> #,var #,end) 'done)

; prints: 2 5 7 done
(do-primes2 p 1 10
            (display p)

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.

For comparison I have included a version of the above macro,
where the destructuring is done by normal syntax-case pattern

/Jens Axel

; do-primes.scm

(define (prime? n)
    ((even? n) (= n 2))
    (else      (let loop ((trial-divisor 3))
                   ((< n (* trial-divisor trial-divisor)) #t)
                   ((zero? (remainder n trial-divisor))   #f)
                     (loop (+ trial-divisor 2))))))))

(define (next-prime n)
  (if (prime? (+ n 1))
      (+ n 1)
      (next-prime (+ n 1))))

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

(do-primes p 1 10
           (display p)

(define-syntax (do-primes2 stx)
  (let* ((form  (syntax->list stx))
         (var        (cadr form))
         (start      (caddr form))
         (end        (cadddr form))
         (body       (cddddr form)))
    #`(do ((#,var (next-prime #,start) (next-prime (+ #,var 1))))
        ((> #,var #,end) 'done)

(do-primes2 p 1 10
            (display p)

Jens Axel Søgaard