LazyArray, Supply libraries...

[Jan-Willem Maessen]

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