#10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): On Phab:D2280, kosmikus said:
In principle: I think this is great and definitely needed so that we can more reliably use all the different deriving-mechanisms, so thanks a lot for trying to move this forward.
But: I think this should not be done via pragmas. (I know I've suggested using pragmas in the past myself, but I've changed my opinon.) I'm not sure whether there is a clear guideline for what should be a pragma and what not, but to me, I think stuff affecting optimizations or performance are perfectly fine, stuff that can make a difference between a program compiling at all or not (OVERLAPPING, OVERLAPPABLE) are critical, and stuff that changes the semantics/result of a program (this change) is too much. I'd much rather see this implemented via actual language syntax. It would also hopefully make it easier to extend it with more flexibility in subsequent versions.
(Copying here because this is a design issue, not an implementation one.) I agree fully with this, including the bit that I, too, have suggested pragmas but now change my stance. I think we should have a guiding principle about pragmas. I propose this: * A pragma should either: 1. Behave precisely like options that could be passed in at the command line, OR 2. Have no effect on the semantics (static or dynamic) of the program Ideally, actually, we'd just have (2), but `LANGUAGE` doesn't qualify for (2). To be clear, by "semantics (static or dynamic)", I mean typability and runtime behavior. Browsing through the current set of accepted pragmas ([https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts... in the manual], if that's complete) all pragmas meet this guideline except these: * The `OVERLAPPING`/`OVERLAPS`/`OVERLAPPABLE`/`INCOHERENT` pragmas, as these affect static semantics. * `RULES`, as these can affect dynamic semantics. Indeed, I'd be in favor of phasing out these pragmas in favor of other syntax. One could argue that `RULES` should be a pragma, because they shouldn't, if written correctly, affect runtime behavior. I would disagree with that argument, I think, but perhaps I'd be in the minority opinion. I know this is a larger discussion than on just this ticket, but I thought I'd mention this here to gauge response. If others like this idea at all, I'll post a fresh ticket. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10598#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler