World: r3wp

Gabriele's FORM-DECIMAL function has always worked solidly for me. 
It could be considered as a mezz.

Yes, but making it native might be a good idea. I call this function 
a lot and with a lot of numbers while filling input-forms.

as long as it's not too complex. form-decimal is a rather complex 
mezzanine.

can't download new alpha, tried xy times and still receiving timeouts 
....

It's possible to download it from web using browser (but it's slow).. 
or try to enhance this value: system/schemes/http/spec/timeout

Downloads are here http://www.rebol.com/r3/downloads.html

maybe a better name would be numerize.

Specific formatting is always a bit of a problem, because everyone 
needs it, they need it to be fast, they need it to be consistent, 
and they need it to be completely different from what other people 
need. Personal preferences, industry standards, local standards, 
none agree. Fortunately in R3 native doesn't have to mean built-in 
or standardized.

Remember, "human-readable" depends on the human doing the reading.

Some notes on my first attempts to run R3-alpha against existing, 
published R2 scripts:
   http://www.rebol.org/art-display-article.r?article=j26z

Hmmm...

we don't use anymore "to-pair reduce [x y]" since a while, but "as-pair 
x y".

The script was written back in 2003, when as-pair was not availabe.


Oddly, R3-a58 does support to-pair, but not for integers, suggesting 
the problem is just a glitch:
    >> to-pair [1 2]
    ** Script error: cannot MAKE/TO pair! from: [1 2]
    >> to-pair [1.0 2.0]
    == 1x2

Interesting conversion in R3.
>>to-pair 2.8
==2x2

That's an R2 feature too. It kind of makes sense:
    to-pair 2
    == 2x2    ;; duplicates the 2 to create the missing value
    to-pair 2.8
    == 2x2   coerce to integer!, then as above.

to-pair [1 2] not working is a bug, btw. Has a ticket and everything.

pairs are very usefull in R2 I hope their functionality doesn't change.

Aside from that bug, I've seen no changes. AS-PAIR might go native 
though.

so when will the plugin interface be documented?

It's not even done yet. After this month I guess.

I just can't wait  :-)

is binary a string?
Carl wants opinions to help him decide:
http://www.rebol.net/r3blogs/0209.html

No twitter or other announcement, but alpha 58 is out -- over 25 
curecode issues addressed:

http://www.rebol.net/wiki/R3_Releases#View.exe_2.100.58_21-June-2009

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.