This turned out to be a really good-feeling change! Ugly dark corners got cleaned up.
The test file is the kind of thing that would give @rgchris nightmares, because it's very symbol-y by its nature (but it's a test file...avoid writing code targeting humans that looks like this):
ren-c/tests/datatypes/sigil.test.reb at master · metaeducation/ren-c · GitHub
Hopefully the regularity there has a feeling of completeness, to where you won't be calling for the death of any of the contained types.
Speaking of which... note the application of the @[...] block type to tell ALL not to evaluate, just to apply the predicate to the items in the block as-is:
apply :all [
@[$word $tu.p.le $pa/th $[bl o ck] $(gr o up)]
/predicate item -> ['$ = sigil of item]
]
That could be controlled with a refinement, but I think it's nice to carry it on the value. Usually it looks better than that, because it's not used with symbol soup.
You can also do this with INERT, that will put the decoration on the block before it's passed to ALL.
>> inert [a b c]
== @[a b c]
apply :all [
inert [$word $tu.p.le $pa/th $[bl o ck] $(gr o up)]
/predicate item -> ['$ = sigil of item]
]
Yep, one type is better. I made it just be a variant of the ISSUE! cell, so the UTF-8 for the sigil is in the cell directly, and it falls mostly under the handling of anything that could take UTF-8-bearing types before.
You can use sigils, words, etc. in some places you could otherwise use quoted strings, e.g. string parsing:
>> str: "AT&T"
>> parse str [try some [change '& ("-and-") | skip 1]]
>> str
== "AT-and-T"
It's not the biggest benefit, but you do save on the visual noise of three teeny vertical lines (and less importantly, you save on creating a string series node). So I like being able to do it.
parse str [try some [change '& ("-and-") | skip 1]]
parse str [try some [change "&" ("-and-") | skip 1]]
Of course if you are parsing an array, the meanings have to be different.