[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] ANN: first draft of R7RS small language available
On Sat, May 7, 2011 at 2:00 AM, Jim Rees <jimreesma@x> wrote:
>> After all the discussion in this thread I'm in favor of (3) (which
>> essentially means that UNQUOTE being an identifier). (2) would be the
>> behavior with keywords being matched by name. (1) is somewhere in
> Your (3) is close, but the rationalization:
> After all we can rebind anything else just fine:
> (let ((+ -))
> `((unquote + (list 1 2)))) => (#<procedure:-> (1 2))
> is unfair, because this example gives UNQUOTE its special meaning (to
> QUASIQUOTE) back. A better example would be:
> (let ((+ -))
> `((not-so-unquote + (list 1 2))))
Actually this rationalization was wrong for other reason:
(let ((+ -)) (quote +)) => +
is matching symbols by name, do we want '-' instead?
(let ((+ -)) (quasiquote (+ ,+))) => (+ #<procedure:->)
is matching quoted symbols by name, do we want (- #<procedure:->) ?
(let ((unquote -)) (quasiquote (+ ,+))) => (+ (unquote +))
UNQUOTE is an identifier but it fails to expand, is the desired
output: (+ (- +)) ?
(let ((- unquote)) (quasiquote (+ (- +))) => syntax error (attempted
evaluation of UNQUOTE)
do we want (+ <#procedure:+>) ?
To me it looks like the above design is not hygienic but fixing it is
not as easy as fixing ELSE or => in COND.
It requires changing evaluation rules of QUOTE and QUASIQUOTE so that
symbols have a chance to be resolved.
In case of UNQUOTE and UNQUOTE-SPLICING it is even more complicated. I
can't come up with any solution except for expanding the whole
QUASIQUOTE form at the evaluation time (which is not going to make
compiler implementors happy)
In this particular case I think the easiest and the *cleanest* fix
would be to make unquote and unquote-splicing reserved words (illegal
This is getting a bit too difficult for me. If someone more
experienced could shine some light on this issue that would be great.
Scheme-reports mailing list