> Why not making two systems, a GHCI general slimmed down purpose
> compiler/interpreter with wider portability, and a research
> GHC or GHCI,
> which can be allowed to be slow and machine specific for the
> tradeoff of
> containing the latest stuff computer scientist researchers
> are interested
> in.
One of the main reasons for transforming the goalposts into GHCi was that
maintaining two systems involved too much overhead for the limited
development resources available. GHCi will share ~95% of its code with GHC,
and will understand exactly the same syntax, including extensions, and will
come with the exact same libraries as GHC for a given platform.
Perhaps in the future we could think about a cut-down version (GHC on your
mobile phone, anyone? :-) with maybe an interpreted Prelude, a subset of the
libraries, some of GHC's optimisations removed to keep the binary small,
etc. but for now we'll concentrate on keeping the maintenance overhead as
low as possible.
> I think that GHCI passing over machine specific assembler
> code will really
> kill off its widespread use, and it will hurt Haskell taking off as a
> general purpose programming language. The group { C++, Java, Haskell }
> would be a really nice suite for general purpose programming,
> if one can
> pick and choose from the their relative strengths at need.
The plan is for GHCi to interpret Haskell directly (either using
meta-circular techniques or via byte-code), rather than compiling it to
native code.
Cheers,
Simon
