G'day all. 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 standard library. 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. Cheers, Andrew Bromage