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

[Simon Peyton Jones]

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<mailto: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<mailto: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<mailto:bravit111 at gmail.com>>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto: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<mailto: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<mailto: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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/87cd6550/attachment-0001.html>