World: r3wp

The original purpose of EQUIV? was the decimal thing, so you might 
want to move it there.

#1830 doesn't actually use STRICT-EQUAL?, so reordering the hierarchy 
won't help. You need to see the new 1830.

That's the whole point of this proposal.

With the above strict-equal, it could safely use it.

Either in the default case, or with a /case, /strict or /whatever 
refinement.

Framed this way, this discussion would be a lot easier, imo; and 
probably more fruitful.

That is a seperate issue that needs its own ticket. FIND and SELECT 
use their own code, so they can only follow the same rules, not use 
the same code.

That is an implementation problem, not a design issue

I am OK with a DAG for the equivalences, but would prefer the exact 
decimal comparison to go in the EQUIV?, STRICT-EQUIV? branch.

Fine with me, but most likely only a minor issue.

For reference, also be aware that we have operator shortcuts for 
the comparison functions. At the moment:
=: equal? (and !=
==: strict-equal? (and !==)
=?: same?


The == operators should then probably become shortcuts for strict-equiv.

That's a bigger problem than binding, believe me. Exact decimal comparison 
makes floating point code nearly unusable by normal programmers.

As mentioned above, that's perfectly fine with me.

It's not decimal precision which makes the FIND (and STRICT-MAP!) 
discussion so cumbersome.

We don't need operators for the equiv branch. STRICT-EQUIV? and SAME? 
are the same thing for words and decimals.

If you want I can write up your reshuffled hierarchy as a CC ticket. 
I think Carl would like it, ans the binding issue has bit him in 
the past.

ans -> as

Thanks for your input. I'll also wait for Ladislav's input at least, 
as the "Comparisons" doc was authored by him.

So let's update this with the decimal precision moved:

- equal?
- strict-equal?: equal + type + case + alias

- equiv?: equal + binding + decimal 
- strict-equiv?: equiv + type + case + alias

- same?: as currently

Strangely enough, it's not binding or exact decimal comparison that 
are at issue with FIND or strict-map! either, it's case and type. 
Nonetheless, this would make it easier to point to the distinction 
between STRICT-EQUAL? and STRICT-EQUIV? when talking about those, 
precisely because those aren't at issue.

Sounds good to me.

As you see, case and type are the major distinction between equal 
and strict-equal.

Yup. That makes sense.

So that would make it easy to define FIND as using EQUAL? per default, 
and STRICT-EQUAL? with /case.

(Or a renamed /case option. A bit hypothetical due to backwards compatibility, 
but mentioning it for the sake of completeness.)

We can't rename the /case option - legacy naming rules. And if the 
equivalences are reshuffled this way, we won't have to.

Andreas, the proposal has been added here: http://issue.cc/r3/1834
- if you have any suggestions or tweaks, mention them here or there 
and I'll update it.

Yes, I have a suggestion: my explicit wish was to wait with this 
for Ladislav's feedback.

Please respect that in the future.

I put in a request for Ladislav's feedback in a ticket comment, and 
in other AltME worlds where he works. Including the RMA world, where 
they write code that would be affected by this.

Unlike here, tickets can be tweaked based on feedback. We needed 
a baseline to start with.

Unlike here, extensive CC discussions are a mess.

Edit "no aliasing" to "alias distinctions". Thanks.

They're a mess here too, but are more useless because they can't 
be searched as easily once they drop off the history, and the relevant 
people who would make the changes aren't generally here that much.. 
CC is a much better place for this kind of thing.

Actually, no aliasing is more correct than what is on the wiki.

equal plus no aliasing
 is bad wording.

And it's really simple: I wanted Ladislav's feedback here first, 
before we write up a ticket and litter it with useless comments. 
Again, please respect that in the future.

OK.

Case-insensitivity is implemented using aliasing. Case sensitivity 
means that the aliases are ignored - no aliasing.

Case sensitivity does not mean that aliases are ignore.

At least I don't know of a way off hand to prove that.

But I trust you that word case sensitivity is implemented using aliases.

But to me, "equal plus no aliasing" still does not clearly express 
whether aliased words are considered to be equal or ignored in this 
case.

equal or different*

Fortunately it can be edited (and I will do that now).

Equal plus alias distinction
 was clearer to me.

(As not all aliases are case related.)

Actually, that feature might go away. The ALIAS function has been 
a big hassle in R3 because of the lack of a central system/words 
repository. We are likely to keep the aliasing facility for internal 
use to implement case insensitivity, but the ALIAS function to do 
other kinds of aliasing may go away.

Yes, I am aware of that.

Oh good :)