Make ghc (stage1) be compilable by non-GHC

[Isaac Dupree]

This depends a bit on the existence of a good-enough non-GHC compiler. Possibility to do recursively dependent modules (I think) presently rules out everything except JHC, which is not entirely working yet. Also pattern guards might need to be implemented in that compiler. Maybe for testing, a ghc that doesn't define GLASGOW_HASKELL (and doesn't use ghc-specific flags ?? possibly a wrapper script of some sort) could be used too.

See  http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962 ... GHC also uses things like IORefs, (unsafeCoerce? only in stage2 I think) that everyone provides, but would still be good to document.

I'm working on this now, we'll see how far I get --Isaac

[Isaac Dupree]

Also grepping the source for GLASGOW_HASKELL finds many things that need examining. Mostly it is "#if"s for compatibility with old versions of libraries that old versions of GHC have; for non-GHC compilers I think the best thing to do with these is to make sure it assumes the latest version of the libraries (old versions of ghc need to be able to compile new ones for a special reason, and the older versions also had more difficulty having upgradeable packages)

[Isaac Dupree]

Hmm, looking again, it does look like GHC's code sometimes uses unboxed stuff and imports GHC.stuff. Some of the places at least, it seems there's really no excuse for doing so... I can change those (at least if I feel sure there are no performance regressions thereby).

[simonpj]

The other thing to watch out for is that we keep GHC in a state in which it can be compiled by several earlier versions of GHC. I forget what our current earlier-version threshold is (Simon M would know), but in doing your refactoring please be careful to maintain this property. We don't want to pull up the ladder after ourselvese too quickly!

Simon

[Isaac Dupree]

Yes, certainly, I think it's ghc-5.04 currently. Is there an easy way to get a copy of that version of ghc (or other versions between that and the current) to test with? Or should I just rely on my intuition while watching for buildbots breaking that use old versions of ghc?

I think it's okay if GHC is merely slower when compiled with older versions of GHC (since normally you'll be using recent GHC for development, and stage2, anyway), for example if older versions of GHC optimized worse or didn't implement UNPACK pragma...

[igloo]

We abandoned 5.04 support recently as the differences in its hierarchical libraries compared to 6.x were causing too much pain. I think any 6.x is supposed to still work, though.

Bindists are the simplest way of getting older versions, but you might have problems due to them being compiled against older libraries. If it proves tricky then just keeping an eye on the nightly builds is the way to go.

[Isaac Dupree]

OK, it's now 6.0 or greater (according to  http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites ). Is it preferred, discouraged or neither, to remove #if __GLASGOW_HASKELL__ > 5.04 sorts of checks in the code now?

[igloo]

Yup, please do remove any such checks.

[Isaac Dupree]

Should such checks for really old ghc also be removed in the various ghc/utils programs?

[igloo]

Support for building with old GHCs, yes. Support for things like looking at the output of old GHCs, possibly not.

[Isaac Dupree]

random notes:

unsafeCoerce# appears to be only used by ghci and template-haskell (i.e. stage2). It would still be nice to use the Unsafe.Coerce "unsafeCoerce" name (IMHO).

'.#' and 'import.*GHC' are good things to grep for to find non-portable code (although especially the first one will find lots of false positives - the . weeds out preprocessor commands that begin with # at the beginning of lines)

[Isaac Dupree]

I made FiniteMap use {-# UNPACK #-} !Int instead of Int#. Probably it would be better to change to FastInt (which is good for when GHC compiles itself without optimizations).

Thoughts about FastInt and unboxing: A compiler that doesn't have unboxed types could represent them like newtype !FastInt = I__ Int. That ! somewhere indicates to the compiler that wherever this type is used, it is used strictly: with the same restrictions as unboxed types, as if it were !Int everywhere: in data declarations, in function arguments as if the !Int -> x syntax were implemented (only, clearer, because there is a clear source-type-level distinction between the strict and non-strict versions). This has a semantic effect in FastInt -> x but no effect in x -> FastInt, I believe. (And many constructions, like (FastInt, x) are not allowed for unboxed types, and FastInt sometimes _is_ unboxed...)

For now, changing to Int or FastInt as appropriate, seems the best course. But I'm busy with school soon so I might not get to it for a while (and I'm sure someone else could do as good a job as me, if they want).

[Isaac Dupree]

In future we may want to aim for compiling GHC with just the extensions it needs, e.g. stage1 with -XPatternGuards not full -fglasgow-exts (except when compiling with an older GHC that doesn't support -X flags).

[Isaac Dupree]

now working on hard work portabilizing! Will send some darcs patches soon. The more suspicious things (e.g. messing with unboxing) I will make sure to run through performance-checker first.

I found out that ghc's code uses Rank2Types in a few places, in a way that would require changing code substantively to remove, so I guess GHC will just require that useful extension implemented in compilers that want to build GHC :-) (unless someone is really interested in changing that sometime -- and only n/Yhc which doesn't implement cyclically-importing modules either, doesn't implement Rank2Types, IIRC)

details come later