WORD! Isotopes: Role of English in the Evaluator

[hostilefork]

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:

"Default Values And MAKE FRAME!"

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.

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

[BlackATTR]

Note: This comment was made when ~unset~ was the longer ~undefined~.

I think that ~undefined~ seems too long and ~ feels too minimal. What about whittling it down a bit to ~undef~, ~def?~ or just ~?~.

[BlackATTR]

I'm ok with all of these shorter proposals. If there's a darned good reason to dial it all the way down to ~, I can be easily persuaded.

[IngoHohmann]

English is a fact of life in programming, so I have no problem with some English in the evaluator.

~ is ok for me, too.

Just don't start with localised values in the evaluator it's more trouble than worth. (German Excel functions, anyone?)

[hostilefork]

@hostilefork

I discuss something particular, which is that in the world of named voids isotopic WORD!s, some of those WORD!s are leaking into the mechanics of implementation. Some of these are "easy to change" (like the convention of returning ~void~). You can wrap a function that returns void to rename its output. You could load in a new mezzanine and skinned natives and reuse the evaluator as-is.

But ~undefined~ is getting baked in at a deeper level. It's something used by binding, and MAKE FRAME!:

I'm afraid this has become the way it is. Certain words... like ~null~ and ~true~ and ~false~ are getting baked in with specific meanings and behaviors.

While making non-English-centric dialects might be fair game, and creating a customized console experience that translates some of these ideas at a higher level... the mechanics are going to be stuck here until the language itself gets abstracted into something more graph-like where WORD!s are linked and mentioned by GUID in binary source files...and names are put on as renderings.

For the medium that this is, I think I've made peace with the WORD! isotopes getting special behaviors. (But the non-isotope forms are all handled equivalently...except in as much that they are connected through evaluation to the behaviors when they take on their isotope form.)

[hostilefork]

It turns out I use (var: ~) all the time. Being able to wipe out a variable's contents with a single character is super handy.

So I don't find being able to redefine ~ as some generic operator all that compelling anymore--any more than I think being able to define apostrophe as a generic operator is a good idea.

But another reason to promote ~ to being the content state for undefined variables is something else that's been nagging me...regarding the tests UNSET? and SET?.

Consider by Analogy the NULL? Function...

NULL? tests if you have a null isotope.

>> null
== ~null~  ; isotope

>> null? null
== ~true~  ; isotope

But UNSET? Would Break The Pattern...

Let's imagine that we used ~unset~ isotopes for the unset state of a variable, instead of just the isotopic state of void (~ isotopes).

It's would be a lot less useful to test for an UNSET? isotope directly than it is to test if a variable contains an ~unset~ isotope. In the current paradigm, it's nearly never that expressions generate ~unset~ isotopes. You basically are always testing variables for unsetness.

So if UNSET? followed the pattern of testing for the isotope directly, you'd have to write:

>> var
** Error: Variable is unset

>> get/any 'var
== ~unset~  ; isotope (in our theoretical world, instead of ~ isotope)

>> unset? get/any 'var
== ~true~  ; isotope

It's much preferable to be able to just say:

unset? var

So that's what UNSET? does; it takes a WORD!/TUPLE! and gets it...then tests it. But I think it's quite reasonable to think if you see ~unset~ isotopes floating about, that the name implies it would be applicable to directly testing that isotope.

>> null? ~null~
== ~true~  ; isotope

>> unset? ~unset~
** Error: "Weird," thinks the user, "why didn't that work?"

With ~ isotopes to represent "unsetness", the mistake is not be as easy to make.

The user would see that a variable contained an ~ isotope, and it would disconnect from the pattern of XXX? looks for a thing named XXX?. They might not know what a ~ isotope is called, but they won't assume they know it's tested with a function called UNSET?

Beyond That, I've Shown That It Reduces Clutter...

Hard to deny that it's easier to see the signal in the noise:

>> get 'frame
== make frame! [
    series: [a b c]
    value: ~something~
    part: ~
    only: #
    dup: ~
    line: ~
]

Compare that to the jumble you get with the more verbose form:

>> get 'frame
== make frame! [
    series: [a b c]
    value: ~something~
    part: ~unset~
    dup: 3
    line: ~unset~
]

And there's something particularly pleasing about seeing it all clean and fresh on a make...

>> make frame! :append
== make frame! [
    series: ~
    value: ~
    part: ~
    dup: ~
    line: ~
]

Plus, QUASI! WORD!s are Now Truthy And Friendly

There's no reason anymore to disallow them in PATH!s and TUPLE!s.

>> item: first [~/home/Projects/ren-c/README.md]
== ~

>> if item [print "It's truthy now..."]
It's truthy now...

There's not any real reason to disallow quasi words in paths and tuples.

>> first [~why~/not/~this?~]
== ~why~

I can actually already think of applications for that.