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 <simo...@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:stege...@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@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
