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

[Peter Tanski]

Brian Hulley wrote:
> 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.

This was one void Yhc was designed to fill, especially by compiling  
to java bytecode.  At the rate I work--if I'm the only one  
deconstructing the current build system--by the time I'm done the Yhc  
team will have everything running.

Greg Fitzgerald wrote:
> I was trying to build something like this recently but hit a  
> roadblock.
> ...
> Unfortunately, the imported module needs to have the line "module
> X.Y.Zwhere", which means the file needs to be aware of its parent
> directories.  I
> think that's too harsh a constraint, and makes it a pain to move  
> things
> around (true in everyday Haskell projects with local modules too!).

Have you looked at Neptune?  It is a scriptable build system based on  
Jaskell, which allows dynamic imports.
An example from the page at http://jaskell.codehaus.org/Jaskell+for 
+Neptune#JaskellforNeptune-90:

//in script1.jsl
1+x
where
   x = import {file="script2.jsl"};
end

You may imagine that the string for "script2.jsl" may be computed.   
Of course this sort of thing breaks the type system in Haskell and  
the result is more Make-like, but that is the tradeoff.  Now why did  
I not try a build system using Neptune?  Probably because I had  
already spent the last three weeks learning CMake, the pecularities  
of SCons, WAF (weird bugs!), m4 (I never had to write tests in  
Autoconf before or debug my own configure files), and higher level  
Make (so it would do what I can do in Jam)--I guess it got lost by  
the wayside...  I was looking at things most people would either  
already know or would want to learn and that should already be  
available on new platforms.

skaller wrote:
> The second is simply that dynamic typing is generally
> better for build systems, because it allows code to
> 'self-adapt'.

There is a somewhat slow-going scheme-based-build-system project  
called Conjure, at http://home.gna.org/conjure/ but it only supports  
Linux and OS X.

> An alternative is to implement the build system in, say,
> Scheme, and then write a Scheme interpreter in Haskell.
> Scheme can self-adapt internally because its compiler
> is built-in.

That is why I was looking into using SISC--it is self-contained and  
may even be distributed along with the source code (SISC itself is  
GPLv2 but that doesn't matter for _using_ it)--by default it looks in  
the current directory.  The downside is the lack of a library with  
directed graphs.

Cheers,
Pete