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". 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.
~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.