Why is VOID! the ~ Antiform, and not ~void~ ?

[rebolbot]

>> 1 + 2 elide print "VOID! is useful..."
VOID! is useful
== 3

VOID! is useful.

But it's very slight in the console:

>> elide print "VOID! is useful..."
VOID! is useful...
== \~\  ; antiform (void!)

Why is it ~ (a "BLANK! antiform") when antiforms like NULL are just antiforms of WORD!?

>> try pick [a b] 3
== \~null~\  ; antiform (logic!)

Wouldn't it be more literate if it were just the antiform of ~void~ ?

>> elide print "VOID! is useful..."
VOID! is useful...
== \~void~\  ; antiform (void!)

[hostilefork]

@rebolbot

Wouldn't it be more literate if it were just the antiform of ~void~ ?

Consider Not Just VOID, but HEAVY VOID

The story of "nothingness" and VOID has a a bigger picture. So the real contrast you need to consider is:

>> ()
== \~\  ; antiform (void!)

>> if <truthy> []
== \~()~\  ; antiform (pack!) "heavy void"

...compared to the WORD!-antiform version:

>> ()
== \~void~\  ; antiform (void!)

>> if <truthy> []
== \~()~\  ; antiform (pack!) "heavy void"

Your WORD! suggestion makes it seems like the "heavy" void is "lighter" than the light void.

So you might thus suggest heavy void changing also... to mirror heavy null by actually containing a void antiform, instead of being empty:

>> ()
== \~void~\  ; antiform (void!)

>> if <truthy> []
== \~(~void~)~\  ; antiform (pack!) "heavy void"

Okay, but...

• that isn't looking much like "emptiness" any more, plus...
• empty packs would still exist.

What do you expect the behavior of empty packs to be, if not what we would ascribe to heavy void?

Using Antiform BLANK! ~ Makes Sense

@rebolbot

Why is it ~ (a "BLANK! antiform")

WORD! Antiforms Are Stable, Not Unstable

It's true that VOID! isn't like some antiforms that really need to be related to their basis types (a SPLICE! has to be the antiform of some kind of list, for instance). There's nothing mechanically important about building on the payload of a BLANK! Cell...because a BLANK! Cell has no payload.

But VOID! is an unstable antiform (e.g. it can't be fetched via plain WORD! access). WORD! antiforms like ~null~ and ~okay~ are stable antiforms.

Right now, it's the "heart byte" of the Cell that determines its type, and dictates stability and instability. WORD! antiforms are all stable, and BLANK! antiforms (of which there's one and only one) are unstable.

(See The Table Of Antiforms In Use)

Could Some WORD! Antiforms Be Stable, Others Not?

I guess anything's possible.

Though without tricks, voids would take slightly longer to identify. Right now they can be recognized by comparing the masked header uintptr_t to a hardcoded constant--a combined mask of the antiform quote byte and comma heart byte. Since every evaluator step has to check if it produces a void, being able to do that test quickly vs. needing to check both the header and a symbol has some performance benefit. (Although there could probably be a bit in the header reserved for "I am a void" as there is already for "I am a null" to do fast tests.)

A random aspect that would be lost would be that there'd be less space in the VOID! Cell due to storing a Symbol and binding, which it would never use. That space isn't used right now for anything, but it could be (file/line number where the void was generated?)

~ Is The Better Answer

• When you consider that HEAVY VOID has to be the ~()~ antiform, I think ~ fares much better as the lighter form than ~void~

• I don't have good feelings about making some WORD! antiforms stable, and others not.

• Labeling the antiforms in the console mitigates the impact of the "weirdness" somewhat.