[ghc-steering-committee] #167: Deprecated Entities, rec: accept

Wed Mar 20 08:02:00 UTC 2019

Joachim, I think we should declare this proposal rejected. We have enough
voices for this decision it seems.

Vitaly

вт, 19 мар. 2019 г. в 21:49, Simon Peyton Jones via ghc-steering-committee <
ghc-steering-committee at haskell.org>:

> 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 *data/pattern/value*?
>
>
>
> 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.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Marlow
> *Sent:* 13 March 2019 13:35
> *To:* Richard Eisenberg <rae at cs.brynmawr.edu>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>;
> Joachim Breitner <mail at joachim-breitner.de>
> *Subject:* Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
> accept
>
>
>
> On Mon, 11 Mar 2019 at 13:26, Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
> "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".
>
>
>
> 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.
>
>
>
>
>
> For those who (like me) might have been a bit confused about the current
> state of things:
>
>    - There are 5 places that we want namespace specifiers now (possibly
>    more later): import, export, fixity, WARNING, DEPRECATED
>    - GHC's existing *ExplicitNamespaces* option allows *type* and
>    *pattern* keywords to be used in import, export
>    - The earlier proposal Require namespacing fixity declarations for
>    type names and WARNING/DEPRECATED pragmas
>    <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>
>    was accepted, and allows *type* and *value* keywords in fixity,
>    WARNING, DEPRECATED
>    - This proposal Deprecated Entities
>    <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>
>    suggests adding *type* and *pattern* specifiers to DEPRECATED pragmas.
>    (note that DEPRECATED pragmas were covered by the earlier proposal, so this
>    conflicts)
>    - Vitaly's suggested modification of this proposal is to  adopt *type*
>    and * data* instead (for DEPRECATED pragmas), while Simon pointed out
>    that we already accepted a proposal for this, using *type* and *value*,
>    and that whatever we do we should do it consistently across import, export,
>    fixity, WARNING, DEPRECATED (yes!)
>
> 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 *data/pattern/value*?
>
>
>
> Richard's concerns about future extensions to add namespacing in
> expressions seem valid to me, it would be unfortunate to use *value* now
> if that will cause problems later.
>
>
>
> Cheers
>
> Simon
>
>
>
>
>
>
>
> Richard
>
>
>
> On Mar 11, 2019, at 9:12 AM, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
>
>
>
> Hi Richard,
>
>
>
> 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.
>
>
>
> Regards,
>
> Vitaly
>
>
>
> On Sun, Mar 10, 2019 at 12:10 AM Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
> My argument for `data` is as follows (quoted from earlier writing of mine):
>
>
>
> ---
>
> 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
> data 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 type and data 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 data applies only to the bits after the =).
>
> ---
>
>
>
> 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).
>
>
>
> Richard
>
>
>
>
>
> On Mar 8, 2019, at 1:12 PM, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
>
>
>
> 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.
>
>
>
> Vitaly
>
>
>
>
>
> On Fri, Mar 8, 2019 at 8:45 PM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi,
>
> I fully support this (I thought I brought it up before, but maybe not
> strongly enough).
>
> Should we just include this change in #167? (If politicians can add
> random riders to laws, so can we). Or does it need more thought?
>
> Cheers,
> Joachim
>
>
> Am Freitag, den 08.03.2019, 14:46 +0000 schrieb Simon Peyton Jones via
> ghc-steering-committee:
> > I also argue that, to be consistent, whatever keyword we agree, we
> should use it
> > In the (accepted) infix/WARNING proposal
> > In import and export lists – presumably for now in addition to
> ‘pattern’, though we might end up deprecating the latter.
> > Simon
> >
> > From: Vitaly Bragilevsky <bravit111 at gmail.com>
> > Sent: 08 March 2019 14:44
> > To: Simon Peyton Jones <simonpj at microsoft.com>
> > Cc: Simon Marlow <marlowsd at gmail.com>; ghc-steering-committee <
> ghc-steering-committee at haskell.org>
> > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
> accept
> >
> > Simon PJ argues for "value" over "data" as a specifier:
> https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193
> <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>
> >
> > 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.
> >
> > Vitaly
> >
> > On Fri, Mar 8, 2019 at 11:42 AM Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
> > > 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.
> > >
> > > Simon
> > >
> > > From: ghc-steering-committee <
> ghc-steering-committee-bounces at haskell.org> On Behalf Of Simon Marlow
> > > Sent: 08 March 2019 07:57
> > > To: Vitaly Bragilevsky <bravit111 at gmail.com>
> > > Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
> > > Subject: Re: [ghc-steering-committee] #167: Deprecated Entities, rec:
> accept
> > >
> > > Yes, I think this is the right way to go.
> > >
> > > Cheers
> > > Simon
> > >
> > > On Fri, 8 Mar 2019 at 05:25, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
> > > > Hi everyone,
> > > >
> > > > I was asked to shepherd the proposal #167 (Deprecated Entities,
> https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst
> <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>).
> 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:
> > > >
> > > > data Bar = Bar
> > > > {-# DEPRECATED type Bar "Don't use type Bar" #-}
> > > > data Baz = Baz
> > > > {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-}
> > > >
> > > > Using this pragma without specifiers should mean deprecating both
> (as is works now).
> > > >
> > > > After discussing this proposal within the committee (see
> https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html
> <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>),
> I recommend acceptance with one change, namely using "data" instead of
> "pattern" for deprecating value-level things.
> > > >
> > > > Reasons for choosing "data":
> > > > * it's a reserved keyword (as opposed to "value", which is another
> option)
> > > > * we are deprecating data constructors here
> > > > * it just feels right (sorry!)
> > > >
> > > > Reasons against "data":
> > > > * it can be confusing whether we mean data type or data constructor
> > > > * we use "value" and "pattern" in other places meaning basically the
> same thing
> > > >
> > > > If the committee decides to go this way, then the wider community
> may think about other proposals, such as
> > > > * adding positional DEPRECATED pragmas (including class instances
> deprecation)
> > > > * fixing inconsistencies with the fixity declarations (
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst
> <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>)
> and updating ExplicitNamespaces in import/export lists
> > > > * deprecating usage of nonpositional DEPRECATED pragma without the
> specifiers
> > > >
> > > > Silence is understood as agreement.
> > > >
> > > > Regards,
> > > > Vitaly
> > > >
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <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>
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <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>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <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>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <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>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <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>
>
>
>
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <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>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190320/08f4d150/attachment-0001.html>