On 20.09 12:59, Henning Thielemann wrote:
Handling large amounts of text as haskell strings is currently not possible as the representation (list of chars) is very inefficient.
Efficiency is always a reason to mess everything. But the inefficiency applies to lists of every data type, so why optimizing only Strings, why not optimizing Lists in general, or better all similar data structures, as far as possible? Why not doing it in a transparent way by an optimizer in the compiler? This is certainly the more complicated task, but the more promising target for the long term. I very like to apply List functions to Strings, so the definition String = [Char] seems to me the most natural definition.
Optimizing all lists would be nice but choosing allways the correct behaviour would be quite hard. Of course if such an optimization would exists Strings would benefit from it. Making strings an abstract type would not preclude using such optimizations. But Strings could be optimized even before the optimization existed. The list of chars seems natural when thinking in terms of transformations, but it is not very natural when trying to interact with external world.
It is currently hard to define typeclass instances for strings as String ( = [Char]) overlaps with [a]. Implementations provide solutions for this, but there should not be a need for workarounds in the first place.
That's a problem, I also like to hear opinions about that. E.g. Show instance of String doesn't output ['b','l','a'] but "bla".
This is because Show has a special case for lists: class Show showsPrec :: Int -> a -> ShowS show :: a -> String showList :: [a] -> Shows This is not very elegant and does not help when using a boilerplate style traversal. - Einar Karttunen