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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
