I've chiseled and shaped things to the point where there's hopefully only one frame-mutation that happens during frame execution, that only happens for one datatype, and only when the field isn't hidden from view. I explain all that here:
I mention something particular, which is that in the world of labeled BAD-WORD!s and isotopes, some of those labels are leaking into the mechanics of implementation.
Some of these are "easy to change" (like the convention of returning
~none~). You can wrap a function that returns none to rename its output. You could load in a new mezzanine and skinned natives and reuse the evaluator as-is.
~unset~ is getting baked in at a deeper level. It's something used by binding, and MAKE FRAME!:
>> f: make frame! :append == make frame! [ series: ~unset~ value: ~unset~ part: ~unset~ only: ~unset~ dup: ~unset~ line: ~unset~ ]
Should We Change The Unset Convention to Plain ~
I like the idea of a core engine that doesn't have any references to specific English words. It would be neat if you could load up a whole different DLL of natives and Mezzanines. But this is showing a specific behavior tied to a particular spelling of a word.
But what if we moved to plain
~ for unset? That would mean seeing this instead:
>> f: make frame! :append == make frame! [ series: ~ value: ~ part: ~ only: ~ dup: ~ line: ~ ]
You still get the idea (bunch of not defined things), it's just cleaner. Then imagine this:
>> f.value: '~baddie~ == make frame! [ series: ~ value: '~baddie~ part: ~ only: # dup: ~ line: ~ ] >> apv: make action! f >> apv [1 2 3] == [1 2 3 ~baddie~]
It kind of pops doesn't it, that only the unlabeled
~ were treated as unspecialized? All those
~unset~ feel like noise.
The Distinguished State As The Unusual State
In terms of looking at BAD-WORD! and asking what the "distinguished" state is, it seems pretty clear that no name is that distinguished state.
If you're wondering what the difference between a "built-in behavior of DO" and a "built-in behavior of the evaluator" is, it comes down to what it's technically possible for you to replace without recompiling the C code.
~none~ is the signal to the console not to print any output (used by HELP for example). But you could tweak to change the console. But the unset is recognized by the internal frame mechanics.
So should ~ be the "system void!", known to mean "unset"?
It may seem more obtuse. But people typing help ~ would be able to get an explanation of it.
One thing that's particular about this state is it can't be converted to WORD!. (null = label of ~) So this makes it distinct on a sort of special level. It kind of seems like if any one single BAD-WORD! state should be having this mean property, that should be the undefined and weird state.