<div dir="ltr">Edsko has done some work of rearranging imports in DynFlags to make the DLL split work, and I&#39;ve implemented the hooks on top of this, in a record, as discussed:<div><br></div><div>- <a href="https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-record.patch">https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-record.patch</a> (not final yet, but should be usable for testing)<br>
</div><div>- demo program: <a href="https://gist.github.com/luite/6506064">https://gist.github.com/luite/6506064</a></div><div><br></div><div>Some disadvantages:</div><div>- as long as the DLL split exists, more restructuring will be required if a new hook is added to something in a module on which DynFlags depends</div>
<div>- 4 new hs-boot files required, new hooks will often require additional hs-boot files (when module A has a hook (so A imports Hooks, this can&#39;t be a source import), the hook will often have some types defined by A, so Hooks will have to import A)</div>
<div><br></div><div>Advantages (over type families / Dynamic hooks):<br></div><div>- Hooks neatly defined together in a single record</div><div><br></div><div>I&#39;m not so sure myself, but if everyone agrees that this is better than the older hooks I&#39;ll convert GHCJS to the new implementation later today and finalize the patch (comments are a bit out of date, and I&#39;m not 100% sure yet that GHCJS doesn&#39;t need another hook for TH support in certain setups) and update the wiki.</div>
<div><br></div><div>luite</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 9, 2013 at 4:55 PM, Edsko de Vries <span dir="ltr">&lt;<a href="mailto:edskodevries@gmail.com" target="_blank">edskodevries@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Simon,<br>
<br>
I talked to Luite this morning and I think we can come up with a<br>
design that includes the enumeration we prefer, with a single use of<br>
Dynamic in DynFlags -- it involves splitting off a PackageState module<br>
from Packages so that DynFlags doesn&#39;t depend on the entirely of<br>
Packages anymore (which would then, transitively, mean that it depends<br>
on Hooks and hence on a large part of ghc), but I think that should be<br>
doable. I&#39;m working on that now.<br>
<span class="HOEnZb"><font color="#888888"><br>
Edsko<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, Sep 9, 2013 at 3:51 PM, Simon Peyton-Jones<br>
&lt;<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>&gt; wrote:<br>
&gt; Edsko<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; I’m very short of time right now. I think you understand the issues here.<br>
&gt; Can you do a round or two with Luite and emerge with a design that you both<br>
&gt; think is best?<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; As I said earlier I’m uncomfortable with doing design work so late in the<br>
&gt; cycle, and I feel that I don’t have time to study the various alternatives<br>
&gt; properly in the next four days.  But since you tell me it’s crucial for<br>
&gt; GHCJS, I suppose that a possible compromise is this.  We release a GHC with<br>
&gt; some design for hooks, but specifically say that the hook design is evolving<br>
&gt; and may well change with the next version.  And then you two, with Thomas<br>
&gt; and other interested parties, work together to evolve a design that everyone<br>
&gt; is happy with.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Does that sound ok?<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Simon<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; From: Luite Stegeman [mailto:<a href="mailto:stegeman@gmail.com">stegeman@gmail.com</a>]<br>
&gt; Sent: 07 September 2013 22:04<br>
&gt; To: Simon Peyton-Jones<br>
&gt; Cc: Thomas Schilling; Edsko de Vries; ghc-devs<br>
&gt;<br>
&gt;<br>
&gt; Subject: Re: GHC 7.8 release status<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ·         Why aren’t you using Data.Dynamic for the hook things?  You are<br>
&gt; precisely doing dynamic typing after all.  (Moreover I want to change<br>
&gt; Data.Dynamic so that it says<br>
&gt;<br>
&gt;      data Dynamic where<br>
&gt;          Dyn :: Typeable a =&gt; a -&gt; Dynamic<br>
&gt; and you want to take advantage of this.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Ah the goal is to avoid the Typeable constraint on the hooked function, and<br>
&gt; to identify what things are actually hooks. Wrapping it in a newtype also<br>
&gt; achieves the first goal and does make the design a bit simpler.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; No need for these strange “data DsForeignsHook = DsForeignsHook” things, or<br>
&gt; for the Hook type family.  Simple!<br>
&gt;<br>
&gt; But it means that hooks are no longer recognisable by their type, they&#39;re<br>
&gt; just some Typeable (the type families approach would at least prevent users<br>
&gt; from accidentally inserting wrong hooks, even though they would still be<br>
&gt; able to make bogus instances on purpose)<br>
&gt;<br>
&gt; ·         The design *must* list all the hooks that GHC uses and their<br>
&gt; types.  There’s no point in adding a hook that GHC doesn’t call!<br>
&gt;<br>
&gt; It appears to be difficult to define all hooks in one module or have them in<br>
&gt; one record because of dependencies and the DLL split on Windows.<br>
&gt; Re-exporting everything from a single module can be done, but would offer no<br>
&gt; guarantees about completeness.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; With the type families design, everything that&#39;s an instance of Hook is a<br>
&gt; hook, although the definitions are scattered throughout the GHC source. The<br>
&gt; Dynamic design would just have to rely on a consistent naming convention.<br>
&gt; Would listing the hooks in comments (in the Hooks module) and on the wiki be<br>
&gt; a reasonable way to document them?<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; I&#39;ve uploaded a new patch, using Dynamic, although I&#39;m not sure if it&#39;s an<br>
&gt; improvement over the original one:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; - patch:<br>
&gt; <a href="https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-dynamic.patch" target="_blank">https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-dynamic.patch</a><br>
&gt;<br>
&gt; - updated hooksDemo: <a href="https://gist.github.com/luite/6478973" target="_blank">https://gist.github.com/luite/6478973</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; It also adds hscParse&#39; and tcRnModule&#39; exports for Edsko&#39;s use case (I think<br>
&gt; that makes it somewhat more flexible than exporting another version of<br>
&gt; hscFileFrontend, since it allows users to write a hook that does something<br>
&gt; between parsing and typechecking or one that overrides one of these phases)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; luite<br>
&gt;<br>
&gt;<br>
</div></div><div class="HOEnZb"><div class="h5">&gt; _______________________________________________<br>
&gt; ghc-devs mailing list<br>
&gt; <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
&gt;<br>
</div></div></blockquote></div><br></div>