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

Fri Mar 8 15:11:42 UTC 2019

Yes, the concern about being consistent across fixity, WARNING, import/export, etc. came up when we were discussing this proposal earlier[1], and I think we all agree that consistency is imperative.

[1]: https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000894.html

On Fri, Mar 8, 2019, at 09:46, Simon Peyton Jones via ghc-steering-committee wrote:
>  
> 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%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599100730&sdata=s8VbHAxHZb3vUqXKJXq%2FVMuIiPYwGzPWNJCyE6mWgTU%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%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599110725&sdata=7Ahx5YEJjUcvj7TAR7Y%2Bli5fFDp5O7uH1y5XPOR07Nc%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%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599110725&sdata=qtZe%2Bwn%2Fz770ILSA7Yx50OxzYyXTSr2wJjgDice2yFU%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%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599120719&sdata=ZQa8twzFBzNPyUte52GBna0Igb7qGnyqAZrhUps7emM%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%7C21374ae23fcf4793082708d6a3d48b1a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876530599120719&sdata=zPbrM1G9Y4w2tUcdANne5mRqGwMYZ2qkhevPzPrdxkE%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
>