<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: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.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:11.0pt;
font-family:"Calibri",sans-serif;}
p.Code, li.Code, div.Code
{mso-style-name:Code;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
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.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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:1719737539;
mso-list-type:hybrid;
mso-list-template-ids:690126842 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;}
@list l1
{mso-list-id:2036541690;
mso-list-type:hybrid;
mso-list-template-ids:-1148410966 134807553 134807567 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l1: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 l1:level2
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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"><span style="mso-fareast-language:EN-US">The issue about ‘*’ seems to be this<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph" style="margin-left:0cm;mso-list:l1 level1 lfo2"><span style="mso-fareast-language:EN-US">We need a way to write down the kind of types. E.g. Int :: ???<o:p></o:p></span></li></ul>
<p class="MsoListParagraph"><span style="mso-fareast-language:EN-US">What is the “???”<o:p></o:p></span></p>
<p class="MsoListParagraph"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:36.0pt;text-indent:-17.85pt;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-family:Symbol;mso-fareast-language:EN-US"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="mso-fareast-language:EN-US">There are several possibilities<o:p></o:p></span></p>
<p class="MsoListParagraph" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:72.0pt;text-indent:-17.85pt;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="mso-fareast-language:EN-US"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="mso-fareast-language:EN-US">Continue to use * as
<b>built in syntax. </b>It’s a massive wart; you can’t write (*->*) because GHC thinks that’s a single lexeme; and * is a terrifically useful infix operator, so stealing it is horrible. I’m sure we would never do this today.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:72.0pt;text-indent:-17.85pt;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="mso-fareast-language:EN-US"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="mso-fareast-language:EN-US">Import a module Data.Type to bring Type into scope using the
<b>normal module scoping mechanism</b>. <o:p></o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<ol style="margin-top:0cm" start="2" type="1">
<ul style="margin-top:0cm" type="square">
<li class="MsoListParagraph" style="margin-top:6.0pt;margin-bottom:6.0pt;margin-left:0cm;mso-list:l1 level3 lfo2">
<span style="mso-fareast-language:EN-US">Advantage: no new special things<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-top:6.0pt;margin-bottom:6.0pt;margin-left:0cm;mso-list:l1 level3 lfo2">
<span style="mso-fareast-language:EN-US">Disadvantage: an extra import; and error messages might say Data.Type.Type fully qualified if you didn’t have the import.<o:p></o:p></span></li></ul>
</ol>
</ul>
<p class="MsoListParagraph" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:72.0pt;text-indent:-17.85pt;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="mso-fareast-language:EN-US"><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="mso-fareast-language:EN-US">Same, but export Type from Prelude.
<o:p></o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<ol style="margin-top:0cm" start="3" type="1">
<ul style="margin-top:0cm" type="square">
<li class="MsoListParagraph" style="margin-top:6.0pt;margin-bottom:6.0pt;margin-left:0cm;mso-list:l1 level3 lfo2">
<span style="mso-fareast-language:EN-US">Advantage: no need for that special import<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-top:6.0pt;margin-bottom:6.0pt;margin-left:0cm;mso-list:l1 level3 lfo2">
<span style="mso-fareast-language:EN-US">Disadvantage: would break existing programs that define Type, and import Prelude, regardless of flags.<o:p></o:p></span></li></ul>
</ol>
</ul>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:90.0pt">
<span style="mso-fareast-language:EN-US">I suppose we could say that you only get Type from Prelude if -XTypeInType is also on, but that IS new (and ad hoc) mechanism.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:72.0pt;text-indent:-17.85pt;mso-list:l1 level2 lfo2">
<![if !supportLists]><span style="mso-fareast-language:EN-US"><span style="mso-list:Ignore">4.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="mso-fareast-language:EN-US">Define Type as a new
<b>keyword</b> (with TypeInType). It does not need to be imported; it cannot be overridden or redefined. (Just like (->).)
<o:p></o:p></span></p>
<ul style="margin-top:0cm" type="disc">
<ol style="margin-top:0cm" start="4" type="1">
<ul style="margin-top:0cm" type="square">
<li class="MsoListParagraph" style="margin-top:6.0pt;margin-bottom:6.0pt;margin-left:0cm;mso-list:l1 level3 lfo2">
<span style="mso-fareast-language:EN-US">A variant of this (which I quite like) is to use the existing keyword
<b>type</b> (lowercase).<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-top:6.0pt;margin-bottom:6.0pt;margin-left:0cm;mso-list:l1 level3 lfo2">
<span style="mso-fareast-language:EN-US">Advantage: simple clear story<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-top:6.0pt;margin-bottom:6.0pt;margin-left:0cm;mso-list:l1 level3 lfo2">
<span style="mso-fareast-language:EN-US">Note: won’t break existing code; only code that says TypeInType<o:p></o:p></span></li></ul>
</ol>
</ul>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="mso-fareast-language:EN-US">Is that a fair summary of the design space?<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></a></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<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"> Iavor Diatchki [mailto:iavor.diatchki@gmail.com]
<br>
<b>Sent:</b> 09 February 2018 17:47<br>
<b>To:</b> Simon Peyton Jones <simonpj@microsoft.com><br>
<b>Cc:</b> Richard Eisenberg <rae@cs.brynmawr.edu>; ghc-steering-committee@haskell.org; Joachim Breitner <mail@joachim-breitner.de><br>
<b>Subject:</b> Re: [ghc-steering-committee] Proposal: Embrace Type in Type<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">
The issue I see is that it is quite common to get a kind error without doing any fancy type level programming---in particular without writing kind signatures or anything like that. So you'd have no reason to import `Data.Kind(Type)`. The result would be
that GHC would give quite a verbose error message, using the fully qualified name of `Type`. Unless we did something special.<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>
<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">
On Fri, Feb 9, 2018 at 2:41 AM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:12.0pt">I’m not sure I see the problem here. If ‘Int’ is not in scope then</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-indent:5.25pt">
<span style="font-size:12.0pt">f :: Int -> Int</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:12.0pt">won’t work. What’s different about ‘Type’</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:12.0pt">Simon</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:12.0pt"> </span><o:p></o:p></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" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-steering-committee [mailto:<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>]
<b>On Behalf Of </b>Richard Eisenberg<br>
<b>Sent:</b> 09 February 2018 04:26<br>
<b>To:</b> Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>><br>
<b>Cc:</b> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>; Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>><br>
<b>Subject:</b> Re: [ghc-steering-committee] Proposal: Embrace Type in Type</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks, Iavor, for bringing this up.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">To clarify the proposal: -XStarIsType is orthogonal to deprecation. The extension is necessary in order to continue to parse existing programs, but if we choose to deprecate *,
then we would deprecate even with -XStarIsType is enabled (precisely to avoid the half-deprecation scenario Iavor is worried about).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I envisioned always printing Type unqualified in error messages, even if it's not imported. If a user writes Type and it's out of scope, we could always have a special-case check
suggesting they import Data.Kind. I won't argue this is a principled design, though, and is likely a poor choice if some other Type is in scope.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The truth is that I don't have a great way forward here (and haven't for years) and am very hopeful someone on this list can come up with one! :) The proposal has my best idea,
but I'm still not thrilled with it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Richard<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Feb 8, 2018, at 1:46 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hello,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I didn't see any discussion about the third part of this proposal, namely the addition of a new extension called `StarIsKind`. The idea is that when this is on, `*` will still
be treated as a special alpha-numeric name, and it will *always* refer to the kind of inhabited types (i.e., same as know). The difference is that it cannot be used as another type-level operator (e.g., for multiplication).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Presumably, when this extension is on, there would be no deprecation warning emitted for `*`? We should clarify this in the proposal.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I am not certain if this is a good idea. It makes the use of `*` sort of "half" deprecated, and leaves us with multiple "standard" ways to refer to the same thing (e.g., in type
errors). Also, if we want people to update their code to use `Type` instead of `*`, then we are just delaying the pain point to whenever `StarIsKind` ends up being not on by default.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">OTOH, if we don't have a standard short-hand way to refer to the kind of inhabited types, I imagine GHC will report some very ugly errors. For example:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> • Expecting one more argument to ‘Maybe’<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> Expected a type, but ‘Maybe’ has kind ‘Data.Kind.Type -> Data.Kind.Type’<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">And this is for a fairly simple kind error, they get much longer if, say, monad transformers are involved.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">What do others think?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-Iavor<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Sat, Feb 3, 2018 at 8:24 PM Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
> On Feb 1, 2018, at 8:58 PM, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br>
><br>
> In particular in light of our use of “type” as a explicit namespace<br>
> token – so far in export and import lists and fixity declarations – I<br>
> worry that we will prevent ourselves from using more such explicit<br>
> namespace things in the future.<br>
<br>
This is a really good point. In private musings, I've often wondered about using the keyword `type` in expressions to denote a namespace change. More concretely, I'm worried about the Dreaded Namespace Problem (DNP): that is, a dependently typed language does
not want to have separate type-level and term-level namespaces. Of course, Haskell has this.<br>
<br>
The best solution I have so far to the DNP is to introduce a *new* namespace, distinct from the two namespaces we have so far. Let's call it the "default" namespace. When -XDependentTypes is on, the default namespace is in effect. Name lookup looks first in
the default namespace. If that fails the namespace consulted next depends on context: the "data" namespace in terms and the "type" namespace in type signatures. (This last bit needs to be specified more concretely, but you get the idea.) Or, perhaps, a failed
lookup in the default namespace will look up in both the type and data namespaces, erroring if a name appears in both.<br>
<br>
If a user wants to specify a namespace directly, they have a very easy way to do so: `type Foo` will look in the type namespace, `data Foo` will look in the data namespace, and `default Foo` will look in the default namespace. :) Because these keywords make
sense currently only at the beginning of a line, this Just Works. I also imagined these constructs could scope over a subexpression: `type (T S)`.<br>
<br>
All of this deserves a proper proposal and it's too early for that proposal. Nevertheless, I'm grateful that Joachim said something here, given that adding `type` as a spelling of `Type` would invalidate this approach. I also am swayed by the fact that `Type`
isn't fully primitive, and making a keyword mean something that's not primitive is a bit awkward. I thus retract this proposed alternative and will update the proposal accordingly.<br>
<br>
Richard<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>