[Haskell-i18n] SourceForge Project Active
Andrew J Bromage
Fri, 30 Aug 2002 11:33:29 +1000
On Thu, Aug 29, 2002 at 11:31:16AM +0200, Martin Norbäck wrote:
> hfl (Andrew Bromage)
> Haskell Foundation Library
> "The future of the Haskell standard library is here."
> CVS contains edison and some Monads
That would be me.
HFL currently contains my personally hacked-over version of Edison,
featuring fundeps and "not just maybe" methods, plus one or two of the
gaps filled in. The other part is the Monad Template Library with one
addition (MonadNondet) and one more in development, not yet checked in.
My thinking behind hfl is similar to Boost for C++. In particular,
I want to produce libraries which are suitable for future
standardisation. That is, it has to be general enough, flexible enough
and generally useful enough to be in a future incarnation of the
To some extent, this is closely aligned with the philosophy behind
haskell-i18n, but perhaps not with the other two projects, which
look to me like more like CPAN, that is, a repository of useful
libraries most of which most programs would not need.
The line between the two ideas is somewhat fuzzy, but intuitively,
an awful lot of programs need FiniteMap or something like it, but not
so many need an IMAP library, even though an IMAP library is a very
good thing to have for those times you need it.
> Perhaps we should try and merge these, is there any point in having
> multiple projects and repositories when we have hierarchical libraries?
Semi-random half-baked thoughts follow.
The major problem with Haskell libraries at the moment, and one of
the reasons why I started HFL, is that there are a lot of existing
libraries "out there" which have nothing in common. Naming
schemes are inconsistent, error/exception handling is inconsistent,
iterator support is handled in a dozen different ways and so on.
This is partly a symptom of the fact that there's not a lot of
common engineering experience with Haskell "out there". Those few
places which do use Haskell (or similar languages) don't cross-
pollinate with each other nearly as much as, say, C++ programmers.
As a result, there are as many styles as there are programmers.
Plus, to be honest, most of the people who write Haskell libraries
are scientists. When you have a research quota to fill, integration
with existing libraries isn't high on your agenda, and rightly so.
Now I'm not opposed to merging in principle, however, if my intuition
on the relative philosophies behind the four current projects is
correct, then it seems to me that we really want is two (sub-)projects:
the "core" libraries, and the "add on" libraries. Naturally we'd want
these (sub)projects to work as symbiotically as possible.
I'd also like, eventually, to institute some proper unit testing, code
auditing and peer review, particularly on anything we're proposing for
standardisation, but this can be discussed later.