This thread is locked and preserved for its historical significance, and to show just how much progress was made in about 4 months in the establishment of generalized isotopes.
For context while reading: isotopes started as a cell flag on the nulls that carried them, to denote they were "heavy nulls".
Around June 9, 2022 I had a Eureka moment on how isotopic errors could be used to implement "definitional failure", which gave the isotope bit meaning on errors.
This was followed soon around July 16, to seeing isotopes as the answer to @rgchris's question of what the product of a SPREAD intent should be... which effectively subtracted a quote level from the semantics I'd been using to eliminate the need for /ONLY, motivating a generalized "quoting level of -1".
So isotopes were no longer implemented with a flag, but a unique quote state (making it impossible to have an isotopic quoted WORD!, for instance...only an isotopic plain WORD!). It became clear that isotopes could be applied to more types, and in this post I argued for generalizing it... pointing out that we could make the "automatically run from words" behavior come only from the isotopic form of ACTION!.
By August 4th I was building up to the idea of quasiforms--but not knowing what to call them yet, I suggest in this thread these items are "antiquoted".
By August 25th I realized isotopic words could serve the needs of representing ~true~ and ~false~.
By September 1 I'd applied isotopic packs to multi-return, and isotopic objects began developing as a nuanced alternative to things like JavaScript "thenables", promises, and other super powers...
We now take you back to July 16, 2022...
A little too soon to declare victory, but... we may have a solution in our hands for the historical problem of splicing arrays, by allowing GROUP! isotopes to convey the splicing intent.
Isotopes are essentially "quote level -1" ... if you take something at quote level 0 and UNMETA it, you're allowed precisely one level of below-rock-bottom.
The isotopes are unfriendly: normal function parameters won't accept them, you cannot put them in arrays, and some of them have strange behaviors when assigned to variables.
So what would an isotopic group look like?
A thought I had inspired by BAD-WORD!s was that they might use tildes on the outsides:
>> unmeta [a b c]
== ~(a b c)~
But that's used for normal BAD-WORD! today, that you unmeta to make isotopes.
Which made me wonder, what if what we call BAD-WORD! today was actually a BAD-WORD! isotope, and you got them from unmeta'ing WORD! ?
>> unmeta 'something
== ~something~
; ^-- ornery, how what we call `~something~ isotope` is today
And then, what if you could make anything isotopic:
>> unmeta 1020
== ~1020~
This would break a number of things--and we've come to depend on reified BAD-WORD!s for some reasonably important purposes. But it crossed my mind and I tend to jot notes here for every single whim that comes to my mind, so there it is.
Storing Isotopic Groups In Variables?
If you go back and review "Generic Quoting Makes Headway on MAKE OBJECT!" you'll see that we've been getting by not needing quotes on items that are inert.
You have to have a quote on (1 + 2) if the intent is to store a GROUP! in a variable, because it will evaluate otherwise:
make object! [group: '(1 + 2)]
But things like BLOCK! haven't needed them (and shouldn't):
make object! [block: [1 + 2]]
However, I think that isotopes are likely going to need to be stored in variables. You'll have to use ^META operations to get the value out of the variable.
Why couldn't it be an error to try and store an isotopic block in a variable? Well, there is some attempts to be friendly by higher-level operations like SPECIALIZE. So when you say
append-a-b-c: specialize :append [value: spread [a b c]] ; or whatever...
What happened was that everything in the frame was marked as holding a special identity for unspecialized-ness. When the code block finishes running, it looks and notices value is a ^META parameter, and does the isotopic quoting for you.
If you don't have that feature, you have to know the convention of the parameter in order to assign it. That's not the end of the world, but it feels like a hassle. Being able to store an isotopic block in a variable enables that feature--as well as others.
So I Think Isotopes Are In For Some Kind of Reckoning
There's a lot of pieces to the puzzle, and they're all tied in together. But the good news is that the corpus of code is so big that the impacts of any change are seen, and so I can try to make sure nothing of value gets lost.