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:
"Default Values And MAKE FRAME!"
I mention something particular, which is that in the world of labeled isotopic WORD!s...some of those labels are leaking into the mechanics of implementation.
Some of these are "easy to change". You can wrap a function that returns a ~word~ isotope to rename its output. You could load in a new mezzanine and skinned natives and reuse the evaluator as-is.
But ~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
So should ~ be known to mean "unset"?
It may seem more obtuse. But people typing help ~ would be able to get an explanation of it.