[Haskell] Improvements to GHC

[John Lask]

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)

my pick would be to

1)  GHC runtime to be dynamically loaded.
     Enable the ghc runtime system to be loaded as a shared object/dll 
rather than being statically compiled in.
     I think the reason this has yet to be done is because it is a rather 
tricky issue, perhaps
     those in the know can comment.

2)  Improving Haskell support for records.
     There has been much discussion over the years, some experimentation, 
but which alas has
     amounted to no change or improvement in Haskell record support. Again 
in my opinion the area
     that Haskell compares least favourably with other languages is in the 
area of record support particularly
       a)  no distinct namespace for record fields
            (forcing people to resort to the module system to resolve name 
space clashes)
       b)  subclassing on records would be great.

     All these things have been discussed before. The most important is (a) 
as it would obviate some of the
     tortured coding that currently appears in many Haskell modules. 
Additionally

       c)  first class labels would be nice

3) Macro / conditional compilation / compiler meta language / additional 
binding forms
    These are perhaps distinct issues but can be discussed together.
    The prevalent use of #ifdef and the cpp is indicative of the general 
need to have some standard means by
    which differences between compilers ghc/hugs/nhc can be accommodated for 
in the source code.
    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

     A means of defining additional binding forms would be nice as it would 
further facilitate embedded dsl
     for which Haskell is pre-eminent, and which use is a great motivator 
for venturing into
     Haskell in the first place.

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
     (hugs has in its code base the possibility of writing out a compiled 
form aka compiler)
     - thereby separating the compile time and run time platforms, providing 
a standard Haskell target platform.