Generic quoting has proven to be pervasive and powerful; and a particularly strong ally in the API for controlling the evaluation of slots. But in the Red Gitter channel there was recently skepticism--which I would call a good example of "groupthink" to be avoided. :-/
The triggering remark was that they were discussing some extremely convoluted and non-generic ways of doing literal branches. So @draegtun offered up Ren-C's solution:
Using QUOTE-ing offers consistency, so no need for variations of IF, EITHER, CASE, etc
>> case [false '[a] true '[b] false '[c]] == [b]
The Redders were rather unappreciative (preferring perhaps to self-congratulate on the "genius" of Rebol2 ALSO--which is both trivial and confuses every piece of code it's used in. ELIDE and invisibles trounce it.)
"blocks are already un-evaluated by default. The non-quoted version would be
paren!. I don't find that kind of "quoting" to be a sane solution, sorry.
The issue is when you are putting something in a slot and you don't know what it's going to be. Maybe it's a WORD!, maybe it's a PATH!, and maybe it's a BLOCK!. Or what if you have a PARSE rule, and you want to match a BLOCK! literally instead of treating something as a rule? And @draegtun has shown you yet another use.
Yet somehow, coming up with alternate names like either* or refinements that have to be put on every control construct is more "sane"? (Uh, nope, sorry!)
Quoting, to prevent evaluation, should be the rare exception, same as lit args. We have blocks, we are unevaluated by default, and funcs that evaluate them because that's the most useful thing to do for those functions .
We don't want to be more Lispy. Lit-word syntax is specific to words, not other values.
What we need to look at are real-world use cases, where you want to prevent evaluation, and compare those.
He brings up looking at real-world use cases. But here they are looking at a real world case and proposing wild workarounds. I don't think it's too much to ask to study the corpus of analysis here (e.g. how to do splicing in the API). And it's worth the time to do that study--I wouldn't be saying it if it weren't important--and I don't see how it's helpful to invoke a tautology like "Lit-word syntax is specific to words, not other values" just because Rebol2 did that.
What about the simple example in Rebol2/Red of obj: make object! [x: first [(1 + 2)]] and then mold obj giving back make object! [x: (1 + 2)]? It's not a perfect example because code that makes a value isn't the same as a literal notation for a single value--but, it does show that wishing to point out spots to protect from evaluation is a common need.
Exactly. Another function for selective evaluation is clearly a simpler option than resorting to new esoteric lexical forms.
Funny to think that a generalized quoting facility is an "esoteric" form. It seems to be pretty regular to me...
(I would argue that there is a bit of a tunnel vision here because he knows how hard it is to make any such changes.)
So I guess... generic quoting (and soft-quoted branches) are a Ren-C exclusive, powering the libRebol API.
Or maybe they'll see the light. Time will tell. :-/