GHC 7.8 release status

[Thomas Schilling]

I started a wiki page at: http://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks

Luite: could you please fill in the hooks that your latest patch defines?


On 4 Sep 2013, at 19:40, Simon Peyton-Jones <simonpj at microsoft.com> wrote:

> 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130905/19b02b9e/attachment.pgp>