String != [Char]

[Tillmann Rendel]

Hi,

ARJANEN Loïc Jean David wrote:
> But now we have at least two tasks to do before we can put up the
> proposal: define what operations should be supported by String and
> should we apply this proposal in the next batch. Given that this
> proposal will break many codebases (we shouldn't hope to apply all of
> list's syntax to this string type) should we apply it alone or wait
> until we have more other codebase-breakers to apply ?

I would expect the following steps:

  1. Define what operations should be supported by String,
     that is, define a String API, possibly including thoughts
     on performance, formal specification, tests, benchmarks, ...

  2. Convince all Haskell implementations to provide an
     implementation of the String API outside the Prelude, as an
     additional module (in the base package?). That implementation can
     be based on [Char] or something else.

  3. Convince all string-like-packages on Hackage to provide
     exactly the String API in a separate module, so these packages
     are now drop-in replacements for the String implementations from
     step 2 above.

At this point, we haven't touched the Prelude, but we have a blessed 
String API with multiple implementations. So applications can opt-in to 
use that String API instead of the Prelude-based [Char]. This allows us to:

  4. Convince packages on Hackage to use the type String (from
     step 2) instead of Prelude-based [Char]; or to use the StringLike
     class instead of a concrete string type.

  5. Refine the String API according to experience.

And finally, we can:

  6. Change Prelude.String to be the type from step 2 above.


My hope is that because of steps 2 and 3, the investment from step 1 
starts to pay off long before we reach step 6.

   Tillmann