World: r3wp

Here is my short list (I am sure I forgot to mention a lot of things 
other people may find important)

Advantages of R3:

- new datatypes

-- map!, money!, percent!, closure!, module!, typeset!, command!, 
get-path!, 
- enhanced objects
- enhanced errors
- support for UNICODE strings
- enhanced bitsets (support for UNICODE)
- enhanced pairs
- 64-bit integers

- better conversions (to binary! and back)

- enhanced PARSE
-- new keywords added
- enhanced MOLD
-- improved MOLD/ALL
- enhanced LOAD
- some functions became natives
-- native APPEND
- more complete set of comparison functions
-- EQUIV? added
- much better RANDOM

- enhanced loops (CONTINUE)

- enhanced debugging capabilities (call stack)
- enhanced protection (PROTECT)

- improved GC

- more open (the host-kit is open source)

Disadvantages:

- missing list! (the demand for the datatype was low)

- missing hash! (for the majority of applications map! should be 
faster and more comfortable)

- no adequate substitute for the [throw] function attribute exists 
yet
- missing struct! (for substitute, see extensions)

Other advantages:

556 more tests than for R2 (see testing and tools group)

Also, less test failures than for R2

no easy access to libraries ...

protocols are untested

- Much better extensions than R2. It's super simple to write an R3 
extension.

Ashley: Good question, thank you.
Ladislav: Thank you for the answer.
apart from GUI
: there is still no official GUI for R3. You can use RMA's.

Well done, Ladislav.

Perhaps also of importance is that many bugs are already well-documented 
and are actively being discussed in Curecode with R3 rather than 
the simple non-discussed reports for RAMBO with R2.

I would add following "negatives" (depends upon how you look into 
it):


- no /libary extension and easy wrapping of DLLs. There was a bounty 
started to bring in kind of R2 DLL capabilities using extensions, 
Max was working on something, but did not deliver. Some ppl claim, 
that working with extensions is easy enough, much more powerfull, 
and that in fact R2 /library interface was weak in comparison in 
capabilities.


- weak and underpowered CALL.No /output or /wait parameter IIRC. 
Carl said, that R2 C code to it was complex, and that the code is 
eventually awailable for volunteer to bring in to R3. The outcome 
is - CALL is limited in usage in comparison to what can be easily 
achieved in R2.


- protocols. The only protocol IIRC was available was HTTP, done 
by Gabriele. It was HTTP 1.1 compatible, but due to some bug (?) 
it was downgraded to 1.0 version. No proxy support. Other protocols 
were done by some other ppl, I do remember Graham doing some work 
here. In regards to protocols, IIRC there was some work done by Kaj, 
who brought Curl networking extension to R3.


- under Windows console is a bit more inconvenient in usage than 
in R2, we use native Windows console, yet we don't have full console 
support, so we can't replace the native R3 one by e.g. Console2 or 
some other version ...


- DBAccess - forget R2 protocols available. The rescue is ODBC extension 
for R3


- CGI - no native CGI support in R3, though it should not be difficult 
to emulate


- Sorting & Unicode - althought we have Unicode strings available, 
sort is not adapted to that, and the question is, if it can be easily 
done ...

Other than that, R3 has the advantages Ladislav mentioned. So if 
you can live with some limitiations I named, you should be OK in 
using R3.

I thought Kaj was using R3 for cgi ??

there is still no official GUI for R3

 - frankly, that is inaccurate. The GUI is "official" in the following 
 senses:

- Carl "delegated" the GUI development to our team
- the GUI is the continuation of the Carl's version
- the GUI is available for everyone
- the documentation is available as well

- the development of the GUI is continuing, for every new version 
of the interpreter, the corresponding GUI version is available

Ladislav - as due to low public interest the GUI is not going to 
be published so often, I would like to ask, if some work on "nice 
skin" has already started? (I am referring to a blog post :-)

it hasn't

Sorting & Unicode - althought we have Unicode strings available, 
sort is not adapted to that, and the question is, if it can be easily 
done ...

 - this is not a disadvantage of R3, in this case R3 surely is better 
 than R2

weak and underpowered CALL.No /output or /wait parameter IIRC.


I agree with the general notion (that CALL is weak, atm), but: /wait 
is there (albeit not working on Linux, IIRC). /output is missing 
indeed.


But CALL is fully doable as extension or from within the hostkit. 
So if anyone really needs it, it's a matter of either developing 
it yourself or funding the development. (Feel free to contact me, 
if interested in the latter.)

no native CGI support in R3


True, although that "native" support is barely needed. `get-env` 
and `system/ports/input` are basically all you need. I am running 
several R3 CGIs which work just fine.

well................ carl where are you ?????

Ladislav, how do we now access the R3 GUI and the REBOL core on which 
it runs?

Singy, it should be on saphirion.com, but there are some server problems 
currently.

No server problems: http://www.saphirion.com/development/r3-gui/

Thanks Robert - that works fine - now :) Henrik was correct at the 
time, the server was having problems - it is what prompted my question.

I just noticed Bohdan Lechnowsky saying following on Facebook: "I 
know for a fact that Carl was working on R3 this past weekend." Any 
insider info on that?

Who is this person?

Found out.

Bo did a talk at REBOL/Collaboration 2004 and is quoted in the notes. 
 Oh yeah, here's his bio... http://www.efishantsea.com/devcon2004/bios.html

a quote from there ... http://www.efishantsea.com/devcon2004/bloopers.html

Bo lives in Ukiah as well.

Bo used to work for RT, afaik.

Yeah, he was in quality assurance and testing

In R3, upper- and lowercase chars are equal, which leads to:

>> #"a" = #"A"
== true
>> #"a" > #"A" 
== true

Isn't that a mistake?

no...

no...

>> #"a" == #"A"
== false

>> #"a" == #"a"
== true

But how can something both be equal and larger than something else 
(using normal equal)? Think about it! Look at strings:

>> "a" = "A"
== true
>> "a" > "A" 
== false

(I wouldn't go for this solution for chars though.)

Because chars can be used as numbers, this rule leads to strange 
things like:

>> a: #"a"
== #"a"
>> b: #"A"
== #"A"
>> a = b
== true
>> (1 * a) = (1 * b)
== false

How would you otherwise compare single upper and lowercase chars, 
then?

Like in R2, I guess.


You could convert them to strings. And some functions, like PARSE, 
deal with it. I'm not 100% sure, it's the best way, but it's better 
than this, I think.

I don't necessarily agree. In fact, when there is already a case 
sensitive solution (==), this seems meaningful enough, if you want 
a fast and memory efficient case-insensitive comparison.

Already documented:

http://curecode.org/rebol3/ticket.rsp?id=1497&cursor=13

I'm pretty sure the current behaviour is the better one.... and why 
something can be larger?
>> to-integer #"a"
== 97
>> to-integer #"A"
== 65

>> (1 * #"a") = (1 * to integer! #"a")
== true

Consistency between the behavior of = between characters and strings 
is really important. R3 is better than R2 in that regard.

= isn't "normal equal", it's approximate equal. All four of the equivalences 
are "normal", for different circumstances.

I guess, the question is, whether chars should be more number-like 
or more string-like. In R2, chars are number-like except in maybe 
PARSE, where they are string-like:

>> parse "a" [#"A"]
== true

even if:

>> #"a" = #"A"
== false


In R3, chars are somewhere in between being number-like and string-like, 
as I see it. We can still do much calculations with chars, but not 
all:

>> 2 * #"a"
== 194
>> 2 ** #"a"

** Script error: ** does not allow char! for its exponent argument


The last is possible in R2. If chars should be more string-like, 
then make them so, Carl! This is really confusing:

>> "a" > "A"
== false
>> #"a" > #"A"
== true

There was a big debate about this before we hammered down the current 
equivalence hierarchy, including the operators. There was even a 
suggestion to have ~= refer to EQUAL?, making = refer to EQUIV?, 
but we finally decided that the paying attention to binding and exact 
IEEE754 equivalence was too advanced for most uses, so = was assigned 
to the most forgiving form of equality. Many other languages with 
an equivalence hierarchy have made a similar choice, so it shouldn't 
be too surprising.

The last is only confusing, if chars are considered string-like, 
as in R3. In R2, #"a" being greater than #"A" makes good sense.

In general, doing math with char! values without explicitly converting 
them is kind of bad form; it leads to developer confusion. The main 
reason you'd do this is because of the awkwardness of combining operator 
and prefix expressions without parentheses. It's interesting that 
it still works in some cases, but not in others. Considering characters 
to be number-like is a bit weird, a bit too C-like for my tastes.