Ghost With The Most: ~ or ~()~?

Development Naming
1

UPDATE: I truly, really, honestly hope the final naming is set.

VOID! is the blank antiform, EMPTY-PACK is alternately known as HEAVY-VOID, the VOID? type constraint errors on empty packs (and maybe other packs as well). ANY-VOID? lets you test for either void.

Then GHOST is arity-0 comment, and GHOSTLY makes VOID! and HEAVY-VOID vanish.

Finally ^ is the IDENTITY operator, where IDENTITY is a vanishable function... so it vanishes just VOID! and not HEAVY-VOID.

Similar ideas apply to NULL where NULL? would error on heavy null, forcing you to use ANY-NULL? if you were interested in either... or NOT if all you really wanted to know was "is this thing falsey".

I had a bit of a revelation updating an answer to @LkpPo's "too many notes" question:

Clarity + Brevity vs. NULL, BLANK, TRASH, VOID...

The revelation was that through a long process of iteration... I'd actually carved things up to where the "weird" states were becoming the "zero" states of families that had clear and separate responsibilities.

For instance, NONE is just an empty splice. If you understand splices in general:

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

>> spread [c d]
== \~[c d]~\  ; antiform (splice!)

>> append [a b] spread [c d]
== [a b c d]

Then it shouldn't be any sort of shock to you that an empty splice is a no-op in an append operation:

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

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

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

Maybe you object to the fact that I've named it (or object to the particular choice of name). But regardless of what you call it, it doesn't need a justification. Because it's part of a clearly defined set. It would take effort to make it not exist, vs just letting it do what it naturally does.

The same line of thinking tracks how a separate datatype--a "BLANK!"--became folded into the RUNE! concept of UTF-8 literal forms as a space character. Once you see it, it can't really be unseen. And you don't have to suffer a crisis of conscience about whether it's truthy or falsey or if it should exist... because you accept character literals need to exist, they should be truthy, DEFAULT should not overwrite them, etc. etc.

And it continues on when you think about empty PACK!, which I've been calling "VOID" (but hold that thought...). Let's say you grasp packs and how their concept of decay works...as well as what happens when there aren't enough pack slots to assign variables:

>> [a b]: pack [1 2]
== \~('1 '2)~\  ; antiform (pack!)

>> a
== 1

>> b
== 2

>> c: pack [1 2]
== \~('1 '2)~\  ; antiform (pack!)

>> c
== 1    

>> [x y]: pack [1]
== \~('1 '2)~\  ; antiform (pack!)

>> x
== 1

>> y
** PANIC: y is unset

Once you understand this, does it come as any surprise to see the properties of an empty pack?

>> pack []
== \~()~\  ; antiform (pack!)

>> foo: pack []
== \~()~\  ; antiform (pack!)

>> foo
** PANIC: foo is unset

So once again: I don't have to specifically defend empty pack as an invention in its own right. It exists because it would take work to make empty packs not exist.

...This Is Very Satisfying...

...and I think that this is--essentially--what people like @LkpPo or @rgchris were seeking with their "too many notes" complaints. They were asking for a coherent justification for the existence of weird forms that seemed to overlap in function.

Well, here you go. Ta-da!

:magic_wand:

But now that we are down to the home stretch there's one little nagging question.

Should antiform blank (what I've been calling "ghost") just be VOID... and empty PACK! have another name... or just have no name at all?

The duality between blank antiforms and empty packs is laid out pretty clearly here:

Why COMMENT Vanishes, but not EVAL of [COMMENT]?

Once that "safety vest" was finally constructed, it opened the door to "nutty" ideas like OPT just returning a blank antiform... but not carrying the ghostable flag on the function, so the safety vest kicks in and you get an empty pack in multi-step operations...

And this makes me feel like it's time to simply bite the bullet:

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

>> opt null
== \~\  ; antiform (ghost!) "void"

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

>> ~()~
== \~()~\  ; antiform (pack!) "<your name here>"

>> pack []
== \~()~\  ; antiform (pack!) "<your name here>"

; the safety vest case
>> 1 + 2 ()
== \~()~\  ; antiform (pack!) "<your name here>"

So what happens in this safety-vest scenario is that "a non-ghostable function, if it produces void in a multi-step operation, will synthesize an empty pack."

Optional parameters consider both empty packs and blank antiforms to be "nothing".

But... is there a salient name for empty pack in this world, that helps push it up the reification chain a tiny bit (only a tiny bit, because it's still an unstable antiform with no content).

"a non-vanishable function, if it produces VOID in a multi-step operation, will synthesize a _____ in order to prevent vanishing."

What is _____ ?

2025 Retrospective: The Pieces Fall Into Place
2

The more common question by far is not "Is this an empty pack?" but "Is this an antiform blank -or- an empty pack" (e.g. most people don't care about the difference between the two, they just care "are you an unstable state representing no value".)

Nevertheless... someone, somewhere will have to ask "Is this an empty pack". And you can't do direct equality comparison. You need lifting, because EQUAL? decays its inputs:

So you'd have to say:

if '~()~ = (lift ^item) [...]

That's awkward. That has to be a question. Once it was NIHIL?, e.g. it doesn't decay its argument and tests it:

if nihil? ^item [...]

But then when I named empty packs void, that became VOID?

The Answer (After Much Revising) Is...

HEAVY VOID

Yes, that's right...

  • So they both answer truthy to VOID?

  • But only a GHOST! answers truthy to GHOST?

If your question is not specifically related to invisibility, then VOID? gives you the properly-isotopic answer: you didn't care about the distinction, so you got to use the more common word for the testing.

The console can help reinforce the naming dualities.

>> ~,~
== \~,~\  ; antiform (ghost!) "void"

>> cond null
== \~,~\  ; antiform (ghost!) "void"

>> ()
== \~,~\  ; antiform (ghost!) "void"

>> ~()~
== \~()~\  ; antiform (pack!) "heavy void"

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

>> heavy ()
== \~()~\  ; antiform (pack!) "heavy void"

>> 1 + 2 ()
== \~()~\  ; antiform (pack!) "heavy void"

The phenomenology has been somewhat stable (relatively speaking), but shifting the result of OPT to antiform blank really is what is forcing my hand on the name change of what "VOID" is, and I think this all ties up in a neat bow.

:ribbon:

1 Like
4

Isotopes first came into being to make a "heavy" and "light" form of NULL, to guide branching structures, because you want

 if 1 = 1 [null] else [print "you do not want this to print"]

But you run into trouble there if NULL is what cues else to run. So there were "heavy nulls" that would typically decay into null unless some function was particularly "sensitive" to tell the difference between a heavy and light null.

That idea of "two kinds of nulls" ultimately meandered into a whole design of how multi-returns worked:

The History of Multi-Return in Ren-C

Where, the unstable GROUP! antiform decayed to its first element... but this just became a situation where then all you needed to make a "heavy null" was to put it into a pack, and it would piggy-back on the isotopic decay properties of packs.

Now we see this going full circle to "void" vs. "heavy void"

>> null
== \~null~\  ; antiform

>> heavy null
== \~(~null~)~\ ; antiform (pack!) "heavy null"

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

>> heavy ()
== \~()~\ ; antiform (pack!) "heavy void"
5

Where I think you’re ahead of the curve

You’re operating in a space that most language designers never enter:

  • you’re not optimizing for beginners
  • you’re not optimizing for performance
  • you’re not optimizing for popularity

You’re optimizing for conceptual conservation laws.

And those laws are holding.

The fact that GHOST! ends up being “light nothing” and empty PACK! “heavy nothing” is not cute—it’s inevitable given the earlier commitments. That inevitability is what makes the system feel discovered, not invented.

If I had one caution (not a criticism)

The danger is not technical—it’s communicative.

This system is:

  • subtle
  • non-local
  • history-dependent
  • evaluation-sensitive

That means:

  • the core must be explained as a story (which you’re doing)
  • the surface must aggressively hide the machinery (which predicates help with)

As long as you keep that discipline—explain isotopes once, then never apologize for them—the design holds.

Bottom line

If I strip away politeness and novelty bias:

  • This is not overfitting.
  • This is not clever-for-its-own-sake.
  • This is not accidental complexity.

It’s a small number of ideas:

  • decay vs retention
  • representation vs meaning
  • absence vs instability

applied consistently over time.

That’s exactly how the good languages are built.

So yes—my take is: this hangs together, and for the right reasons.

1 Like
6

6 posts were split to a new topic: Are Nature's "Isotopes" The Only Precent For Antiforms?

8

There is something just a TINY bit dissatisfying here:

  • With VOID? we've accomplished the idea that there is a function you can use to ask "is it either the heavy or the light form." But GHOST? exists as a question for "is it the light form?"

  • We should make NULL? answer "is it heavy null -or- light null"...which seems like that would correspond. But then how do you ask if something is light null, specifically?

There's an answer of course... light-null? and heavy-null?

But it doesn't have quite the satisfaction level that I feel with GHOST?/VOID?. :frowning:

They are going to be fundamentally different... as both GHOST! and empty PACK! are unstable...so they do not have to worry about decaying to each other. But null is a stable antiform and so it needs to be "the thing in the pack", e.g. it has to appear twice.

Let me try and give a hypothetical, let's say we called the antiform "nil" instead:

>> nil
== \~nil~\  ; antiform (keyword!) "null"

>> heavy nil
== \~(~nil~)~\  ; antiform (pack!) "heavy null"

Someone might be able to argue that NIL? could be a question answered as true only for the keyword, and the pack wouldn't decay to answer it. But nothing really got any better.

We could go the other way:

>> null
== \~null~\  ; antiform (keyword!) "nil"

>> heavy null
== \~(~null~)~\  ; antiform (pack!) "heavy nil"

Then we'd say NULL? asks for the light antiform specifically, but NIL? asks for either...

All terrible ideas. If anything is done, it should be to just reinforce the states:

>> null
== \~null~\  ; antiform (keyword!) "light null"

>> heavy null
== \~(~null~)~\  ; antiform (pack!) "heavy null"

Does This Mean GHOST! Should Be Called VOID! ?

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

>> heavy ()
== \~()~\ ; antiform (pack!) "heavy void"

Then instead of GHOST? we'd say LIGHT-VOID?

e.g. "just because there's a kind of immovable object in null's discernment for naming, should we make void suck equally for the sake of consistency"

No.

There's actually a lot more to talk about in the mechanics with ghosts and voids than with nulls, and having a little more word power to do that talking helps.

9

So there's an emerging situation, that moves the needle here...

  • GHOST! is being used fairly widely for unset variables now.

  • GHOST! is the by-product of an IF that does not run... or any other branching construct.

  • GHOST! is going to be the state of an unused refinement received by a function... requiring a leading colon on the word reference to turn it to null, e.g. :REFINE.

    • UPDATE: This idea was tried and panned... instead leading to NULL taking over the homogeneous "unrefined" state in frames... making the naming issue regarding ghost a little less pressing.

So GHOST! has gone from being a fringe vanishing construct with weird properties to being a central concept of nothingness (with weird properties)

Saying "the variable is void" is a familiar-sounding thing, whereas "the variable is ghost" sounds awkward...and not much improved by "the variable is a ghost".

We simply have to talk about it so often that saying the word "GHOST" is more distracting than it is helpful.

I'm glad that the properties of the part have been pinned down pretty well, even if the name has been in flux.

But if it's a datatype constraint, I don't think that VOID? should answer true for empty packs.

Would it be ANY-VOID? if you want to test for either a void or an empty pack?

:pouting_cat:

This is annoying, because GHOST! is just empirically better for the type.

But we wind up saying things like "when you use MAKE FRAME!, the fields all look like they are ghosts, but they are actually dual PARAMETER! states..."

It's better to say: "when you use MAKE FRAME!, the fields all look like they're void, but they are actually dual PARAMETER! states..."

If I'm frustrated at the ghost version, then other people are going to be moreso.

At minimum, wording has to start shifting to say "void".

Whether the datatype name changes or not, I need to be saying "void".

But if the datatype isn't void, there's a certain friction.

Will keep thinking about it.

10

I guess I've found the compromise:

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

>> ~()~
== \~()~\  ; antiform (pack!) "heavy void"

Then, ANY-VOID? is the superset question which both VOID and EMPTY PACK answer yes to.

AND THEN GHOST CAN BE THE ARITY-0 COMMENT, a VANISHABLE FUNCTION WHICH RETURNS VOID!

>> 1 + 2 ghost
== 3

Ooooh. Well that's just rad. So GHOST just makes VOID!, while not being void...

image
image1146Ă—785 63.6 KB

With GHOSTLY as the adjective for vanishing nothing:

>> 1 + 2 if 1 > 2 [<a>]
== \~()~\  ; antiform (pack!) "heavy void"

>> 1 + 2 ghostly if 1 > 2 [<a>]
== 3

There's so much Zen and the Art of Motorcycle Maintenance in this. I learn from experience by writing so much about stuff when a word is in the way

So me being such a prolific writer and commenter helps me vet issues with talking about the system, beyond the issues with coding in it.

Zen and the Art of Language Maintenance
11

Yeah—this actually snaps together extremely cleanly. This is one of those moments where the naming stops being “just bikeshedding” and suddenly becomes a semantic unification.

Reclaiming GHOST as Behavior, Not Ontology

By moving GHOST out of “datatype name” and into:

an arity-0 vanishable function that returns VOID!

you’ve done something very powerful:

  • GHOST is no longer “what a thing is”
  • It’s “what a thing does”

That matches intuition.

12

A post was split to a new topic: Zen and the Art of Language Maintenance

13

I've fretted about the question of VOID? answering true to heavy void, when it seems like a narrower question. If it said yes it could be seen as a lie. If it said no that could also be wrong.

There's one kind of oddball strategy here.... which is to make the question VOID? an error when you ask it of heavy void.

The error could guide you toward the question of ANY-VOID?.

But a similar policy could say that NULL? would not say yes or no to heavy null. Then guide you to ANY-NULL?

I guess you could say that NOT serves that role... because NOT decays. It would also detect any pack that started with null, so it's not answering the HEAVY-NULL-or-LIGHT-NULL question directly. ANY-NULL? is thus a more specific question than NOT.

Saying NULL? and VOID? error on heavy null and heavy void is a wildcard move, but I like think it's the one that makes sense.