Hi, I have a similar notions. Either would work, both have downsides. Re positionally, I notice that the way GHC expects them to be placed is pretty rigid, and may make the code less nice to read, with a possibly large pragma between the constructor and the arguments. I find this to not fit well with the rest of the language, where we can even move type signatures away from the code if that improves readability. But the ability to deprecate instances is a strong argument in favor of a positional variant. TBH, all these problems (how to nicely place annotations of sorts next to many kinds of declarations) had to be answered for haddock already, so piggy-backing on that might be the best coarse of action, e.g. something along the lines of where DEPRECATED is followed by either | or ^, with the same meaning as for haddocks. This easily extends to allowing either positional or named pragmas, and leave it up to the user what they prefer: {-# DEPRECATED pattern Baz "Baz is deprecated too" #-} This is maybe a somewhat elaborate for “just” the DEPRECATED pragma, but we are solving a problem here will come up with other existing or future pragmas as well, so a generic solution that we are happy with and that can be applied uniformly would be nice. With this in mind, maybe we should accept the proposal with the named variant for now, and make “refined positional pragmas” a separate proposal that deals with a positional way of writing of all annotation- like pragmas. It is a pitty that ANN and DEPRECATED, although very similar in their needs of addressing modules, terms and types, have already diverged in how they do it (ANN module vs. positional DEPRECATED; a type qualifier for ANN, but no qualifiers for DEPRECATED, and more than one qualifier after this proposal). Cheers, Joachim Am Freitag, den 01.02.2019, 10:04 -0800 schrieb Iavor Diatchki:

Hello,

this seems quite reasonable and I think we should accept it. I don't have a strong preference on if this is positional or not. If it is positional, it may be nice to associate it with a specific delcaration, so that you don't have to write the name twice. OTOH, I also see values in the ability to put all deprecation pragmas in one place, rather than sprinkling them throughout a declaration.

-Iavor

On Fri, Feb 1, 2019 at 6:58 AM Vitaly Bragilevsky wrote:

...

Dear Committee,

I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/0000...). It is proposed to extend DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. Simon suggested another alternative to make DEPRECATED pragmas positional (in consistency with the deprecating modules). I like the positional alternative more, as it enables more fine-grained control over deprecated entities and can be extended to deprecating unnamed entities (like type class instances). It seems the author is okay with rewriting the proposal, but the current proposal is already implemented. So, the question is: do we want it quick or good? I am not ready to answer this question and come up with the recommendation on the proposal yet.

Please, comment on the following issues: a) which form of the DEPRECATED pragma you prefer, b) do you see any potential drawbacks of the positional form, c) are there any caveats with deprecating instances. Your comments are very welcome either here or on GitHub (https://github.com/ghc-proposals/ghc-proposals/pull/167).

Thanks, Vitaly _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi, Am Sonntag, den 03.02.2019, 10:45 -0500 schrieb Eric Seidel:

I'm more bothered by the fact that the data/constructor tag has now become 'pattern', which feels to me like it should only apply to pattern synonyms. But according to https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-4257364... it sounds like that ship may have sailed already if we want to be consistent (which we should!).

We can maybe fix it consistently, and phase out “pattern” (make it an alias for whatever we choose) … but do we have an obviously appropriate name? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

The point of "pattern" (I believe) is that we want it to be invisible to the importer whether a constructor name was declared as a pattern synonym or a real data constructor, to allow abstraction and smooth migration of APIs when the concrete representation of a datatype changes. However, it would also make sense to allow "data" instead of "pattern", with exactly the same meaning (import either a data constructor or a pattern synonym with the given name). I wonder why we didn't do that. On this proposal, I think the named, standalone variant is preferable to the positional variant if we choose only one, because it allows more flexibility. Although I could imagine both being useful. Cheers Simon On Mon, 4 Feb 2019 at 02:39, Eric Seidel wrote:

In https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-ty... we already have an approved alternative: "value".

On Sun, Feb 3, 2019, at 17:50, Joachim Breitner wrote:

...

Hi,

Am Sonntag, den 03.02.2019, 10:45 -0500 schrieb Eric Seidel:

...

I'm more bothered by the fact that the data/constructor tag has now become 'pattern', which feels to me like it should only apply to pattern synonyms. But according to

https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-4257364...

...

it sounds like that ship may have sailed already if we want to be consistent (which we should!).

We can maybe fix it consistently, and phase out “pattern” (make it an alias for whatever we choose) … but do we have an obviously appropriate name?

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee Email had 1 attachment: + signature.asc 1k (application/pgp-signature)

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

- In general, I favor the named variant, as it's easier (i.e. more flexible) to work with. Of course, we need to be positional to deprecate instances (though this is not in the proposal, so is the idea in scope here?). - 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 `=`). The problem with `value` is that we would have `{-# DEPRECATED value, foo #-}` mean something very different than `{-# DEPRECATED value foo #-}`. This isn't a deal-breaker (punctuation normally is important in programming), but it's unfortunate. - Extending the proposal slightly, I would love to see a warning if one deprecation (or fixity declaration, while we're at it) applies to both a term-level entity and a type-level one (without specifying both separately). In my opinion, the fact that we ever allowed that is embarrassing. :) In the future, we might even say that it's an error. Richard

On Feb 4, 2019, at 5:20 PM, Joachim Breitner wrote:

Hi,

Am Montag, den 04.02.2019, 08:44 +0000 schrieb Simon Marlow:

...

The point of "pattern" (I believe) is that we want it to be invisible to the importer whether a constructor name was declared as a pattern synonym or a real data constructor, to allow abstraction and smooth migration of APIs when the concrete representation of a datatype changes. However, it would also make sense to allow "data" instead of "pattern", with exactly the same meaning (import either a data constructor or a pattern synonym with the given name). I wonder why we didn't do that.

I agree that “the better name” should be a synonym for pattern (or the other way around).

But I don’t think it should be data, because we write

data Bool = True | False

and it would be odd if `data Bool` means something different here and in an import statement.

“value”, as Eric says, is better.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Feb 5, 2019, at 7:11 PM, Eric Seidel wrote:

My main concern is that I'd like us to be consistent in how we disambiguate namespaces. If we want to use `data`, we should use it everywhere (synonyms are fine by me as long as they are also consistent). This would means we'd need to revise the fixity proposal I linked to above.

Yes, I should have included this in my email. If we decide to go in this direction, I would want to be consistent. This would include updating the fixity proposal (which is, I believe, still unimplemented) and expanding -XExplicitNamespaces to include `data`. Eventually, we would deprecate the use of `pattern` in import/export lists and then remove that feature. I suppose all this would necessitate yet another proposal.... but I do think the wider community (not just this list) should weigh in. However, before doing so, I'd be curious for more feedback from this group as a test-bed. Richard