Init_Null(cell) vs. Init_Nulled(cell)

hostilefork · January 28, 2026, 2:10pm

There are two distinct concepts of NULL one has to deal with when reading the sources for the interpreter.

One is the C concept of the NULL pointer, and this is a single platform-sized pointer which holds zero.

(Pedantically: it's not actually the case that the underlying platform has to use 0 to represent null pointers... it's just that at the level of the C language, you experience it as 0 when it's converted back and forth to integers. Practically speaking any platform we compile to uses 0 for the bits.)

The other is the concept of a NULLED CELL. Cells are 4 platform pointers in size. A Nulled Cell is actually a WORD! cell, with a LIFT_BYTE saying it's an antiform. Hence it reports as a LOGIC! instead of as a WORD!.

Implementation Dilemma: What Meaning Is The Default?

There are functions like Init_Word(...) or Init_Block(...) etc, which initialize Cells.

It would be annoying if you had to write Init_Word_Cell(...), so I don't do that.

Similarly, Is_Word(...) and Is_Block(...) have quick and to-the-point names due to the common usage. I don't like the idea of that getting any more verbose.

But when you say Init_Null(...) there's a bit of a risk that a C developer reading the sources would go "oh, that's setting something to the nullptr."

And if you say Is_Null(p) some people might think that meant (p == 0)

So I've done something that's a bit of a tax in the source, which is to write it as "NULLED"

Is_Nulled(...)

Init_Nulled(...)

But it makes me sad when I read it.

So sad that I drop the "-ED" when routines are named in a way that makes it clear it can't be a null pointer, e.g. Init_Lifted_Null(...)

This becomes a mental tax to decide when to say Null and when not.

I Actually Use `nullptr`, not C's NULL.

In C, NULL can be (and sometimes is) just #define NULL 0

C++ introduced nullptr as something more complex that you can characterize as definitely a pointer.

I use a definition #define nullptr ((void*)0) if compiling as C.

So Could I Just Say Nullptr if I Mean C NULL?

This would mean that if a routine was dealing in null pointers, it would say something like Set_X_To_Nullptr(p) as opposed to Set_X_To_Null(p)

Note: In The API, There Are No Nulled Cells

Something clever about the API is that nulled cells are always experienced as the host language's null concept.

So there isn't a rebIsNull(...) API or anything of the sort.

That means this issue is solely an internal implementation detail of the interpreter.

Should I do: `Is_Nulled(...)` => `Is_Null(...)`

I've come very close to doing it many times.

Something stops me when I think about people reading the interpreter sources--which are written in C...and being confused.

But really, folks... does Is_Nulled() really providing any clarity? Where it gets the benefit is that it's weird, and that weirdness would make you think "I don't see why someone would call that function to test a pointer for null, maybe I should look at that"

Yet no one would call a function in C to test for a null pointer in the first place. Is the fact that you're calling a function enough in and of itself to say "that's probably doing something"?

The source would read better without this "-ED" leaking around places.

I feel like I should just get rid of it.

The Tyranny of Text Files...

Of course it's insane that we are not using UUIDs to identify this stuff in a graph.

Then it could have as many names as you want. Push a button and render it in Japanese.

But... well, welcome to my world of trying to convince people about things that are right... and it not happening as quickly as it should...

rebolbot · January 30, 2026, 9:04am

It sounds like you’ve reached the "Expert’s Breaking Point." When the safety rails start feeling more like a recurring fine for doing your job correctly, it’s usually time to pull them up.

I'd lean toward dropping the "-ED" for a few reasons:

Function calls are self-documenting - As you note, nobody calls a function to test for C null pointers (if (p == nullptr) is idiomatic). So Is_Null(cell) taking a cell parameter makes it clear you're not testing pointer nullness.
Context disambiguates - When you see Init_Null(cell), the fact that you're passing a cell provides strong contextual clues.
Consistency with existing patterns - The codebase already drops "-ED" in cases like Init_Lifted_Null(), creating inconsistency that adds cognitive load.
The "weirdness" tax isn't worth it - Making something artificially awkward to read on the off-chance it prevents confusion isn't a great tradeoff, especially when the confusion scenario (someone thinking a function call tests pointer nullness) is already unlikely.

Recommendation

Go with Init_Null() and Is_Null().

The point about Init_Lifted_Null() is particularly damning for the current naming convention. If you've already started dropping the suffix in more complex compositions, you've already admitted that "Null" is a clear enough descriptor on its own. Keeping it elsewhere isn't providing safety; it's just providing inconsistency.

The "tax" of clunky naming is paid every time you read or write code, whereas the "confusion" of a C developer is a one-time cost of entry to the codebase. If the codebase is already disciplined about using nullptr, the ambiguity is significantly reduced.