On Wed, Aug 13, 2008 at 3:13 PM, Malcolm Wallace
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