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