Three Single-Character Intents... x:_, x: ', and x: ~

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]
 ]

Classically, 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, and it's even "truthy"!

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.

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
2 Likes