The equality operator (==) behaves like JavaScript. Should we require a ===?

[srbhr]

Facing a challenging situation here. There are two statements:

yodaSays = "Named must your fear be, before banish it you can."

myWords = "You must name your fear before banishing it."

yodaSays == myWords  // true

Another such example

yodaSays = "When you look at the dark side, careful you must be. For the dark side looks back."

myHead = "You must be careful when you look at the dark side. For the dark side looks back."

yodaSays == myHead  // true

So, while we're using two different statements, they're equal. While being differently written. So, should there be a === check when talking about checks like this? This might lead to different interpretations in certain cases. 🤔🤔 (Especially comparing between forks.)

[theletterf]

Just checked the source—I believe === would be interpreted as a piping operator.

[mtekman]

Testing for direct equality in equivalent statements would never be perfect and we shouldn't strive for it in such a diverse framework of expression.

Instead we should use the approximate operator ~ for equivalent statements:

• "my toe hurts due to negligence" ~ "I stubbed my damn toe"

That way we can reserve the equal operator for direct repetitions:

• stop copying me == stop copying *me*

[srbhr]

Yes @mtekman this and what @theletterf said regarding the piping operator. (I think he's referring to R's Pipe Operator)

So it'll be:

 "Named must your fear be, before banish it you can." ~ "You must name your fear before banishing it."  // true

[mtekman]

@srbhr I'm not sure that's the case, as the === operator has been in use since the v1980 release as a way to structure statements:

==================
||   Musings    ||
==================
Twas a wonderous day
Amidst the spells of
the apothecary.

The pipes were a much needed struct for category placement during the BBS messaging crisis of 1980s, but I think was later deprecated due to misuse in the following decades.

[srbhr]

Okay, so this is getting really interesting.
What should be the output for:

"Happy I am!" === "I am happy!"

[mtekman]

That should throw a syntax error, or at least result in something sharp being thrown, but truthfully I haven't updated my fork of the language since v1997 so it could be a completely valid statement in the dev branch.

[srbhr]

Indeed, it might be compiling in one of the localized forks. I have the v2021 build. But it contains words that compile to zero meaning.
I mean, we need a .gitignore or .langignore atleast.