Hierarchical libraries document updated
Folks, I've updated the document at http://www.haskell.org/~simonmar/libraries/libraries.html to reflect some changes in how the libraries situation is evolving. This document is the central place where the workings of the hierarchical library system is described: it discusses how new libraries are contributed, where they live, what form they take and so on. The document is also in CVS (fptools/libraries/doc/libraries.sgml). Previously, we talked about the "Core Libraries" which were all going to be kept in one place (fptools/libraries), and this has pretty much been the situation up to now. But from here on, I expect things to become more distributed: people will maintain their own libraries and do releases independently of the compilers, and when we have a separate library infrastructure there will be no need for libraries to reside in the fptools tree. So with this in mind, the document now talks about "Reference Libraries". It is more clear about how names in the hierarchy are allocated (namely by asking on libraries@haskell.org), and it has a full list of what names have been allocated so far, who maintains those libraries and where to get the code. The evolution of a library infrastructure will have an impact on much of this, so I suggest that this document is the right place to record the results of that discussion (if/when there are some!). Comments welcome, as usual. Cheers, Simon
Hi all, Going along with Simon M's last email, I am getting ready to stamp my DSP library with version 0.00.1 and put everything under CVS conrol, but would like to get some comments before I do so. A current snapshot is at http://users.snip.net/~donadio/haskell/hsdsp-snapshot.tar.gz Everything has been converted to a hierarchical library, and about 2/3 of it has been converted to use Haddock for documentation. There are also a few small demo apps. I am going to reread the Library Guide, but I would appreciate comments on the following issues: There are currently four libraries in the snapshot: DSP, Matrix, Poly, and Stat. I would like to add these to the official namespace, and would like to know where they should live. Everything is GPL. I don't really care one way or another about this, but there is some code that I don't claim copyright to, and some derived code that inherits the GPL. In particular, MT19932.hs and Roots.hs have different copyright holders, and the original code was GPL. FFT.hs, FFTHard.hs, and PFA.hs have some derived code, so they have to inherit the GPL. I have to consult with the author, but IIRCookbook.lhs is a derived work, and I have a feeling that the license on this will be PD. Any other comments would be appreciated. Thanks a bunch. -- Matthew Donadio (m.p.donadio@ieee.org)
Matthew Donadio wrote:
Any other comments would be appreciated.
BTW, thanks for all the comments on my last round of questions. The messages are still sitting in my mail folder, and I will get around to replying to them... -- Matthew Donadio (m.p.donadio@ieee.org)
"Simon Marlow"
I've updated the document at http://www.haskell.org/~simonmar/libraries/libraries.html to reflect some changes in how the libraries situation is evolving.
The latest version of the libraries document is looking good, and thanks for keeping it rolling Simon. In the section on Portability, bit-wise operations (i.e. Data.Bits) are noted as non-portable, yet as far as I'm aware they are supported by all the implementations now. Would anyone object if I move that bullet item to the section on "extensions that can be assumed portable"? Also, in section 4.4, the allocation of libraries to maintainers is a somewhat rough approximation, I'd say. No doubt we can gradually refine it. For instance, Debug.QuickCheck.* is currently allocated to this mailing list, but I'm sure it should really be under the control of John Hughes and Koen Claessen - I know that they are planning a new release soon. I have never heard of the System.DL library before, and couldn't guess from the name what functionality it aimed to provide. I had to go look at the source code to determine what it does! A definite candidate for clearer naming - I would suggest System.DynamicLinker or something along those lines. Regards, Malcolm
participants (4)
-
Malcolm Wallace -
Matthew Donadio -
Ross Paterson -
Simon Marlow