WORD! Isotopes: Role of English in the Evaluator

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.

2 Likes

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

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.

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?)

3 Likes

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.)

1 Like

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.

1 Like

A post was split to a new topic: Merge Equal Fields when Molding/Printing Objects