[ffn]

Love the language, I've been using it (phoenix) to build a more real-time version of my current rails app. But I have a concern with Elixir core's Enum. In particular, the Enumerable protocol has us implementing Enum.reduce for our own data-types, but Enum.map is written as

`reduce(collection, [], R.map(fun)) |> :lists.reverse`

is there any chance Elixir's enum core can take a page from Clojure's transducer idea and, instead of implementing map with reduce and [], implement it with transduce and some function that steps?

I've often had the need to map and filter over strings to achieve rails-like features such as #to_url, #classify, #underscore, and #humanize... but being forced to either rewrite Enum functions for strings or constantly peppering in String.split("") and Enum.join("") feels really bad.

[josevalim]

It would be possible to have something like `Enum.map |> Enum.into`. You could also do `Stream.map |> Enum.into` if you don't want to traverse it multiple times (similar to Clojure's `into`). In fact:

    iex> Stream.unfold("hello", &String.next_codepoint/1) |> Enum.to_list
    ["h", "e", "l", "l", "o"]

The reasons we don't have first class support for this though are:

1. There are multiple ways you could traverse a string. By bytes, by codepoints or by graphemes. I don't think we should pick any of those as default. Ruby did that and to this day it is source of confusion (aggravated by the behavior change from 1.8 to 1.9)

2. Modifying strings like this would be horribly inefficient. Using split/join wouldn't be recommended also as you are generating a bunch of intermediate garbage to go from string -> string. The recommended way is to rely on pattern matching and Elixir's bit syntax as the compiler will be able to optimize most cases well.