World: r3wp

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.

So, I'd like to ask if there is any sureproof way of telling apart 
which scripts are for R3 and which are for older Rebols?  This may 
indeed be obvious question, but I try to ask these now as long as 
I can cause I'd expect these to be asked a lot by the time R3 is 
released.

I don't think there is currently.  The community should decide on 
the best method though.  I think simply changing the extension could 
be useful such as .r3   Other languages use extensions to differ 
between code version such as .c verses .cpp    However, another method 
is simply to put a stamp message in the header such as:

REBOL [
     Title: "My coolest Program"
     Stamp:  R3
]

There is no such way. Some scripts work for many versions of REBOL, 
some don't. A way to tell is to use the NEEDS entry in the headers. 
See:
http://www.rebol.com/docs/core23/rebolcore-5.html#section-2

But it's not widely used.

I don't think Needs should be used for the version requirement but 
for external needs.

Those items should be separated from the version requirements.

Or I should say execution requirements of the script.

Id rather see it like

REBOL3[
	Normal headers here, as much as you feel the need
]

So  needs would be used with Stamp as this:

REBOL [
    Title: "My Coolest Program"
    version: 1.0
    Stamp: 'R3
    Needs: [2.0 ODBC]
]

I don't really have a problem with the REBOL3 way.  It seems this 
was discussed before and some valid concerns were raised but I don't 
recall what they were.

The problem I do see with using REBOL3 is that you then need to use 
REBOL3.1 etc... as new versions come out.

That´s true.  but I tend to belive it will be highly unlikely there 
will be as much important groundbraking changes on moving from 3.0 
to 3.1 as is from 2.6 to 3.0.

My point behind this forward/backward compatibility chat is primarly, 
that I'd like to see a way to stop average user on accidently loading 
old scripts on R3.  I'm sure the top-100 gurus of Rebol can dance 
their way around differences at will, but at the moment R3 (and R3/view) 
is released there will (hopefully) be considerable number of new 
users for Rebol.


Secondary would be giving an idea of a toolkit ( lint like script 
for Rebol  or perhaps some debug-mode at runtime? )  that would allow 
developer to see which parts of the code needs to checked/rewritten 
for R3 compatibility.

I do admit I have not searched trough old posts (blogs, vikis, archives. 
whtever is available) to see if this is obviously an old issue (and 
not necessary to talk again?).

other problem is the retro portablity 
....

all the scrpts made accross the 10 last years usng REbl 2 wll then 
not be usable with R3 ... Ans this have been discussed lke 2  years 
ago when carl proposed to do a major verson upgrade that was wth 
the discuton arund the "Because no one knows it  do i change rebol's 
name ?". It was sad to say that rebol after 10  yeas was stll in 
the underground limbus....

Many non View scripts will be portable with no, or little, change. 
This article discusses my earlier conversion experiences:
   http://www.rebol.org/art-display-article.r?article=j26z

Is this based on a small sample of your own scripts?  Any largish 
scripts tested yet?

Well my motto is a little different.
structural complexity allows  functional simplicity

Wich means, more you make your code compact and fast , more your 
code is reused.

(sorry, wrong thread)

Seems to contradict the idea of using the least powerful language 
...

i was discussing about "writing easy to understand mezzanine" again 
 "compact and fast but maybe hard to understand mezzanines"

if your code is slow, can always speed it up by running a faster 
cpu :)

machine cycles are cheap .. brain cycles expensive

but at some point, if your code is too slow and too huge, it will 
not be reused, so that you'll lost your investment

if your code is not maintainable it will not be re-used either.

Or, you'll have a job for life!

the scalability is also linked to the compacness.

Suanda, it was partially your article (alongside CS Rebol3 blog) 
that got me wondering loud about potential need of tools/flag/tag 
related to R2/R3 differences. I'll move some thougths about this 
to Advocacy.

Peter: "All 824 pass under 2.5.6." - then I would say, that the tests 
are biased in favour of R2 2.5.6, since I have lots of tests failing 
in 2.5.6

The 824 tests are unit tests of the production Rebol.org system which 
still runs in 2.5.6. So in that sense they are biased in favour of 
 2.5.6. My point was that many of them still work unchanged under 
R3.


The two main reasons that I started to build the Rebol.org unit tests 
was that they would help stop bugs being introduced when the code 
is enhanced and also help when it comes time to upgrade the version 
of Rebol that Rebol.org uses.


Sadly, I haven't written anywhere near the number of tests yet to 
reach my objectives.


(By the way, I wrote most of the tests before R3 was announced; I've 
recently converted them to a test framewoirk that also runs under 
R3.)