<div dir="ltr">Thank you for this summary, Simon. I didn't realize that the earlier proposal <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst" target="_blank">Require namespacing fixity declarations for type names and WARNING/DEPRECATED pragmas</a> affects DEPRECATED pragmas. They were mentioned in the title but they were not mentioned in the proposed changes. Now I see in the Motivation section that «<i>as well as DEPRECATED pragmas, which accomplish the same thing, so I'll refer to them henceforth as just WARNING pragmas</i>». <div><br></div><div>Joachim, I'm not sure how to proceed here. I don't think that this is the case for "Needs Revision". I could start another thread with the recommendation to reject this proposal with the reason that another (accepted) proposal subsumes this one but it doesn't make too much sense either.</div><div><br></div><div>Vitaly<br><br><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2019 at 4:35 PM Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, 11 Mar 2019 at 13:26, Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>> wrote:<br></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>"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".<div><br></div><div>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.</div></div></blockquote><div><br></div><div><br></div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>For those who (like me) might have been a bit confused about the current state of things:</div><div><ul><li>There are 5 places that we want namespace specifiers now (possibly more later): import, export, fixity, WARNING, DEPRECATED</li><li>GHC's existing <b>ExplicitNamespaces</b> option allows <b>type</b> and <b>pattern</b> keywords to be used in import, export </li><li>The earlier proposal <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst" target="_blank">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 <br></li><li>This proposal <a href="https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst" target="_blank">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)<br></li><li>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!)<br></li></ul></div></div><div class="gmail_quote">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>? <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><div><br></div><div>Cheers</div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>Simon</div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>Richard</div><div><div><br><blockquote type="cite"><div>On Mar 11, 2019, at 9:12 AM, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank">bravit111@gmail.com</a>> wrote:</div><br class="m_277420566494194173m_-808646954181277247gmail-m_7202207439007616299Apple-interchange-newline"><div><div dir="ltr"><div>Hi Richard, </div><div><br></div><div>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.</div><div><br></div><div>Regards, </div><div>Vitaly</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>My argument for `data` is as follows (quoted from earlier writing of mine):<div><br></div><div>---</div><div>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>data</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>type</code> and <code>data</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>data</code> applies only to the bits after the <code>=</code>). </div><div>---</div><div><br></div><div>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).</div><div><br></div><div></div></div><div><div>Richard</div></div><div><div><br><div><br><blockquote type="cite"><div>On Mar 8, 2019, at 1:12 PM, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank">bravit111@gmail.com</a>> wrote:</div><br class="m_277420566494194173m_-808646954181277247gmail-m_7202207439007616299m_-6921029120898598668Apple-interchange-newline"><div><div dir="ltr"><div>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.</div><div><br></div><div>Vitaly</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193" rel="noreferrer" 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://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst" rel="noreferrer" 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://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html" rel="noreferrer" 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://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst" rel="noreferrer" 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" 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="http://www.joachim-breitner.de/" rel="noreferrer" 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
_______________________________________________<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><br></div></blockquote></div><br></div></div></blockquote></div></div>
</div></blockquote></div><br></div></div>_______________________________________________<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" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div></div></div></blockquote></div></div></div></div>