<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=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.Code, li.Code, div.Code
{mso-style-name:Code;
mso-style-link:"Code Char";
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Courier New";
color:#1F497D;}
span.CodeChar
{mso-style-name:"Code Char";
mso-style-link:Code;
font-family:"Courier New";
color:#1F497D;}
span.EmailStyle19
{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;}
/* List Definitions */
@list l0
{mso-list-id:1531259858;
mso-list-type:hybrid;
mso-list-template-ids:745470742 134807553 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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" style="margin-left:36.0pt">I am back from vacation! <o:p></o:p></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">Well I am ON vacation, but the children are in bed...<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">Two thoughts:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">I like EvTerm as a distinct data type precisely because it enumerates all the forms of evidence we need. Once you allow
arbitrary CoreExprs, we lose that explicit enumeration. <o:p></o:p></span></p>
<p class="MsoListParagraph"><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="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Now, that might be OK. Evidence terms are proof terms: any well typed EvTerm is a proof of the predicate described by its
type. So if a CoreExpr has the right type, then it *<b>should</b>* be the case that the evidence term is OK (provided it’s not bottom). So I can’t quite nail down why I like the explicit EvTerm; except the relatively minor reason that it puts off desugaring
to the desugarer.<o:p></o:p></span></p>
<p class="MsoListParagraph"><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="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D;mso-fareast-language:EN-US"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">On a separate matter, can we eliminate the trap-door from TcPluginM to TcM? That is, can you enumerate all the things you
need from TcPluginM? The reason I ask is that I’d like to stop building TcS on top of TcM, and instead make it a free-standing monad. Reason: we increasingly want to do constraint solving outside a full-blown typechecker. Eg. when doing pattern-match exhaustiveness
checks. Faking up a TcM monad with lots of error thunks seems wrong.<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">Lastly: would someone like to add Adam’s explanation to the Commentary somewhere?<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>
<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"> Iavor Diatchki [mailto:iavor.diatchki@gmail.com]
<br>
<b>Sent:</b> 27 May 2015 17:26<br>
<b>To:</b> Adam Gundry; Richard Eisenberg; Simon Peyton Jones<br>
<b>Cc:</b> Christiaan Baaij<br>
<b>Subject:</b> Re: TypeChecker plugins and the TcS monad; given constraints in GHC HEAD<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">
Hi guys,<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">
I am back from vacation! (cc-ing Richard and Simon, as they might also be interested in some of these changes).<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 am very much on board with the changes suggested by Adam.<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">
A couple of thoughts:<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">
* GHC already has some support for evaluation of custom type-families, we added it for evaluating + and friends. It might be good to use the same system for custom evaluation in tc-plugins too, even if we have to modify it some. Currently, this is done
by having another "flavor" of type constructor (see `FamTyConFlav` in module `TyCon`), namely one that has built-in evaluation rules. The actual details of how the evaluation happens are in module `CoAxiom`, see `BuiltInSynFamily`: the first field is for
evaluating the constructor applied to some arguments (the other two are for emitting derived constraints, `sfInteractTop` is for improvements of a constraint on it's own, and `sfInteractIntert` is for interactions with another constraint that already existis).<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">
* If we are going to be modifying `TcEvidence`, I'd be really keen on integrating the evidence for coersions and other evidence a bit more: in particular, it really make sense to allow class predicates in the assumptions of equality constraints. This would
allow us to generate evidence for improvements due to interactions of given classes with functional dependencies (e.g., we could express axioms like this: `forall a b c. (C a b, C a c) => (b ~ c)`)<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">
-Iavor<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">
<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">
<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 Tue, May 26, 2015 at 6:34 AM, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.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">
Thanks Christiaan,<br>
<br>
Nice work on ghc-tcplugins-extra. Providing a common package that<br>
abstracts away GHC API variations between versions (as far as possible)<br>
seems really useful. I notice you also include a workaround for GHC<br>
#10301, which is good. I'll try to switch over uom-plugin to use it.<br>
<br>
As far as I can see, there's no way to bind EvTerms outside TcS; indeed<br>
that's a major part of the point of TcS. I'm inclining towards making<br>
TcPluginM into a wrapper around TcS, then exposing a nice API to create<br>
givens etc.<br>
<br>
Perhaps we should put together a list of proposed changes to the plugins<br>
API, in the light of experience writing the things? There are a few<br>
other things I'd like:<br>
<br>
* the ability to embed arbitrary Core expressions in EvTerms;<br>
<br>
* a new field in TcPlugin to define type-family reductions directly,<br>
rather than having to look for equality constraints involving them;<br>
<br>
* serializable CoAxiomRules to allow proper evidence in place of UnivCo<br>
(doing this for families of rules is a bit tricky, but it should be easy<br>
enough to define single axioms).<br>
<br>
Anything you'd like to add? Iavor?<br>
<br>
Cheers,<br>
<br>
Adam<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>
<br>
On 21/05/15 18:46, Christiaan Baaij wrote:<br>
> Hi Adam, Iavor,<br>
><br>
> 1. typechecker-plugins-extra package:<br>
><br>
> I started on a typechecker-plugin-extra package<br>
> at: <a href="https://github.com/clash-lang/ghc-tcplugins-extra" target="_blank">
https://github.com/clash-lang/ghc-tcplugins-extra</a><br>
> Which currently<br>
> contains: <a href="https://github.com/clash-lang/ghc-tcplugins-extra/blob/master/src/GHC/TcPluginM/Extra.hs" target="_blank">
https://github.com/clash-lang/ghc-tcplugins-extra/blob/master/src/GHC/TcPluginM/Extra.hs</a><br>
><br>
> It currently compiles with both GHC 7.10.1 and HEAD.<br>
> Althought the 'newSimpleGiven' function is basically broken in HEAD<br>
> because there is no way to bind the evidence anywhere.<br>
><br>
> 2. wanted & error messages:<br>
><br>
> Indeed, I fixed the error message location by using the correct 'CtLoc'.<br>
> I needed the chain of wanted 'EvVar' to get deferred-type-errors working<br>
> properly.<br>
> However, as you say, the proper way to solve this problem it to create<br>
> evidence for the 'parent' wanted in terms of the discharged wanteds.<br>
> Currently I've been using the same thing you can Iavor are using:<br>
> UnivCo, the unsafeCoerce of EvTerms.<br>
> I'll investigate if I can somehow manage to properly solve this problem.<br>
> At least the fallback mechanism I've implemented already is currently<br>
> working.<br>
><br>
> 3. TcS vs TcM<br>
> If we keep TcPluginM as a wrapper around TcM, do you know "where" we<br>
> could bind EvTerms so that other parts of the constraint solving<br>
> pipeline can also access them?<br>
> Are these EvTerms bound in some IORef'd environment which we can access<br>
> in TcM?<br>
><br>
> Cheers,<br>
><br>
> Christiaan<br>
><br>
> On 21 May 2015 at 18:51, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a><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">
> <mailto:<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>>> wrote:<br>
><br>
> Hi Christiaan,<br>
><br>
> Thanks for your emails, and sorry I can't quite keep up with them! Let<br>
> me try to tackle the issues you raise, in no particular order:<br>
><br>
><br>
> 1. TcS vs. TcM<br>
><br>
> There's no immediate problem with running plugins in TcS rather than<br>
> TcM. Indeed, this was my original proposal, but we decided otherwise<br>
> because TcS is really supposed to capture the internal state of GHC's<br>
> constraint solver, which shouldn't (in principle) be of interest to<br>
> plugins. That is, plugins are deliberately not given access to the inert<br>
> set (and hence its cache of solved constraints), because we want to<br>
> build an interface that is independent of GHC's particular constraint<br>
> solving algorithm. At least that's the goal...<br>
><br>
><br>
> 2. Disappearance of ctev_evtm<br>
><br>
> I don't follow HEAD closely enough to have spotted this, so thanks for<br>
> pointing it out. It looks like the change is indeed a problem for<br>
> plugins, because the plugin interface indeed doesn't offer the<br>
> integration with TcS necessary to create evidence variables that are<br>
> already bound. I guess we should add a function to TcPluginM to bind an<br>
> evidence variable. In fact, probably we should offer functions in<br>
> TcPluginM that look something like<br>
><br>
> newWanted :: CtLoc -> PredType -> TcPluginM CtEvidence<br>
> newDerived :: CtLoc -> PredType -> TcPluginM CtEvidence<br>
> newGiven :: CtLoc -> PredType -> EvTerm -> TcPluginM CtEvidence<br>
><br>
> (or perhaps CtOrigin instead of CtLoc? I can never remember the<br>
> difference).<br>
><br>
><br>
> 3. On wanteds and error messages<br>
><br>
> I've not come across the issues you mention with error message locations<br>
> and deferred type errors, but I guess that might be because my plugin<br>
> tends to spot insoluble constraints fairly early (rather than<br>
> simplifying constraints that subsequently turn out to be insoluble on a<br>
> later iteration).<br>
><br>
> The way this ought to work is that a plugin should solve a wanted with<br>
> an evidence term that contains a reference to a new wanted, rather than<br>
> completely bogus evidence; this should ensure that deferred type errors<br>
> fire correctly. But in practice that might be difficult at the moment.<br>
><br>
> In general, I like the idea of a typechecker-plugin-extra package to<br>
> bundle up useful common plugin functionality, some of which may later be<br>
> moved into GHC itself. (We could start with those functions above!)<br>
> Perhaps it could also provide some measure of stability across GHC<br>
> releases. I've not yet convinced myself that the trick you describe for<br>
> creating chains of wanteds is really necessary to get good error<br>
> locations, but if it is, making it part of such a package is a good<br>
> plan.<br>
><br>
> Cheers,<br>
><br>
> Adam<br>
><br>
><br>
><br>
> On 21/05/15 09:39, Christiaan Baaij wrote:<br>
> > Hi Adam, Hi Iavor,<br>
> ><br>
> > While working on creating my type-checker plugins, I noticed that<br>
> there are some functions in operate in the ’TcS’ monad that I would<br>
> like to use.<br>
> > In an earlier email, for example, Iavor suggested that I use<br>
> ‘newWantedEvVar’ to create new wanted constraints, but this operates<br>
> in the ’TcS’ monad.<br>
> > Of course, there’s ‘runTcS’, but this creates a TcS monad with an<br>
> empty ‘Bag' of ‘EvBind’.<br>
> > What this means, is that (I think), ‘newWantedEvVar’ and<br>
> ‘newWantedEvVarNC’, basically behave the same when run inside<br>
> ‘runTcS’, because ‘newWantedEvVar’ is going to look for existing<br>
> evidence in an empty ‘Bag’…<br>
> ><br>
> > Also, I saw that plugins are run by the functions in the<br>
> ‘TcInteract’ module, which all run inside the ‘TcS’ monad.<br>
> > So my question is, would it make sense to make ‘TcPluginM’ a<br>
> wrapper around ‘TcS’ instead of ‘TcM’?<br>
> > I understand that it would mean<br>
> ><br>
> > tcPluginIO :: IO a -> TcPluginM a<br>
> ><br>
> > would have to be specified in terms of either<br>
> ‘TcSMonad.wrapErrTcS’ or ‘TsSMonad.wrapErrTcS’ and violate the<br>
> purpose of those functions.<br>
> > Anyhow, that’s my question/suggestion with regards to the TcS monad.<br>
> > On to the other part.<br>
> ><br>
> ><br>
> > I noticed that both your plugins store the Coercion/Evidence for a<br>
> new Given constraint in the ‘ctev_evtm’ field of the ‘CtGiven’<br>
> constructor.<br>
> > However, in GHC HEAD, this field no longer exists…<br>
> > In GHC HEAD, there is only ‘ctev_evar’, of type ‘EvVar’, in the<br>
> ‘CtGiven’ constructor.<br>
> > I think Simon PJ refactored this because nowhere else in the GHC<br>
> compiler was ‘ctev_evtm’ used to store anything else than an identifier…<br>
> > The reason being that the evidence was stored ‘TcSEnv’ passed<br>
> around in the TcS monad.<br>
> > So in GHC HEAD, I think there’s no longer any way create new<br>
> Givens of which their evidence can be stored somewhere…<br>
> > Perhaps one of you two knows how to store evidence of a Given in<br>
> GHC HEAD?<br>
> ><br>
> > Best regards,<br>
> ><br>
> > Christiaan<br>
> ><br>
<br>
<br>
--<br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="http://www.well-typed.com/" target="_blank">http://www.well-typed.com/</a><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>
</div>
</body>
</html>