Hey and thanks for promptly responding to my last query,
a few remarks on the semantics of quasiquoting,
Why support only one pair of quasiquote and unquote?
ie
###########
# in maru
###########
.`,2
=> 2
.`1
=> 1
.``,,1
error: undefined variable: unquote
... unquote
<stdin>:4 (unquote 1)
<stdin>:4 (cons (unquote 1) (quote ()))
<stdin>:4 (cons (quote quasiquote) (cons (unquote 1) (quote ())))
###########
# in common lisp
###########
* `,2
2
* `1
1
* ``,,1
1
* ``,,,1
debugger invoked on a SB-INT:SIMPLE-READER-ERROR in thread
#<THREAD "initial thread" RUNNING {1002998F23}>:
Comma not inside a backquote.
Line: 1, Column: 4, File-Position: 4
Stream: #<SB-IMPL::STRING-INPUT-STREAM {100493CDC3}>
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(SB-INT:SIMPLE-READER-ERROR
#<SB-IMPL::STRING-INPUT-STREAM {100493CDC3}>
"Comma not inside a backquote.")
Not that the common lisp way is inherently better, just curious as to why
the quasiquote is the way it is.
We can see in the quasiquote function that it effectively recurses on the
car of the list if it too is a list and once we find 'unquote we just
return the cdr. There is also no further accounting of nested quasiquote
symbols.
My second question is with respect to unquote splicing. Particularly, this
case.
###########
# in maru
###########
.`(,@3)
=> 3
.`,@3
=> (unquote-splicing 3)
.`,@(3)
=> (unquote-splicing (3))
common lisp errors on all three.
Are these semantics arbitrary because unquote-splicing doesn't make sense
for an atom?
High level design intent of maru's quasiquote would also be interesting.
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
