<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">rae@cs.brynmawr.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">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 style="word-wrap:break-word;line-break:after-white-space"><div>Richard</div></div><div style="word-wrap:break-word;line-break:after-white-space"><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_-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: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>
_______________________________________________<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>