World: r3wp

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

(Maybe add a blank linke before the - EQUAL? item.)(

I didn't even know there was a newline bit, though it seems obvious 
in retrospect. It would be lost in the transfer of the value to the 
stack frame for the function call I bet, because stack frames and 
value slots of contexts don't keep track of newlines. You'd have 
to pass in a reference to the block the value is stored in, I'm guessing.

wrong

Even more interesting. Say more.

written in http://www.rebol.net/wiki/Identity#The_new-line_attribute

I used to think that newlines in blocks were hidden values in the 
block itself. It makes sense to just have it be a bit in a value 
slot.

It is a value bit.

>> a: copy [1 2 3]
== [1 2 3]

>> new-line next a on     
== [
    2 3
]

>> b: copy []             
== []

>> append b first a   
== [1]

>> append b second a  
== [1
    2
]

>> append b third a   
== [1
    2 3
]

Guess it's in all value slots, not just the ones in block types, 
and just ignored when inapplicable.

At least that makes the value slot easier to implement. Good choice.

Well, it is not ideal this way, for two reasons:


- it does not affect all possible line break positions in a block 
(there are n + 1 such positions in a block of length n, as can be 
easily figured)
- it "pollutes" the values, affecting their identity, e.g.

Well, the latter is probably why same? does not respect this bit, 
no :) ?