Mitigating Drift of Underscore Meanings in R3C

[hostilefork]

@rgchris

For me (using the family name) Rebol's first obligation is to represent data—both in language and the way the language is interpreted in memory. Specifically BLANK! and its underscore literal is a huge win (this is from me, the ultra-conservative sceptic) in representing positive nothingness—that a thing exists but lacks assignation: [name: "Thing" link: _]. Despite that positivity, I do think that as it represents the known absence of a value in data, it should be falsey in the general flow that data primarily should determine that flow.

I am adamant that RUNE! is the right choice for "blanks" and that falsey was always the wrong choice for a reified in-block non-antiform value.

@hostilefork

_ is No Longer BLANK!, It's A Lexical SPACE Character

>> form _
== " "

>> rune? _
== \~okay~\  ; antiform

>> tab: ____

>> rune? tab
== \~okay~\  ; antiform

>> form tab
== "    "

But I've made another change, and hopefully @rgchris will like it... to go back to using the name "blank" for space runes... there's just more of them now!

Any RUNE! which is all space characters answers truthy to the question BLANK? Everything else answers with null, so it makes blank kind of like a datatype...

>> blank? _
== \~okay~\  ; antiform

>> blank? #a
== \~null~\  ; antiform

>> blank? ____
== \~okay~\  ; antiform

>> blank? [a b c]
== \~null~\  ; antiform

This means that you can point at an underscore and say "that's a blank" and be telling the truth, as you would be if you said "that's a space". Either term can apply.

Much Better Than Empty SPLICE! Being "Blank"

When underscore became SPACE and the name BLANK "became available", I tried using it for empty splices.

That was unpleasant and confusing. I kept mixing it up, and kept wanting to call underscores blanks. Correcting myself got tiresome, so I decided it was better to call empty splice a "hole".

There's lots of ways to make empty splices:

>> spread []
== \~()~\  ; antiform (splice!) "none"

>> first [~[]~]
== ~[]~   ; <-- not a none, but a "lifted" none (quasiform block!)

>> eval [~[]~]
== \~[]~\  ; antiform (splice!) "none"

>> ~[]~
== \~[]~\  ; antiform (splice!) "none"

But it's nice to have a WORD! for it:

>> none
== \~[]~\  ; antiform (splice!) "none"

>> append [a b c] none
== [a b c]

>> append "abc" none
== "abc"

>> append #{AABBCC} none
== #{AABBCC}

Fewer Fundamentals, But: More Parts, More Power

If you accept that a language needs to have a representation for a space character literal, then you won't begrudge us the "too many notes" aspect of having "blank".

And this speaks also to some @rgchris criticisms:

@rgchris

I have this sense that the BLANK-NULL-VOID-ERROR story has too many actors with overlapping roles. I don't have anything tangible to back that up with at this time.

The roles are just about fully crystallized, and the decisions of when-to-use-what flow automatically.

While I admit that it's been an imperfect journey, I think I've been on a clearly evolving path, which has had the right goals as the design has moved through the necessary decisions and inventions. (The shuffling of words has been a necessary part of that journey, albeit I'm sure it hasn't helped anyone trying to grasp it. I've tried to retcon the forum posts to make the actual steps of the invention process possible to follow.)

In updating a response to a question from @LkpPo with similar criticisms, I see how really strong the choices are:

Clarity + Brevity vs. NULL, BLANK, TRASH, VOID... - #3 by hostilefork

...but also strangely how things are starting to point very much at a pointed "NULL and VOID" duality as the real fundamental parts of "nothing"...with things like empty splices and empty packs or trash serving their well-defined roles.

...bringing it in line kind of with historical NONE! and UNSET!, just in a very futuristic isotopic way!