<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:"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:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
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:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
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";
mso-fareast-language:EN-US;}
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:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoPlainText" style="margin-left:36.0pt">1. Should we allow binding type variables that are not explicitly quantified with a forall? I'm concerned about the potential for breaking code should GHC's rules for ordering quantifiers change. Does GHC already
guarantee a particular ordering?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">See <a href="https://github.com/ghc-proposals/ghc-proposals/pull/155#issuecomment-469241834">
my comments</a> on GitHub.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:36.0pt">2. I wonder if supporting type binders in inference mode is as hard as the proposal fears.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I think it’s hard. <o:p></o:p></p>
<p class="MsoPlainText"> f @a x = x<o:p></o:p></p>
<p class="MsoPlainText">we could infer any of.<o:p></o:p></p>
<p class="MsoPlainText"> f :: forall a b. b -> b<o:p></o:p></p>
<p class="MsoPlainText"> f :: forall a. a -> a<o:p></o:p></p>
<p class="MsoPlainText"> f :: forall b a. b -> b<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Roughly, it’s as hard as figuring out impredicative polymorphism I think. Let’s not go there
<span style="font-family:"Segoe UI Emoji",sans-serif">😊</span>.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Simon<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><span lang="EN-US" style="mso-fareast-language:EN-GB">-----Original Message-----<br>
From: ghc-steering-committee <ghc-steering-committee-bounces@haskell.org> On Behalf Of Eric Seidel<br>
Sent: 04 March 2019 01:44<br>
To: ghc-steering-committee@haskell.org<br>
Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas</span></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">One argument in favor of the proposal that I don't believe I've seen mentioned is that, now that we can explicitly apply types with the @ syntax, it feels very intuitive to also bind them with the same syntax. So even if this proposal
does not add much technically over ScopedTypeVariables, I think it's still a good idea.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I do have a couple of questions/comments though:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">1. Should we allow binding type variables that are not explicitly quantified with a forall? I'm concerned about the potential for breaking code should GHC's rules for ordering quantifiers change. Does GHC already guarantee a particular
ordering? Would we want to?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">2. I wonder if supporting type binders in inference mode is as hard as the proposal fears. The alternatives section mentions the possibility of extracting a partial type signature from the LHS, but I had a simpler thought. Why not say
that `\ @a -> body` infers the type `forall a. ty` where `body :: ty`, and let unification handle the rest? It seems like that would handle all of the variants of `null` in section 7, though not the example in section 3 with the equality constraint. But to
be honest, I'd be ok with rejecting that program. It would be much clearer with a single type binder.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I don't think the lack of a solution for type binders in inference mode should block this proposal, but it would be much nicer if we had one! I don't want Haskell programmers to have to learn the intricacies of bidirectional type checking
to use what is otherwise a very intuitive feature.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Eric<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">On Tue, Feb 19, 2019, at 14:01, Iavor Diatchki wrote:<o:p></o:p></p>
<p class="MsoPlainText">> After a bit more thought, I am not sure what do we get with this
<o:p></o:p></p>
<p class="MsoPlainText">> notation over ScopedTypeVariables. In particular, here are some things
<o:p></o:p></p>
<p class="MsoPlainText">> that came up as I was trying to write a couple of examples:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 1. The order in which variables are introduced is not <o:p>
</o:p></p>
<p class="MsoPlainText">> clear---presumably it is some sort of left to write ordering based on
<o:p></o:p></p>
<p class="MsoPlainText">> the type signature. For example:<o:p></o:p></p>
<p class="MsoPlainText">> f1 :: (a,b) -> a -- first type param is `a`?<o:p></o:p></p>
<p class="MsoPlainText">> f2 :: Ord b => a -> b -> a -- first type param is `b`?<o:p></o:p></p>
<p class="MsoPlainText">> type T a b = (b,a)<o:p></o:p></p>
<p class="MsoPlainText">> f3 :: T a b -> a -- first type param is?<o:p></o:p></p>
<p class="MsoPlainText">> This approach seems quite fragile.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 2. The proposal says that a problem with the `forall` in
<o:p></o:p></p>
<p class="MsoPlainText">> ScopedTypeVariables is that the signature can be arbitrarily far away
<o:p></o:p></p>
<p class="MsoPlainText">> from the implementation. I agree that this is a problem, but it seems
<o:p></o:p></p>
<p class="MsoPlainText">> to remain a problem with this proposal, as you have to look at the
<o:p></o:p></p>
<p class="MsoPlainText">> signature to see in what order you should write the parameters.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> 3. There are some things that you can write with the `forall`
<o:p></o:p></p>
<p class="MsoPlainText">> notation, that you cannot write using this notation. For example:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> f3 :: forall a. Bool<o:p></o:p></p>
<p class="MsoPlainText">> f3 = null ([] :: [a])<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Clearly this example is a bit contrived, but still it illustrates a problem.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> As is, I am not sure what we are getting over ScopedTypeVariables. Am
<o:p></o:p></p>
<p class="MsoPlainText">> I missing something here?<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> -Iavor<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> On Tue, Feb 19, 2019 at 10:28 AM Iavor Diatchki <o:p></o:p></p>
<p class="MsoPlainText">> <<a href="mailto:iavor.diatchki@gmail.com"><span style="color:windowtext;text-decoration:none">iavor.diatchki@gmail.com</span></a>> wrote:<o:p></o:p></p>
<p class="MsoPlainText">> > Hello,<o:p></o:p></p>
<p class="MsoPlainText">> > <o:p></o:p></p>
<p class="MsoPlainText">> > let's get the discussion going about proposal #155 (<a href="https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000-type-lambda.rst"><span style="color:windowtext;text-decoration:none">https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000-type-lambda.rst</span></a>).<o:p></o:p></p>
<p class="MsoPlainText">> > <o:p></o:p></p>
<p class="MsoPlainText">> > Summary:<o:p></o:p></p>
<p class="MsoPlainText">> > the idea is pretty simple: allow functions to name their type arguments explicitly, so that they can be used in type signatures within the function's definition. The notation for a type argument is `@a`, and such type arguments can
be used only when functions have an explicit type signature (technically, when GHC is doing "checking" rather then "inference").<o:p></o:p></p>
<p class="MsoPlainText">> > <o:p></o:p></p>
<p class="MsoPlainText">> > This proposal provides an alternative to "ScopedTypeVariables" to
<o:p></o:p></p>
<p class="MsoPlainText">> > refer to type parameters, which I think is a step in the right
<o:p></o:p></p>
<p class="MsoPlainText">> > direction, as using the `forall` to introduce type variables always
<o:p></o:p></p>
<p class="MsoPlainText">> > felt a bit hacky to me (now, there's a technical argument :)<o:p></o:p></p>
<p class="MsoPlainText">> > <o:p></o:p></p>
<p class="MsoPlainText">> > I am a bit concerned with the notation though: in other places where we use `@a`, (e.g., #126 type application in patterns, and TypeApplications) the `a` is a type, while in this use it must be a variable. I wonder if this punning
might be confusing. I don't really have an alternative suggestion though.<o:p></o:p></p>
<p class="MsoPlainText">> > <o:p></o:p></p>
<p class="MsoPlainText">> > What does everyone else thing?<o:p></o:p></p>
<p class="MsoPlainText">> > <o:p></o:p></p>
<p class="MsoPlainText">> > -Iavor<o:p></o:p></p>
<p class="MsoPlainText">> _______________________________________________<o:p></o:p></p>
<p class="MsoPlainText">> ghc-steering-committee mailing list<o:p></o:p></p>
<p class="MsoPlainText">> <a href="mailto:ghc-steering-committee@haskell.org"><span style="color:windowtext;text-decoration:none">ghc-steering-committee@haskell.org</span></a><o:p></o:p></p>
<p class="MsoPlainText">> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ">
<span style="color:windowtext;text-decoration:none">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committ</span></a><o:p></o:p></p>
<p class="MsoPlainText">> ee<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">_______________________________________________<o:p></o:p></p>
<p class="MsoPlainText">ghc-steering-committee mailing list<o:p></o:p></p>
<p class="MsoPlainText"><a href="mailto:ghc-steering-committee@haskell.org"><span style="color:windowtext;text-decoration:none">ghc-steering-committee@haskell.org</span></a><o:p></o:p></p>
<p class="MsoPlainText"><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee"><span style="color:windowtext;text-decoration:none">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</span></a><o:p></o:p></p>
</div>
</body>
</html>