#15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: Old description:

I assumed we already had a ticket about this, but it appears we have not.

I'm not saying this is a necessarily a bug in the implementation; but we should make sure this is properly documented in the user's guide, and ideally justify why it's done this way rather than the alternatives:

As described in StrictPragma,

...

`Strict` implies `StrictData`

Currently however the inverse case does not hold, i.e. `NoStrict` does *not* imply `NoStrictData`

This has the surprising property (assuming these were left-most flags on the CLI) that

- `-XStrict -XNoStrict` == `-XStrictData`

- `-XStrictData -XNoStrict` == `-XStrictData`

However, if `-XNoStrict` was to naively imply `-XNoStrictData`, we'd have the properties

- `-XStrict -XNoStrict` == *id*

- `-XStrictData -XNoStrict` == *id*

This might be a bit less confusing; another variant would be

- `-XStrict -XNoStrict` == *id*

- `-XStrictData -XNoStrict` == `-XStrictData`

Btw, I'm not sure what the following means:

- `-XStrict -XNoStrictData` == ?

New description: I assumed we already had a ticket about this, but it appears we have not. I'm not saying this is a necessarily a bug in the implementation; but we should make sure this is properly documented in the user's guide, and ideally justify why it's done this way rather than the alternatives: As described in StrictPragma,

`Strict` implies `StrictData`

Currently however the inverse case does not hold, i.e. `NoStrict` does *not* imply `NoStrictData` This has the surprising property (assuming these were left-most flags on the CLI) that - `-XStrict -XNoStrict` == `-XStrictData` - `-XStrictData -XNoStrict` == `-XStrictData` However, if `-XNoStrict` was to naively imply `-XNoStrictData`, we'd have the properties - `-XStrict -XNoStrict` == ∅ - `-XStrictData -XNoStrict` == ∅ This might be a bit less confusing; another variant would be - `-XStrict -XNoStrict` == ∅ - `-XStrictData -XNoStrict` == `-XStrictData` (strictly speaking, it's not ∅ unless it's these are the left-most flags; also, any `-XNo` still has a cancellation effect on any flags occuring to the left on the CLI) Btw, I'm not sure what the following means: - `-XStrict -XNoStrictData` == ? -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15562#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Well, with the current semantics, automatically reordering your `LANGUAGE` pragmas can change the effective set of enabled extensions. So that's something IDEs and refactoring tools will hopefully be aware of. At least for now we have a simple heuristic such tooling can use to avoid changing the meaning of pragmas: groups of negative and positive pragmas do not commute. I.e. you are only allowed to reorder pragmas within a sequence of either positive or negative pragmas. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15562#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:4 goldfire]:

My vote would be simply not to make any guarantees of this sort. It's not hard for a tool to consult `DynFlags.impliedXFlags` and figure out what reorderings are OK.

While I agree now with that it's hopeless to give any guarantees; I disagree that consulting `DynFlags.impliedXFlags` is "not hard" for tools -- tools most often avoid to link against `lib:ghc` so they wouldn't have access to it; instead they tend to query e.g. `ghc --supported-languages` which unfortunately does not expose the relationships between those flags. It would be very useful for tooling if `ghc`'s CLI had some flag to dump an extended version of `--supported-languages` that's easy to parse -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15562#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler