Dear Haskell libraries specialists, the Haskell community hopes to hear from you about all the interesting stuff you've been brewing over the last six months, not to mention the even more interesting stuff in the pipeline!-) That includes individual libraries, developments in the hierarchical libraries (Simon M., the usual contact for this, is away;), as well as the discussions (Haskell WS & after) about library infrastructure, and your conclusions and plans. In short, anything interesting that happened on this list but may not have reached the general Haskeller yet. Check the topics and contributors list to see what still needs filling in: http://www.haskell.org/communities/topics.html ----------------------------------------------------------------- Haskell Communities and Activities Report (November 2003 edition) http://www.haskell.org/communities/ Could everybody send in their individual reports ** by the end of THIS week ** ? Please?-) ----------------------------------------------------------------- Thanks, Claus (current editor)
"C.Reinke"
That includes individual libraries, developments in the hierarchical libraries (Simon M., the usual contact for this, is away;), as well as the discussions (Haskell WS & after) about library infrastructure, and your conclusions and plans. In short, anything interesting that happened on this list but may not have reached the general Haskeller yet.
Since Simon is away, I thought I would attempt to write a general
introduction to the meta-activity in the libraries area (see below).
However, rather than usurp his title by stealth, I am posting my
summary to the libraries list so that anyone can edit/improve it.
Please feel free to write a better summary and submit it to Claus!
(And individuals who have been proposing infrastructural things
might want to add a few more paragraphs of detail on their own
contributions.)
Regards,
Malcolm
----
HC&A Report - Hierarchical libraries
Apart from actually writing libraries that do stuff, recent
meta-activity in the libraries community has concentrated on plans for
making libraries easier to install, to distribute, to maintain, and
therefore also easier to write and contribute to Haskellers at large.
Isaac Jones
On Tue, Oct 28, 2003 at 11:11:54AM +0000, Malcolm Wallace wrote:
In other recent news, the common 'base' package of libraries has recently been subdivided to separate off non-core functionality, making the core more stable, whilst enabling independent evolution of the other libraries. The split-off packages include parsec, QuickCheck, and the monad transformers. Other packages resident in the haskell.org CVS tree include OpenGL, GLUT, HaXml, Japi (Java API), ObjectIO, Win32, X11, HGL (Haskell Graphics Library), haskell-src, network, readline, and unix.
Tiny quibble: the monad transformers aren't gone yet; presumably they will when Iavor's new version is ready.
hello, it's funny because that was my though as soon as i saw the message :-). on more careful reading the monad transformers are mentioned (right after QuickCheck). by the way i have a few overall library related questions: 1. at what point should we remove the Unstable.* name, i.e. does anyone have any criteria besides "it seems to work"? most software these days seems to be distributed on this basis, so perhaps we should adapt this as well. i don't have time to prove the corectness of the monad library, but it seems to work. i can't gurantee that there are no bugs, and i don't think we should freeze its interface as soon as the Unstable.* bit is removed (especially for some of the newer transformers). i think "releasing" the library is a good idea as it will give more people the opportunity to use it, hence find bugs in the implementation or the interface. 2. how does one go about distributing a library that is in the fptools repository? it would seem that at the moment there is a lot of burocratic overhead that goes on when i type "make", i am not sure what it does, or which bits of the fptools need to be distributed together with the actual source of the library. of course i can replace the make file with my own that does only what is necessary but i figured it is nicer if i use the "standard method" bye iavor Ross Paterson wrote:
On Tue, Oct 28, 2003 at 11:11:54AM +0000, Malcolm Wallace wrote:
In other recent news, the common 'base' package of libraries has recently been subdivided to separate off non-core functionality, making the core more stable, whilst enabling independent evolution of the other libraries. The split-off packages include parsec, QuickCheck, and the monad transformers. Other packages resident in the haskell.org CVS tree include OpenGL, GLUT, HaXml, Japi (Java API), ObjectIO, Win32, X11, HGL (Haskell Graphics Library), haskell-src, network, readline, and unix.
Tiny quibble: the monad transformers aren't gone yet; presumably they will when Iavor's new version is ready. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================
G'day all.
Quoting "Iavor S. Diatchki"
by the way i have a few overall library related questions: 1. at what point should we remove the Unstable.* name, i.e. does anyone have any criteria besides "it seems to work"?
This is actually a general software engineering question. I think the only hard-and-fast rule here is: when you're happy with it.
most software these days seems to be distributed on this basis, so perhaps we should adapt this as well.
Given that we're looking at code that may become part of a future standard, perhaps we might like to introduce some kind of informal code review process. What do others think? Cheers, Andrew Bromage
At 11:44 27/10/03 -0800, Iavor S. Diatchki wrote:
1. at what point should we remove the Unstable.* name, i.e. does anyone have any criteria besides "it seems to work"?
most software these days seems to be distributed on this basis, so perhaps we should adapt this as well. i don't have time to prove the corectness of the monad library, but it seems to work. i can't gurantee that there are no bugs, and i don't think we should freeze its interface as soon as the Unstable.* bit is removed (especially for some of the newer transformers). i think "releasing" the library is a good idea as it will give more people the opportunity to use it, hence find bugs in the implementation or the interface.
In the area of network protocol design, a touchstone often used is some variant of "two interoperable implementations" (e.g. the "running code" leg of "rough consensus and running code"). Maybe a comparable criterion for library code might relate to its use in real, complete applications? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
participants (6)
-
ajb＠spamcop.net -
C.Reinke -
Graham Klyne -
Iavor S. Diatchki -
Malcolm Wallace -
Ross Paterson