IS/ISN'T Step 1: temp. remove = != <> EQUAL? NOT-EQUAL?

[hostilefork]

The ultimate goal of this commit is to eliminate the STRICT-EQUAL?
family of functions and operators, by not having a form of equality
that is "more equal than equal". Instead, the lax form of equality
in default use by FIND, SWITCH and other operators would be called
"is-ness". So "A" is not equal to "a", but "A" IS "a".

This adds IS and ISN'T, while temporarily making the former lax equal
operations undefined. However, the strict operators are still defined.
This gives people a chance to find all the = in their code and decide
if it should become a == or an IS (for example).

One difference between IS and ISN'T and previous lax equality is that
it does not consider different string types to match, nor does it
consider different word types to match. Hence <FOO> is <fOo> but
<FOO> isn't "FOO". Integers and decimals continue to match within
a certain epsilon when using IS.

The next step in this process would be taken when all files have been
adapted for this change. It would proceed to undefine the strict
equality operators, and have them retake =, !=, and <>.

[giuliolunati]

This really implies a lot of changes in daily used code. :-/

[IngoHohmann]

Given that practically all uses of = in the tests really meant == and the same may be true for most other code ... how about just making the change in one step?

Random thought of the day:
Would it make sense to have a ren-c pitfalls mode which would warn / error on things like this?

[giuliolunati]

Sure that has been yet considered ... but why not ~ and !~ instead of IS and ISN'T ? For me, IS sounds more strict than = and should be used for identity, e.g. let a: "" b: a c: copy a then all [a = b | a = c | a IS b | a ISN'T c]

[hostilefork]

This really implies a lot of changes in daily used code. :-/

As with other changes (like // for comments), it's an important thing that has had a lot of thought put into it. I don't take these kinds of things lightly.

I've mentioned the rather bad property we have today, where = is paired with !=... and then == is paired with !==. That's a pretty big pitfall, because most people think of == as being paired with !=.
Something has to change, here.

And the longer things have gone on, I've come to think that == just really sucks as an equality operator. It seems quite the waste to be doing assignments through set-words:, having = available, and then throwing it all away by bringing back in == (and confusingly so, as just mentioned). When you step back and look at what it does to code, it is not visually pleasing... the == pattern looks too much like line-drawing, and would be much better for that. Things like strict-greater-or-equal? suck too...this "STRICT" word is very ugly to be tacking on, creating very long phrases.

Trying to find a word for strict equality is difficult, also. FIND/CASE is rather confusing because it doesn't just apply to case (1 is lax equal to 1.0). Also there is a very common CASE construct in the language with a totally different meaning of "case", making it confusing. FIND/STRICT is a lot to type and not that appealing. I propose that FIND/= is briefer and can be connected better with the operation being used.

Change is inevitable here, and I think this is one solves a lot of problems with a pleasing result.

For me, IS sounds more strict than = and should be used for identity

IS is a flexible word in English, with many applications. You would say "the total is $29.95", more often than you would say "the car is the car". It could also be used for attributes, like "the car is blue".

I realize that the word has a lot of purposes, but I think this one is pretty natural...and my experience with it has shown that the mind can parse expressions that use it better than I'd thought it would. While it doesn't "pop out" the way = does, it doesn't feel like it really needs to...you can still read the expression just fine.

Sure that has been yet considered ... but why not ~ and !~

~ is very similar when seen from a distance to -. It does not have good properties for readability. It's also in a very inconvenient location on the keyboard (at least mine) and has to be shifted too.

When you look at what FIND, SWITCH, and other Rebol operations that use lax comparisons have in common...they are all English words. IS being a word puts it into that category, and it's very natural to read. Rebol is fundamentally a language which is about words over symbols, and using our language processing where possible...

[hostilefork]

Given that practically all uses of = in the tests really meant == and the same may be true for most other code ... how about just making the change in one step?

The step of substituting = for == and != for !== is a pretty easy one, and can be taken at people's leisure...there won't be any particular rush to reuse ==. I think this is the saner path for giving people time to audit the callsites and giving an informative error.

Would it make sense to have a ren-c pitfalls mode which would warn / error on things like this?

Yes, it's called r2warn.reb:

https://github.com/hostilefork/rebol/blob/070ca110204515647149a394c3db11dc7b1a78cd/scripts/r2warn.reb#L64

The goal was to separate out the warnings so they could be used with the redbol.reb emulation or not. So you could be running under old Rebol conventions and be given a "hey, this changed" message but have it still work the old way... or run under new conventions and be warned as you go about the change.

It needs to keep a table and warn only once, etc. I am hoping someone else will develop the feature, I'm just trying to keep the list (!)