Version control systems

[Johan Tibell]

On Wed, Aug 13, 2008 at 3:13 PM, Malcolm Wallace
<Malcolm.Wallace at cs.york.ac.uk> wrote:
>> I think an even better analogy is probably comparing it to developer
>> of GCC changing the libc implementation of another compiler or vice
>> versa.
>
> Our shared libraries do not belong to any one compiler.  They are joint
> creations, with a lot of community (non-compiler-hacker) involvement.

I'm very grateful these people took the time to write these libraries.
However, how these modules were created is irrelevant when it comes to
addressing the current problem. Parts of their implementation is
compiler dependent and having compiler specific code live together is
bound to lead to problems because the people hacking on those modules
are likely to use and validate on only one compiler. It would be
difficult to require them to do otherwise too. To avoid this problem
either the compiler dependent code has to be abstracted out from these
modules so people can ignore the differences or the implementations of
these files need to be kept separate.

Consider the following scenario. GHC hackers implement Data.Array in
A.hs, Hugs and NHC98 hackers develop separate implementations in B.hs
and C.hs respectively. We now run something like

diff A.hs B.hs C.hs | sed <diff markers with if-defs> > X.hs

X.hs could be likened to what current implementation of these files
look like. If the three groups don't validate their changes on all
compilers they risk breaking someones build. Especially note the poor
scaling properties of this approach were each new implementation adds
one more compiler for everyone to verify on. I think the reason this
works at all right now is that most work is happening on GHC and
that's also were the most users are.

Cheers,

Johan