Am So., 28. Juni 2020 um 04:10 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:

>> What FHD-matcher handles is irrelevant.   The issue is to write a macro that expands into an FHD-matcher.

Ah, thanks. This what I didn't get earlier.

>> This is a bit contrived example:
>>
>> (define-syntax gen-match
>>   (er-macro-transformer
>>    (lambda (f r c)
>>      (let ((name (cadr f))
>>            (input (caddr f)))
>>        `(,(r 'match) ,input
>>          (`(,',name ,,'x ,,'y) `'(,,'x ,,'y))
>>          (_ #f))))))
>>
>> (gen-match foo <expr>) expands into a match that checks if <expr> is (foo <x> <y>) or not.
>>
>> gosh> (gen-match foo '(foo 1 2))
>> '(1 2)
>> gosh> (gen-match foo '(bar 1 2))
>> #f
>>
>> The expanded form is like this.   Gauche's match is Wright's match.
>>
>> gosh> (macroexpand-1 '(gen-match foo in))
>> (match in (`(,'foo ,x ,y) `'(,x ,y)) (_ #f))
>>
>> If the matcher uses implicit quasiquote, however, I can't simply use the nested quasiquote to generate the pattern.  Here's what I came up with:
>>
>> (define-syntax gen-match
>>   (er-macro-transformer
>>    (lambda (f r c)
>>      (let ((name (cadr f))
>>            (input (caddr f)))
>>        `(,(r 'match) ,input
>>          ((,name ,(list 'unquote 'x) ,(list 'unquote 'y)) `'(,,'x ,,'y))
>>          (_ #f))))))
>>
>> Expansion would be:
>>
>> gosh> (macroexpand-1 '(gen-match foo in))
>> (match in ((foo ,x ,y) `'(,x ,y)) (_ #f))

Instead of `list', you can use literals and every works and looks no
worse than the first example:

... `(,(r 'match) ,input
      ((,name ,',x ,',y)) `'(,,'x ,,'y)) ...

>> Now, you can argue that such code is relatively rare.  But I think that it is a built-in feature for quasiquote to check nesting levels, and I smell something fundamentally shaky in the implicit quasiquotes that breaks the model.   Who knows what might happen if one tries to write three or four level nested quasiquotes, which includes more than one type of implicit quasiquotes?  (e.g. scsh's process macro is another example using implicit quasiquote).   So I oppose including implicit quasiquotes, even if it's optional.

Whatever template engine one uses (quasiquotation, syntax-case's
syntax, explicit list constructors), it should be somewhat agnostic to
whatever S-expression it is expanding into. At that level, it is just
syntax. So if the template action strongly prefers some S-expressions
versus others, it is the template engine that is actually smelly. The
identifiers used for the template engine (quasiquote, unquote, ...)
shouldn't dictate the identifiers used in the output. But it seems to
me that quasiquotation simply works.