Re: [Haskell-i18n] SourceForge Project Active
tor 2002-08-29 klockan 04.20 skrev Ashley Yakeley:
A SourceForge project for the internationalisation effort is active at http://sourceforge.net/projects/haskell-i18n/
Searching for "haskell" att sourceforge gave me these: hfl (Andrew Bromage) Haskell Foundation Library "The future of the Haskell standard library is here." CVS contains edison and some Monads hbase (Ashley Yakeley) "Common Haskell code for other semantic.org projects, and other useful things." CVS contains a number of good-looking modules (Org.Org.Semantic.*), among other things HBase.Text.UTF8. haskell-libs Haskell User-Submitted Libraries "Haskell User-Submitted Libraries includes anything we can get our hands on and clean up for general use, as well as new libraries that would be useful to the general Haskell community. Submit your libs, or join the project to create needed libs!" CVS contains Imap.hs haskell-i18n (the latest addition :) Perhaps we should try and merge these, is there any point in having multiple projects and repositories when we have hierarchical libraries? Regards, Martin -- Martin Norbäck d95mback@dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B
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
From: Andrew J Bromage [mailto:ajb@spamcop.net] Sent: 30 August 2002 02:33
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.
Agreed that there are lots of inconsistent libraries out there, but why start a new project when there's already libraries@haskell.org? Surely this is the right point of focus for developing new libraries, and we also have a CVS repository for the code: fptools/libraries on cvs.haskell.org. We also have the beginnings of guidelines for naming conventions and coding style. Perhaps it's because it appears that the barrier to getting one's code into fptools/libraries is quite high. Really, it's not that hard - the only reasons I would actively argue against something going into fptools/libraries are: if there is duplication of functionality between libraries that will only serve to confuse users, or if there is substantial disagreement about whether a particular API is the "right thing". I see the process of standardisation as separate; at some point after the libraries have matured in fptools/libraries for some time, we will standardise some of them in a Haskell 98 addendum. This will probably be an ongoing process, with more libraries becoming standardised as they mature.
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.
Absolutely. Feel free to write down your ideas and we'll integrate them into the library project documentation, such as it is: fptools/libraries/docs/libraries.sgml, there's an online version here: http://www.haskell.org/~simonmar/libraries/libraries.html Cheers, Simon
G'day all. On Fri, Aug 30, 2002 at 10:09:25AM +0100, Simon Marlow wrote:
Agreed that there are lots of inconsistent libraries out there, but why start a new project when there's already libraries@haskell.org? Surely this is the right point of focus for developing new libraries, and we also have a CVS repository for the code: fptools/libraries on cvs.haskell.org. We also have the beginnings of guidelines for naming conventions and coding style.
The short answer is that, speaking as a user of GHC and GHCi, I'd prefer to have libraries with mature interfaces "out of the box". Integrating experimental libraries too early inevitably creates a body of legacy code that I don't want to be responsible for. For example, for my part I've made a lot of changes in my version of Edison which are not backwards-compatible, which I believe are an improvement, but I still don't know if I've got it "right" yet. I don't want to break everyone's Edison code only to have it break again next release. Of course if the changes turn out not to require incompatibilities, there's nothing stopping me from submitting them, but had I been hacking fptools/libraries to begin with, I might have been more hesitant about playing with existing libraries in the first place. The long answer I won't go into in detail, but part of the problem is that being a fptools/libraries developer basically means having a GHC development environment. That requires an investment which I'm personally not able to make at the moment.
Really, it's not that hard - the only reasons I would actively argue against something going into fptools/libraries are: if there is duplication of functionality between libraries that will only serve to confuse users, or if there is substantial disagreement about whether a particular API is the "right thing".
...both of which describe exactly the situation that I'm in at the moment!
I see the process of standardisation as separate; at some point after the libraries have matured in fptools/libraries for some time, we will standardise some of them in a Haskell 98 addendum. This will probably be an ongoing process, with more libraries becoming standardised as they mature.
This raises an interesting question, because almost all newer libraries (certainly the ones I write) all use non-98 language features. I suspect that this is true of many new libraries, and certainly most of the "interesting" ones. Cheers, Andrew Bromage
[trimmed recipient list]
The long answer I won't go into in detail, but part of the problem is that being a fptools/libraries developer basically means having a GHC development environment. That requires an investment which I'm personally not able to make at the moment.
Whilst I don't think it'll change your mind, there is a considerably easier route to being a libraries developer: use Hugs. Hugs is easy to work with, we tend to avoid complex Makefiles, we don't have umpteen different 'way's to build our libraries, recompiling is really fast, etc. Ross Paterson has been working away at making a lot of the new hierarchial libraries work with Hugs; I've added support for the latest ffi spec to Hugs; and Sigbjorn Finne has been plugging gaps in Hugs' library support where Hugs-specific code is required. The result is that it is now quite feasible to use Hugs when working on the hierarchial libraries. [Of course, I'm talking about the CVS copy of Hugs here - but this is little hardship since you'd certainly be working with the CVS copy of the libraries.] Some caveats: 1) This doesn't take away from Andrew's point about not wanting too much experimentation in the supposedly stable libraries. 2) Of course, Hugs doesn't have anything comparable to GHC's profiling infrastructure and a few other cool GHC support tools. 3) What I say is true for almost any library you want to develop. Any library that is except Unicode - Hugs still only supports 8-bit Chars. :-( -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
participants (4)
-
Alastair Reid -
Andrew J Bromage -
Martin Norbäck -
Simon Marlow