[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
question about Quasiquote
Yes, that's the kind of setup I was thinking about when I wrote that
macros might be a problem. However, it doesn't explain why the
nesting levels have been introduced way before there was any mention
of hygienic macro systems in the language report.
Furthermore, a nesting level counter doesn't seem to be the
``natural'' solution to the problem.
Here is another proposal (yet incomplete):
``Evaluate and replace ALL `outermost' unquotations in the template.''
This certainly allows for quasiquote being used inside unquotations.
The problem with using unquotations in the template without having
them expanded remains. It could be solved as follows:
``Evaluate the <expr> part in all subexpressions of the form (unquote
<expr>) and (unquote-splicing <expr>) and replace them as usual UNLESS
the subexpression has the form (unquote unquote) or (unquote
unquote-splicing). These subforms will be replaced by a single
unquote or unquote-splicing respectively.''
Let me write William Clingers example using this convention:
(define (expand-letrec bindings body)
`((,new-lambda ,(map car bindings)
,@(map (lambda (binding)
`(,new-set! ,(car binding)
,(cadr binding)))
bindings)
,@body)
,@(map (lambda (binding) `(,new-quote unspecified)) bindings)))
-- It hasn't changed at all!
Now, how about my initial example:
(define a 'aa)
(define b 'bb)
`<some template> =?> `(aa bb)
<some template> would simply be:
`(,a ,b)
because now
``(,a ,b) => `(aa bb)
Furthermore:
``(,a (,unquote b)) => `(aa ,b)
The whole thing seems to be
- easier to understand
- easier to use
- easier to implement
- interfacing with (hygienic) macros just fine
Drawback:
- the use of unquote and unquote-splicing AS VARIABLES in templates becomes
difficult
Any comments?
-Matthias