Canonizing Holes To NULL vs. Leaving Them As Is

Development Optimization
1

In talking about why I liked the idea of standardizing NULL as the "unspecialized default state", I pointed out some displeasing code:

for (; key != key_tail; ++key, ++param, ++arg) {
    if (Is_Specialized(param))
        Blit_Param(arg, param);
    else {
        assert(Is_Cell_A_Bedrock_Hole(param));  // unspecialized PARAMETER!
        Erase_Cell(arg);
        if (Get_Parameter_Flag(param, REFINEMENT))
            Init_Nulled(arg);  // <-- unspecialized refinement
        else
            Init_Ghost(arg);  // <-- unspecialized everything else
    }
}

What I was specifically pointing to being displeased by was the deviation of trying to make refinements null while making others ghost.

But I realized this was a relic of the old notion that frames needed to use states that were as "out of band as possible" for unspecified slots. That all went away with "bedrock" states... at which point NULL became an out-of-band-enough state to use when it was necessary to pretend things were in-band values, because you had the ability to tell when they were not.

So that shows we can clean this up:

for (; key != key_tail; ++key, ++param, ++arg) {
    if (Is_Specialized(param))
        Blit_Param(arg, param);
    else {
        assert(Is_Cell_A_Bedrock_Hole(param));
        Erase_Cell(arg);
        Init_Nulled(arg);
    }
}

But wait... Why are we nulling, instead of just copying the "holes"?

for (; key != key_tail; ++key, ++param, ++arg) {
    if (Is_Specialized(param))
        Blit_Param(arg, param);
    else {
        assert(Is_Cell_A_Bedrock_Hole(param));
        Blit_Param(arg, param);
    }
}

This just turns into:

for (; key != key_tail; ++key, ++param, ++arg)
    Blit_Param(arg, param);

And if you aren't concerned about debug builds and cell origin tracking, you can just make that a memcpy()!

#if NO_RUNTIME_CHECKS
    memcpy(arg, param, sizeof(Cell) * (key_tail - key))
#else
    for (; key != key_tail; ++key, ++param, ++arg)
        Blit_Param(arg, param);
#endif

The "problem" is that we would be leaking bedrock parameter holes into functions for unrefined parameter slots.

But Is That A Problem?

No! That's good!

This means the FRAME! itself holds the holes, and moreover you can change them to alter the PARAMETER! typechecking for unspecialized slots, or leave them as-is to inherit the existing rules from what you are specializing!

Super slick!

:+1: