<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
.MsoPapDefault
{mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">I do like the single record.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">I would really really like a strong clear Note [blah] on the hooks::Dynamic field of DynFlags. It’s *<b>so</b>* non-obvious why it’s
dynamic, and the reason is a really bad one, namely the windows DLL split nonsense. (Not our fault but still needs very clear signposting.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">I don’t understand why we need 4 new hs-boot files. Eg why DsMonad.hs-boot? It should be safely below Hooks.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">Linker.hs-boot is solely because of LibrarySpec. It would be possible to push that into HscTypes. (Again with a comment to explain
why.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">DriverPipeline is aleady 2,100 lines long, and could reasonably be split with CompPipeline in the PipelineMonad module, say.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">In other words, a bit of refactoring might eliminate the loops *<b>and</b>* sometimes arguably improve the code.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">I don’t feel terribly strongly about all this. It does feel a bit ad hoc… in a variety of places (eg deep in Linker.hs) there are
calls to hooks, and it’s not clear to me why exactly those are the right places. But I suppose they are simply driven by what has been needed.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">Anyway if you two are happy (no one else seems to mind either way) then go ahead.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Luite Stegeman [mailto:stegeman@gmail.com]
<br>
<b>Sent:</b> 10 September 2013 08:37<br>
<b>To:</b> Edsko de Vries<br>
<b>Cc:</b> Simon Peyton-Jones; ghc-devs; Edsko de Vries<br>
<b>Subject:</b> Re: GHC 7.8 release status<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Edsko has done some work of rearranging imports in DynFlags to make the DLL split work, and I've implemented the hooks on top of this, in a record, as discussed:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
- <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)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
- demo program: <a href="https://gist.github.com/luite/6506064">https://gist.github.com/luite/6506064</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Some disadvantages:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
- 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<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
- 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't be a source import), the hook will often have some types defined by A, so Hooks will have to import A)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Advantages (over type families / Dynamic hooks):<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
- Hooks neatly defined together in a single record<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
I'm not so sure myself, but if everyone agrees that this is better than the older hooks I'll convert GHCJS to the new implementation later today and finalize the patch (comments are a bit out of date, and I'm not 100% sure yet that GHCJS doesn't need another
hook for TH support in certain setups) and update the wiki.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
luite<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Mon, Sep 9, 2013 at 4:55 PM, Edsko de Vries <<a href="mailto:edskodevries@gmail.com" target="_blank">edskodevries@gmail.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
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'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'm working on that now.<br>
<span style="color:#888888"><br>
<span class="hoenzb">Edsko</span></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<br>
On Mon, Sep 9, 2013 at 3:51 PM, Simon Peyton-Jones<br>
<<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<br>
> Edsko<br>
><br>
><br>
><br>
> I’m very short of time right now. I think you understand the issues here.<br>
> Can you do a round or two with Luite and emerge with a design that you both<br>
> think is best?<br>
><br>
><br>
><br>
> As I said earlier I’m uncomfortable with doing design work so late in the<br>
> cycle, and I feel that I don’t have time to study the various alternatives<br>
> properly in the next four days. But since you tell me it’s crucial for<br>
> GHCJS, I suppose that a possible compromise is this. We release a GHC with<br>
> some design for hooks, but specifically say that the hook design is evolving<br>
> and may well change with the next version. And then you two, with Thomas<br>
> and other interested parties, work together to evolve a design that everyone<br>
> is happy with.<br>
><br>
><br>
><br>
> Does that sound ok?<br>
><br>
><br>
><br>
> Simon<br>
><br>
><br>
><br>
> From: Luite Stegeman [mailto:<a href="mailto:stegeman@gmail.com">stegeman@gmail.com</a>]<br>
> Sent: 07 September 2013 22:04<br>
> To: Simon Peyton-Jones<br>
> Cc: Thomas Schilling; Edsko de Vries; ghc-devs<br>
><br>
><br>
> Subject: Re: GHC 7.8 release status<br>
><br>
><br>
><br>
> · Why aren’t you using Data.Dynamic for the hook things? You are<br>
> precisely doing dynamic typing after all. (Moreover I want to change<br>
> Data.Dynamic so that it says<br>
><br>
> data Dynamic where<br>
> Dyn :: Typeable a => a -> Dynamic<br>
> and you want to take advantage of this.<br>
><br>
><br>
><br>
> Ah the goal is to avoid the Typeable constraint on the hooked function, and<br>
> to identify what things are actually hooks. Wrapping it in a newtype also<br>
> achieves the first goal and does make the design a bit simpler.<br>
><br>
><br>
><br>
> No need for these strange “data DsForeignsHook = DsForeignsHook” things, or<br>
> for the Hook type family. Simple!<br>
><br>
> But it means that hooks are no longer recognisable by their type, they're<br>
> just some Typeable (the type families approach would at least prevent users<br>
> from accidentally inserting wrong hooks, even though they would still be<br>
> able to make bogus instances on purpose)<br>
><br>
> · The design *must* list all the hooks that GHC uses and their<br>
> types. There’s no point in adding a hook that GHC doesn’t call!<br>
><br>
> It appears to be difficult to define all hooks in one module or have them in<br>
> one record because of dependencies and the DLL split on Windows.<br>
> Re-exporting everything from a single module can be done, but would offer no<br>
> guarantees about completeness.<br>
><br>
><br>
><br>
> With the type families design, everything that's an instance of Hook is a<br>
> hook, although the definitions are scattered throughout the GHC source. The<br>
> Dynamic design would just have to rely on a consistent naming convention.<br>
> Would listing the hooks in comments (in the Hooks module) and on the wiki be<br>
> a reasonable way to document them?<br>
><br>
><br>
><br>
> I've uploaded a new patch, using Dynamic, although I'm not sure if it's an<br>
> improvement over the original one:<br>
><br>
><br>
><br>
> - patch:<br>
> <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>
><br>
> - updated hooksDemo: <a href="https://gist.github.com/luite/6478973" target="_blank">
https://gist.github.com/luite/6478973</a><br>
><br>
><br>
><br>
> It also adds hscParse' and tcRnModule' exports for Edsko's use case (I think<br>
> that makes it somewhat more flexible than exporting another version of<br>
> hscFileFrontend, since it allows users to write a hook that does something<br>
> between parsing and typechecking or one that overrides one of these phases)<br>
><br>
><br>
><br>
> luite<br>
><br>
><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>