"I'm not BAD!...I'm just MOLD-ed that way..."

I'm tinkering with an implementation of fully generic isotopes. The idea is that all types have an isotopic form, and routines can choose to react to this isotopic form giving it special meaning.

This means the tilde markings which used to designate a BAD-WORD! would be ways of making any value isotopic:

>> ~foo~
== foo  ; isotope

>> ~[d e]~
== [d e]  ; isotope

>> ~1020~
== 1020  ; isotope

>> ~#[datatype word!]~
== #[datatype word!]  ; isotope

The notation is not an isotope itself, it's just used to produce them. And if you're looking in an object and see it molds out fields that are these and non-quoted, that implies that the field itself actually holds an isotope.

>> obj: make object! [x: spread [d e], y: ~[d e]~, z: '~[d e]~]
== make object! [
    x: ~[d e]~
    y: ~[d e]~
    z: '~[d e]~
]

>> obj.x
** Error: obj.x is a BLOCK! isotope, use ^META to access

>> obj.y
** Error: obj.y is a BLOCK! isotope, use ^META to access

>> obj.z
== ~[d e]~

So you can see how the notation works with the generic form, and can be quoted itself.

I Kind Of Want To Curtail Use Of These In Source...

The original thought about BAD-WORD! was that their ugly notation was supposed to be used to draw attention to them. So like in the object molding above, you'd be able to see where the isotopes were and it would guide your eyes to the problem.

And in fact, I'm not even 100% sure that we want to support storing isotopes in variables unless we absolutely have to. Perhaps isotopic blocks would generate errors if you tried--and it would force you to use a ^META operation to persist it. But a representation that evaluates to them is needed for mechanical reasons either way.

Nevertheless, you could use them to do things like splicing literal blocks:

>> append [a b c] [d e]
== [a b c [d e]]

>> append [a b c] ~[d e]~
== [a b c d e]

It would actually be an efficient way to do it, but I feel like it might numb people to the squiggles...which are intended to draw attention to cases where the isotopes leaked through an operation and shouldn't have. So best practices would suggest using operators instead

>> append [a b c] spread [d e]
== [a b c d e]

But The ~XXX~ Forms Need A Name... Is It BAD! ?

I'd called ~xxx~ a BAD-WORD!. Now that the tildes are a generic container kind of like QUOTED!, that would default to just being... BAD!

>> type of fourth [a b c ~[d e]~]
== #[datatype! bad!]

So there's going to be a whole naming situation for operations to get the contained item out, and what to call this container.

(If it's so BAD, does it need to be... REFORMed? :stuck_out_tongue: )

I don't know how to fit this into the isotope naming scheme...it's a thing that generates isotopes when it evaluates. The analogy breaks down if you try to call it a NUCLEUS or something odd like that.

Calling the ~xxx~ forms BAD! does have the advantage of being able to combine that and say ~[d e]~ is a "bad block" and ~1020~ is a "bad integer", but... you'll see these in well-formed programs. It makes it sound like something is corrupt, when the real intent is different.

It could be called QUASI! which could related it to QUOTED!. "~[d e]~ is a quasi-block"

Bear in mind they can be quoted, so '~[d e]~ would then be a "quoted quasi-block". :frowning:

In some sense, [d e] and ~[d e]~ and '[d e] and ''[d e] could all be thought of as "isotopes" of blocks...in addition to what we call the "isotope" form (which has no representation, because it's something you can only measure by turning it into another form).

So we might call ~[d e]~ a "block isotope", and then give some other name to the invisible status that it produces...?

>> ~[d e]~  ; call this a block isotope?
== [d e]  ; then this could be... a... ghost block?

But overall my leaning is that I like calling the ephemeral form "isotope", because I think that captures its weird invisible/reactivity/decaying character.

The Pejorative "BAD!" May Seem Harsh, But May Be Good?

If the name can scare people out of trying to use these too much at source level, that's not the worst outcome.

But then there still have to be ways of getting the contents out. QUOTED! has UNQUOTE and NOQUOTE to take off quoting layers, and QUOTE to add them on.

Right now I've got MAKE BAD! to produce them:

>> make bad! 1020
== ~1020~

>> make bad! [d e]
== ~[d e]~

If we called them something like TOXIC! then there could be detox and toxify. :radioactive:

There's plenty to be involved with working out the mechanics and not worrying about the names, but wanted to put the naming issue out to be mulled over.

2 Likes

quasi, pseudo, fake, mock, somewhat, nearly, acting,
special, marked, tainted, ...

I guess the last 3 ideas could hint into a good direction.

I think I am leaning to calling it QUASI.

  • Same number of letters as QUOTE

  • Starts with Q and looks similar so indicates a similar phenomenon

  • Offers seemingly obvious verb forms QUASI and UNQUASI, and the test QUASI?

  • "Looks like it sounds"... tildes always suggest something of an approximation, like ~30 meaning "approximately 30".

  • Quasi carries some of the pejorative sense of "badness", because prescriptively I maintain that we don't want to be seeing these in common source--at least not a lot of unquoted "uses" of them.

  • I suppose I'm not that concerned about having to say the phrase "quoted quasi word" any moreso than having to say "quoted bad word".

Unfortunately the datatype doesn't afford an obvious name like QUOTED! does as QUASID!

Does that suggest that the datatypes should be simply called QUOTE! and QUASI!

We don't call a GROUP! a GROUPED! or a BLOCK! a BLOCKED! just because it describes a wrapper around its contents. It takes on the name of the container.

Though it would take some getting used to. if quote? x [...] feels like it collides with other concrete things... like the character of a quote mark. It sort of has the same issue as PAREN? did, or if block was called BRACKET!.

It may just be all right to have the distinction between QUOTED! and QUASI!.

2 Likes