Hello all - As it seems there's continued interest in the LazyArray library outside of the small circle of HBCLibs users, it seems like there ought to be a place for it in the Haskell library hierarchy. I have working code that we've been using for several months now, but which I cleaned up and documented a bit over the weekend. I posted the link to Haskell-Cafe on Saturday, but here it is again: http://www.csg.lcs.mit.edu/~earwig/haskell-lib/ The LazyArray library is ready to ship, and I'm eager to donate it to the cause if it's wanted. It could, for example, be added to hslibs or given a place in the Grand New Library Hierarchy. What hoops must be jumped through? The Supply library is not as well tested; the old library proposal mentioned a "LibSupply" of generic splittable supplies, though, and I can find no actual implementation or even a proposed interface beyond the existence of the type "Supply a". I suspect it will work fine in its present form, but would like to deal with the following: * If you know of another implementation, could you please send me a pointer? I'll try to get a united interface. I suspect existing LibSupply -ish implementations don't implement fmap and zip-like functions, but I'd love to be pleasantly surprised. I'm not totally satisfied with my function names, and would love to compare notes with another implementation if one exists. * Along the same lines, I'd love to hear comments on the functionality. Too much? Awful names? * I want to re-code NameSupply from HBCLibs using Supply. (I already ported NameSupply to GHC, which is what gave me enough clue to write Supply in the first place.) * It'd be nice to do an implementation of Random in terms of Supply as well. I suspect this would actually improve the kludgey Random in hugs at least. I don't really use Random regularly myself, but re-coding the hugs library should be easy enough that it won't be any worse than it already is. * I'd like to switch the Eager Haskell compiler over to a re-coded NameSupply to reinforce my confidence in the implementation. Note the other stuff mentioned on the web page will need a lot more work to be shippable. I urgently needed enumerable, joinable maps, but I haven't actually found the time to deploy them yet. Most of the other libraries depend on precursors of joinable fast sets/maps. Jan-Willem Maessen