If you can see the usage of the *-WORD! forms, then the *-TUPLE! forms should seem fairly obvious as tagging along on that. Because you can just as easily want to suppress an action from execution if it is a member of an object as if it's in a plain bound variable. Or set it, or get the META of it, or whatever.
GET-WORD!/TUPLE! suppresses action evaluation. GET-BLOCK! reduces, and can even be used as a branch type:
>> if true :[1 + 2 10 + 20]
== [3 30]
>> case [
false [print "skip me"]
true :[1 + 2 10 + 20]
]
== [3 30]
GET-PATH! does partial specialization.
>> append/dup [a b c] [d] 2
== [a b c [d] [d]]
>> apd: :append/dup
== ~#[frame! {apd} [series value dup /part /line]]~ ; anti
>> apd [a b c] [d] 2
== [a b c [d] [d]]
GET-GROUP! has been contemplated as a "reevaluate" as it had been in the parse dialect, so you can do a kind of inline composition instead of DO COMPOSE... though I've hedged on it while thinking about how the pieces fit together.
>> :(second [print b:]) 10
== 10
>> b
== 10
That's pending thinking about whether it's a great idea or not. But it certainly does have uses in dialects.
SET-WORD!/TUPLE! is needed for assignment. SET-BLOCK! is featured in multi-return.
SET-GROUP! sets with the thing that you have in your hand, which is pretty nice:
>> word: in [] 'var
>> (word): 10
== 10
>> var
== 10
It's generic so it retriggers for other SET-XXX! types.
>> block: [b a]
>> (reverse block): pack [1 2]
== 1
>> a
== 1
>> b
== 2
SET-PATH! has legacy application in the evaluator for Redbol emulation since it didn't have tuples that were as general as paths (it only has numeric tuples like 1.2.3). Outside of dialects I'm not entirely sure what it should do otherwise, but that doesn't mean I won't think of something.
I've explained that these do have aggressive use in dialects, although in the main evaluator the biggest leverage comes from just the @ operator itself.
In PARSE it's difficult to imagine how to write some things without the literal matching operator, e.g. you can use @num or @(3 - 2) here... and I don't know what Red suggests you do (and there are larger guiding principles in UPARSE that make it work):
red>> num: 1
red>> parse [1 1 1] [some num]
*** Script Error: PARSE - invalid rule or usage of rule: 1
red>> parse [1 1 1] [some (3 - 2)]
== false
Anyway, they are definitely used.
Used and useful. Note in particular that a META-WORD! or META-TUPLE! is quite distinct from a separate meta operation.
>> ^ 10
== '10
>> x: ~
>> ^ x
** Error: x is not set
>> ^x
== ~
While I've pondered things like "what would META-BLOCK! do in the main evaluator" it has a very clear purpose in PARSE, since blocks execute match results and produce products.
Datatypes and typesets have always been a sticking point in the language, and this stuff is new, so I'm not 100% sure about where it's going yet. I think we may be headed for a situation where the & is used directly with predicate functions, e.g. &integer? instead of &integer, and this will change the shape of things.
But right now, &[...] does a logical or of type operations, while &(...) does logical and.
>> switch/type -10 [
&(odd? negative?) [print "It's odd and negative"]
&[odd? negative?] [print "It's either odd or negative"]
]
It's either odd or negative
I can certainly see uses in dialects for things like HTML entities, Æ and such.
The upcoming $XXX types will have a usage on day 1 for giving bindings to things that can carry bindings, and every last one of them will be in use.
Overall I just disagree with the premise that the existing matrix is wasteful or all that arbitrary. The coverage seems reasonable to me, and there are plenty of problems to sort out with the strategy being how it is.
I try to never say never--many proposals pop up and someday things may get to the point where a weird idea becomes needed. The "SCRUNCH!" proposal is one of the things that nags at me now and then as expanding the expressive space so much that it may turn out to be a good idea after all.
But at the moment, composite sigils address only one small problem in multi-returns that's been on my mind... while they introduce countless usage and implementation questions.
Bear in mind that the things you see here aren't implemented by a magic genie. I have to write some sort of code for them. And even "small" changes have wide-ranging ramifications. Only just today have I been able to lift the limit of 64 datatypes so the full byte in the cell can be used. (I will probably write up why the legacy of the uint64_t TYPESET! implementation ended up being such a difficult design point to overcome.)
Anyway... so if I say I have no clue how to get something to work without wrecking the implementation or having bad impacts on userspace code, that's actually a pretty strong vote against even the biggest hunch one might have (even if it's my hunch).
If you wind up sticking around and hacking on Ren-C instead of developing your own language--and want to pick composite sigils as an area of study--then a fleshed out implementation would certainly be given due consideration. However, there's some combination of I don't know how to do it along with I think the result would wind up being ugly and complicated ... whereas I mostly know where the current path is going and am largely at peace with it.