Simon M says:
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.
Indeed, I'd be perfectly happy to have both variants. (And we could extend this to existing deprecations/warnings, e.g. there's no good reason to force module deprecations to be positional.) Richard says:
- 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.
I don't have a problem with `data`. I think the potential confusion around `data Bool = True | False` won't faze experienced Haskellers (who are the target audience for these pragmas). And the fact that `data` is already a reserved keyword is quite nice. 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.