64-bit windows version? (Haskell is a scripting language too!)

[Brian Hulley]

skaller wrote:
> 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 
combinations of
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 
code.

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?

Best regards,

Brian.