World: r3wp

i propose a new fork for rebol.
REBOL-EACH

hehe :)

fact is that find with a codeblock as criterium would be very usefull 
.. maybe it already exists under some other name? I remember someone 
proposing it not a long ago too

Pekr, the FOR* functions have their own naming convention, and for 
historical reasons "-" isn't included.

I use map reduce and seek  at jsgoo and I can do a lot of stuff with 
those (an appy inject for dictionaries) .. let's say you want to 
check if users with username and password exists in a block of users:

find-each U users [ all [ equal? U/user user equal? U/pwd pwd ] ] 
... much cleaner and more error prone than with foreach IMHO ( and 
these functions show intent of why you are looping through block 
of users )

(seek is similar to  what here would  be find-each for example)

Steeve, the *EACH functions have a really specific calling convention 
and all have the same bind/copy overhead for the code block. The 
other series functions have neither of thoise characteristics.

Janko, I agree on one point, i dislike the name remove-each (too 
long).

Why don't we use the short name "filter" which is not used anywhere 
else (so we don't need -each prefix to decipher it from other uses).

(error proff  not error prone ) :))

Janko, REMOVE-EACH is not reverse in meaning - elements are removed 
if they meet a particular criteria. The REBOL version is modifying, 
though.

Steeve, is the filter function modifying or does it return a new 
series?

Brian: but don't you usually want to whitelist not blacklist stuff, 
(what should stay not what should be lost) ? I don't use something 
like filter much so I don't know what is more used

I use REMOVE-EACH a lot in R2, but mostly because of how fast it 
is. It is easy to make your condition return false or none.

ok

Pekr, MAP-EACH (using the new name) is used in LOAD to implement 
LOAD [%s1.r %s2.r ...]. I don't know how it is used in the rest of 
the mezzanines. I mostly use it in my own code, but the version I 
backported to R2 as a mezzanine.

can I just express humble request that if you will have something 
like map in "core" please also have accumulate .. they are cousins 
if you use one you will also the other .. (like map-reduce) :)

I tried, but it won't go in the core - it has been moved to R3/Plus.

to bad... I gues some people won't use neither map-each or accumulate 
, but those that will use map-each will also use accumulate, as they 
together give you the most usages of foreach and other primitive 
loops

Other functions that are in the core now will also be moved to R3/Plus. 
We don't know which will make the cut, just that the cuts are coming. 
The core will be tight, bt the functions will still be available 
if you need them.

ok.. no problem I will survive .. I am happy that they will be there 
core or plus

Janko, map and fold are only efficient in functional languages that 
are compiled and optimized. In hand-optimized, interpreted languages 
iteration is *much* more efficient.

You could use map and fold to implement foreach, but FOREACH is much 
faster that that implementation.

that that -> than that

if I would care only for efficient I wouldn't be using compiled languages 
anyway .. sometimes it doesn't matter that much .. I like map/fold 
because they cleanly express what you want to do , you don't have 
to setup and update temp variables and they are expressions ( they 
return result)

wouldnt = would

Pekr, LOAD-PLUGIN is an internal function. We reserve the most awkward 
names for the internal functions :)

And READ-TEXT doesn't exist and won't - it will probably be READ/text 
instead.

I don't know about the name "fold" - it has ambigous meaning in English, 
with the primary meaning being something else.

I don't care about the exact name much ... I usually call it reduce 
but reduce has a very important and basic meaning in rebol already

Yeah, and a different meaning too...

I am OK with MAP -> MAP-EACH.

BrianH: one question - what is the motive to have R3/plus? Is there 
really a need to move few funcs out from main R3 module? Isn't it 
a bit preliminary?

ah, BrianH, if you think that I will not mind have read/text, then 
you are unlucky here - man, it really sucks :-)

This is exactly the case, where something is under-engineered, and 
influences REBOL's design. There would be no need for such an exception, 
if Codecs would be able to work the streamed way, not just upon the 
data in memory ....

Above reminds me - does our parse enhancement proposal contain request 
to continuous (streamed) parsing? I can imagine parse being fast 
enough to have REBOL level codecs. But surely I don't want to read/part 
manually, nor do I want to read 1GB of video into RAM, just to find 
out, what the codec is :-)

parse on ports definitely is possible, but would have limitations. 
 because of the rollback aspect of rules.

if bytes aren't available anymore, we can't rollback, obviously...

could be solved by buffering, but the quesiton is, how much to buffer 
anyway, so it really might not work :-)

Pekr, I'm still mad at you for making me think R3 was almost done 
a year or so ago.  I waited with great anticipation for that date. 
 That was a big letdown!  :>)

in cases where the data is pretty linear or backup isn't needed due 
to format, a simple error is all you need to return when you encounter 
un-expected data... this can mean streamed xml parsing.

increasing latency, but not throughput if you chain two servers, 
or two threads.

Louis - then go and smash your head agains the wall, it might help 
:-)

I never said R3 is close to being finished. So what let-down you 
are talking about? We were talking public release, which happened 
and is available for some time.

Pekr, I'm doing that right now head smashing right now trying to 
find a bug in my script.  It doesn't seem to help. But don't worry. 
I'm not really mad at you. Just joking.

Pekr, the reason for R3/Plus is so we don't have to say no to people's 
requests for new functions, but don't want to bloat REBOL. With modules 
we don't have to make everything monolithic anymore. We have a new 
situation with R3.

The main advantages to having functions built into REBOL:
- REBOL itself can use them.
- You can count on them being there.

- They will be tested and reworked by the best of the community (the 
REBOL optimizer).

The main disadvantages to building functions into REBOL:

- Increases overhead, both in startup time and memory overhead. Compare 
R2 /Base to /Core to see what I mean.
- Predefines more words.

- These might not do what you want, so you'll end up redefining them 
anyways.


Building a community is a balancing act. Once we started taking requests 
for new features to make REBOL better, the floodgates opened. Even 
after filtering out the impossible or otherwise bad ideas, there 
was a lot of good stuff in there. But we don't want to bloat REBOL 
into Perl.


Fortunately, we had added modules to R3 to help organize the code 
and deal with the last two disadvantages to building in functions. 
And we have DevBase to accept community contributions. These are 
all the infrastructure we needed to create a standard library, tentatively 
called R3/Plus.


So now we don't have to worry about accepting requests for new features, 
because we know how ruthless we are going to be about our mezzanine 
cuts. If REBOL itself uses the function, it either stays as a mezzanine, 
or in some cases goes native. If the value of the function for users 
is high, the overhead is low, and there is consensus, it may get 
to stay too. Otherwise they become library functions. FUNCTOR wasn't 
the first cut, and it won't be the last.


Keep in mind that with plugins, library functions can be native too. 
And the REBOL optimizer still applies. And with modules you can declare 
your dependencies. There's very little downside to having R3/Plus.

As for the Parse Proposals, well, the proposals need some reorganizing. 
We've had some months to think about them while we've been working 
on other priorities, and one thing that is clear is that some of 
the operations need to apply to only certain data types and not others, 
and some are more global.

The existing parse model could extend to ports if they are seekable. 
Alternation, backtracking and position setting would be translated 
into seeking. The value assigned to words with the set-word operation 
would be an integer offset. The rules would look the same.

Buffering would be handled by the port scheme and the underlying 
OS - no explicit buffering necessary.

This could only work with the R3 port model though, not with R2's 
port model.

hmm, somewhere, i have a script which simulates parsing on an opened 
file (a port) in R2

R3 ports are vaguely similar to /direct ports in R2, but with better 
buffering and in some cases asynchrony. There are more advantages, 
but those are the main ones that apply here. You'd need /read and 
/seek mode to parse with backtracking.