Fixes and future plans with the frontend, was 'LHC+base now installable with cabal-install!'

[Austin Seipp]

Hi,

I have just uploaded another version of lhc to hackage -
0.6.20081211.2 - that should fix most of the problems you'll have if
you want to use lhc and get the base package as well.

Before you install it, you should get the *very* latest darcs version
of Cabal and install it (duncan pushed a nice patch today) and then
install lhc with:

 $ cabal update; cabal install lhc -fwith-base

And done!

The fixes here were mainly some package location stuff, so you don't
need to 'sudo' to install it with base (this had to be fixed on the
lhc side and cabal side of things,) but if you have the latest HEAD
cabal then this should work pretty smoothly for you!

Please report problems if you have any.

Also,

> That's great, Austin. That makes it really easy for people (like me, who
> need a low activation energy) to try out LHC.

Good. :)

> I also recommend that you keep the one available on Hackage up to date with
> small releases. It's a good way to allow people to play with the latest and
> greatest. Don't wait 6 months to release a new version.

Right now we're sort of uploading to hackage at whim as we push new fixes to the
HEAD repo, and there isn't really a clear version policy right now,
but I'm sure as time goes on we'll be uploading new versions fairly regularly.

> I look forward to the day when I can build EMGM [1] with LHC. (Think
> undecidable instances, Template Haskell, etc.)

On this note, I have a branch sitting around with with some work on
trying to replace the frontend with haskell-src-exts. It's not going
too easily.

The main thing is that the frontend for lhc is derived from the
hatchet code, which John extensively modified himself. The way I see
it, swapping haskell-src-exts for the parser is probably going to
require (essentially) recoding the entire frontend and typechecker to
support various extensions; editing all the code to use
haskell-src-exts datatypes etc. would probably be *more* tiresome.

Right now, here's what haskell-src-exts README says it supports (I
also believe it supports the magic hash and view pattern extensions):

* Multi-parameter type classes (MPTCs)
* Functional dependencies
* Associated types, type families
* Liberal class and instance heads
* Implicit parameters (ghc and hugs)
* Explicit kind signatures
* Pattern guards
* Generalized algebraic data types (GADTs)
* Template Haskell (TH)
* Universal and existential quantification (forall)
* Empty data type declarations
* Unboxed tuples (# #)
* Standalone deriving
* Regular patterns
* Haskell XML, HSX style
* Pragmas
* View-patterns
* Magic hash

Relatively lax categorization based on difficulty:

 Done already:
  * Empty data delcs
  * existential quantification
 Not done, but simple:
  * Multi-parameter type classes
  * Standalone deriving
  * Unboxed tuples (maybe done?)
  * Magic hash?
  * Pattern guards
  * Bang patterns
 Tough(er):
  * GADTs
  * Functional dependencies
  * Associated types
  * Template Haskell
 ??:
  * View patterns
  * Explicit kind signatures
  * Implicit parameters
  * Regular patterns
  * Haskell XML?

Also, there are things which haskell-src-exts obviously supports but
are purely type system extensions, like:

  * Undecidable instances
  * Overlapping instances
  * Liberal class & instance heads
  * Rank-N polymorphism

(Also, remember that if we use haskell-src-exts then n+k patterns are
not supported, so technically I guess you could say we are not
haskell98 compliant (this is what the README says)?)

So, this is quite a lot. I believe a few of these are really more
broad than deep and we can probably nail down some of the simpler extensions
pretty easily, but the complicated extensions will take more time. We
at least have GHC's research to guide us. :)

What do you all think about this change? Rewriting the whole frontend
will probably be necessary for much of these changes to take place I
think (at least we have a parser to build on...)

> Regards,
> Sean

Austin