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
_______________________________________________
Haskell mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell
