64-bit windows version? (Haskell is a scripting language too!)
brianh at metamilk.com
Thu Jun 21 21:06:42 EDT 2007
> The key thing for the building portability is that the C and C++
> compilers are represented by Python classes. There is a pre-programmed
> class for gcc, and another for MSVC++.
I suggest (for GHC) a Haskell class with instances for the different
compilers and platforms and optimization levels.
> (a) Pick a portable scripting language which is readily available
> on all platforms. I chose Python. Perl would also do.
If I had time to look into improving the GHC build system I'd definitely
use Haskell as the scripting language. What's the point of having to
learn more than one language to accomplish a task? Surely it is more
productive to add functionality to a single language (especially when
it's only a case of writing some libraries) rather than grappling with
the different syntaxes and limitations and quirks of a multitude of
languages/tools and the problems of trying to get them all to work
harmoniously together on different platforms?
In concrete terms, for each sub-project within GHC ie each directory of
source files I'd have a little Haskell program that was responsible for
building that sub-project. Kind of like CM.make or the ML Basis system,
except with the full power of Haskell so that complicated things such as
building successive boot levels could easily be automated. (Ie instead
of having a special tool like make that is invoked on "dead" data
(supplied by autoconf etc) to drive the build process, instead use
Haskell as a scripting language.)
The top level build would be done by another Haskell program which
delegated responsibility to the sub-programs in each directory.
I'd include the complete source code for all the Haskell tools like Alex
and Happy so they could be built the same way.
In other words, the entire GHC project would be built by running a
single Haskell program, and every single piece of source would either be
a Haskell module or a file that is the input to a Haskell program that
the main build-driver has built first (from Haskell sources). Therefore
there would be no dependency on anything except GHC itself.
To port GHC to a completely new platform, you'd of course need a Haskell
compiler or interpreter already. However to bootstrap the process only a
slow interpreter would be needed so as long as a portable pre-built
bytecode version was available for download the only thing left to port
would be a byte code interpreter which could just be a single file of c
Perhaps this is too long-term a vision for solving the short term
problems, but maybe it could be the basis of some future projects?
More information about the Glasgow-haskell-users