[Haskell] Improvements to GHC

[Ketil Malde]

John Lask wrote:

> I would like to sound out the Haskell community on what the feeling 
> are most desirable to improve the "commerciality" (i.e. its general 
> use) of ghc and Haskell in general (as distinct from feature set)

I think more standardization on an extended feature set would be nice.  
It has gotten better, and is still improving.  Still, it would be nice 
to be able to say that something is valid "haskell 05", instead of -98.

> 1)  GHC runtime to be dynamically loaded.

Why does this matter?  Is anybody really running many, distinct Haskell 
programs simulatneously?  I always compile with -optl-static anyway, 
just to avoid possible breakage when binaries are moved between machines.

> 2)  Improving Haskell support for records.

Right - the problem is that nobody seems to agree exactly how to do 
this.  I like the fact that record access looks like (is?) a simple 
function application, and conversely, dislike that the record update 
syntax is different.

>    To date this issue has not been tackled in any meaningful way, 
> perhaps we can continue
>     to use cpp but for the sake of portability

I think it was Simon that said that most uses of CPP directives was 
adaption to Windows vs. Unix.  My only(?) use is to provide file names 
and line numbers for exceptions (e.g. #define head (\x -> case x of 
{(x1:_) -> x1; [] -> error "head: empty list (__FILE__:__LINE__)") -- or 
something like that).  Unfortunately, CPP doesn't support macros for 
infix operators (array dereference, for instance).

> 4) Taking up the issue of portability and byte codes in a recent thread.
>     The lvm used in the helium compiler perhaps offers the opportunity 
> of defining a standard
>     Haskell byte code platform which other compilers can target for 
> instance ghc/hugs 

Personally, I fail to see why this is so important - well, I guess if 
you want to distribute proprietary (closed-source) software and hope 
that suffices to compile and test it on only one platform.  IMO, this 
isn't true of  Java, and this model only manages to combine the 
disadvantages of compilation with the drawbacks of interpretation.  :-)

Anyway, Microsoft's CLR might also work, and I think there was some work 
in that direction.

-k