The concept here would be that it would take in a string, give it to you character-by-character, and then you could produce a character or string to add to what ultimately becomes a string output.
MAP-EACH should work on strings, but shouldn't by default return a string, it should continue to return a block; that would make it more useful for polymorphic code. Making it return a string should be done with an /as option (similar to Oldes/Rebol-issues#724, with errors triggered for incompatible types), or with an /into option (#709); that would also make it more useful for polymorphic code. Why should the type of the input constrain the output type, when we could have controlled conversion? See Oldes/Rebol-issues#2081 for an example of this kind of controlled conversion.
Rebolbot added the Type.wish on Jan 12, 2016
Hostilefork commented on Oct 8, 2018:
Ren-C follows the convention of always producing a BLOCK!, while accepting other series types as input. This leans on some of the justifications given for getting rid of the /INTO refinement....accepting the generality of blocks and looking for other means of optimization.
Submitted by: fork
It would be nice if map-each could take a string in and give a string back.
The concept here would be that it would take in a string, give it to you character-by-character, and then you could produce a character or string to add to what ultimately becomes a string output.
Imported from: CureCode [ Version: r3 master Type: Wish Platform: All Category: Native Reproduce: Always Fixed-in:none ] Imported from: https://github.com/rebol/rebol-issues/issues/2157
Comments:
Submitted by: BrianH
MAP-EACH should work on strings, but shouldn't by default return a string, it should continue to return a block; that would make it more useful for polymorphic code. Making it return a string should be done with an /as option (similar to Oldes/Rebol-issues#724, with errors triggered for incompatible types), or with an /into option (#709); that would also make it more useful for polymorphic code. Why should the type of the input constrain the output type, when we could have controlled conversion? See Oldes/Rebol-issues#2081 for an example of this kind of controlled conversion.
Ren-C follows the convention of always producing a BLOCK!, while accepting other series types as input. This leans on some of the justifications given for getting rid of the /INTO refinement....accepting the generality of blocks and looking for other means of optimization.