I'm looking at putting some gaps in the type table, and at first I was going to write something along the lines of this, with BLANK?:
blank 1
integer 2
decimal 3
_ 4
_ 5
any-series 6
any-unit 7
Then I stopped and thought "well, wait, might TRASH? be better?"
blank 1
integer 2
decimal 3
~ 4
~ 5
any-series 6
any-unit 7
Of course you have a lot of single-character choices, if single-characterness is important. # is the space character. And single-characterness isn't in and of itself all that big a deal.
What's The Difference?
There's a key difference: if you want something in that slot that's going to signal a misunderstanding, trash will get the you there faster.
Nominally what's expected in that slot is a WORD! And there are various things you can do with a blank, like convert it TO a TEXT!...
>> to text! _
== ""
Whereas trash doesn't do that. It's a quasiform, so like quoted values and antiforms it is not considered "fundamental":
>> to text! first [~]
** Script Error: to expects [~void~ fundamental?] for its element argument
So really, you will get errors on any quasiform you use. There's lots of options:
blank 1
integer 2
decimal 3
~nope~ 4
~[nuh-uh]~ 5
any-series 6
any-unit 7
But when I look at this, it suddenly presents a pretty strong justification for quasiform integers:
blank 1
integer 2
decimal 3
~4~
~5~
any-series 6
any-unit 7
Though maybe one should be happy enough with meta-tripwire, quasi-tag:
blank 1
integer 2
decimal 3
~<4>~
~<5>~
any-series 6
any-unit 7
Or if you think GROUP! looks better, which it kind of does:
blank 1
integer 2
decimal 3
~(4)~
~(5)~
any-series 6
any-unit 7
This is where you see the value of the "useless" reversible TO scheme that I've been trying to drill in:
>> to integer! unquasi first [~(4)~]
== 4
Comprende?
Anyway, Back To The Main Point...
The main point is that by exploring these little choices we can see that you don't just make the choice based on how things look. Pushing values into the quasi or quoted band gives you a useful orneryness.
It's far too easy to get in situations where you don't know if what you have is a word or a string, and you check to see if they're equal and the code goes merrily along.
In fact... I sort of wonder if the difference between = and == should not be strictness per se, but that == will raise an error if the types you're comparing aren't identical. Then you can TRY it to suppress the error, and get null, which is the result from inequality:
>> "a" = <a>
== ~null~ ; anti
>> "a" == <a>
** Error: == requires compared types be the same, or use TRY
>> try "a" == <a>
== ~null~ ; anti
But what I started wondering was, is it useful to have an answer to the length of a WORD!? Just because we can, should we, or does that risk more downstream misunderstanding when you typically don't want to take the length of a word, and can alias it as text if you need to?
>> length of 'abc
== 3 ; we CAN, but should we?
I'd made it possible to do that, but I don't think that's a good idea. Instead:
>> length of as text! 'abc
== 3 ; if you need to do it, you can