Attached file `Bug.tar.gz`

(download).

two small Cabal files for revealing this bug

Attached file `grapefruit-records-dev20071215.tar.gz`

(download).

No problems with GHC 8.2.2, by the way.

When trying to build `order-maintenance-0.2.1.0`

, GHC 8.4.2-rc1 panics. Its output is as follows:

```
[ 1 of 21] Compiling Data.Order.Algorithm.Raw ( src/library/Data/Order/Algorithm/Raw.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw.o )
[ 2 of 21] Compiling Data.Order.Algorithm.Raw.DietzSleatorAmortizedLog ( src/library/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1.20180329 for x86_64-unknown-linux):
StgCmmEnv: variable not found
x_a46z
local binds for:
$tc'Label
$tcLabel
$tc'Cell
$tcCell
$trModule
$tc'Cell1
$tc'Cell2
$tc'Cell3
$trModule1
$trModule2
$trModule3
$trModule4
$tc'Label1
$tc'Label2
$tc'Label3
$tcCell1
$tcCell2
$tcLabel1
$tcLabel2
lvl_r4UD
lvl1_r4UE
lvl2_r4UF
lvl3_r4UG
lvl4_r4UH
lvl5_r4UI
lvl6_r4UJ
lvl7_r4UK
lvl8_r4UL
lvl9_r4UM
lvl10_r4UN
lvl11_r4UO
lvl12_r4UP
lvl13_r4UQ
lvl14_r4UR
lvl15_r4US
lvl16_r4UT
lvl17_r4UU
$krep_r4UV
$krep1_r4UW
$krep2_r4UX
lvl18_r4UY
$krep3_r4UZ
$krep4_r4V0
$krep5_r4V1
$krep6_r4V2
$krep7_r4V3
$krep8_r4V4
$krep9_r4V5
lvl19_r4V6
lvl20_r4V7
lvl21_r4V8
lvl22_r4V9
lvl23_r4Va
lvl24_r4Vb
lvl25_r4Vc
ww_s4W2
lwild_s4W3
lwild1_s4W4
noOfLabels_s4W5
noOfLabels1_s4W6
labelMask_s4W7
$wnewAfterCell_s4Wa
ww1_s4Wb
ipv1_s4Wf
wild_s4Wg
ds_s4Wh
ds2_s4Wi
ww2_s4Wk
ww3_s4Wl
ww4_s4Wn
ww5_s4Wo
wild1_s4Wq
smallGap_s4Wr
wild2_s4Ws
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```

The same problem exists with GHC 8.4.1.

Trac field | Value |
---|---|

Version | 8.4.2-rc1 |

Type | Bug |

TypeOfFailure | OtherFailure |

Priority | normal |

Resolution | Unresolved |

Component | Compiler |

Test case | |

Differential revisions | |

BlockedBy | |

Related | |

Blocking | |

CC | |

Operating system | |

Architecture |

Note that the way `ScopedTypeVariables`

works for instance declarations nowadays already breaks Haskell 98/2010 code.

At the moment, `ScopedTypeVariables`

does not have an effect for type signatures without an explicit `forall`

. Therefore, you are forced to explicitly quantify type variables if you want the type variables of your type signature to be visible outside the type signature.

When defining global variables, this means that you have to change part of the interface (the type signature) because of a change in the implementation. Of course, the change is only syntactical, but there is still a change. This is particularly problematic, because Haddock will follow the source code when deciding whether to include a top-level `forall`

in the generated documentation or not. Your Haddock-generated documentation will include spurious `forall`

s just because of the way your implementation works.

You could say that this is just a Haddock issue. However, problems do not stop here. There is also an inconsistency between scoped type variables in variable definitions and scoped type variables in instance declarations. In instance declarations, you do not have to use an explicit `forall`

. Type variables in the instance declaration head are visible in the body as soon as `ScopedTypeVariables`

is enabled.

I propose to change the semantics of `ScopedTypeVariables`

such that as soon as it is enabled, the feature is in effect for all rank-1 type variables in any type signature.

Trac field | Value |
---|---|

Version | 8.2.1 |

Type | FeatureRequest |

TypeOfFailure | OtherFailure |

Priority | normal |

Resolution | Unresolved |

Component | Compiler (Type checker) |

Test case | |

Differential revisions | |

BlockedBy | |

Related | |

Blocking | |

CC | jeltsch |

Operating system | |

Architecture |

Visible type application in patterns would be *extremely* useful for implementing core transformations in the new version of the `incremental-computing`

package.

The following code cannot be compiled:

```
{-# LANGUAGE ConstraintKinds, Rank2Types, TypeFamilies #-}
import GHC.Exts (Constraint)
type family F a b :: Constraint
data T b c = T
f :: (forall b . F a b => T b c) -> a
f _ = undefined
```

GHC outputs the following error message:

```
Untouchable.hs:9:6: error:
• Couldn't match type ‘c0’ with ‘c’
‘c0’ is untouchable
inside the constraints: F a b
bound by the type signature for:
f :: F a b => T b c0
at Untouchable.hs:9:6-37
‘c’ is a rigid type variable bound by
the type signature for:
f :: forall a c. (forall b. F a b => T b c) -> a
at Untouchable.hs:9:6
Expected type: T b c0
Actual type: T b c
• In the ambiguity check for ‘f’
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the type signature:
f :: (forall b. F a b => T b c) -> a
```

Trac field | Value |
---|---|

Version | 8.2.1-rc2 |

Type | Bug |

TypeOfFailure | OtherFailure |

Priority | normal |

Resolution | Unresolved |

Component | Compiler (Type checker) |

Test case | |

Differential revisions | |

BlockedBy | |

Related | |

Blocking | |

CC | |

Operating system | |

Architecture |

Thank you very much, Simon. I think I will test this new solution with `incremental-computing`

soon.

Is there any chance that this patch or the previous one will make it into GHC 7.10.2?

Trac field | Value |
---|---|

CC | adamgundry, goldfire, kosmikus → adamgundry, goldfire, jeltsch, kosmikus |

I have an issue with GHC 7.10.1, which is probably rooted in the same bug. The following code is accepted by GHC 7.8.3, but not 7.10.1:

```
{-# LANGUAGE TypeFamilies #-}
type family F a :: *
type family G b :: *
x :: G (F a) ~ a => F a
x = undefined
```

GHC 7.10.1 gives the following error message:

```
Could not deduce (F a0 ~ F a)
from the context (G (F a) ~ a)
bound by the type signature for x :: (G (F a) ~ a) => F a
at Test.hs:7:6-23
NB: ‘F’ is a type function, and may not be injective
The type variable ‘a0’ is ambiguous
In the ambiguity check for the type signature for ‘x’:
x :: forall a. (G (F a) ~ a) => F a
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the type signature for ‘x’: x :: G (F a) ~ a => F a
```

Is this code accepted by GHC HEAD?

I came across this problem when trying to recompile the `incremental-computing`

package with GHC 7.10.1. Since this issue breaks `incremental-computing`

in a nontrivial way, I would be *extremely* happy if the fix of this bug would make it into GHC 7.10.2.

Replying to [ticket:7071#comment:65576]:

All the work was done by Dan Winograd-Cort.

Thanks a lot, Dan.

Does the fix of this bug also resolve feature request #7081 or parts of it, that is, does desugaring for “lambda case” and “multi-way if” now work generically for expressions and arrows?

There is now a new feature request #7081 for arrow analogs of lambda case and multi-way if. This also covers an arrow command analog of lambda case in addition to the `proc`

expression analog.

Replying to simonpj:

#4359 (closed) proposal for

`proc case`

and multi-branch if

There is now a separate feature request #7081 for arrow analogs of lambda case and multi-way if, since ticket #4359 (closed) (which actually was about the non-arrow variants) has been closed.

GHC has now support for lambda case and multi-way if (see ticket #4359). It would be good if arrow variants of these features would be implemented. There are three things that should be considered:

Lambda case expressions should have analog `proc`

expressions where

```
proc case pat_1 -> cmd_1
...
pat_n -> cmd_n
```

desugars to

```
proc fresh -> case fresh of
pat_1 -> cmd_1
...
pat_n -> cmd_n
```

Lambda case expressions should also have analog arrow commands where

```
\ case pat_1 -> cmd_1
...
pat_n -> cmd_n
```

desugars to

```
\ fresh -> case fresh of
pat_1 -> cmd_1
...
pat_n -> cmd_n
```

Multi-way if expressions should have analog arrow commands where

```
if | cond_1 -> cmd_1
...
cond_n -> cmd_n
```

desugars to

```
case () of
_ | cond_1 -> cmd_1
...
| cond_n -> cmd_n
```

Identifiers `pat_i`

, `cond_i`

, and `cmd_i`

denote patterns, boolean expressions, and arrow commands, respectively.

Bug #7071 has to be fixed before starting with this ticket.

Trac field | Value |
---|---|

Version | 7.5 |

Type | FeatureRequest |

TypeOfFailure | OtherFailure |

Priority | normal |

Resolution | Unresolved |

Component | Compiler |

Test case | |

Differential revisions | |

BlockedBy | |

Related | |

Blocking | |

CC | |

Operating system | |

Architecture |

Replying to [ticket:4359#comment:62931 igloo]:

I don't see a major problem with

`case of`

/`proc of`

, although personally I would also prefer`\ of`

/`proc of`

.

Since `proc`

is the arrow analog of `\`

, I think we should use a syntax that uses `\`

in the notation for ordinary lambda case and uses `proc`

instead of `\`

for the arrow lambda case.

Replying to [ticket:4359#comment:62929 igloo]:

The lexer complexity is only an issue with the

`\ case`

syntax, not with either`\ of`

or`case of`

, right?So given opinion seems to be divided on which is aesthetically nicer, which don't we implement one of the syntaxes that gives a simpler, cleaner specification and implementation?

It’s not just about aesthetics, specification, and implementation. The `case of`

solution has the problem that it cannot be carried over to arrow expressions. So we have the following situation:

`case of` | no analog for arrow expressions |
---|---|

`\case` | lexer complexity |

`\of` | not immediately visible that it is about case distinction |

I tend to prefer `\of`

.

Replying to [ticket:4359#comment:62890 simonpj]:

Concerning arrows, I do agree that (

`proc case`

alts) as syntactic sugar for (`prox x -> case x of`

alts) would be consistent. I don't know the arrow equivalent of multi-branch if would look like. Want to flesh it out?

And example using it would look like this:

```
proc x -> if | x > 0 -> f -< -1
| x == 0 -> g -< 0
| otherwise -> h -< 1
```

HoweverI am deeply reluctant to fiddle with the arrow code at all; there's a long-standing plan to refactor the arrow-handling code which is currently complex and crufy. If anyone arrow-keen person is willing to undertake this, I am happy to help. The ticket is #7071 (closed).

I can imagine to help here, but I would like to be permitted to add support for arrow versions of lambda case and multi-branch if.