<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;}
@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;}
code
{mso-style-priority:99;
font-family:"Courier New";}
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.EmailStyle23
{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;}
@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:1197154855;
mso-list-template-ids:-129304986;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.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 don't think it makes a lot of sense to accept this proposal, since it conflicts with the earlier one. Should we instead work on a modification of the earlier proposal to extend it to import/export lists, and
also resolve the debate about <b>data/pattern/value</b>? <o:p></o:p></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">Good summary. We clearly need something that behaves uniformly in the five situations Simon describes. Whether we think of it as “a modification of an earlier proposal” or “a new proposal” doesn’t
really matter.<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>Simon Marlow<br>
<b>Sent:</b> 13 March 2019 13:35<br>
<b>To:</b> Richard Eisenberg <rae@cs.brynmawr.edu><br>
<b>Cc:</b> ghc-steering-committee <ghc-steering-committee@haskell.org>; Joachim Breitner <mail@joachim-breitner.de><br>
<b>Subject:</b> Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">On Mon, 11 Mar 2019 at 13:26, Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu">rae@cs.brynmawr.edu</a>> wrote:<o:p></o:p></p>
</div>
<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>
<p class="MsoNormal">"value" would not work as the namespace indicator I envision for the future, as it's a commonly used variable name. (I would advocate against making it a keyword for this reason.) This knob is relatively easy to turn, though, so it's conceivable
to use "value" today, and then if/when we start using "data" in the future, allow the use of "data" where we use "value", eventually deprecating and removing "value". It's a bit annoying to users to keep changing it, but only a bit. I've been in this game
long enough to know that the future isn't quite predictable, and so I see the sense in choosing the best thing for us now, leaving the door open to fixing it later if necessary. I still advocate for "data", but I won't burst into tears if we choose "value".<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I could see waiting a day or two for further commentary and then putting it to a committee vote. In the end, I think this choice matters little.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For those who (like me) might have been a bit confused about the current state of things:<o:p></o:p></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
There are 5 places that we want namespace specifiers now (possibly more later): import, export, fixity, WARNING, DEPRECATED<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
GHC's existing <b>ExplicitNamespaces</b> option allows <b>type</b> and <b>pattern</b> keywords to be used in import, export
<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
The earlier proposal <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0008-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398072333&sdata=ZDHMErg3a2TOIPwJoDlnFtkzspZDakmTuDrArpqtJEA%3D&reserved=0">
Require namespacing fixity declarations for type names and WARNING/DEPRECATED pragmas</a> was accepted, and allows
<b>type</b> and <b>value</b> keywords in fixity, WARNING, DEPRECATED <o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
This proposal <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnineonine%2Fghc-proposals%2Fblob%2Fdepr-entities%2Fproposals%2F0000-deprecated-entities.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398072333&sdata=o2ljHn9Yjn3Ezf%2FPTIIGT48aRSvg6hm22kwIfilr6%2FY%3D&reserved=0">
Deprecated Entities</a> suggests adding <b>type</b> and <b>pattern</b> specifiers to DEPRECATED pragmas. (note that DEPRECATED pragmas were covered by the earlier proposal, so this conflicts)<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
Vitaly's suggested modification of this proposal is to adopt <b>type</b> and <b>
data</b> instead (for DEPRECATED pragmas), while Simon pointed out that we already accepted a proposal for this, using
<b>type</b> and <b>value</b>, and that whatever we do we should do it consistently across import, export, fixity, WARNING, DEPRECATED (yes!)<o:p></o:p></li></ul>
</div>
</div>
<div>
<p class="MsoNormal">I don't think it makes a lot of sense to accept this proposal, since it conflicts with the earlier one. Should we instead work on a modification of the earlier proposal to extend it to import/export lists, and also resolve the debate about
<b>data/pattern/value</b>? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Richard's concerns about future extensions to add namespacing in expressions seem valid to me, it would be unfortunate to use
<b>value</b> now if that will cause problems later.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Simon<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><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"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Richard<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Mar 11, 2019, at 9:12 AM, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank">bravit111@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">Hi Richard, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Do you think that using "value" now is a real stopper for the future you are talking about? Maybe we should start thinking about making "value" a reserved keyword because it suits our purposes best as a namespace specifier. It looks like
this data/value debate is the only issue before reaching the consensus on this proposal. So we have to do something about it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Regards, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Vitaly<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sun, Mar 10, 2019 at 12:10 AM 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-right:0cm">
<div>
<p class="MsoNormal">My argument for `data` is as follows (quoted from earlier writing of mine):<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">---<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Though I understand the reasons against it, I'm an unabashed supporter of using the word "data" to supplant "pattern". My principal argument is that
<code><span style="font-size:10.0pt">data</span></code> can be used freely in the syntax, given that it's a keyword that has current meaning only as the first lexeme in a top-level declaration. (Specifically, I pine for a future where types and terms mix. We
can then use <code><span style="font-size:10.0pt">type</span></code> and <code><span style="font-size:10.0pt">data</span></code> in the middle of expressions/types to denote namespaces.) It also works nicely to mean "data constructor". I agree that it doesn't
work as well with functions or the potential confusion around "data Bool = True | False" (though, in that last example, we can pretend hard that the
<code><span style="font-size:10.0pt">data</span></code> applies only to the bits after the
<code><span style="font-size:10.0pt">=</span></code>). <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">---<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In other words, I think `data` is more future-compatible than any of the alternatives, even though I agree that `value` flows more smoothly. We can think of `data` as meaning "data-level", not "data constructor" (though that admittedly
takes a bit of mental gymnastics).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Richard<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Mar 8, 2019, at 1:12 PM, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank">bravit111@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">I think we don't have a consensus on the particular word yet: is it data or value. I'd like to listen to Richard who was strongly in favor of data. We are in agreement about consistency though.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Vitaly<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Mar 8, 2019 at 8:45 PM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</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">
<p class="MsoNormal">Hi,<br>
<br>
I fully support this (I thought I brought it up before, but maybe not<br>
strongly enough).<br>
<br>
Should we just include this change in #167? (If politicians can add<br>
random riders to laws, so can we). Or does it need more thought?<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via<br>
ghc-steering-committee:<br>
> I also argue that, to be consistent, whatever keyword we agree, we should use it<br>
> In the (accepted) infix/WARNING proposal<br>
> In import and export lists – presumably for now in addition to ‘pattern’, though we might end up deprecating the latter.<br>
> Simon<br>
> <br>
> From: Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank">bravit111@gmail.com</a>>
<br>
> Sent: 08 March 2019 14:44<br>
> To: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
> Cc: Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>>; ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
> Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept<br>
> <br>
> Simon PJ argues for "value" over "data" as a specifier: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F167%23issuecomment-470947193&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398082326&sdata=bap1ILHXYU%2Bxblq5N3DapBvpr5Se3TdNiwLi8kHT3I0%3D&reserved=0" target="_blank">
https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193</a><br>
> <br>
> I'm fine with this choice either (and I'm satisfied with the argument that deprecating or setting fixity for value "value" is a rare case to be considered seriously). If you have another opinion, please, speak up.<br>
> <br>
> Vitaly<br>
> <br>
> On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br>
> > I’ve made a post on the proposal thread asking why we don’t just follow the already-adopted proposal for WARNING and infix pragmas.<br>
> > <br>
> > Simon<br>
> > <br>
> > From: ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>> On Behalf Of Simon Marlow<br>
> > Sent: 08 March 2019 07:57<br>
> > To: Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank">bravit111@gmail.com</a>><br>
> > Cc: ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept<br>
> > <br>
> > Yes, I think this is the right way to go.<br>
> > <br>
> > Cheers<br>
> > Simon<br>
> > <br>
> > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank">bravit111@gmail.com</a>> wrote:<br>
> > > Hi everyone, <br>
> > > <br>
> > > I was asked to shepherd the proposal #167 (Deprecated Entities, <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnineonine%2Fghc-proposals%2Fblob%2Fdepr-entities%2Fproposals%2F0000-deprecated-entities.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398082326&sdata=V%2Bgqa%2FslqR01WIiGKDyuXFSYqp4RkFdbHcB6G1l2l1w%3D&reserved=0" target="_blank">
https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst</a>). It is proposed to extend (nonpositional) DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things.
In its current formulation, the proposal suggests to use the specifiers "type" for type-level things and "pattern" for value-level things as follows:<br>
> > > <br>
> > > data Bar = Bar<br>
> > > {-# DEPRECATED type Bar "Don't use type Bar" #-} <br>
> > > data Baz = Baz<br>
> > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}<br>
> > > <br>
> > > Using this pragma without specifiers should mean deprecating both (as is works now).<br>
> > > <br>
> > > After discussing this proposal within the committee (see <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fpipermail%2Fghc-steering-committee%2F2019-February%2F000894.html&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398092323&sdata=YTuIVN7wsC%2FmzJ51PH2RGCPLiecKhvkEFO0Ug3Aq7fg%3D&reserved=0" target="_blank">
https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html</a>), I recommend acceptance with one change, namely using "data" instead of "pattern" for deprecating value-level things.
<br>
> > > <br>
> > > Reasons for choosing "data":<br>
> > > * it's a reserved keyword (as opposed to "value", which is another option)<br>
> > > * we are deprecating data constructors here<br>
> > > * it just feels right (sorry!)<br>
> > > <br>
> > > Reasons against "data":<br>
> > > * it can be confusing whether we mean data type or data constructor<br>
> > > * we use "value" and "pattern" in other places meaning basically the same thing<br>
> > > <br>
> > > If the committee decides to go this way, then the wider community may think about other proposals, such as<br>
> > > * adding positional DEPRECATED pragmas (including class instances deprecation)<br>
> > > * fixing inconsistencies with the fixity declarations (<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0008-type-infix.rst&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398092323&sdata=ktRl25ulQKFOI7cxTFabP0wTcg7C9g77LzxPO1riyVs%3D&reserved=0" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst</a>)
and updating ExplicitNamespaces in import/export lists<br>
> > > * deprecating usage of nonpositional DEPRECATED pragma without the specifiers<br>
> > > <br>
> > > Silence is understood as agreement. <br>
> > > <br>
> > > Regards, <br>
> > > Vitaly<br>
> > > <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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398102314&sdata=VC3xfGC13FRwTHAklISNNhA1rcoql3OZVTPDkUddWGY%3D&reserved=0" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> <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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398102314&sdata=VC3xfGC13FRwTHAklISNNhA1rcoql3OZVTPDkUddWGY%3D&reserved=0" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398112311&sdata=uuKaUz37cFsSoxYHkKX%2Ba2DoSTUtw50aMrga5FCW8LE%3D&reserved=0" target="_blank">
http://www.joachim-breitner.de/</a><br>
<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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398112311&sdata=ngNXSvxU3dcuQq0SOQZf8DNtP5Sz4sGbg9Y2eSu%2BeIo%3D&reserved=0" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal">_______________________________________________<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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398122306&sdata=Oyy8xoNizqkTE4RovIMahuiWA6hvoVtib0S%2FgLStY0c%3D&reserved=0" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C11f6477c61a248e5504b08d6a7b8c74d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636880809398122306&sdata=Oyy8xoNizqkTE4RovIMahuiWA6hvoVtib0S%2FgLStY0c%3D&reserved=0" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>