Prior to modern quasiforms,
~ was a special "BAD-WORD! with no name", e.g. a null spelling:
>> type of '~ == #[datatype! bad-word!] >> as text! '~ ; null
So unlike regular WORD!, it was possible to have a BAD-WORD! that had no UTF-8 representation. (Yes, this was a sign that something was amiss.)
However, I liked having
~ be something that could be reserved by the system, and I thought the "bad-wordness" plus the lack of any associated text made it a good choice for being what we'd call "none"
>> if none? '~ [print "Yup, that's a none"] Yup, that's a none. >> '~ ; console would not show by default >> mold print "So ~ was the result of things like PRINT" So ~ was the result of things like PRINT == "~"
(You can re-read my explanation of why void is a bad return value for things like PRINT or HELP. If you want to communicate to the console that it not print anything, then you need to do that communication through some kind of non-void thing, otherwise that signal is too slippery.)
You could put these BAD-WORD!s in blocks, which made them kind of a lousy choice for the result of a PRINT. So when isotopes came on the scene, it seemed a much better idea to say that none was the isotopic form of something.
So in the first cut of generic isotopes, I said ~ was the quasiform of BLANK! (as opposed to ~_~, which looks pretty bad):
>> quasi _ == ~ >> ~ == ~ ; isotope >> quasi? '~ == ~true~ ; isotope >> none? ~ == ~true~ ; isotope
But... Would It Make More Sense Related to Void?
Initially I was at something of a loss for how void fit into the isotopic world.
One of my early reasonings was that VOID was more "etheric" than NULL. So perhaps void was actually the isotopic form of null, and ~ could be null's quasiform:
>> quasi null == ~ >> ~ ; void
But this was confusing, since if
~ was the meta of void, there really isn't any such thing as a "~ isotope". You could never make one, because I thought it needed to vaporize.
>> 1 + 2 ~ == 3
I was bothered by taking it for this purpose, because I was pretty attached to
~ for representing unset variables. It looked clean, letting you see the things you've set and haven't:
>> f: make frame! :append >> f.dup: 2 >> f.value: "a string" >> f == make frame! [ series: ~ value: "a string" part: ~ dup: 2 line: ~ ]
If ~ represented voids then unset variables would be something like isotopic blanks, and look significantly crappier:
>> f == make frame! [ series: ~_~ value: "a string" part: ~_~ dup: 2 line: ~_~ ]
But it wasn't just in these printouts, also in source. Being able to simply type
(x: ~) to unset a variable and have that be the right way to do it...in an object field or just in code, was just too good.
That made me feel pretty attached to the idea that ~ is the contents of an unset variable, which is not displayed by the terminal, and which is ornery to things like ANY or ALL.