Re: New collections package ready (almost)
Jean-Philippe Bernardy wrote:
I've set up the new collections package, and it compiles under ghc and hugs. I don't know about nhc, because I've been unable to compile nhc. (I've got a x86_64 system; I've tryied to compile under a chroot does not work, and configure program baffles me.) The non-ghc version is portable though, so it _should_ work under nhc alright.
So, you can try to make "collections" a default package, so I can start moving stuff out of "base" into it.
Ok, I misunderstood what you were doing here. I thought you were simply packaging AVL trees, but you're actually including the generic collections framework. I'm not completely comfortable with shipping this framework with GHC at the moment, given the small amount of discussion it has received, and the volume of competition in this space. This isn't a criticism of the design at all (indeed, I haven't looked at it in detail). I'd much prefer to see this provided as a separate package for now. Of course if a concensus emerges that this collections framework is the right way to go, then we'll certainly include it - a collections framework is pretty basic functionality. Cheers, Simon
Hello Simon, Monday, March 13, 2006, 3:19:54 PM, you wrote:
So, you can try to make "collections" a default package, so I can start moving stuff out of "base" into it.
SM> I'm not completely comfortable with shipping this framework with GHC at SM> the moment, given the small amount of discussion it has received, and SM> the volume of competition in this space. This isn't a criticism of the SM> design at all (indeed, I haven't looked at it in detail). I'd much SM> prefer to see this provided as a separate package for now. SM> Of course if a concensus emerges that this collections framework is the SM> right way to go, then we'll certainly include it - a collections SM> framework is pretty basic functionality. i want to support this. i also working on the libs that, i hope, will go into the ghc 6.6, but until they are thoroughly tested and tuned it's better to make them individual packages. in particular, i name my modules "GHC.Arr_", "Data.Array_.*" and so on, so that they can be compiled together with existing GHC sources but this naming makes obvious what modules of base package they should replace on the other side, it may be a good idea to give to such packages some place on the official darcs server so that work on them can be made collaborative as on other ghc/base parts -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Monday 13 March 2006 14:07, Bulat Ziganshin wrote:
it's better to make them individual packages. in particular, i name my modules "GHC.Arr_", "Data.Array_.*" and so on, so that they can be compiled together with existing GHC sources but this naming makes obvious what modules of base package they should replace
IMO, this nearly-non-solution ;-) is just one more argument to introduce some variant of module/package grafting. Ben
On Mon, 2006-03-13 at 16:07 +0300, Bulat Ziganshin wrote:
in particular, i name my modules "GHC.Arr_", "Data.Array_.*" and so on, so that they can be compiled together with existing GHC sources but this naming makes obvious what modules of base package they should replace
I think the normal convention is to use a name like: Data.Array.BZCoolNewImpl.* rather than Data.Array_.* Ok, not so long, but you get the idea. For example, my re-implementation of the Graphics.SOE API using Gtk2Hs is named Graphics.SOE.Gtk Duncan
participants (4)
-
Benjamin Franksen -
Bulat Ziganshin -
Duncan Coutts -
Simon Marlow