[Haskell-cafe] Strings - why [Char] is not nice

[Einar Karttunen]

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