Am Mo., 21. Okt. 2019 um 21:27 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> My $.02
>
> [ie]r-macro-transformer has a nice property that it allows you to combine orthogonal, generic
> tools to write macro transformers, whilst syntax-case forces you to use specialized tools that
> can only be used within syntax-case.

I don't think that it is necessarily right. In principle, nothing
speaks against using the special forms `syntax-case' and `syntax' and
the pattern variable system in run-time code. And the syntax-case
pattern matcher has to be provided in any case because syntax-rules
uses the same pattern matcher. On the other hand, to match source
code, a more general pattern matcher than `syntax-case' won't help
much.

>
> Here's "when-not" macro in er-macro-transformer, with Gauche's supporting libraries:
>
> (define-syntax when-not
>    (er-macro-transformer
>       (lambda (form rename id=?)
>          (match form
>             ((_ test expr1 expr ...)
>              (quasirename rename
>                 `(if (not ,test) (begin ,expr1 ,@expr))))))))
>
> Here's syntax-case version:
>
> (define-syntax when-not
>     (lambda (x)
>       (syntax-case x ()
>          ((_ test expr1 expr ...)
>           #'(if (not test) (begin expr1 expr ...))))))
>
> er-macro-transformer version uses match macro (Wright's match), and
> Gauche's quasirename macro (which applies rename procedure on symbols not unoquoted).
> They are not tied to macro system at all---they're generally useful tools.
>
> Most of times, syntax-case will make shorter code, and that makes syntax-case perfect "middle-level"
> tool.

Apart from cleaner code, a syntax-case macro will retain source code
location information. This is not only important for debugging but
makes it possible to write macros like the R7RS form `include', which
shall include the file from the directory where the source of the
include form comes from.

> I wish it could be deconstructed to orthogonal basic tools.  Could the pattern matcher be
> splitted from it?  It seems such a waste if an implementation has to have two set of pattern
> matchers, and one of them can only be used with specific macro expanders.
> (I know the wrapped syntactic forms require special handling.  But I imagine we could define
> a pattern matcher library that can accept wrapped form and bare form, for example.)

In principle, one could specify syntax parameters that control how
`syntax-case' destructures its input and how `syntax' composes its
argument. This way, it can be adapted to input and output of any
shape.

If you want to fully decompose the syntax-case system, one could end
up with the following components:

(0) Specification what a transformer is, including identifier syntax
and variable transformers.

(1) The idea that source code is not necessarily represented by an
sexp but by some abstraction ("a syntax object") that may be an sexp
expression, but may also be something fancier and may include, for
example, source location information and lexical information.

(2) A primitive procedure to destructure syntax objects like Racket's
`syntax-e'.

(3) A primitive procedure to construct syntax object, like `datum->syntax'.

(4) Some identifier syntax that represents the current macro
environment and that can be used with `datum->syntax'.

(5) A way for macros to lexically introduce pattern variables and to
bind them to expand-time values.

(6) A way for procedural macros to recognize pattern variables and to
retrieve their values.

(7) An implementation of `syntax-case' using the above.

(8) An implementation of `syntax' using the above.

A "native" implementation of `syntax' would still be faster, though.
Also, source code location information may be lost.

On the other hand, something like `syntax-e' can easily be implemented
on top of `syntax-case', so in any `syntax-case' system, you can use
your favorite pattern matcher.

Thus, I would propose to implement the syntax-case system as is but
with making sure that `syntax-case' and `syntax' also work outside
macro transformers. Furthermore, the concept of pattern variables
could be made available to user-level code (so that one can build a
matcher like `syntax-case' from primitive building blocks).

Marc