World: r3wp

I would like to see Extensions and Host code finished to final state 
(it means support for devices, vectors, callbacks, etc.), and concurrency 
added too, or it imo has no sense to call it a beta ...

Rapid release model, remember. There's no such thing as a final feature 
set. Beta means that what is there is expected to work.

Nonetheless, extensions and host code in a more usable state is likely. 
Concurrency less so for the 3.0 release - concurrency is a big issue 
that needs more review, particularly once the subtleties of the model 
are well known enough to make the mezzanines task-safe.

Task-safety will require a full code review, natives included. Probably 
some adjustments to the system model and module code too.

And in the meanwhile, R3 is usable for some purposes now. More so 
with some bug fixes. It will be time to go beta soon.

I think you should stick to announced release dates. Better axe some 
features than not to deliver

Especially when the features can be added later. The rapid release 
model means that "later" releases are still coming soon :)

what about a sum or product functions for R3?

>> sum [1 2 3]
==6

Suggest them in CureCode as wishes. Or write them up as mezz or extension 
functions - those are easy to adapt.

will do when I get the chance.

I'm all for it. I've suggested them in the past, but didn't get much 
traction. Here's a non-recursive starting point.

    ; Should our seed value be 0.0 to coerce to decimal? If they
    ; include a decimal value before any overflow, it will be OK.
    ; Changed to match the first type in the block.
    sum: func [block [any-block!] /local result] [
        result: any [
            attempt [make pick block 1 0]
            attempt [0 * pick block 1]
            0
        ]
        foreach value reduce block [result: result + value]
        result
    ]

I just added the wish request.

Why the coersion to decimal?  Just curious.

Should sum [] return 0 or none?

well, if only the default math operators could accept series of scalars 
by default, it would be incredibly simple and powerful.
It should not be so hard to have that behaviour nativly...
A + [1 2 3 4] == A + 1 + 2 + 3 + 4

Vector math has already been suggested.

yep, but we are always waiting

Coercion to decimal would be to prevetn overflow. I prefer not to 
do that though.

Zero versus none is a good question Brian. I have SUM return zero, 
but my AVG func returns none.

0 seems better, it prevents throwing useless errors
(my old claim)

We might not need to coerce to decimal. The first decimal in the 
list will make that coersion for us. And we don't want decimal results 
for a list of integers - it's a loss of precision. I suspect that 
initializing result with the integer 0 will be sufficient.

Then any decimal or money in the list will promote.

Agreed. The only issue is if you don't get a decimal value before 
an overflow occurs, but that's just something to doc.

Actually, documenting that this function doesn't do any error handling 
beyond the arguments of + would be good.

Agreed.

Sounds like the function is moving along.  Great thing is that if 
you build the one you have what you need for the product function 
as well.

sum: func [block [block! vector!] /local result] [
    result: 0
    foreach value reduce block [result: result + :value]
    result
]

Some error handing, some speedups, and vector support.

no need to return the result at the end

foreach do that

Not for a empty block.

right

And it will just throw an error if the block contains anything not 
addable.

That's the R3 way - throw a useful error so the programmer can fix 
their code, no DWIM :)

why the :value?

Your already reducing the block.

In case reducing the block makes a function or some other active 
value - no double eval. It's a way to trip bad errors quicker.

ok.

uggly one-liner version.

sum: func[block [block!]][

 foreach [v1: v2] next head reduce/into block copy [0 0][v1/1: :v2 
 + v1/0]
]
-_-;

yeah !!!! i do not use any locals

...

It uses a lambda local. :-)

i should have used forall, less uggly :-)

And faster. Reversing the order of arguments might not be a good 
idea though - some operators are more forgiving of their left value.

i was not seriously doing a proposal :-)

v1/1: v1/0 + :v2

Yeah, I'm trying to remember (since I didn't comment it) why I coerced 
the result. Something in my brain says there was a good reason.

Maybe I'll remember if we write a test suite for it.

We should make a whole module of math functions, with test code. 
Let the REBOL optimizer at it and then see what we can include.