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

Mon Mar 11 13:12:00 UTC 2019

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
>> >
>> > 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
>>
> _______________________________________________
> 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/20190311/1a7bb222/attachment.html>