Re: base package (Was: GHC 7.8 release?)

Hi, Am Donnerstag, den 14.02.2013, 21:41 -0500 schrieb brandon s allbery kf8nh:

On Thursday, February 14, 2013 at 8:14 PM, Johan Tibell wrote:

...

On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner wrote: I don't think having FFI far down the stack is a problem. There are lots of pure data types we'd like in the "pure data" layer (e.g. bytestring) that uses FFI. As long as the I/O layer itself (System.IO, the I/O manager, etc) doesn't get pulled in there's no real problem in depending on the FFI.

I think it would be nice, also to other Haskell implementations that might have not have FFI, to separate the really basic stuff from pure-but-impurely-implemented stuff. At least as long as it does not caues trouble. GHC.Fingerprint does not need to be crippled when it is going to use a pure hashing; I quickly added some simple fingerpriting found via Wikipedia that was easier than MD5. https://github.com/nomeata/packages-base/commit/b7f80066a03fd296950e0cafa227... The choice is of course not final, maybe something with more bits is desirable.

Doesn't the FFI pull in some part of the I/O layer, though? In particular threaded programs are going to end up using forkOS?

Another good reason to try to have a pure ground library. Based on base-pure, the next step would be to check if FFI can be provided without IO (but I doubt that is difficult), so there would be an base-io package on top of base-pure, and then bytestring can depend on that base-io and base-pure, while users of bytestring of course don’t have to depend on base-io (as long as they are not using the IO-related functions of bytestring). Questions: * Does anyone have a tool to compare package APIs? It would be interesting to diff base’s API with the combined APIs of the package we are creating right now. * Currently, base-pure exports lots of modules that should not be part of its “pure” API (all the GHC.* packages). But I assume they need to be exported for the benefit of packages like base-io built on top. Should we provide another package that re-exports those that are for public consumption and is likely to have a more stable API? Again I feel the need for packages re-exporting modules without incurring a conflict. * What to do with Prelude. Should it be in base-io (which is potentially the lowest package containing everything needed) or rather in a package of its own? Or should it live in a package of its own? Or can we use the haskell2010 package for that somehow? * Should base-io provide just the IO monad and all, say, file-related stuff in a separate package or is this going too far? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata