> The primary argument is to not break something that works well for most
> purposes, including teaching, at a huge cost of backwards compatibility
> for marginal if any real benefits.
I'm persuaded by this argument. And I'm glad that teachers are speaking up in
this debate - it's hard to get a balanced discussion on an obscure mailing list.
So I'm far from convinced that [Char] is a bad default for the String type.
But it's important that as far as possible Text should not be a second class
citizen, so I'd support adding OverloadedStrings to the language, and maybe
looking at overloading some of the String APIs in the standard libraries.
Remember that FilePath is not part of the debate, since neither [Char] nor Text
are correct representations of FilePath.
If we want to do an evaluation of the pedagogical value of [Char] vs. Text, I
suggest writing something like a regex matcher in both and comparing the two.
One more thing: historically, performance considerations have been given a
fairly low priority in the language design process for Haskell, and rightly so.
That doesn't mean performance has been ignored altogether (for example, seq),
but it is almost never the case that a concession in other language design
principles (e.g. consistency, simplicity) is made for performance reasons
alone. We should remember, when thinking about changes to Haskell, that
Haskell is the way it is because of this uncompromising attitude, and we should
be glad that Haskell is not burdened with (many) legacy warts that were
invented to work around performance problems that no longer exist. I'm not
saying that this means we should ignore Text as a performance hack, just that
performance should not come at the expense of good language design.
Cheers,
Simon
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
