[Haskell-cafe] Strings - why [Char] is not nice
ekarttun at cs.helsinki.fi
Mon Sep 20 07:13:20 EDT 2004
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
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
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:
showsPrec :: Int -> a -> ShowS
show :: a -> String
showList :: [a] -> Shows
This is not very elegant and does not help when using a boilerplate style
- Einar Karttunen
More information about the Haskell-Cafe