World: r3wp

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

read/as ftp://ftp.rebol.com/matrix.avi[ file: %movies/matrix.avi 
]

and to resume


read/ask/seek ftp://ftp.rebol.com/matrix.avi[ file: %movies/matrix.avi 
 ] current-file-size-of-matrix.avi

hmm, but /as was proposed to specify just type of encoding IIRC, 
not some other functionality ... some of us wanted /as being more 
general, allowing you to specify a codec to decode. Codecs are so 
far inefficient (not streamed), because you have to read all data 
firts, then pass it to encode/decode.

Carl never posted a resolution to read/write case ....

Need some way to pass parameters to scheme actors.  Andreas is using 
read/lines !

I think my schemes are making R3 unstable.  Tried to post a message 
and got from chat


rebol system error #1301: invalid datatype 99 ... should never happen 
...

Well, we don't need of specific refinements, cause we can pass a 
block to read (which is converted to a port!).

>> read [scheme: 'ftp host: ... path:... other_data: ....]


The  block format could be used to pass other parameters in a more 
handy way.


>> read [ftp://ftp.rebol.com/matrix.avifile: %movies/matrix.avi]


And the good news, is that it's absolulty possible to have something 
like that now.
We just have to patch the function: system/intrinsic/make-port

Steeve - it is good we have you here :-)

btw - some time ago someone stated here, that current https scheme 
is done "old school". Was that you? Isn't now the right time to define 
the better way (if any) to aproach schemes and networking? :-)

Well, I am using a write spec block ...

sorry again (it's true i said this)