World: r3wp

yeah, I am really satisfied with last few months of developments, 
and I think that the community in overall is, as Carl is doing mostly 
Core stuff, and not GUI. R3 is getting more and more robust and consistent, 
although there is still some way to go. I can feel that we are getting 
more R3 fixes per month, than we get for R2 in last decade :-)

Yes -- I am hitting bugs, reporting them on curecode and often seeing 
them fixed in just a few days. It's a good time to be evaluating 
R3.

New operator !== for STRICT-NOT-EQUAL? - that was the last comparison 
action without an operator :)

Carl asked: wouldn't it be best to have same? to check for bit-by-bit 
equality? - this would "doom" same? :a 'a to yield False, requaring 
a new comparison operator to compare for "the same variable" case

requiring, sorry

So SAME? is less strict than STRICT-EQUAL? for words?

not just for words, for numbers,...

but, certainly not "completely less strict":

>> same? 'a use [a] ['a]
== false

>> strict-equal? 'a use [a] ['a]
== true

Weird - I thought it was a strict hierarchy of increasing equality. 
Never wrote code that would be tripped up by that.

new comparison operator
 - why not = or EQUAL?

this hierarchy never existed, AFAICT.

since equal? 'a use [a] ['a] should yield True IMO

The only thing I am sure about is, that the IDENTICAL? function ( 
http://www.rebol.net/wiki/Identity) is the finest possible (except 
for my bugs).

For SAME? I am more concerned about word binding equality than datatype 
equality. If the datatypes differing would make the return value 
false, we can always convert to the same datatype.

the "usual equality" is the coarsest equality we have - so the coarsest 
side of the hierarchy exists

it is so coarse, that it even isn't transitive (e.g. approximate 
equality for decimals)

After reading that wiki about identity, almost all of those criticisms 
of SAME? sound like CureCode tickets you haven't written yet. Carl's 
proposed bit-for-bit equality should solve most of those criticisms.

all, but I am not sure they are criticisms, they are just difference 
points

SAME? should mean "the same thing". Those difference points are bugs.

In R2, where as-binary is an alias:
>> a: "aa" same? a as-binary a
== false

Differing word types should behave the same, even when bound to the 
same context.

if we want the hierarchy to be linearly ordered by fineness, then 
the equality should compare just spelling of words, the second one 
- finer and non-existent yet, should compare spelling and binding, 
the third one should compare spelling + binding + datatype (can be 
strict-equal?), the fourth one is not that necessary in this case

my IDENTICAL? may be considered a "quirk", taking into account even 
such thing as the New-line bit

BrianH: if binary and string types are more divorced, what do we 
gain in particular?

We gain a host of potential new abilities to work with binaries. 
Right now the half-assed way that binaries sometimes act like strings 
is making it difficult to process binaries like binaries. Getting 
rid of the false equivalency will make all sorts off improvements 
possible.

Including proper, powerful support for binaries in PARSE.

better bit twitteling would be good

Ladislav, just checked your SAME? criticisms from the wiki against 
R3, and only the date! transitivity thing still applies.

Struct! is not implemented, nor is denomination in money!. Closed 
ports are not errors and decimals are fixed. Unset and error are 
still not values. The only thing left is the date! zones and the 
type-ignorant any-word comparisons.

how about my last comment to r3blog?

I hadn't noticed the new blog post. Replied there.

yet another posted

SAME? meaning same bits should include the type flags too - otherwise 
same bits is meaningless or cooincidental.

Maxim, now you can defend your copy deep on object issue - http://www.rebol.net/r3blogs/0212.html

BrainH: btw - Meijeru's identity confirmed - http://users.telenet.be/rwmeijer/
, he now mentions REBOL - http://users.telenet.be/rwmeijer/proglang/

Cool - we need as much help as we can get. I'm glad he participates 
in the chat too, and his testing has been very helpful.

One more mystery person to go: Peta, are you out there? :)

It's not another (secret) Pekr's name? :)

The bug fixes just keep coming -- Alpha 59 out barely a day after 
A58:

http://www.rebol.net/wiki/R3_Releases#View.exe_2.100.59_23-June-2009


Curecode #961 was fixed in less than 24 hours....That must be a record!

Notice Meijeru's daytime work... must be a fruitful hobby.

I think I ran into him before (may be virtually), I remember him 
as a very kind and nice person.

pekr: well, I did add new posts, but I think everyone MUST participate. 
 this is such a core issue, it can make / break many systems out 
there.

in my case, it breaks every single API I have.

that is unless you consider a 100x (thats 10000%) increase in RAM 
usage and script slowdown acceptable.

http://www.rebol.net/r3blogs/0213.html- A60 special release.

The link in the blog does not work [has /rebol3/ not /r3/ ]

This link does work:
http://www.rebol.com/r3/downloads/r3-a60.exe

http://www.rebol.org/art-display-article.r?article=w24v- porting 
INCLUDE to R3

brian I would like your comments on the deep object copy issue ( 
http://www.rebol.net/r3blogs/0212.html)

I have been trying to think think it through - there are advantages 
and disadvantages to either way. It is harder to undo a copy than 
not...

exactly, which is why I think we should not be bound by one or the 
other .... 

did you see my posts... I provide some alternatives.

I'm still thinking. I'll comment after I narrow down this parse bug.