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

[Richard Eisenberg]

- 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 <mail at joachim-breitner.de> 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 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