This feature was originally called "labeled voids" in 2020--under a completely different set of terminology than being used a year later. It was then moved to be called BAD-WORD!, which existed in both an "isotopic" and "friendly form. Today we don't just have this feature for WORD!--but for every other data type, with what are known as QUASI! and isotopic forms.
So looking back on it, ultimately this idea laid the groundwork for many foundational features based on isotopes. Quite historic! I've updated the terminology here to BAD-WORD!, but not retrofitted it further.
Something @rgchris had done that I liked was to use TAG! in module headers as a sort of TBD when the script header contained a configuration for that script.
It cued you what you needed to edit, and the script could deliver you errors telling you if you didn't configure it one way or another:
Rebol [
Title: "My Cool Script"
Description: {
Edit the variable below to set the directory.
}
Directory: <your-path-here>
]
The code looks to see if the directory is a FILE! or a TAG!. If it's a tag, it errors. But the erroring has to be done manually.
This made me wonder about what it would be like if there was a mean type that was WORD!-like, with an interned immutable spelling. But it would error if you tried to access a variable holding it.
Notationally, I thought surrounding the word with ~
would be good:
Directory: ~file!~
I chose this because:
-
The argument for the purpose like in headers for "TBD" seems a solid one for a light and usable notation...vs. some monstrosity like
#[bad-word! "file!"]
. -
We're running out of symbols, so there is not much to pick from.
-
~ is undesirable for general use due to its hard-to-hit location on most keyboards.
-
~ is wavy and off-putting and weird--but that's an asset for this purpose.
It seems clear that this would be a win over what tilde is used for in today's codebases.
Since these can be used as a kind of deferred error--a bad result that's only there to be bad if you actually use it--the text in these words could help guide you to what happened.
Example: With branching structures, it's confusing that nulls are turned into non-null. But wouldn't it be clearer if there was some name on that thing?
>> if true [null]
== ~branched~
Or if you reduce some code that tries to put something in a block but can't:
>> reduce [<a> null]
== [<a> ~null~]
They Error If Evaluated, So You Have To Quote Them
Since BAD-WORD!s are "ornery" you must quote them to not get an error when they are encountered in an evaluative contexts:
>> '~foo~
== ~foo~
>> ~foo~
** Error: BAD-WORD! cannot be evaluated
UPDATE: Explaining isotopes is beyond the scope of this historical thread, but suffice to say that something like ~foo~ no longer errors in evaluation... it produces a "~foo~ isotope".
This Feels Like A Strong Play For Ren-C's Hand
It makes the "brick" a lot more useful for building with, and you can already see above that it would guide people to better awareness with things like ~branched~.