<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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
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:11.0pt;
font-family:"Courier New";}
span.CodeChar
{mso-style-name:"Code Char";
mso-style-link:Code;
font-family:"Courier New";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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="mso-fareast-language:EN-US">I’m afraid I agree here. We need a much more compelling motivation before adopting all this extra stuff. Moreover, absent compelling use-cases it’s all too easy to implement something that, when
the use-cases arrive, turns out to be not quite right. Best to inform the design directly from a collection of motivating uses.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">There’s a simple bug-fix for now: just reject the program. If we get lots of people yelling that they really want such programs, we can tackle it then.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="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">From:</span></b><span lang="EN-US"> ghc-steering-committee <ghc-steering-committee-bounces@haskell.org>
<b>On Behalf Of </b>Richard Eisenberg<br>
<b>Sent:</b> 07 March 2019 15:21<br>
<b>To:</b> ghc-steering-committee <ghc-steering-committee@haskell.org><br>
<b>Subject:</b> [ghc-steering-committee] #207: Type variables in TH quotes (recommendation: reject)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi committee,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Matthew Pickering has proposed #207: Fix the treatment of type variables in quotations. (In contrast to the email from our Most Honored and Appreciated Secretary: Matt wrote the proposal, not me.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">PR: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F207&data=02%7C01%7Csimonpj%40microsoft.com%7Cc8827273f9e44622cb0408d6a3109b10%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636875689049631261&sdata=AXbw0Qv0srD4CbUt2HE8AR%2FxOfO%2Fpk7YFa61x384Bmw%3D&reserved=0">https://github.com/ghc-proposals/ghc-proposals/pull/207</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Proposal: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmpickering%2Fghc-proposals%2Fblob%2Fcsp-types%2Fproposals%2F0000-csp-types.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc8827273f9e44622cb0408d6a3109b10%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636875689049641265&sdata=e95B6Dsf0jhEy8IU%2BWCNfjQG8yT8S3KE5eqfCfL9GfE%3D&reserved=0">https://github.com/mpickering/ghc-proposals/blob/csp-types/proposals/0000-csp-types.rst</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The proposal considers code like this:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">foo :: forall a. Proxy a -> Q Exp<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">foo _ = [| let x :: a -> a; ... |]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Note that the type variable `a` is in scope in the quotation. Currently, this quotation is accepted, but then any use of it in a splice leads to an error, because the `a` has a Unique of a variable that has fallen out of scope. This is
just plain wrong.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Matt proposes to fix this by introducing a new class LiftT, with one method: liftTyCl :: forall {k} (a :: k). LiftT a => Q Type. This is a type-level equivalent of the existing Lift class, whose `lift` method produces a Q Exp. Instances
of LiftT would be automatically provided by GHC at all types, including polytypes. Matt has already implemented the proposal.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I recommend against accepting this proposal in its current form, for the following reasons:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - While the proposal addresses a specific, real bug in TH, this is far from the simplest solution. Instead, we could just state that no variables brought into scope outside a TH quote remain in scope within the TH quote. The body of `foo`
above would be rejected for this reason.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - There is no motivation for the new feature in the proposal, other than fixing the bug.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - The example in the proposal is one that, even with this proposal implemented, would not work: it uses *typed* TH, which does not allow type-level splices. So, even if Matt has a genuine need for this feature leading to the example in
the proposal, implementing the proposal doesn't actually solve his problem.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - The proposal mentions the possibility of using Typeable instead of LiftT, but discards this idea because we cannot solve, e.g., Typeable (forall a. a -> a); in contrast, we can solve LiftT instances of that form. However, generating
a need for a LiftT instance of that form requires -XImpredicativeTypes, which is a bug, not a feature.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - Although Matt has kindly already implemented this feature, we all know that the initial implementation of a feature is only the tip of the iceberg in its cost. Adding this feature, as proposed, introduces yet another class that we have
to have custom treatment for, along with various other points of complexity.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Perhaps with proper motivation -- and with an implementation based on Typeable -- I would be more in support. I do think this may be useful. But given the fact that the TH bug has existed since the dawn of time and no one has complained
until now -- and even now, there is no practical, on the ground motivation -- I'm uninclined to move forward here.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As usual, I will take silence as agreement with this recommendation to reject, but I'd love to hear opposing viewpoints.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Richard<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>