World: r3wp

Algorithms dominate speed over details in almost all programs

It goes the other way too: If you try to write REBOL-like code in 
most other languages then you will run into a wall. For most you 
will need to reimplement most of the natives before you can start, 
if it is possible to do REBOL-like code at all (often not with parsers). 
And when you do manage to get that code running it is often slower 
than REBOL code because of the optimization its natives have gone 
through.

Yes, Greenspun's tenth rule

There are some exceptions to this, languages that have comparable 
levels of built-in functionality, or more: Common Lisp, or Perl 6 
for instance.

Well, then we're doomed against Perl 6 :-)

PARSE rules are comparable to Perl 6 rules, both in speed and functionality. 
There are tricks you can do in either that you can't do in the other, 
or in some cases not easily. R2's PARSE outdid Perl 5's regexes, 
but R3 had to drastically update PARSE to catch up with Perl 6's 
rules.

I never heard Carl mentioning that as the objective :-)

I was the one who managed the parse proposals project - it was *my* 
objective.

There are tricks that you can do with dynamic rules that are provably 
impossible for static rules to do (patterns that static rules can't 
recognize). PARSE is a superset of the PEG model, while Perl 6 rules 
are a superset of recursive descent (LL), and there are patterns 
that LL can't handle that PEG can.

PARSE is dynamic PEG - there's nothing else like it (known to Wikipedia 
at least).

There's a lot in this world that is kept from Wikipedia...

Nothing publically released in even commercial form then.

There are a lot of tricks that you can do in REBOL's DO dialect as 
well that can't be replicated in a compiled language without using 
self-modifying code. And vice-versa as well. Tradeoffs. But once 
you choose interpretation then you can optimize the language semantics 
to make that really efficient. That is why half of what a compiler 
does is done by LOAD, and optimized REBOL code looks a lot like what 
the other half of a compiler does. That is why REBOL DO is more comparable 
to one of Scheme's macro systems than it is to Scheme itself.

Exactly: REBOL's tradeoff is that it's a slow language that allows 
you to write fast programs

R3's DO dialect can be slower than compiled code for certain code 
patterns, but faster for others, depending on the compiler and language 
you are comparing it to (many dynamic languages were slower for a 
lot of code until recently). But you can make things a lot faster 
if you stop thinking of REBOL as being a language, and start thinking 
of it as being a library of native functions and datatypes, with 
a variety of high-level scripting languges built in to script that 
library, and some built-in functions written in those scripting languages. 
Plus you can add your own libraries and scripting languages if you 
like. Looking at things that way is the first step to becoming good 
at hand-optimizing REBOL.

R3 had to drastically update PARSE to catch up with Perl 6's rules.
 - that is not an objective, that is a statement, as I see it

such (or worse) problems I have with almost everything stated above

and, btw, no update to PARSE was "drastic" in fact

That's true, "drastic" is a bit of an overstatement. Almost(?) everything 
you can do in R3's PARSE you could do in R2 with dynamic parse tricks, 
DO dialect tricks or a preprocessor. But for the average PARSE user 
who can't understand the advanced workarounds the new capabilities 
are just that: new. If you look at idiomatic R3 rules compared to 
their R2 equivalents then the changes at least *look* drastic. Certainly 
different enough that for most people PARSE is quite a bit more powerful.

And it was an objective, from way back when we did the first round 
of PARSE proposals. At the time I had been following the development 
of Perl 6, especially their rules enhancements. Some of the PARSE 
proposals were based on trying to catch up with or show up Perl 6, 
and others came from tricks that other parser generators like ANTLR 
could do (like IF). To be fair, it was an unstated objective, at 
least on the pages. Peta had different objectives of course, like 
better matching the PEG theoretical model, and those were also good.

I'm sure that you had other objectives as well when you got involved 
in the most recent parse project 6 or 7 months after it started. 
Were you involved in the first round of parse proposals about 6 years 
ago? I remember Gabriele making a page for them after they had been 
discussed for a while, but not whether the initial discussions were 
here or on the mailing list.

Your recent work on the project has been much appreciated.

To be concrete, the resons, why I objected to "drastic" were:

1) R2 parse rules work in R3

2) R3 parse rules either work in R2, or can be translated easily 
to R2 (using e.g. the

http://www.rebol.org/view-script.r?script=parseen.r

functions)


Thus, everybody - don't be afraid of any "drastic" changes, nothing 
you learn or prepare in R2 will be lost, in fact.

When I look at the parse project, I see these changes as very useful:


1) the FAIL keyword - has been used as an idiom and proposed before 
the parse project started

2) the NOT keyword - has been used as an idiom and proposed before 
the parse project started
3) the AND keyword - a new and useful addition

4) the QUOTE keyword - used as an idiom and proposed before the parse 
project started

5) the REJECT keyword - a new and useful addition allowing to stop 
a parse cycle with a failure

6) the IF keyword - used as an idiom and proposed before the parse 
project started


As far as other improvements are concerned, I do not find them useful, 
and do not plan to use them, in fact. (YMMV)

When I look at the REJECT keyword - the FAIL idiom was used frequently 
before to obtain exactly the REJECT effect

As far as the speed statements go, I perceive them too inconcrete, 
and, therefore, misleading.

My 2 cents. 

It appears to me that the new RETURN command is underated currently.
It can compete in many places with idioms involving FIND + COPY.

This result looks quite unbelievable to me:

>> time-block [quote (x:)] 0,05
== 1.983642578125e-7

>> time-block [first [(x:)]] 0,05
== 2.46047973632813e-7

, how is that possible?

(the only reason, that looks probable to me is, that FIRST calls 
PICK...

You're right, FIRST and LAST call PICK
I discovered it while writing  my first scheme in R3.

That was done to make datatypes and schemes easier to implement and 
more consistent, and because we dropped reflection with ordinals.

I agree Steeve, and use PARSE RETURN a lot in adhoc code. I use all 
of the new addidions quite a bit, except for REJECT, which I had 
forgotten existed (don't remember the proposal for it).

addidions -> additions

There was one wiki/doc/blog/curecode page, describing differences 
between various possibilities of copying or not stuff during e.g. 
object construction. Could someone help me to find it? I would like 
to re-read it ...

It's on rebol.net, so down, but the bookmark I have was

http://www.rebol.net/w/index.php?title=Copy_Semantics&redirect=no

rebol.net is up again, at the moment. In case it is done when you 
try to follow the "copy semantics" link, Yahoo has a copy cached.

down*

Have we had REBOL 3 for 64-bit OS yet?

Don't think so

I ran out of memory using R3 because of a huge map!. I was doing 
a Chinese social-network-graph analysis. If R3 supports 64-bit OS, 
I will have the 64-bit HW, 64-bit OS, and 8 GB RAM  ready. Too much 
data to analysize, too less memory.

interesting :-)

Indeed :-)

Actually, Sharp phone using our Tapas OS (which is based on Android) 
is shipping in China. (http://www.udeek.com/archives/628) I hope 
that R3 with View can be port to android soon.

So I can introduce it to Chinese mobile phone users.

Jerry, have you considered to put your wish to CureCode?

Yes, please! I am glad that someone has finally run into the 32bit 
memory limits in R3 with real code rather than just test code :)

Nevertheless, there may be a problem with a map! hash limit, so, 
I am not sure, that just a simple solution would suffice

We already resolved that problem earlier - maps rehash with a bigger 
limit when they run out of room now. All we need to do is provide 
Carl with an appropriate number of items to hash, where Ladislav 
would know what I mean by appropriate.

R2 would populate the block below with 200 (or so) random values.
R3 populates it with one value replicated 200 times.
Bug, nasty gotcha, or inexplicably elegant feature?

    random/seed now/time/precise
    blk: copy []
    loop 200 [append blk random/secure "abcdefghi"]
    print length? unique blk
    == 1    ;;R3's result (a110)