World: r3wp

speed is a priority especially with Rebol which can be really slow 
if you don't take care

functional:

reduce [ "hi " (either is-male? gender [ "boy" ] [ "girl" ]) , "how 
are you?" ]

vs imperativeish:
a: "hi "
either is-male? gender [ append a "boy" ] [ append a "girl" ]
append a " How are you?"
a

so although I got impression from Carl's blogposts that he thinks 
rebol should be practical vs. functional , I think a lot of it's 
power and elegance and practicality come from functional aspects 
of it (just expressing my opinion)

( ok, my memory was bad, Carl only said rebol is not Pure Functional 
PL , which is totally different thing and I don't want it to be pure 
functional :) )

http://www.rebol.com/article/0206.html

i think the power of rebol comes from the big amount of small code 
schemes so that by combining only some of them you can do all you 
want.
It's the main difference with other functional languages.
The amount of natives schemes and data types.

Adding more and more natives schemes (like matrix operations on series) 
is the way to get Rebol more and more powerful

the unification of series management is one of the major sources 
of code reduction in rebol.

the other is the fact that series are mutable, and many functions 
edit the input series directly.

even more so in R3  :-)

This works ... posting a message is actually called updating your 
status!


 page: read/custom [ scheme: 'http host: "twitter.com" target: "statuses/update.xml" 
 user: "my-twitter-id" pass: "mypassword" ]  [ POST "status=Playing 
 with REBOL and the Twitter API" ]

interesting, can you post other messages than "status=" ?

(never used twitter)

http://apiwiki.twitter.com/Twitter-API-Documentation

is there a quick way to tell if an integer overflows?

I'm missing an overflow? function:

overflow? 632479375863785946758934675892
== true

int-overflow?: func [n [number!]] [error? try [to-integer n]]

hmm.. yes, thanks.

unfortunately this might not work... to-integer sometimes returns 
a decimal... unlesss its been fixed for 2.7.6

It should work - always return integer! or error! - if the input 
is a number! (as specified in the type test of the argument. TO-INTEGER 
would  only have that problem with string input.

aaah yes... missed the input type ... sorry.

any good reason apart from the fact that data is a block that this 
is not allowed?

forskip data: [ 1 2 3 4 ] 2 [ ]

but you have to do:

data: [ 1 2 3 4 ]
forskip data 2 [ ... ]

cause the word is being used as the index.

probably cause in the time frame of evaluation the set word happens 
after the forskip hits it.

Is that a good reason?  :)

the assignment I mean.

USAGE:
    FORSKIP 'word skip-num body

Yep, the set-word gets assign to word, the [1 2 3 4] gets assigned 
to skip-num, and 2 gets assigned to body, because of the lit-word 
argument in forskip

Maybe this should be changed so that a default word is used instead 
...

if a lit-word is not supplied as an argument but a block

Perhaps split the iteration word argument from the data argument, 
like 'foreach has?

seems a reasonable suggestion.

FORALL and FORSKIP are faster than FOREACH in R3 because they don't 
have a local word that requires a BIND/copy of the code.

You don't notice this in R2 because they're mezzanine and all of 
that overhead is greater, but it is noticable in R3 where they are 
native.

Wouldn't it be more efficient to just BIND instead of BIND/copy body 
blocks in loops by default, and additionnally provide a /copy refinement 
in the (very) rare cases where you don't want the body block to be 
modified? Is it a design decision or did I missed some obvious reason?

You have to BIND/copy or *EACH would not be recursion-safe (or task-safe 
in R3).

I thought about the upcoming task! support but forgot about the "recursion" 
case. I might have wrote only 3 or 4 functions in 10 years of coding 
in REBOL that fall in that case (that's why in R2, it could have 
been no-copy by default). But tasking in R3 should make it more frequent 
I guess.

I guess I write more recursive code than you do :)

That's very possible, I use recursion only when the gain in code 
size or clarity looks obvious. Also, not having tail-call optimization 
doesn't push you much toward recursive approach in the general case.

I use it for building or processing recursive data structures - it's 
faster for that, tail-call-optimized or not. I only switch to iteration 
and hacks if the data blows the stack, which is rare.

The recursive calls limit used to be quite low (150-200 calls), has 
that limit been extended in recent 2.7.x versions?

I think so, but don't know. Haven't run into it so far, since I don't 
do recursive loops, just trees.

So you don't use recursive calls inside FOREACH loops...

Too restrictive.

I agree, using recursion for walking through hierarchical structures 
is a good approach as these structures usually have a depth limit 
far below the stack limit (e.g. parsing XML data) . In the last years, 
I've found that using block parsing for block! trees walking was 
probably the most efficient approach (code size and speed wise).

yep i use parse too, to do so. It doesn't need rerursives functions

faster, One call with parse

I prefer to use PARSE when I can, but recursion can be tricky if 
you use local variables. Not (always) impossible, but tricky. It's 
on the list to be fixed with the R3 parse proposals.

I know, i saw many implementations wich use recursive calls of parse 
(to deal with local var) in the past.
But i don't like that.

I saw it's slower most of the time than using recursive rules (well, 
it's the purpose of parse)

It's not always possible to refactor the parse rules to make the 
variable usage recursion-safe. Most of the time it is though.

even in that case, i prefer to code an emulated stack (using a block)