Hi,
[...]
> I expect the following to be equal, and they are.
>
> (cons 'sym func)
>
> (quasiquote (sym . (unquote func))) `(sym . ,func)
>
> Guile writes them both as
>
> (sym . #<procedure func (x)>)
>
> But, the following is also equivalent, which is a surprise to me.
>
> (quasiquote (sym unquote func))
> `(sym unquote func)
>
> Is this a valid use of unquote?
It has to be. Because a list consists of car+cdr pairs,
the notations (a . (b . (c . ()))) and (a b c) are equivalent
and thus indistinguishable to the scheme reader:
(equal?
(with-input-from-string "(a . (b . (c . ())))" read)
(with-input-from-string "(a b c)" read))
; ===> #t
> I get that (cons 'a (list 'b 'c)) == (list 'a 'b 'c), but, I'm not sure
> if unquote should be valid in that sort of construction.
The only alternative is that you wouldn't be able to write
`(a . ,b), because -- since `x is transformed by reader
to (quasiquote x), and ,x -- to (unquote x), the reader
sees this as:
(quasiquote (a . ,b))
== (quasiquote (a . (unquote b)))
== (quasiquote (a unquote b))
But I think that from the perspective of the implementation
of the "quasiquote" macro this is still consistent.
Let's consider a simplified version of the macro -- call it
semiquote -- that doesn't allow nesting of semiquotes,
supports only lists, and doesn't support unquote-splicing:
(define-syntax semiquote
(syntax-rules (unquote)
((_ (unquote form))
form)
((_ (head . tail))
(cons (semiquote head) (semiquote tail)))
((_ atom)
'atom)))
As you can see, the second case invokes semiquote
on the tail of the list. So if it happens to be
(unquote form), it will be considered the first case
in the next iteration.
Note however, that if you write (a b unquote c d),
the unquote won't be interpreted, because there's
only a rule for (_ (unquote form)), and not for
(_ (unquote form . rest)).
Having said that, I'd suggest reconsidering the idea
(which might be a little OT), that if a function call
is an improper list, like
(+ a b . c),
then it could be interpreted by the evaluator as
(apply + a b c)
(now it just raises a syntax error).
Best regards,
M.
