Am Di., 30. Juni 2020 um 21:43 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> syntax-case can be used to match against a bare (unwrapped) expression, but pattern variables must be referenced within syntax expressions.  So you have to do (syntax->datum (syntax ...)) to substitute match, correct?  Using syntax-case for general pattern matching is doable, though it feels like re-adapting a tool created for another purpose.

The R6RS syntax-case cannot match against a bare expression, it has to
be a syntax object, which means that bare symbols are not allowed (a
particular implementation may allow this, of course). So the input has
to be wrapped with `datum->syntax' first.

So it makes sense to use `syntax-case' when source code is to be
matched (or to be generated), but it doesn't make much sense to use it
to match, say, function parameters. On the other hand, when
`syntax-case' is available, it doesn't make sense to use one of the
other matchers to match source code.

To make syntax-case applicable to more use cases, the concept of a
syntax object should be parameterizable.

> Is it possible to split the pure pattern matching feature and the other syntactic thingy from syntax-case, and define syntax-case in terms of those building blocks?  I guess there's a reason it's not done so, but when I want to match on datum (rather than Scheme code fragment), which is the majority of my use cases, I don't want to care about syntactic something.

This would work with the parameterization idea that defines how to
decompose and compose a syntax object. For your use case, a syntax
object would just be a Scheme datum and identifiers would be bare
symbols. Likewise, `syntax' would have to depend on a parameter so
that #'a evaluates to the symbol `a' and not to an opaque syntax
object representing the identifier `a' in the lexical context of the
#'a form.