Picking up on a few of the points that Sven made:
> * There is no really portable way to level those language
> differences. IMHO, piping Haskell through cpp is a hack and has
> its own problems: nhc13 defines __HASKELL_98__, GHC
> __HASKELL98__;
> nhc13 defines __HASKELL__=3, ghc __HASKELL1__=5, and hbc
> __HASKELL_1_3__. Hugs does not come with a Haskell-compatible
> preprocessor at all. We use hscpp from the ghc distribution for
> this, but hscpp only knows about a -v flag. No chance to define
> something else via the command line. Not to mention continuation
> lines/string gaps...
We (GHC) are compatible with hbc in this area I think - hbc defines
__HASKELL1__=3 for Haskell 1.3, we define __HASKELL1__=5 and __HASKELL98__.
Sadly we didn't check with the nhc folks before deciding on this, although I
think we did consult the ghc-users list.
I don't see a problem with standardising on either __HASKELL_98__ or
__HASKELL98__, let's just pick one. Votes? And these should probably be
mentioned in the Haskell report in an appendix somewhere.
> * If you upgrade your version of GHC, its libraries change
> in such a
> way that you have to recompile all your code: A
> compiler-generated
> entity (ds42, lvl1, tpl60, ...) from one version can mean quite a
> different thing in the next.
What you're really saying is: "if the libraries that you compiled your
program against change, you have to recompile your program." Not doing this
is dodgy at best, even for C.
> * While we are at preprocessing: What about a pragma {-#
> line 42 #-} ?
> Debugging Happy/Green Card/... output is no fun without it.
GHC has this by the way - it's just that Happy doesn't generate them
(yet...).
> * Make compilation of simple programs a simple thing for Joe User.
We could include ghcmake with ghc - then it's just a case of typing
'ghcmake' in a directory that contains at least Main.hs.
Cheers,
Simon
