Er, I'll assume you're talking about the fact that Kernel omits quote from the core language, and instead leaves it up to programmers to implement their own nonstandard quote if they need it.
($define $q
($vau (result) env
result))
Even so, I'm not sure what having quote has to do with anything. Your examples don't use quote except to get first-class access to symbols, which you could already get access to as the unevaluated arguments of an fexpr call.
---
"so it can't use apply with operatives, and so its fexprs are less powerful."
I can understand if you've got the @ syntax on your mind and you'd like to squeeze a lot of value out of it, the way Arc squeezes so much out of putting things in functional position. However, whatever power you get here, I don't think it makes up for the ways you undermine your language, as I describe in my other comment.
As we continue to discuss this, it might help if we look at things in terms of John Shutt's own thorough definitions of expressive and abstractive power (http://lambda-the-ultimate.org/node/4345#comment-66918). A formal theory can't tell us how to formalize the informal things we care about, but if we do manage to use it well, we can skip ahead to more profound conclusions. This theory in particular has gotta be extremely relevant to Kernel, since it's by the same person. :-p
I haven't looked at your link yet, but I want to clarify my comment first so that we can attack it together after I'm updated. ^_^
My solution relies on unquote and therefore on backquote. I don't recall Kernel mentioning them; scheme seems to ignore them in general. But let's assume that they are implementable just like quote. When I say "quote" I mean this holy trinity :)
I know Kernel doesn't prevent quote, but it discourages it. Even if you got apply working with backquoted macros in Kernel, it wouldn't be very helpful if most macros were backquote-less as a matter of course. This seems like a limitation of the philosophy.
More strongly, I want to argue that having syntax for quote/backquote/unquote is valuable. In wart all symbols are overrideable[1]. It uses punctuation for quote/backquote/unquote/splice to highlight that they are different from symbols, more fundamental to the programming model. Supporting apply for macros has made them even more so, even more fundamentally entangled together and baked into the interpreter.
[1] The one exception is fn. Perhaps I should make it λ? Nah, that doesn't solve the problem. Hmm, the only punctuation character wart hasn't already put to use is #.. :D
"My solution relies on unquote and therefore on backquote."
Oh, right.
---
"More strongly, I want to argue that having syntax for quote/backquote/unquote is valuable."
I don't think that's as expressive as infix syntax. With the right kind of a.b syntax, we could write `(a b ,c) as qq.(a b uq.c), trading in some readability for the flexibility to define our own variants.[1] Would you still want to have dedicated quasiquotation syntax then?
(Even I might answer yes sometimes. The staged fexpr system I describe at http://arclanguage.org/item?id=15868 uses unquote syntax as a way to compute during a previous stage of the command processor.)
[1] Penknife does something like this, but the use of structured string manipulation instead of s-expressions forces it to use a string-like escaping mechanism for unquote: qq.[a b \,c]
