Hi, If this is the consensus, than people that feel this way should write a document describing the new process so that we know how to contribute code. Based on the current sentiments, we should decide at least on the following: - what is a "core" package Perhaps, a package that is distributed with GHC? But then, we should be having this discussion on the GHC users list... Also, was not the whole point of splitting the base library, so that we can gain the freedom to update libraries independent of implementations? - what constitutes a "significant" change Not sure how to define this. I would be weary of changes to the existing functions/types in the APIs of existing modules. But adding extra functionality? Especially, if---like in the case of Zipper---the implementation can be more or less computed from an existing definition in the package (I am referring to the fact that the zipper is the derivative of Tree, for details you can look at Conor's paper). - what makes code "proven" Again, not sure how to define this. The code for Zipper has QC tests that cover it 100%, according to HPC. Of course, this does not mean that it is perfect, but certainly should give us some assurance that it works. Does code have to sit on hackage for a certain amount of time, before it can be added to the libraries? Or are we going to require that it is already used by many people as a separate package, and then we are going to ask everyone to change their code, so that they can start using it from the new location? Neither option seems very nice. But more to the point though, does anyone have any suggestions about what may be wrong with the Zipper concretely, rather then the library process in general? Neil, the sniplet that you posted from the IRC channel does not give us an idea of what we might want to change. -Iavor On Wed, Jun 4, 2008 at 2:39 AM, Malcolm Wallace <Malcolm.Wallace@cs.york.ac.uk> wrote:
Duncan Coutts <duncan.coutts@worc.ox.ac.uk> wrote:
I would tend to agree with Neil that significant additions to the core libraries should be proven first as separate packages and integrated later.
+1
Regards, Malcolm _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries