[GHC] #10134: Pattern Matching Causes Infinite Type Error
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Howsagoin, This is a report about ghci (7.8.4) with CLaSH 0.4.1 I have a collection of modules that show an odd error. I don't want to send them to the list but I can send them to the developers if they think the described behaviour is definitely an error, which I suspect it is. When I write:
(a,b) = expression
I get a type error about an occurs check: cannot construct infinite type: t0 ~ (t0 + 1) -1. The error message doesn't mention t0. However, when I leave out the pattern matching on the tuple and write
var = expression a = fst var b = snd var
where var is a fresh variable, everything is fine. This is odd, because all I did was stripping off the pattern matching. To make sure, I also tried
var = expression (a,b) = var
This also gave the same type checking error. If there's anybody willing to have a look at this, please feel free to contact me by email. If you think I should produce a small example, also please let me know, but please note that it already took me several hours before I found that leaving out the pattern matching solved the problem:-( TIA for your time. Marc van Dongen dongen@cs.ucc.ie -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): That is indeed odd. Does it happen with 7.10? If you can produce a small example I'd definitely look at it. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): If you're trying to minimize further, I have a hunch that type families (perhaps even looping ones) are to blame, somehow. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): Thanks. The modules that cause it are already small. I'll try and minimise further. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): OK. I've managed to trim down the problem to a few lines. I'm including the contents of three files (it wasn't clear how to attach). Dummy1, which mainly contains type definitions that are needed in my real modules, Dummy2, which contains a datatype and a function, the type of which ``causes'' the problem, and Dummy3, which has the bug. If you compile Dummy3, you get an error. If you comment that line out and uncomment the three previous lines, you'll see that all is fine. In short, I wouldn't expect this behaviour (but I haven't programmed in Haskell for a long time). {{{
-- Dummy1.lhs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-}
module Dummy1( Dummy1, Exponential, Positive ) where import CLaSH.Prelude
data Dummy1 n a = Dummy1 { tree :: Vec n a -- | The converging computation. } deriving Show
type Exponential n = ( Positive n , KnownNat (2^n) , KnownNat ((2^n)-1) , KnownNat ((2^n)-2) , KnownNat ((2^(n-1))+((2^(n-1))-1)) , (((2^n)-1)+1)~(2^n) , (((2^n)-2)+1)~((2^n)-1) , ((2^(n-1)-1)*2)~(2^n-2) , (2^n-2+1)~((2^(n-1))+((2^(n-1))-1)) , (((2^(n-1))+((2^(n-1))-1))*2)~((2^n)+((2^n)-2)) )
type Positive n = ( KnownNat n , KnownNat (n-1) , ((n-1)+1)~n )
}}} {{{
-- Dummy2.lhs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE AllowAmbiguousTypes #-}
module Dummy2( Dummy2, nextDummy2 ) where
import CLaSH.Prelude import Dummy1
-- | Data type for arc consistency convergence circuit -- | * The delay of the circuit is @2*(n+d)@. data Dummy2 n d = Dummy2 { dummy :: Vec ((n+d)) Bool } deriving Show
nextDummy2 :: ( KnownNat n , KnownNat d , Exponential (n+d) , Positive (2*(n+d)) ) => Dummy2 n d -> ( Dummy2 n d, Bool ) nextDummy2 cv = error []
}}} {{{
-- Dummy3.lhs {-# LANGUAGE MultiParamTypeClasses #-}
module Dummy3( Dummy3 ) where
import CLaSH.Prelude import Dummy1 import Dummy2
data Dummy3 n d = Dummy3 { dummy2 :: Dummy2 n d } deriving Show
nextDummy3 :: ( Exponential d , Exponential n , Exponential (n+d) , Positive (2*(n+d)) , ((2^n)*(2^d))~(2^(n+d)) ) => Dummy3 n d -> Dummy3 n d nextDummy3 ac = Dummy3 { dummy2 = dummyFst } where -- dummy2' = nextDummy2 (dummy2 ac) -- dummyFst = fst dummy2' -- dummySnd = snd dummy2' (dummyFst,dummySnd) = nextDummy2 (dummy2 ac)
-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): It looks as if the constraint @((n-1)+1)~n@ is the cause of the error. Thanks to Christiaan Baaij for finding this out. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Does that mean you can simplify still further? `Exponential` is still a pretty big constraint. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): OK Here's the simplest example. The problem goes away if you don't use @Positive (2*(n+d))@ but just @Positive (n+d)@. {{{
module Dummy( Dummy ) where
import CLaSH.Prelude
type Positive n = ( KnownNat n , KnownNat (n-1) , ((n-1)+1)~n )
data Dummy n d = Dummy { vec :: Vec n (Vec d Bool) } deriving Show
nextDummy :: ( KnownNat n , KnownNat d , Positive (2*(n+d)) ) => Dummy n d -> Dummy n d nextDummy d = Dummy { vec = vec dFst } where -- d2' = nextDummy' d -- dFst = fst d2' -- dSnd = snd d2' (dFst,dSnd) = nextDummy' d
nextDummy' :: ( KnownNat n , KnownNat d , Positive (2*(n+d)) ) => Dummy n d -> ( Dummy n d, Bool ) nextDummy' _ = error [] }}}
-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The code is small but depends on `import CLaAH.Prelude`. What's that? Can you suck out the important bits and put them in the test case? (I did try `cabal unpack clash` and got `clash-0.1.3.11`, but it didn't contain a `Prelude` module.) Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): Hi Simon, You must build this with _clash_, which is built on top of ghc. I tried to simplified the example but I couldn't. Still I learnt something. * I removed the need for @CLaSH.Prelude@ and copied a definition for @Vec@ into the @Dummy@ module. I then imported @GHC.TypeLits@ and added lots of pragmas suggested by ghc. After that the module compiled fine. * I then did a bit more inverstigating and found that if I add the pragma @{-# LANGUAGE TypeFamilies #-}@ to the original @Dummy@ module (the one that depends on @CLaSH.Prelude@) solves the problem. Regards, Marc -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): But `clash-0.1.3.11` does not include a module called `CLaSH.Prelude`. You say "You must build this with _clash_, which is built on top of ghc". Can you give a sequence of steps to achieve that? From what I can see clash has a huge dependency list {{{ build-depends: ghc >= 6.12 && < 6.13, pretty >= 1.0.1.1 && < 1.1, vhdl >= 0.1.2.1 && < 0.2, haskell98 >= 1.0.1.1 && < 1.1, data-accessor >= 0.2.1.3 && < 2.3, containers >= 0.3 && < 0.4, base >= 4.2 && < 4.3, transformers >= 0.2 && < 0.3, filepath >= 1.1.0.4 && < 1.2, template-haskell >= 2.4.0.1 && < 2.5, data-accessor-template >= 0.2.1.8 && < 0.3, prettyclass >= 1.0 && < 1.1, directory >= 1.0 && < 1.1, tfp >= 0.2 && < 0.4, th-lift >= 0.5.4 && < 0.6, time >= 1.1.4 && < 1.2, utility-ht < 0.0.7 }}} I'm having a hard time believing that installing vhdl (which sounds like a big deal) is crucial to demonstrating the problem. Maybe instead of copying the definition for `Vec` into `Dummy`, make a separate module `Clash.Stubs`, and populate it with the stuff that `Dummy` needs? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): The main CLaSH page is http://christiaanb.github.io/clash2/. It contains a link to a tutorial. To compile @Dummy.lhs@ with clash, you write _clash Dummy.lhs_. It will call ghc itself. You can also call _clash --interactive Dummy.lhs_, which will call ghci. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error
-------------------------------------+-------------------------------------
Reporter: dongen | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.4
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: None/Unknown | Unknown/Multiple
Blocked By: | Test Case:
Related Tickets: | Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by simonpj):
Aha. The missing piece (which I found on the CLaSH page) is that the
library in question is `clash-ghc` not `clash`.
But I failed immediately
{{{
bash$ cabal install clash-ghc --with-
ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: clash-ghc-0.4.1 (user goal)
trying: base-4.8.0.0/installed-inp... (dependency of clash-ghc-0.4.1)
trying: unbound-0.4.3.1 (dependency of clash-ghc-0.4.1)
trying: RepLib-0.5.3.3 (dependency of unbound-0.4.3.1)
next goal: template-haskell (dependency of RepLib-0.5.3.3)
rejecting: template-haskell-2.10.0.0/installed-inp... (conflict: RepLib =>
template-haskell>=2.4 && <2.10)
rejecting: template-haskell-2.9.0.0 (conflict: base==4.8.0.0/installed-
inp...,
template-haskell => base==4.7.*)
rejecting: template-haskell-2.8.0.0 (conflict: base==4.8.0.0/installed-
inp...,
template-haskell => base==4.6.*)
rejecting: template-haskell-2.7.0.0 (conflict: base==4.8.0.0/installed-
inp...,
template-haskell => base==4.5.*)
rejecting: template-haskell-2.6.0.0 (conflict: base==4.8.0.0/installed-
inp...,
template-haskell => base==4.4.*)
rejecting: template-haskell-2.5.0.0 (conflict: base==4.8.0.0/installed-
inp...,
template-haskell => base==4.3.*)
rejecting: template-haskell-2.4.0.1 (conflict: base==4.8.0.0/installed-
inp...,
template-haskell => base==4.2.*)
rejecting: template-haskell-2.4.0.0 (conflict: base==4.8.0.0/installed-
inp...,
template-haskell => base>=3 && <4.3)
rejecting: template-haskell-2.3.0.1, 2.3.0.0, 2.2.0.0 (conflict: RepLib =>
template-haskell>=2.4 && <2.10)
Backjump limit reached (change with --max-backjumps).
}}}
I can't even see the code:
{{{
bash$ cabal unpack clash-ghc
Downloading clash-ghc-0.4.1...
cabal:
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): This smells like a "Let should not be generalised" problem. dongen: Does enabling the `MonoLocalBinds` extension fix the problem? Conversely, in your one-module, no-dependencies version, does enabling `NoMonoLocalBinds` cause the problem to appear? The `TypeFamilies` extension implies `MonoLocalBinds`. My guess is that this is a case where using definitions whose types mention type families means that a `let` should not be generalised. And that will be hard to fix without enabling `MonoLocalBinds` by default. Interesting -- I'd love to see that minimal case! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => infoneeded Comment: Presumably, if this is a GHC issue and not a clash issue (okay, seems likely!) then there is some input file that clash provides to ghc which would exhibit this behavior. dongen, since you are the one who knows about clash, could you extract this file? Or, if clash is instead a GHC API consumer, then it may require more clash expertise to figure out exactly what input is being provided to GHC. Probably all it takes is extracting the definitions of all those type families from wherever they are defined by clash; but in any case we need a test case for GHC, and you as the clash user are best situated to provide it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): @simon Thanks. I don't have time to work on a minimal example. As I mentioned extracting the cause of the problem already took hours. This is really nasty stuff and there's no quarantee I'll succeed. @rwbarton I already tried copying the definitions and produce an example that doesn't depend on CLaSH. Unfortunately, the example compiled fine. I mentioned this in a previous post. I'll look at `MonoLocalBinds` suggestion later. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dongen): @goldfire Substituting `MonoLocalBinds` for `TypeFamilies` in my most recent example also compiles fine. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "T10134.hs" added. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "ClashPrelude.hs" added. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): To reproduce this problem: * Download `T10134.hs` and `ClashPrelude.hs`, which is a further reduced version of `Dummy.lhs` above, without any dependencies. * Run `ghc-7.8.4 T10134.hs -fforce-recomp -XDataKinds -XTypeOperators -XConstraintKinds -XTypeFamilies -XNoMonomorphismRestriction -XNoMonoLocalBinds`. (I didn't add these as language pragmas to the file, to show that clash- ghc sets them) * This is the error: {{{ Occurs check: cannot construct the infinite type: t0 ~ (t0 + 1) - 1 The type variable ‘t0’ is ambiguous When checking that ‘dSnd’ has the inferred type ‘Bool’ Probable cause: the inferred type is ambiguous In an equation for ‘nextDummy’: nextDummy d = Dummy {vec = vec dFst} where (dFst, dSnd) = nextDummy' d }}} To reproduce with clash-ghc itself, I did something like this: {{{ $ cabal sandbox init $ cabal install --with-ghc=ghc-7.8.4 clash-ghc==0.4.1 --constraint=clash- lib==0.4.1 $ ./cabal-sandbox/bin/clash -package-db=.cabal-sandbox/x86_64-linux- ghc-7.8.4-packages.conf.d/ T10134.hs` ... same error ... }}} What's going on is this: * clash-ghc is basically a copy of ghc-bin, with some modifications. * One of the modifications is that by default it sets `TypeFamilies` and some other language extensions, and unsets `MonoMorphismRestriction`. * Normally, when you set `TypeFamilies` (or `GADTs`), you also get `MonoLocalBinds`. clash-ghc doesn't call the code that does that however, and instead manipulates DynFlags directly. * So to reproduce the problem with just ghc, we have to set `TypeFamilies`, but unset `MonoLocalBinds`. `T10134.hs` compiles fine with ghc-7.10.2 and HEAD. It does show the following warning: {{{ Redundant constraint: Positive (2 * (n + d)) In the type signature for: nextDummy' :: Positive (2 * (n + d)) => Dummy n d -> (Dummy n d, Bool) }}} After removing that constraint, the example compiles with ghc-7.8.4 also. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new Comment: That's all I know. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by darchon): * cc: darchon (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): `TypeFamilies` without `MonoLocalBinds` is an unsupported configuration. The user manual, section 7.13.9.3 (on let-generalization) concludes with this:
The flag `-XMonoLocalBinds` is implied by `-XTypeFamilies` and `-XGADTs`. You can switch it off again with `-XNoMonoLocalBinds` but type inference becomes less predicatable if you do so. (Read the papers!)
So it seems this is clash's problem, after all, in setting a wonky configuration. I think this ticket can be closed as invalid, but one of the posters should double-check me before closing. Thanks, @thomie, for the analysis! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Wonky or not, GHC ought to be able to solve `t0 ~ (t0 + 1) - 1`. And indeed it is fine with GHC 7.10 and HEAD. So I'll add this nicely-reduced test (thank you) as a regression test, and close the ticket. I hope that CLASH compiles ok with 7.10! Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error -------------------------------------+------------------------------------- Reporter: dongen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T10134 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T10134 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10134#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#10134: Pattern Matching Causes Infinite Type Error
-------------------------------------+-------------------------------------
Reporter: dongen | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.4
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
| polykinds/T10134
Blocked By: | Blocking:
Related Tickets: | Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by Simon Peyton Jones
participants (1)
-
GHC