World: r3wp

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.

Who's that optimizer ?

The "REBOL optimizer" is a running joke. The best way to optimize 
your REBOL code is to post it publicly in AltME or R3 chat and dare 
people to improve it. Then the community tries to one-up each other 
to improve it :)

-_-;

It's the best optimizer known to man :)

sure :)

For certain project domains, R3 interpreted code can be faster than 
compiled code, once it's been through the REBOL optimizer.

That happened with some REBOL-vs-Java code the other day here.

but there is several criteria to optimize something.
- Best Speed
- Shortest code
- shortest memory overhead
- best ratio of above criteria

An interesting example of that is AJOIN. The R3 version has less 
memory overhead, the R2 version in 2.7.7 is faster.

Oh, and that means that the mezzanine is faster than the native :)

rare

Not really, for code that plays to REBOL's strengths. It happens 
quite often.

Rare for the kind of thing you tend to do though (emulators, iirc).

throw/catch does not work in R3?

Testing.

Bolek, THROW and CATCH work in R3 but there is a strange interaction 
with TRY.

How about we have some more refinements to read ??

Graham: my reply from R3 Chat:  I think that we will not get much 
refinements for read/write functions. The planned ones were /string 
(text) and /as (enconding). What you want is read working in a streamed 
way. We might get it in future, but I doubt we get what you propose.

Why not?  Because refinements slow down 'read?

And maybe design of read/write was never actually finished ;-)

16-Apr-2008: Prunning down read and write - http://www.rebol.net/r3blogs/0127.html

11-Nov-2009: Finalising read and write - http://www.rebol.net/r3blogs/0294.html

well, I guess we could specifiy it in the /as block

I don't know. Just read realated discussions - many opinions, what 
read/write should (not) do ...

I am with ones proposing having read/write as simple as possible, 
adding just /as for codec support. Codec API should be defined, the 
same way as we have Device API, port API, etc. /string should be 
no excuse .... in the past (1.2 days), Holger posted to IOS:

read http://something.com:my-callback