GHC 7.8 release status

[Simon Peyton-Jones]

I do need more than a patch, please, please.  A wiki page explaining the design, as seen by the user (of the GHC API), the problems it solves, and the use-cases it enables, would be most helpful.  

Simon

| -----Original Message-----
| From: Thomas Schilling [mailto:nominolo at googlemail.com]
| Sent: 04 September 2013 17:26
| To: Simon Peyton-Jones; Luite Stegeman
| Cc: Nicolas Frisby; "Pedro Magalhães (dreixel at gmail.com)"; Richard
| Eisenberg (eir at cis.upenn.edu); Geoffrey Mainland
| (mainland at cs.drexel.edu); Iavor Diatchki; Austin Seipp; Edsko de Vries;
| Ryan Newton (rrnewton at gmail.com); David Luposchainsky; ghc-
| devs at haskell.org
| Subject: Re: GHC 7.8 release status
| 
| 
| On 4 Sep 2013, at 15:52, Simon Peyton-Jones <simonpj at microsoft.com>
| wrote:
| 
| >  Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be
| jolly soon.  At the moment I don't even know the motivation or design,
| let alone implementation.  Could you make a wiki page explaining the
| proposed design?  Is it really important to do this for 7.8?
| 
| Yes, it is quite important to get this into 7.8.  Not having these
| features in GHC makes it very difficult for people to adopt GHCJS.  One
| could argue that GHCJS is not yet production-ready anyway and users that
| want to try it can figure out building GHC from source to use it, but
| this doesn't quite apply.
| 
|  1. GHCJS targets a wider audience than users brave enough to compile
| GHC from source. In addition, the next chance to get these features into
| GHC is in a year from now, so when GHCJS becomes more mature then this
| will be a major hurdle for adoption.
| 
|  2. These changes are also required for IDE tools which really mustn't
| require users to build a custom version of GHC.
| 
| 
| Luite's design is actually very flexible.  It simply allows GHC API
| users to provide functions that are called instead of (or in addition
| to) existing functions in GHC.  Instead of calling, say, "genHardCode",
| the driver now looks up whether the user has specified a hook for
| genHardCode and calls that instead.
| 
| Currently we only specify a small number of hooks that are sufficient
| for our use cases.  Future releases of GHC can be extended to include
| more hooks, if that is needed.
| 
| Hooks are stored as an untyped map inside the DynFlags (to avoid issues
| with circular dependencies).  Each hook is looked up using a single-
| constructor type and type families are used to make this type safe.
| There is one use of unsafeCoerce to avoid having to make every hook
| function an instance of Typeable.
| 
| Unlike CorePlugins, it is only a GHC API feature, and users cannot
| specify plugins to be added via command line options.  If we can come up
| with a good design, then we could add this in GHC 7.10, but it is not
| necessary at this point.
| 
| Luite: Do you have a link to your latest patch?