<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">"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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Richard</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 11, 2019, at 9:12 AM, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" class="">bravit111@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi Richard, </div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Regards, </div><div class="">Vitaly</div><br class=""><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" class="">rae@cs.brynmawr.edu</a>> wrote:<br class=""></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" class="">My argument for `data` is as follows (quoted from earlier writing of mine):<div class=""><br class=""></div><div class="">---</div><div class="">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 class="">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 class="">type</code> and <code class="">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 class="">data</code> applies only to the bits after the <code class="">=</code>). </div><div class="">---</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""></div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">Richard</div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 8, 2019, at 1:12 PM, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank" class="">bravit111@gmail.com</a>> wrote:</div><br class="m_-6921029120898598668Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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 class=""><br class=""></div><div class="">Vitaly</div><div class=""><br class=""></div></div><br class=""><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" class="">mail@joachim-breitner.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">
<br class="">
I fully support this (I thought I brought it up before, but maybe not<br class="">
strongly enough).<br class="">
<br class="">
Should we just include this change in #167? (If politicians can add<br class="">
random riders to laws, so can we). Or does it need more thought?<br class="">
<br class="">
Cheers,<br class="">
Joachim<br class="">
<br class="">
<br class="">
Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via<br class="">
ghc-steering-committee:<br class="">
> I also argue that, to be consistent, whatever keyword we agree, we should use it<br class="">
> In the (accepted) infix/WARNING proposal<br class="">
> In import and export lists – presumably for now in addition to ‘pattern’, though we might end up deprecating the latter.<br class="">
> Simon<br class="">
> <br class="">
> From: Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank" class="">bravit111@gmail.com</a>> <br class="">
> Sent: 08 March 2019 14:44<br class="">
> To: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" class="">simonpj@microsoft.com</a>><br class="">
> Cc: Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank" class="">marlowsd@gmail.com</a>>; ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a>><br class="">
> Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept<br class="">
> <br class="">
> 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" class="">https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193</a><br class="">
> <br class="">
> 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 class="">
> <br class="">
> Vitaly<br class="">
> <br class="">
> On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" class="">simonpj@microsoft.com</a>> wrote:<br class="">
> > 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 class="">
> > <br class="">
> > Simon<br class="">
> > <br class="">
> > From: ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank" class="">ghc-steering-committee-bounces@haskell.org</a>> On Behalf Of Simon Marlow<br class="">
> > Sent: 08 March 2019 07:57<br class="">
> > To: Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank" class="">bravit111@gmail.com</a>><br class="">
> > Cc: ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a>><br class="">
> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec: accept<br class="">
> > <br class="">
> > Yes, I think this is the right way to go.<br class="">
> > <br class="">
> > Cheers<br class="">
> > Simon<br class="">
> > <br class="">
> > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank" class="">bravit111@gmail.com</a>> wrote:<br class="">
> > > Hi everyone, <br class="">
> > > <br class="">
> > > 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" class="">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 class="">
> > > <br class="">
> > > data Bar = Bar<br class="">
> > > {-# DEPRECATED type Bar "Don't use type Bar" #-} <br class="">
> > > data Baz = Baz<br class="">
> > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}<br class="">
> > > <br class="">
> > > Using this pragma without specifiers should mean deprecating both (as is works now).<br class="">
> > > <br class="">
> > > 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" class="">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 class="">
> > > <br class="">
> > > Reasons for choosing "data":<br class="">
> > > * it's a reserved keyword (as opposed to "value", which is another option)<br class="">
> > > * we are deprecating data constructors here<br class="">
> > > * it just feels right (sorry!)<br class="">
> > > <br class="">
> > > Reasons against "data":<br class="">
> > > * it can be confusing whether we mean data type or data constructor<br class="">
> > > * we use "value" and "pattern" in other places meaning basically the same thing<br class="">
> > > <br class="">
> > > If the committee decides to go this way, then the wider community may think about other proposals, such as<br class="">
> > > * adding positional DEPRECATED pragmas (including class instances deprecation)<br class="">
> > > * 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" class="">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst</a>) and updating ExplicitNamespaces in import/export lists<br class="">
> > > * deprecating usage of nonpositional DEPRECATED pragma without the specifiers<br class="">
> > > <br class="">
> > > Silence is understood as agreement. <br class="">
> > > <br class="">
> > > Regards, <br class="">
> > > Vitaly<br class="">
> > > <br class="">
> > > _______________________________________________<br class="">
> > > ghc-steering-committee mailing list<br class="">
> > > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
> > > <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
> <br class="">
> _______________________________________________<br class="">
> ghc-steering-committee mailing list<br class="">
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
-- <br class="">
Joachim Breitner<br class="">
<a href="mailto:mail@joachim-breitner.de" target="_blank" class="">mail@joachim-breitner.de</a><br class="">
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank" class="">http://www.joachim-breitner.de/</a><br class="">
<br class="">
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class=""><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div></div>
</div></blockquote></div><br class=""></div></body></html>