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

Vitaly Bragilevsky bravit111 at gmail.com
Fri Mar 8 18:12:59 UTC 2019


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
> >
> > 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).
> 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),
> 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)
> 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
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20190308/3d3bd41e/attachment-0001.html>


More information about the ghc-steering-committee mailing list