Sven Panne writes:
> Using Haskell programs and libraries with different compilers and/or
> interpreters (or even with different versions of the same system!) is
> currently quite a frustrating experience.
I agree. And as the current maintainer of one of the Haskell systems,
I'd like to work both with frustrated users and with other compiler
writers to help make things easier.
> * Different language versions (1.3, 1.4, 98, ...) exist. This is
> inevitably so for any language which is in use, see C++, Java, ...
Yes, but the explicit goal of Haskell 98 is that it should *replace*
all earlier versions of the language. Any confusion between 1.3/1.4/98
code should only be temporary: as stable implementations of the 98
standard emerge, all 1.3/1.4 code should be converted or thrown away.
(Why? Because we know that 98 will be around for a long time.)
> * There is no really portable way to level those language
> differences. IMHO, piping Haskell through cpp is a hack and has
> its own problems: nhc98 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...
Yep. Part of the problem here is that none of these cpp symbols are
documented, so one compiler writer has no idea what another compiler
writer is using, and makes his/her own choice. Ideally, once the 98
standard settles down, none of these symbols will be required any
longer. (But we will still be left with __GLASGOW_HASKELL__, __HBC__,
and __NHC__ to determine compiler-specific differences as opposed to
language-version differences. These symbols are not documented
anywhere either!)
> * Libraries differ vastly between systems, although there is some hope
> for Hugs/GHC.
Ideally, libraries should be stand-alone, portable to any Haskell system.
And every Haskell system should have an easy standard way to link against
ready-compiled-and-installed libraries.
> * There is no universal tool for easy compilation of simple multi-module
> programs. OK, there is make, hmake, hbcmake, Hugs' import chasing...
Apart from Hugs, which is something of a special case in this regard, I
believe hmake does exactly what you want across all the other
platforms. I have been promising a release of hmake (separate from the
nhc98 distribution) for a while now, but other things have got in the
way. Unfortunately it will still be several weeks before I have the
time to look at this again.
> * Write down and implement an (extensible) standard for the compilers'
> command line flags. Don't forget runtime flags, too.
I think this is a good goal. Any volunteers?
> * The Haskell 98 libraries are nice, but by no means sufficient.
> A quick(!) agreement on libs to include in every system is necessary,
I think a clean, portable, way of linking in arbitrary pre-compiled
libraries (ideally determined automatically by hmake, based on
import-chasing) is a desirable precursor. But I'd also like to see
lots of portably-written libraries made available too.
> * Programmers: Try to make your programs run on newer systems without
> any cpp-trickery, it's not that hard. The casual user should not need
> to be aware of the things aeons ago. The following example e.g. works
> on Hugs98 and GHC without anything special. nhc13 needs
> "-cpp '-DANCIENT_HASKELL_BEGIN=-}' '-DANCIENT_HASKELL_END={-'
> '-DHASKELL98_BEGIN=\end{code}' '-DHASKELL98_END=\begin{code}'".
That's a little unfair! For one thing, you are comparing two Haskell
98 systems with a Haskell 1.3 system (soon to be obsolete). For
another, you have chosen to use deliberately obfuscatory preprocessor
directives. Were you to compare against nhc98, none of that trickery
would be necessary.
Regards,
Malcolm
