World: r3wp

Does rugby run under R3?

Kaj, thanks for the offer. Currently I am pressed for time, finishing 
some strategies in my new job. We can get back to it in few weeks 
....

OK, let me know

graham, I strongly doubt it.

Me too

But, R3 has Reb services built in?

it will, not yet though. (but, we hope to have it working for release 
or shortly after)

Would it be a good idea, if functions like ADD could take second 
argument as a block, so it could add up many values? Example:
>> add 1 [2 3 4 5]
== 15

It's the same kind of functionality as JOIN, which can take second 
argument as a block to join many values.

there is a method to do that in R3 already. :-)

ah, wait, I'm wrong. I thought you meant, adding 1 to each specific 
number in the b lock.

I see! My example were maybe not the best, because I'm not thinking 
of INC. Another example:
>> x: 4
>> add x [1 2 3 5]
== 15

Thinking a little further, what if I want to add all the values in 
a block. With my suggested ADD function, I could do:
>> blk: [1 2 3 4 5]
>> add blk/1 next blk
== 15

But that's clumsy. With JOIN, we also have REJOIN. So if we have 
this new version of ADD, should we also have a READD? (Bad name!) 
Example:
>> blk: [1 2 3 4 5]
>> readd blk
== 15

So, one week to official R3 release? Should we start count-down? 
:-)

I... don't know if I would do that :-)

you mean we should not bet on that date? :-)

But sooner or later it has to come out, no? :-)

Well, I am willing to wait, but not endlessly, let's say 7.9. is 
fine with me, I am 35 :-)

I don't think it's realistic.

some people are very quiet right now, so I guess they are working 
intensely on stuff for the next alpha.

why would Gabriele mention that date here? After all - it will be 
public alpha, not beta, no?

I don't know why it was mentioned. I would personally not mention 
any dates until we are fairly sure that there is about 1 week of 
work left.

well, it all depends when you want to release. I think that for R3 
to be feature complete, and I mean all those plug-ins, rif, rebin, 
unicode, it will take another year to be there ....

mentioning dates only makes me feel bad that we could not make it 
to that date. :-)

Pekr, the "couple of weeks delay" was for the beta, according to 
Carl's blog.

yes, there'll be a ton of work after the beta release. I hope that 
people will come together in the right groups to extend R3 to its 
full capacity.

the most difficult part will to attract new developers, being able 
to extend native (C level) code base ...

I think, we should read it as: at of 6-Jul-2007, the beta was delayed 
a couple of weeks. I have a feeling, there is being hard work going 
on, but it could be delayed yet more. We'll have to wait and see.

Personally I like the things in there to be robust better than having 
tons of features.

Geomol, yes, people are working very hard. I wouldn't consider the 
delays as anything to worry about if the dates were not published. 
There are no setbacks or things that have failed or strong disagreements 
or detours into "ohh, shiny!" land. :-) It just needs to take the 
time it needs to be finished.

I don't mind about dealys either, as much as R3 is as cool as I think 
it is going to be ...

Maybe we should send a message to Carl, that he'll receive a present, 
when R3 is out? As a carrot! ;-)

btw - Python is going to get 3.0 version too, release mid 2008, and 
Guido says it will break many code. So our schedule is still ok, 
although Python is already ahead in some areas ...

Carrot? So are we going to call a release Rabbit? :-) Knoc knoc, 
Neo ... and Neo sees rebol console on his monitor :-)

Geomol, well, hehe, to me R3 seems to be like a painting. When exactly 
is it done? :-)

John, READD would probaly be called SUM.

Question: How useful would you find the following, and what other 
aggregate funcs would you find most useful? 

fold: func [
	block [any-block!] "Block of values"
	accum "Accumulator value" 
	f [any-function!] "Function to apply"
][
    foreach val block [accum: f :accum :val]
]
sum: func [block [any-block!]] [fold block 0 :add]
product: func [block [any-block!]] [fold block 1 :multiply]
average: func [block [any-block!]][
    if empty? block [return none]
    divide  sum block  length? block
]

geomol, that kind of function is called FOLD, and we're hoping to 
have it as a mezz in R3.

our deadline is August 1st. of course, it's not impossible for us 
to miss it, but we don't want to miss it. (Henrik, Carl is quiet 
because he's away.)

ah, i see gregg has posted fold already :)

and, please remember that august 1st is our internal deadline, not 
a public statement. so, there has been no announcement about the 
beta being august 1st. i hope it will be around that date because 
that is our deadline. only Carl makes official announcements, unless 
noted otherwise. :)

What is best? To have new functions like SUM, PRODUCT, etc. or having 
already present functions operate on blocks also?

One big force of REBOL is the datatypes, so isn't the second option 
the best?

Is there a theoretical difference between FOLD and MAP?

If you choose new functions like SUM, someone might argue, that JOIN 
with a block as second argument should be another function taking 
only one argument:
JOINALL ["a" "b" 2]
or REJOIN (that we have) if the block should be reduced.

I guess, it comes down to temperement and programming style. Expanding 
existing functions would mean:
add 4 [1 2 3 5]
adding new functions could give:
sum [1 2 3 4 5]

New functions means more words to learn and remember. Benefit is, 
that it's maybe easier to read the code. hm

SUM is a standard term, and a common aggregate func. It could be 
a shortcut for "add number block". Generally, I like the idea of 
"overloading" funcs to make them smarter, e.g. a dialected version 
of EXTRACT is high on my list, but it's a fine line, and each choice 
has to be made carefully.

FOLD vs MAP - FOLD accumulates, while MAP applys the func and returns 
a series of results.

I find 'collect very usefull lately,thanks for that 8-)  will it 
be part of R3?

:-) We can hope.

i'm secretly using it in vid proto so to make the chances of it being 
in higher ;)

geomol: the problem is, that there are at least two things that add 
4 [1 2 3] could do. and, i think the most "natural" would be for 
it to result in [5 6 7].