World: r3wp

mostly, speed-up improvements. except for 2 functions AFAIK.
Do you know which ones guys ?
(Brian, you don't play :-)

It might be easier to get this than it is to get Lisp. Lisp says 
that code is data, but it isn't necessarily so. Code realli *is* 
data in REBOL, at runtime, and the whole language is bilt around 
it. Once you get that it's amazing how easy the rest gets.

What I mean about lacking compatibility: Things like ports are totally 
different, so we can't directly port protocols. They have to be rewritten. 
VID is also an entirely new system that bears little resemblance 
to the original VID. AFAIK using DLLs is also very different. But 
of course many functions may work the same, even if they are rewritten 
underneath.

I bet, that it would be easy to port the old VID from R2, to R3, 
but it is unlikely, that anybody would want to do it.

yes, it might be possible. there were also talks about emulating 
VID at some point. maybe that's better left for a hobby project.

Brian: I noticed that I had earlier (ears ago) missed the Rebol word 
  Compose  entirely..   No wonder some things seemd to be ackward..

'Compose was an addition to get round some awkwardness ...

i'm not sure it's easy. The flow of GUI events is drived very differently. 
It's could be a burden to simulate the R2 behavior.

Well, Compose is not comfortable. More comfortable replacements were 
proposed at http://www.rebol.net/wiki/Replacement.

To be honest Ladislav, i don't see the interset of the INLINE function.
What can be done with INLINE, we can't to currently ?

The answer to your question is dead simple: nothing.

ahah, a lighter syntax ?

In fact, the Inline function can be implemented as a mezzanine, which 
would serve as a proof, that you can do without it, if you wish.

But, the same applies to the Compose function, it can be implemented 
as a mezzanine too.

Or even Reduce, if you have Do/next.

As a half.funny sidenote. I was reading http://www.rebol.net/wiki/Parse_Project
and there is comment about people having CompSci degrees.. I have 
one, and I still feel a bit dumb ...

You can certainly ask, if something is unclear to you in that page.

nah.. I think I just need to stretch my brains a bit and try to remember 
those things I did learn at the Uni years ago..

Not sure it helps

Right, some things may be newer, than what you learned at the university

And I''ve never been so much on theory side..  I've preferered practical 
things..

Well, the attempt was to define the dialect to be as practical as 
possible, which certainly isn't an easy task.

As a practical ... I ment things like Embedded,  measurement  & control 
with some asm+c code, self-made wireless protocols etc.. Of those 
I know something (and got  my master´s degree).

The parsing model of R3 is based on a theory that didn't exist when 
I was last in college :)

To make you feel better: there are at least 20 proposals in the article 
I personally don't mind about (alternatives, that weren't chosen, 
as well as some keywords I do not plan to use).

Re the practicality: a good Parse dialect may be very practical (can 
be used to implement dialects, parse texts, match various patterns, 
etc.), but, at the same time, the design of it is rather a theoretical 
task.

Which is happily over :)

Yes, although there is a possibility, that a new requirement/need 
appears.

But, anyway, I like the result so far.

The most recent Parse finding is probably CureCode #1401, which serves 
as a proof, that While is more "universal/fundamental" than Any (or 
Same), which may be found "crippled" in some situations, just because 
it "knows better than the user what to do" - I personally hate such 
software and am happy we convinced Carl to at least introduce the 
While keyword/operator.

errata: Same replace by Some

All of the real parsing gurus are happy that while was added, and 
all of the parsing newbies will stick to any and some :)

still the auto break from infinite loop with 'some ... is ... insane 
...

In other words, you are at the guru side too, Pekr

And I feel need of Huge set of examples and cookbooks just for the 
new parser..  (plus couple asperins)

:-D

Joanna, not that it is an easy reading, but..., did you look at http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse

Aheemm.. How many different sites have these docs? officlas, unofficials, 
new old antiqued ?

Too many. We're trying to move that stuff into DocBase (for community 
stuff) and the manual (for official stuff).

That was a community written book ... different purpose

was
 ? :)

Oh, never ming, you;re referring to the wikibook.

I helped starting the wikibook before R3 was announced. When R3 was 
announced, I though "well, damn, we'll have to start over, when R3 
is out in a couple of months." :-)

Just got the feeling..   was reading Wikibook..      Got this line 
(ok, it was explained, but still)   
  parse [-1] [1 1 -1]

Reminds me of those old days I used to whack together some nasty 
stuff with sed and awk ...  Thankfully I have forgotten most of those. 
:)

parse [-1] [lit -1]

That's R3 though.

Some data on R2 -> R3 conversions. I have 824 unit tests for Rebol.org 
that which can be run on both Core 2.5.6 and the latest R3 Alpha. 
All 824 pass under 2.5.6. Under R3, 670 pass and 154 fail. The tests 
only cover 32 functions (out of the hundreds if not thousands in 
the Library system). 13 of the functions will require changes to 
run under R3, 19 won't/

From the liitle time I've spent looking at the rebol.org system in 
respect of converting it to R3, the code changes required seem to 
be very small (I've only looked at the cgi and core code, no View 
or VID).


The biggest problem would seem to be the  need to change the source 
code to UTF-8. MUch of the rebol.org code is pretty old and was written 
without attention to string encoding. The newer code is mainly ISO-8859-1 
"aware" and seems to be ISO-8859-1encoded. Some of the Rebol.org 
code won't load in R3 because it contains invalid UTF-8 characters. 
Changing the source encoding is trivial but with that comes the need 
to change all the data stored in Rebol.org to UTF-8 for it to be 
processed properly.

So Joanna, if you make sure that you always use UTF-8 encoding with 
Rebol 2 you should find few problems in later migrating to Rebol 
3.