Version control systems

[Johan Tibell]

On Wed, Aug 13, 2008 at 12:21 PM, Malcolm Wallace
<malcolm.wallace at cs.york.ac.uk> wrote:
>> - 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