On 05/13/11 08:56, Alex Shinn wrote:

> and the expander would then do something like
>
>   (define (expand-macro op expr use-env mac-env)
>     (cond ((er-macro-transformer? op)
>               ((er-macro-procedure op) expr use-env mac-env))
>              (else
>               (op expr))))
>
> Now, for the plain procedure to be useful expr would actually
> have to be wrapped somehow, and a basic API for structuring
> and destructuring syntax objects would need to be provided,
> such as what R6RS provide (without syntax-case).

Ugly hack for sure. Looks like the *core* would need to know about all
the macro systems in use.

It'd be much nicer to have the core expander use whatever form of lambda
it wants, and then for wrapper macros to convert
syntax-object/syntactic-closure/explicit-renameing/syntax-rules into
that form as applicable - as pluggable modules on top of the core.

Is that too much to ask? That syntax-object just play ball with the others?

The "It's simpler to be a syntax -> syntax function" argument is an
argument in favour of syntax objects. I accept that point. It's a good
point. But it still doesn't at all say that functions on syntax objects
need to be the *core* representation of syntax transformers.

A system that uses ER deep inside, or soem bizarre ten-argument
super-expander that can access the lexical environment as a first-class
object so you can write macros that detect misspelt symbols and suggest
which bound symbol has the closest spelling or whatnot, but which
provides a syntax-object-transformer wrapper, can still let students see
a nice simple syntax -> syntax transformation.

(define-syntax foo
  (syntax-object-transformer
     (lambda (stx) ...)))

...can coexist happily with all the others!

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports