On Wed, Aug 13, 2008 at 12:21 PM, Malcolm Wallace
- Why does NHC98 break so often? Is it because people are checking in code that is not Haskell 98 compatible?
Yes, there is a bit of that. Also, as you point out, there is quite a lot of CPP conditionally compiled code in the libraries, and I would say that it is the major contributor to breakage. It is often unclear which parts of the code are shared and which separate, so a lot of breakage arises from e.g. exporting a name that is defined for ghc only.
In addition, there are some (once obscure) bugs in nhc98 that are now triggered increasingly frequently. (We can't blame anyone except nhc98 for those of course.) These include complex import renaming resolution, and contexts on pattern variables.
Can we make sure that these libraries are always built with some Haskell 98 compatibility flag by GHC so people find out when they add non Haskell 98 stuff?
- It seems to me that implementations "share" libraries using CPP. That seems like a bad approach to me.
Agreed. The CPP was always intended to be as temporary as possible, with the goal to share as much as possible. One of the problems is that the primitives provided by compilers are different. Really, there should be a package below 'base' in the dependency tree, specific to each compiler, and non-shared. Then everything from base upwards would be cleaner and more portable.
Some code rearrangement could go a long way to. We could put compiler specific implementations of certain functions in a separate module. We could then import the right compiler specific module with just one if-def and then reexport the functions from e.g. Data.Array. module Data.Array ( map, filter ) where #ifdef __GLASGOW_HASKELL__ import Ghc.Data.Array as Impl #endif #ifdef __HUGS__ import Hugs.Data.Array as Impl #endif -- | Documentation map = Impl.map -- | This implementation is shared. filter p xs = ... I don't know if this is the best way (I need to give the subject some more thought).
If it's so difficult to share code without continuously breaking the build then we're better of keeping the code separate.
I don't agree. The only way to achieve convergence is to start from some semi-merged point, and work to eliminate the differences. Igloo is doing a fantastic job of determining the dependencies and gradually moving stuff around to enable this to happen.
Trying to come up with a solution that allows us to share code in a sane way would of course be better. But if that doesn't work, maybe because the problem is inherent with the way we share code, and the build breakages continue I would argue strongly for always keeping HEAD buildable over sharing implementation. Cheers, Johan