World: r3wp

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.

I changed that.

Still wrong.

>> a: 42
== 42

>> alias 'a "b"
== b

>> equal? 'a 'b
== true

Ladislav, thanks. Seems the better option then would be to map == 
and !== to strict-equiv? and strict-not-equiv?.

I don't want to emphasize the aliasing thing or otherwise the ticket 
would need editing if/when ALIAS goes away. Still, good point.

Then don't emphasize it. It is one comparison dimension that currently 
exists.

That reminds me, need to check whether there is a ticket to remove 
ALIAS.

No, there is not.

Ignores datatypes, bindings, case, aliasing.
 should be sufficient

Also, get rid of the *NOT* mentions in the main body. If at all, 
mention that in a remark at the end of the ticket.

Good idea.

Done.

BTW, Same? is still less strict than my Identical? (even for decimals)

Interesting. How does that happen? I thought SAME? just did a bit-for-bit 
comparison.

yes, but the NEW-LINE? bit is ignored

Heh :) awesome.

Ok, ticket's good. Thanks Brian.

That's funny :)