IIRC, Scheme handles nested quasiquoting differently than Common Lisp - expands the unquotes in a different order or some such. I've been meaning to figure out precisely how they differ at some point, but I suspect that merely taking code involving nested quasiquoting from lisp and transplanting it to Arc will not work; Arc code involving quasiquoting translates down fairly directly to Scheme.
Arc doesn't report an error because the second argument to unquote gets tossed out during compilation:
(In case you're unfamiliar with what just happened: ':a at the arc interpreter drops you into scheme, at which point you can access the internals of arc's compiler. (ac code env) compiles the Arc code 'code to scheme, where 'env is a list of locally-bound identifiers in scope.)
This is actually a fairly common "bug" in arc's compiler. The same thing happens with coerce:
arc> (coerce 2 'int (prn "this is ignored"))
this is ignored
2
This is because 'coerce underneath (well, unless you're using my programmable coercion hack, which fixes the above) is just one big function of the form (lambda (x type . args) ...), and unless args is used, it's ignored. args is used, for example, in (coerce "f" 'int 16), in which 16 stands for the base in which "f" is to be read as an integer.
Scheme handles nested quasiquoting differently than Common Lisp - expands the unquotes in a different order or some such.
Well, if we're to believe a single statement in an Alan Bawden paper from 1999: "I am not aware of the existence of a correct optimizing quasiquotation expander for Scheme. (None of the Scheme implementations that I tested implement nested splicing correctly.)" -- http://repository.readscheme.org/ftp/papers/pepm99/bawden.pd...
The entire semantic reasoning is what I'm hung up on: does it seem right that ,,@(...) isn't supposed to work? Not that I'm necessarily advocating one rationale over another, just that I've simply not heard any such rationale. (My Google-fu is upsettingly weak here.)
Arc doesn't report an error because the second argument to unquote gets tossed out during compilation
Ah, duh. Makes sense. I had tried combing through the compiler, but was rather aimless. Thanks.
This is actually a fairly common "bug" in arc's compiler.
I'd probably call it a bug in the case of 'coerce, since the arguments (being passed directly to a Scheme function) all get evaluated -- if the third argument was truly ignored (in the "compiled away" sense), then it shouldn't even do anything. Plus, this behavior also reaches functions like 'outfile and (to an extent) 'writec.
Granted, maybe it's wise to go against "protecting" the programmer and assume that they know what they're doing; maybe I'd happen to want to assign a variable in the same statement as an 'outfile, I don't know.
