Ramda: Should we extend `map` to `:: (char -> char) -> String -> String`?

Created on 28 Jul 2019  路  3Comments  路  Source: ramda/ramda

A discussion on Stack Overflow (see the question, my answer, and the comments on both) on why map doesn't work on Strings, the way it does in Haskell made me wonder if we should in fact add such behavior. My first thought is no; to do so would require type-checking the output from the transformation function, and that is not how we tend to work around here. Moreover, I can see few important use-cases. map(toUpper, 'hello') //=> 'HELLO', sure, but that's already covered by toUpper('hello').

Nonetheless, it's an interesting question. Any thoughts?

@hitmands, @luqui, @bergus,

Most helpful comment

Your StackOverflow answer says enough imo: Strings are not a functor, and map should never return a string - which is not a list of characters like in Haskell, it's more like a Text or ByteString and you cannot fmap over those either.
If you want to change the current behaviour, I could see two alternatives:

  • throw a TypeError if called with a string, just to aid debugging and set expectations right
  • treat a string like any other iterable, use its [Symbol.iterator]() (not array indices) and return, uh, some other kind of iterable?

Not sure which is more in the spirit of Ramda, and what forward and backward compatibility issues a change would incur.

All 3 comments

Your StackOverflow answer says enough imo: Strings are not a functor, and map should never return a string - which is not a list of characters like in Haskell, it's more like a Text or ByteString and you cannot fmap over those either.
If you want to change the current behaviour, I could see two alternatives:

  • throw a TypeError if called with a string, just to aid debugging and set expectations right
  • treat a string like any other iterable, use its [Symbol.iterator]() (not array indices) and return, uh, some other kind of iterable?

Not sure which is more in the spirit of Ramda, and what forward and backward compatibility issues a change would incur.

Hi there,
I am actually quite convinced by your answer on s.o. @CrossEye.

I can't see a change on ramda that would make map behave haskell-like, it would be non-natural in javascript. Theoretically, as you and others mentioned, strings aren't functors.

throw a TypeError if called with a string, just to aid debugging and set expectations right

I am not a big fan of this, and would make map behave differently from other ramda functions...

treat a string like any other iterable, use its Symbol.iterator (not array indices) and return, uh, some other kind of iterable?

I'd like to see where this could bring us

Thanks @bergus, @hitmands! I guess convincing others helps me convince myself! 馃槇

Closing now.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

davidchambers picture davidchambers  路  4Comments

woss picture woss  路  3Comments

Antontelesh picture Antontelesh  路  3Comments

DanielFGray picture DanielFGray  路  3Comments

kanitsharma picture kanitsharma  路  3Comments