Should MAP-EACH be changed to splice by default?

#1

I was trying to do something in JavaScript, going character by character and replacing text in a string. JS strings are immutable so it was kind of annoying.

It made me wish to be able to do a MAP-EACH on a TEXT! and have the body return either a NULL, a CHAR!, or a TEXT!...

>> map-each c "123" [
     case c [
         #"1" ["one"]
         #"3" [#"T"]
     ]  ; don't have any match for 2, so fall through with null
]
== "oneT"

The ability to go element-by-element and map to potentially 0, 1, or many elements seemed like an appealing thing. Enough that I wondered if MAP-EACH should splice by default.

Splicing is strictly more powerful, because you can put things into a block:

>> map-each x [a [b c] <d> e] [if not tag? x [x]]
== [a b c e]

>> map-each x [a [b c] <d> e] [if not tag? x [reduce [x]]]
== [a [b c] e]

>> map-each x [a [b c] <d> e] [if not tag? x [:[x]]]
== [a [b c] e]

It would seem to suggest you'd want an /ONLY for convenience.

There are benefits. But as with APPEND doing splicing when it's not asked... it's a likely source of bugs. This category of bugs is probably one of the biggest.

Another side of the argument is to go with MAP-EACH as it does today, producing a BLOCK! always. If you always get a block, then you get to make up the step which coalesces things.

I've made arguments for this line of thinking in the past. It seems a bit wasteful to always be producing a BLOCK! from a large text string, then merging it together. But perhaps the argument made against /INTO applies here too...that anyone who cares wouldn't use MAP-EACH?