Am Mo., 29. Juni 2020 um 22:27 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:

> So, the most flexible interpretation is that (quasiquote x) and (unquote x) are just another syntax or macro call and the programmer can freely give semantics to each separately by defining macros, and it shouldn't be limited by the default semantics.  Marc's position is closer to this, I think.

Yes, I guess my position is closer to this. `quasiquote' and `unquote'
are very precious macro names (or very precious names for auxiliary
syntax) because they are treated specially by the reader. Thus, more
than one macro wants to make use of it at least as auxiliary syntax.

> What I feel is that having a shorthand notation does give them a slightly special position rather than other built-in syntaxes such as 'lambda' or 'if'.  Having a special syntax is to give a visual cue for the reader's benefit, and in the quasiquote case, a reader naturally seeks for quasiquote-unquote correspondence, since it's the convention.  Scheme won't force the programmer to follow it, meaning you can define your own macro to use unpaired unquotes, but I feel it needs a legitimate reason strong enough to break the convention and reader's expectation.

There is actually one completely different advantage when quasiquote
is specified explicitly: It allows us to hygienically rebind the
quasiquote identifier in the matching clauses so that, for example,
the following is possible:

(match in
  (`(,x ...) `(foo ,x ...)))

(Note the use of ellipsis, which needs a simple extension of the qq
syntax. See http://snow-fort.org/s/rapid-scheme.org/marc/rapid/quasiquote/0.1.1/index.html.