<div dir="ltr"><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)">·<span style="font-size:7pt;font-family:'Times New Roman'">
</span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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</span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple"><p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">
data Dynamic where<br>
Dyn :: Typeable a => a -> Dynamic<br>
and you want to take advantage of this.</span><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></p></div></blockquote><div><br></div><div>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.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple">
<p><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">No need for these strange “data DsForeignsHook = DsForeignsHook” things, or for the Hook type family. Simple!</span><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></p>
</div></blockquote><div>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)<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p>
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">The design *<b>must</b>* list all the hooks that GHC uses and their types. There’s no point in adding a hook that GHC
doesn’t call!</span></p></div></div></blockquote><div>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.</div>
<div><br></div><div>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?<br>
</div>
<div><br></div><div>I've uploaded a new patch, using Dynamic, although I'm not sure if it's an improvement over the original one:</div><div><br></div><div>- patch: <a href="https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-dynamic.patch">https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-dynamic.patch</a></div>
<div>- updated hooksDemo: <a href="https://gist.github.com/luite/6478973" target="_blank">https://gist.github.com/luite/6478973</a></div>
<div><br></div><div>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)</div>
<div><br></div><div>luite</div></div></div></div>