Lingering Idea: Labeled "Ornery" WORD!s

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 :call_me_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~.

3 Likes

I like this a lot, it increases transparency in a good way and should make the language easier to learn/understand. I don't see many downsides listed-- are we missing anything?

2 Likes

Consensus on a notation is probably all that's needed.

There's even be enough cell bits that these could trace back to the file and line where they were created, if that were wired up. So if you're downstream of one of these you could get information on where it came from.

(I was just thinking about what would happen if frame-local variables were initialized to ~local~, but then wondering about what would happen once it got far from home and you wondered about its origins...local to what?)

Similar ideas might be possible for BLANK! and NULL. I should tinker with it.

2 Likes

YESSS :+1:
I like it. Much.

2 Likes

I've had this thought for a couple of years now (again, mostly triggered by Chris's tag trick). But I hadn't made a specific post about it where I proposed actual names (e.g. ~branched~). But in doing so, it kind of reinforces just how many of these might be useful.

Potential for this becoming a frequently-reached-for light-error mechanism might be high. Conversion to error could use the symbol as the ID (given that these are constrained to WORD! spelling rules and interning so multiple instances aren't taking up multiple copies of the string). Conversion of errors to voids could be another interesting direction. This gives you something like the "armed" and "disarmed" states of Rebol2, but a lot more interesting.

(Note: This suggests avoiding internal tildes, so that ~bad-mojo~ can be converted to bad-mojo without incurring the problem of being a BAD-WORD! itself. I think this suggests disallowing internal ~, and only having it at the beginning and end.)

While Rebmu will mourn the loss of ~ for word names, it will give another tool for dialecting. So it won't be like it can't be used.

2 Likes

It would be nice if this worked:

path: '~/foo/bar

And I think, I never used tilde in an identifier anywhere.

A post was split to a new topic: Isotopic WORD!s For More Informative States in TLS