Rename SPLIT's /INTO refinement

[rebolbot]

Submitted by: abolka

SPLIT currently has an /INTO refinement, that toggles between splitting into parts of length N and splitting into N parts (cf. the example code).

While aptly named in and of itself, this non-standard usage of /INTO conflicts with the intention to use /INTO outbuffer as a common refinement to pre-supply a result buffer to functions (to avoid allocating intermediate storage). This latter usage is currently implemented in e.g. AJOIN, COLLECT, COMPOSE, EXTRACT, REDUCE, or REWORD.

So SPLIT's /INTO refinement should be renamed, to avoid conflict with the standard /INTO usage.

;; Split into parts of length 2:
>> split [a b c d e f] 2  
== [[a b] [c d] [e f]]

;; Split into 2 parts:
>> split/into [a b c d e f] 2
== [[a b c] [d e f]]

^{CC - Data [ Version: r3 master Type: Wish Platform: All Category: Mezzanine Reproduce: Always Fixed-in:none ]}

[rebolbot]

Submitted by: fork

As evidenced by the above comments in the example code, /INTO would be a troublesome name that could apply to both scenarios...

A name that seems to only apply to the "/INTO" case could be /EVENLY..., although it would have to be explained as "Split into N equally-sized parts as best possible (with at most one non-empty piece of an unequal size to the others)"

>> split/evenly [a b c d e f] 2
== [[a b c] [d e f]]

>> split/evenly [a b c d e f] 7
== [[a] [b] [c] [d] [e] [f] []]

>> split/evenly [a b c d e f] 4
== [[a] [b] [c] [d e f]]

[rebolbot]

Submitted by: rgchris

Is it certain that split/into shouldn't be default and defer the current default to a split/skip or split/length? To say split "something" 4, it might be expected that it splits into four parts. split/skip "something" 4 would slice into four-sized pieces.

[rebolbot]

Submitted by: fork

+1 for the switch and calling the old default behavior split/skip (as proposed by @onetom)

The current default skipping behavior is pretty Rebol specific. "I split the rope in two" means something in English, and it does not mean you split the rope in many pieces of size 2

split/length has the problem as with /into... are you splitting with the intent of producing a result which will have that length? Or are you splitting into pieces which have that length? It's ambiguous.

/skip is unambiguous, has precedent, and not contentious with English usage.

[rebolbot]

Submitted by: BrianH

I agree with changing the default, but how about calling the new option /by instead? This would be more helpful when you do multi-level splitting, where the value you're splitting by would be an array compatible dimensions block, rather than a select compatible record size.

[rebolbot]

Submitted by: Gregg

+1 for the switch and calling the old default behavior split/skip.

Brian, I think it will do what you want without /BY, because of how block args are processed. Or I'm misunderstanding.

[Oldes]

Sorry.. I used split/pieces in my version as it seems to be the most appropriate for the result.

>> split/pieces [1 2 3 4] 2
== [[1 2] [3 4]]

>> split/pieces [1 2 3 4 5] 2
== [[1 2] [3 4 5]]

>> split/pieces "12345" 2
== ["12" "345"]

[Oldes]

Now one could make a wish to add /into refinement for the target where the pieces should be stored.

[hostilefork]

I used split/pieces

I think the argument would be that you're always splitting the series into pieces. So this can come off a bit like saying split/split.

/INTO is clearly a bad name. And with years under the bridge from this being last discussed, I now think that the Rebol interpretation of /SKIP would come across as the current "default" behavior, to just skip 2 each time. Which makes it seem less good for this refinement.

One thing I noticed is that Red does not have this refinement, suggesting possibly it was not considered that important. No use cases really come to mind.

I may rather drop it and wait for it to be explicitly requested, at which time the name can be reconsidered.