[Haskell] Improvements to GHC
jvlask at hotmail.com
Wed Nov 16 17:27:52 EST 2005
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
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.
c) first class labels would be nice
3) Macro / conditional compilation / compiler meta language / additional
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
(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.
More information about the Haskell