So it's nice in a row of initializations to be able to kind of gloss over the "empty bits" and see the data.
foo: make object! [
bar: '
baz: '
mumble: "a string"
frotz: '
]
Compare that with if you had to say:
foo: make object! [
bar: null
baz: null
mumble: "a string"
frotz: null
]
If instead of NULL what you wanted to assign was BLANK!, you can do this with a single character also:
foo: make object! [
bar: _
baz: _
mumble: "a string"
frotz: _
]
I've explained in the modern theory of BLANK! vs. NULL vs. BAD-WORD! why which you would choose makes a difference. And once again, this would be a bit visibly more shoddy if you had to write it out:
foo: make object! [
bar: blank
baz: blank
mumble: "a string"
frotz: blank
]
So it's nice that if you have these different intents for how to treat "empty" things, you can pick a clean way to write them that doesn't cloud up the non-empty things surrounding them.
But with NULL and BLANK! having this coverage, doesn't it seem unfortunate to have to write out the BAD-WORD! intent?
foo: make object! [
bar: ~unset~
baz: ~unset~
mumble: "a string"
frotz: ~unset~
]
Isn't a shorthand warranted here?
foo: make object! [
bar: ~
baz: ~
mumble: "a string"
frotz: ~
]
Here's the case where you are saying it's empty and you want accessing the field to cause an error. On a scale of 1 to 3 of "meanness":
-
BLANK! is the friendliest (opts out of many operations and makes them return null)
-
NULL is a little less friendly (doesn't cause an error on reference/testing but will cause errors on things like APPEND)
-
An isotopic BAD-WORD! that has gone through an evaluation step--as above--is the meanest (will error just on referring to the value)
The Landscape Has Changed
One reason that I thought it was a bad idea to make ~ a "bad word with NULL spelling" was that it would mess with paths like:
for-each item first [~/some/dir] [
print ["Item is" item]
]
Allowing such mean BAD-WORD!s to be in PATH!s seemed awkward. You'd be getting errors on something that looked like it should be friendly.
BUT now that's a non-isotope form of a BAD-WORD!. You can deal with it like any other value when you come across it literally, it's just not truthy or falsey.
This seems to shift the balance to saying that having a light way of saying "this field will error if there's a problem has value"
I don't know that this means it should take the role of ~unset~. ~unset~ seems more explanatory of the state of unsetness for a variable, and is a bit more visible.
But once they become isotopes BAD-WORD!s are kind of bending the rules. While normal BAD-WORD!s are not true or false, the isotope of ~null~ is falsey. There are various squirrelly behaviors that you get into once you start working with isotopes.
So...what if:
>> ~
== ~unset~ ; isotope
e.g. the normal BAD-WORD! of ~ will turn into the isotope of ~unset~ when you evaluate it?
Or maybe it's left open. Maybe ~ remains a plain WORD!, that runs a function, that gives back the unset isotope? That leaves it more open.
Regardless of how it happens, I think I like that behavior:
>> ~
== ~unset~ ; isotope