GHC 7.8 release status

[Luke Iannini]

Hi Luite,

Would we be able to adapt this to get generalized Template Haskell support
for GHC iOS/cross compilation?

Cheers
Luke


On Wed, Sep 4, 2013 at 6:09 PM, Luite Stegeman <stegeman at gmail.com> wrote:

> I've updated the wiki page, expanding the descriptions and adding code
> from the actual implementation:
> http://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks
> An demo program that uses all hooks here:
> https://gist.github.com/luite/6444273
> (I've listed the users (or proposers) of every hook, and how they use it,
> Thomas / Edsko, can you check that they indeed do what you need?)
> The patch is here:
>
> https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks.patch
>
> In addition to defining the heterogeneous map and the hooks themselves,
> extra exports have been added to make it possible for users to actually
> make a hook implementation without copying most of the module's source
> code. The demo program implements all hooks to check this.
>
> Also the GHCJS patch is here:
>
>
> https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch
>
> It adds the following:
> - in DynFlags an extra WayCustom constructor to add a custom 'tag' to
> generated files (GHCJS builds multiple architectures to support Template
> Haskell among other things, one with the 'js' tag)
> - in ForeignCall the JavaScriptCallConv calling convention
> - in Platform an ArchJavaScript architecture
> - `foreign import javascript' support in the parser and lexer
> - The JavaScriptFFI extension that enables the `foreign import javascript'
> syntax, only supported on ArchJavaScript (So using it on a regular GHC
> would always result in a compile error saying that it's unsupported on the
> user's platform)
>
> luite
>
>
> On Thu, Sep 5, 2013 at 12:17 AM, Thomas Schilling <nominolo at googlemail.com
> > wrote:
>
>> 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?
>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130904/32f0f1a7/attachment.htm>