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

Wed Mar 13 13:35:11 UTC 2019

On Mon, 11 Mar 2019 at 13:26, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:

> "value" would not work as the namespace indicator I envision for the
> future, as it's a commonly used variable name. (I would advocate against
> making it a keyword for this reason.) This knob is relatively easy to turn,
> though, so it's conceivable to use "value" today, and then if/when we start
> using "data" in the future, allow the use of "data" where we use "value",
> eventually deprecating and removing "value". It's a bit annoying to users
> to keep changing it, but only a bit. I've been in this game long enough to
> know that the future isn't quite predictable, and so I see the sense in
> choosing the best thing for us now, leaving the door open to fixing it
> later if necessary. I still advocate for "data", but I won't burst into
> tears if we choose "value".
>
> I could see waiting a day or two for further commentary and then putting
> it to a committee vote. In the end, I think this choice matters little.
>

For those who (like me) might have been a bit confused about the current
state of things:

   - There are 5 places that we want namespace specifiers now (possibly
   more later): import, export, fixity, WARNING, DEPRECATED
   - GHC's existing *ExplicitNamespaces* option allows *type* and *pattern*
   keywords to be used in import, export
   - The earlier proposal Require namespacing fixity declarations for type
   names and WARNING/DEPRECATED pragmas
   <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst>
   was accepted, and allows *type* and *value* keywords in fixity, WARNING,
   DEPRECATED
   - This proposal Deprecated Entities
   <https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000-deprecated-entities.rst>
   suggests adding *type* and *pattern* specifiers to DEPRECATED pragmas.
   (note that DEPRECATED pragmas were covered by the earlier proposal, so this
   conflicts)
   - Vitaly's suggested modification of this proposal is to  adopt *type*
   and *data* instead (for DEPRECATED pragmas), while Simon pointed out
   that we already accepted a proposal for this, using *type* and *value*,
   and that whatever we do we should do it consistently across import, export,
   fixity, WARNING, DEPRECATED (yes!)

I don't think it makes a lot of sense to accept this proposal, since it
conflicts with the earlier one. Should we instead work on a modification of
the earlier proposal to extend it to import/export lists, and also resolve
the debate about *data/pattern/value*?

Richard's concerns about future extensions to add namespacing in
expressions seem valid to me, it would be unfortunate to use *value* now if
that will cause problems later.

Cheers
Simon

> Richard
>
> On Mar 11, 2019, at 9:12 AM, Vitaly Bragilevsky <bravit111 at gmail.com>
> wrote:
>
> 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
>>
>>
>>
> _______________________________________________
> 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/20190313/baf7c6f5/attachment-0001.html>