Re: [ghc-steering-committee] Proposal #167 (Deprecated Entities): Request for comments

- 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