A proliferation of $#@^':~WORD~:s

[bradrn]

@hostilefork

Someday there might be a way to go after things like you're talking about. Maybe there's a dialected pattern for testing for the sigils, like if {::}.word.? item [...] or if {$}.path.{^}.? item [...] which could help avoiding the need to specifically name ::word or $pa/th^. And maybe it would be an improvement, not a detriment to the experience of solving problems with the tool.

But I'm a skeptic, and that's not really what I'm looking for in terms of the look and feel of this particular artifact. I don't actually like it having as many parts as it does, but I'm tempering that by trying to make the parts as uniform and pleasing as I can.

Putting it this way, it sounds reasonable. It’s fair to say my proposal was too flexible, in that it allowed a huge range of options, few of which were really useful while nonetheless making the whole language more difficult.

However, that being said…

@hostilefork

I favor a small set of sigils following a pattern that can build upon the robustness of the parts they modify.

I feel this sentiment is belied by the actual state of the language. To see why, let’s review the current sigiled types (excluding ones like ISSUE! which can be considered their own thing):

• Initial : is used in GET-WORD!, GET-BLOCK!, GET-GROUP!, GET-TUPLE!, GET-PATH!
• Final : is used in SET-WORD!, SET-BLOCK!, SET-GROUP!, SET-TUPLE!, SET-PATH!
• Initial @ is used in THE-WORD!, THE-BLOCK!, THE-GROUP! THE-PATH!, THE-TUPLE!
• Initial ^ is used in META-WORD!, META-BLOCK!, META-GROUP!, META-PATH!, META-TUPLE!, META-WORD!
• Initial & is used in TYPE-WORD!, TYPE-BLOCK!, TYPE-GROUP!, TYPE-PATH!, TYPE-TUPLE!, TYPE-WORD!

I would find it difficult to describe this situation as ‘robust’. Most of these types are almost entirely useless: only the *-WORD! variants see really wide use. GET-BLOCK!s are used for multi-returns, and COMPOSE gets some use out of the various *-GROUP!s, but other than that, it isn’t completely clear why anyone would use them.

Of course, the reason they’re present is obvious: they’re following a pattern! But that immediately raises more questions:

• Why this specific set of base types, and no others? I see no obvious reason why types like WORD! and PATH! should be able to take sigils, but types like ISSUE! and FILE! can’t. (Or, for that matter, why THE-WORD! can’t either.)
• Why is this pattern not formalised within the language? Sure, there’s a few predicates (like ANY-META-VALUE? or ANY-PATH?), but by and large, Ren-C barely seems to make use of the fact that it has this consistent pattern.

Essentially, this feels to me like a few components which were found to work well for specific usecases, but were generalised in a way which doesn’t fully cohere when you look at it closely. In that regard it reminds me of binding, another part of the language which worked well in places but was hard to reason about in its full generality. And, even if sigils are less significant than binding, this still gives me a similar feeling of discomfort.