[EMAIL PROTECTED]:
> While it makes sense to think about
> alternative representations at the outset (and possibly use them
> internally), the absence of a full-featured string processing library
> is more of an obstacle than it's lack of efficiency.
>
> --
> Jón Fairbairn
Exactly. At least 5 members of this list applied/abused of the word
"efficiency" in this context. For some, the laziness is the *source*
of efficiency (space economy?), for others it would be nice to have
unboxed arrays. I am persuaded that what we really need now is a set
of concrete examples so that we could do some profiling. If we deal
essentially with one huge, but finite string, e.g. the contents of an
editor buffer, what we need is a fast concatenation, insertion,
suppression. I would use *obviously* update'able lists.
A complicated parsing involves the substring matching, and this is
not entirely linear; besides, some algorithms (BM or KMP, I forgot
which)
become more efficient if the strings can be scanned backwards, from
which we conclude what we should.
--
Perhaps I am an advocatus diaboli, but I think that the obstacle (for
whom??) is *not* the absence of a full-featured string processing
library,
but the scarcity of applications of Haskell.
It is a good idea to build generic libraries. I am full of admiration
for such people as Chris Okasaki, and others, preparing now some
fabulous reusable generic data structures. But I would be much happier
knowing that there are people *outside* our FP Brave World waiting for
it, with some immediate application projects. STL was not a gratuitous
(*)
initiative, but a response for a demand; putting some order into all
this C++ bedlam was a necessity.
For the moment the Haskell world seems to be reigned by Order, Beauty
and Lazy Force...
=====================
(*) "gratuitous": Alta Vista finds 27842 pages with; "gratuitious":
more than 600, mainly from ".com" sites. What about writing a nice
spell checker in Haskell? Somebody needs a PhD theme?
Jerzy Karczmarczuk
Caen, France
