World: r3wp

Paul, the R option exists and works like you specify.

Ahhh, that must mean that me and the Great mind of Carl think alike. 
 ;-)

I'm still a noob to RebDev.

I'd be happy if they had word-wrap, as I've been manually word-wrapping 
my own posts.

Reply to your nail-biter Henrik: #1789.

I thought Henrik's R3 GUI skills would have manufactured a GUI for 
RebDev by now.

R3's GUI is missing some necessary styles for a RebDev client, notably 
grids. Filling in the blanks needs more programmers, so we are focussing 
on getting the file management portions of DevBase integrated first 
so we can get other people involved in the process. Priorities :(

Also I'm pressed for time for about another month.

This /into option proposal is based on profile-driven *language design*. 
It's a new approach to REBOL.

I like the idea Brian.  In fact, I use that manner often in the things 
I do.

But why not make the /into default behavior?  And then use /copy 
for the alternative?

Because the series creatiion builder model is easier for less advanced 
REBOL programmers to use. Buffers need management (as #1789 explains). 
This new model is for more advanced programming, such as mezzanine 
and library code.

Well, right now i need discussion and consensus. I have CureCode 
wishes, mezzanine modifications, new functions, and massive optimizations 
all waiting on this. I'm really blocked until this is decided on.

I guess, I don't follow.  Maybe, I'm jumping to conclusions about 
what /into actually implies.  To me, /into implies that the original 
series passed to the function is what is modified and not a copy 
of it.

No, that's the /no-copy option - it's a completely different thing. 
See #1789.

Well, then I'm in favor of the no-copy option as the default behavior.

Please read #1789 before you make that decision. The difference between 
/no-copy and /into is important.

So you mean something like:
rejoin/into [a b c] out
instead of:
append out rejoin [a b c]
? I think I like it.

Yes. But not for (RE)JOIN because JOIN or REJOIN /into is exactly 
the same as INSERT and INSERT REDUCE. What we *do* need to add /into 
to is (RE)MOLD, (RE)FORM, REDUCE, COMPOSE, READ, COLLECT (needs changes), 
MAP and EXTRACT.

Brian, I read it and the option I believe should be default behavior 
is for the original series to be modified.

Which is what I thought the /into option was implying.

BrianH: I'm 100% for /into and, if possible, it would be one of my 
top features to backport to R2.

I thought that too.

No, those are modifier functions. We already have those, and the 
algorithm for implementing a modifier is completely different than 
a builder. Some functions (like DELINE) could be changed into modifiers 
with /no-copy and that wouuld make sense. It doesn't make sense when 
the builder is creating something based on a spec or template, which 
often has a completely different datatype than the result. For these 
functions an output buffer makes more sense.

(That was a reply to Paul)

Ok, then I'm for the modifier as the default operation.

Modifiers and builders are completely different classes of functions, 
with some overlap (see DELINE or REPLACE vs. REWORD). When the function 
is making a copy of the spec with some tweaks, a /no-copy option 
makes sense, or a completely separate function with complex mezzanines. 
When the builder function creates something really different than 
the spec (like ARRAY or READ), there is no point to a /no-copy refinement 
since there is no eqivalent modifier even in theory.

That is the difference between /no-copy (which turns a builder into 
a modifier), /copy (which turns a modifier into a builder), and /into 
(which makes a builder insert into a provided buffer instead of creating 
its own series).

Brian, now you say it inserts. Does it clear the series and inserts, 
just inserts or overwrites the existing content?

So read-io in R2 would be an example of /into?

Henrik: Inserts and *doesn't* overwrite the existing content. Paul: 
Yes.

The functions for which /into would give us the absolutely biggest 
bang-for-the-buck are REDUCE and COMPOSE. Have you ever done chained 
calls to INSERT or APPEND of intermediate blocks created by REDUCE 
or COMPOSE? All that code goes away.

Ok, now I follow what your saying.

I don't follow. I'm an example guy.

henrik, the key is your supplying a buffer.

for /into.

READ/into would replace READ-IO, which doesn't exist in R3.

Paul, I think I follow that far. What happens to the buffer is what 
I don't get. When BrianH says it inserts, that implies a lot of overhead 
on manipulating that buffer to me.

I think the same way Henrik.

Henrik, the trick is that it would work *exactly* like INSERT. If 
you want to replace the contents, CLEAR or REMOVE/part it yourself. 
If you want it on the end, use TAIL. If you want to chain, go for 
it. The calling code can manage their buffers however they want, 
and we can provide buffer management helper functions if we need 
to. I did extensive testing and INSERT is the most general function 
to model after.

BrianH, now I'm confused. Is INSERT without tail much faster on blocks 
in R3 than in R2? Or do you say: "reduce/into [blurp] tail out" ?

BrianH, but are we not doubling in size the memory space for that 
function?  If were passing it a huge series to begin with - would 
we not end up with a buffer that is potentially as big or bigger 
than the original series if were inserting data?

If you *only* model after INSERT it minimizes the changes to the 
builder code. We aren't saving memory on a single call, we allowing 
careful reuse of memory on multiple calls. I've done the tests, the 
overall memory overhead goes down drastically.

Most of the time a function using build/into functions will preallocate 
a series, build some data into it, then return the series. Builder 
functions can use lower-level builder functions. You get a reduction 
in intermediate series creation overall.

Give me a moment and I'll show you an example, using variants of 
the COLLECT function.

; Here's a version of COLLECT without /into, a typical example of 
a builder.
collect: func [

 "Evaluates a block, storing values via KEEP function, and returns 
 block of collected values."
	body [block!] "Block to evaluate"
	/local output
][
	output: make block! 16
	do func [keep] body func [value /only] [
		apply :append [output :value none none only]
		:value
	]
	output
]

; Here's COLLECT with the /into option.
collect: func [

 "Evaluates a block, storing values via KEEP function, and returns 
 block of collected values."
	body [block!] "Block to evaluate"
	/into "Collect into a given series, rather than a new block"
	output [series!] "The series to output to"
][
	unless output [output: make block! 16]
	do func [keep] body func [value /only] [
		output: apply :insert [output :value none none only]
		:value
	]
	either into [output] [head output]
]


Note that the version with /into also lets you use other series types 
than just block!. This option added to REDUCE and COMPOSE would let 
you create parens and paths as well, even though REDUCE and COMPOSE 
can only take block! specs.

This is where we get our "bang for the buck": minimal changes, maximum 
benefit.

Is INTO not meant to be handled natively?

The /into option will be handled natively when added to natives, 
but handled by mezzanine code when added to mezzanines. It's a minimal 
change either way. Backports to R2 of native /into options might 
need mezzanine wrappers though.

The overhead of /into is two comparisons per function, and one assignment 
per insert in the function. Really low.