There's a cost difference between:
>> data: quote first [a b c]
== 'a
>> data: blockify first [a]
== [a]
Adding a quote level just bumps a number in a byte of a Cell. Whereas making a BLOCK! requires creating a whole Array.
We could conceivably treat QUOTED! as if it were iterable, and the iteration could just give the item minus a quote level:
>> data: quote first [a b c]
== 'a
>> for-each item data [print mold data]
a
This might not be crazy. Cutting an array saves 8 platform pointers (32 bytes on 32-bit platforms and 64 bytes on 64-bit platforms.) It's one less entity for the GC to manage... it improves the locality...
It Would Help UPARSE On Day One
While I'm not sure of all the places that might be able to make use of it, certainly the GLOM operator could use it...
>> accumulator: none
>> result: ...
== 'x
>> glom $accumulator result
== 'x
>> result: ...
== 'y
>> glom $accumulator result
== [x y]
It's definitely a sacrifice of clarity for efficiency. 
But UPARSE needs all the performance help it can get.
Exploiting Ren-C's highly-leverage design is going to be critical to making it perform, and I think this is one of those things worth doing.
2 Likes
So I tried this... BUT there's also code that needs to remove items out of a glommed collection.
MAP-EACH can work, but we're trying to be efficient. 
It's not a huge problem, but it does mean special-casing the quoted item case and not being able to do it with iteration. 
There was a bug in GLOM that I had to revisit, and when I did revisit it... this made me question the optimization. The important optimization was avoiding creating new identities of empty blocks. But once you create an identity for a block holding an element, that's the only identity you need in the average case...regardless of how many elements you add.
So it was "avoiding one Stub allocation" (8 platform pointers) vs. having to run many cycles of interpreter code to branch the path to handle the QUOTED! case. Not worth it--at all.
That aside: I think that considering QUOTED! as a "container" is likely misguided in general. What quoting "means" is more likely to be dialected as some kind of marker. I've begun to think that if anything, single-element SPLICE! is better... in particular because you don't have to do "mental math" to subtract a quote level from "what you're actually talking about" (''2 as a container for '2 isn't as readable as ~['2]~) And yet I'm still not sure if FOR-EACH should even allow that--so quoted is down the rankings a lot.
So I'm now pretty doubtful that things like FOR-EACH should iterate QUOTED! as if it were a "container of one item" as some kind of optimization. Maybe internal code can use the quote byte creatively here or there, but exposing this to user is a false economy--as I say, usermode code can't capitalize on the benefit because every bit of branch code in usermode costs more than the savings could be.