<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">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>