GHC 7.8 release status

[Edsko de Vries]

Simon,

I talked to Luite this morning and I think we can come up with a
design that includes the enumeration we prefer, with a single use of
Dynamic in DynFlags -- it involves splitting off a PackageState module
from Packages so that DynFlags doesn't depend on the entirely of
Packages anymore (which would then, transitively, mean that it depends
on Hooks and hence on a large part of ghc), but I think that should be
doable. I'm working on that now.

Edsko

On Mon, Sep 9, 2013 at 3:51 PM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> Edsko
>
>
>
> I’m very short of time right now. I think you understand the issues here.
> Can you do a round or two with Luite and emerge with a design that you both
> think is best?
>
>
>
> As I said earlier I’m uncomfortable with doing design work so late in the
> cycle, and I feel that I don’t have time to study the various alternatives
> properly in the next four days.  But since you tell me it’s crucial for
> GHCJS, I suppose that a possible compromise is this.  We release a GHC with
> some design for hooks, but specifically say that the hook design is evolving
> and may well change with the next version.  And then you two, with Thomas
> and other interested parties, work together to evolve a design that everyone
> is happy with.
>
>
>
> Does that sound ok?
>
>
>
> Simon
>
>
>
> From: Luite Stegeman [mailto:stegeman at gmail.com]
> Sent: 07 September 2013 22:04
> To: Simon Peyton-Jones
> Cc: Thomas Schilling; Edsko de Vries; ghc-devs
>
>
> Subject: Re: GHC 7.8 release status
>
>
>
> ·         Why aren’t you using Data.Dynamic for the hook things?  You are
> precisely doing dynamic typing after all.  (Moreover I want to change
> Data.Dynamic so that it says
>
>      data Dynamic where
>          Dyn :: Typeable a => a -> Dynamic
> and you want to take advantage of this.
>
>
>
> Ah the goal is to avoid the Typeable constraint on the hooked function, and
> to identify what things are actually hooks. Wrapping it in a newtype also
> achieves the first goal and does make the design a bit simpler.
>
>
>
> No need for these strange “data DsForeignsHook = DsForeignsHook” things, or
> for the Hook type family.  Simple!
>
> But it means that hooks are no longer recognisable by their type, they're
> just some Typeable (the type families approach would at least prevent users
> from accidentally inserting wrong hooks, even though they would still be
> able to make bogus instances on purpose)
>
> ·         The design *must* list all the hooks that GHC uses and their
> types.  There’s no point in adding a hook that GHC doesn’t call!
>
> It appears to be difficult to define all hooks in one module or have them in
> one record because of dependencies and the DLL split on Windows.
> Re-exporting everything from a single module can be done, but would offer no
> guarantees about completeness.
>
>
>
> With the type families design, everything that's an instance of Hook is a
> hook, although the definitions are scattered throughout the GHC source. The
> Dynamic design would just have to rely on a consistent naming convention.
> Would listing the hooks in comments (in the Hooks module) and on the wiki be
> a reasonable way to document them?
>
>
>
> I've uploaded a new patch, using Dynamic, although I'm not sure if it's an
> improvement over the original one:
>
>
>
> - patch:
> https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-dynamic.patch
>
> - updated hooksDemo: https://gist.github.com/luite/6478973
>
>
>
> It also adds hscParse' and tcRnModule' exports for Edsko's use case (I think
> that makes it somewhat more flexible than exporting another version of
> hscFileFrontend, since it allows users to write a hook that does something
> between parsing and typechecking or one that overrides one of these phases)
>
>
>
> luite
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>