World: r3wp

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 !==.

I am trying to determine whether it would be acceptable to replace 
== with =? in decimal code where exact comparison is needed. Otherwise 
we would need to switch to prefix form if this proposal goes through, 
which math people don't necessarily like, or come up with operators 
for the equiv line.

If we keep the mapping of strict-equal? to == then == would loose 
the added decimal precision under the new proposal.

Andreas, do you like the new wording?

To be honest, no.

Hmm, I would prefer the current state, then:


- == is what I would use frequently, while I would not want to use 
=? in place of it, because of the difference

- the change would require quite a lot of work, and where is a guarantee, 
that a new idea does not occur in a couple of weeks again?

The long wording is for precision, and because these tickets serve 
as documentation of the issues for future reference.

I don't want to define what the comparison dimensions are in this 
ticket. Leave that to an external document.

That only hides the important issue.

Also, it is wrong: "equal? ... ignores case-aliasing of words".

equal? also ignores every other aliasing.