World: r3wp

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

But as of A110, we still have it  :) So to formulate the wish on 
that basis, we need to take it into account, or someone else will 
hassle us about having left out alias.

Yup. Working on the wording now. I think the semantics of the proposal 
are good though.

Just keep it short, though.

>> equal? -0. 0.
== true

>> equiv? -0. 0.
== true

>> strict-equal? -0. 0.
== true

>> same? -0. 0.
== false

(I suppose, that is one thing Brian wanted to know)

Good to know. How would it affect numeric code if we made this change? 
Do we need operators for exact comparison?

numeric code - I do not think this specific property can affect anything

We don't use denormalized numbers or anything like that which would 
make numbers with different bit patterns refer to the same number?

I am not sure I understand your question. Nevertheless, the least 
strict is currently Equal?, which, most probably, is useful. The 
most strict (for numeric code using decimals) that we could need 
is Equiv? The Same? is is important only because it is the most strict 
possible

I think the real question is: we also have strict-equal? which is 
(IIUC) as strict as equiv? for numeric code using decimals _and_ 
is also mapped to operators: == and !==.