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

Vitaly Bragilevsky bravit111 at gmail.com
Fri Mar 8 14:44:05 UTC 2019


Simon PJ argues for "value" over "data" as a specifier:
https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-470947193

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%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630814000&sdata=sJ3QiAx6Z55hJvsYajJEKfx6M8IVZ2DEY4LRRiaBTI8%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%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630824013&sdata=DEu9cf6sX2xf%2BxegCrh1TikJT%2B3yWB3BgA1k9CmCLs4%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%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630834021&sdata=IrpWyWLVksadQK5bo%2B7d%2B10LWuztYUcFwkAUsZxA5cg%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%7C29c80f1b5e6e43273aaa08d6a39bbdbb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636876286630834021&sdata=BfV5VDwcmFI210G0Aq5uZFmsC8Pc5fQdkB%2F8Hi5mtmI%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190308/8531e671/attachment-0001.html>


More information about the ghc-steering-committee mailing list