- ghc-tickets - Haskell.org

[GHC] #13657: Documentation: Functional dependencies by other means
by GHC 07 Jun '17

07 Jun '17

#13657: Documentation: Functional dependencies by other means -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: 10431 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There's an idiom that's briefly mentioned under Equality constraints [section 10.14.1], but is more general and more powerful. The trouble: is where to document it? Because you get the power from a combination of extensions: * -XMultiParamTypeClasses [10.8.1.1] * Superclass constraints, which can also be MultiParam [10.8.1.2] * -XFunctionalDependencies [10.8.2] * and/or superclass Equality constraints with Type families, having the effect of FunDeps [10.14.1] * The overall effect can satisfy the FunDep Coverage conditions, which means you might not need -XUndecidableInstances [10.8.3.5] 10.14.1 says: > Equality constraints can also appear in class and instance contexts. The former enable a simple translation of programs using functional dependencies into programs using family synonyms instead. That's not wrong; but by talking about "class and instance contexts" in the same breath does fail to emphasise that: * whereas Instance constraints don't apply until after the instance has been selected\\(And it's a common newbie mistake to think they restrict the selection.) * superclass constraints apply during type improvement __before__ selecting instances\\as described here http://stackoverflow.com/questions/35252562/find-an-element-in-an- hlist/35260970#35260970 "superclass context is critical ..." [thanks @DFeuer] * This behaviour means that even if you don't explicitly put a FunDep `| ... -> ...` on a class: * If you put a superclass equality constraint on a class, that induces a FunDep as explained in 10.14.1; but just as much * If you put a superclass __class__ constraint on a class, and that superclass has a FunDep, that also induces a FunDep. * and so on for a superclass constraint of a superclass constraint of a superclass constraint .... I suggest the bulk of the write-up goes under a new sub-section for FunDeps: ---- == 10.8.2.3 Functional dependency-like behaviour through superclass constraints Constraints in the class context can achieve the effect of Functional dependencies even without the explicit vertical bar and dependency arrow syntax in the class declaration. Either: * Using an Equality constraint to a Type family [10.14.1]; or * A superclass constraint that does have an explicit Functional dependency. * Or a superclass constraint which is itself constrained in one of those ways. A class declaration of the form {{{ class C a b | a -> b }}} can equivalently be given as {{{ class (F a ~ b) => C a b where type F a }}} That is, we represent every functional dependency (FD) `a1 .. an -> b` by an FD type family `F a1 .. an` and a superclass context equality `F a1 .. an ~ b`, essentially giving a name to the functional dependency. [See 10.14.1; using `(~)` needs -XTypeFamilies or -XGADTs.] In class instances, we define the type instances of FD families in accordance with the class head. Or class `C` can equivalently be given as {{{ class (D a b) => C a b ... class D a b | a -> b -- or class (G a ~ b) => D a b where type G a }}} The class instances for `D` will closely follow those for `C`. So there is not much gain in expressivity. Consider also: {{{ class (D a c) => E a b c ... -- class D as above }}} for which the `D` instances will be more compact than `E`. Note that `D` might not declare any methods, but merely be used for type improvement. Method signatures for class `C` are not affected by either of these ways for achieving dependencies. ---- Reference this thread: https://mail.haskell.org/pipermail/glasgow-haskell- users/2017-April/026515.html, with some fancier examples of pseudo- FunDeps. See also #10431. Is this power made clear in the theoretical literature? It's kinda implicit in the TypeFamilies2008 paper; but note that was written concurrently with Type Families development; and published before the work was completed. Specifically, supporting Type Families and `(~)` in superclass constraints was delivered a long time after the rest of the work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13794: Stack update failed
by GHC 07 Jun '17

07 Jun '17

#13794: Stack update failed --------------------------------------+--------------------------------- Reporter: stevenspasbo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Stacktrace asked me to report this as a bug: {{{#!shell [1 of 1] Compiling Main ( /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack- upgrade71650/stack-1.4.0/Setup.hs, /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack- upgrade71650/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack- upgrade71650/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ... Configuring stack-1.4.0... stack-1.4.0: build Preprocessing library stack-1.4.0... [ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 124] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o ) [ 3 of 124] Compiling Stack.Options.ScriptParser ( src/Stack/Options/ScriptParser.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Options/ScriptParser.o ) [ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 6 of 124] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 8 of 124] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) [ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/ghc74455_0/libghc_68.dylib, 5): no suitable image found. Did find: /var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/ghc74455_0/libghc_68.dylib: malformed mach-o: load commands size (50752) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 26 action(s). -- While building package stack-1.4.0 using: /private/var/folders/yx/scmdmrjx25vf6y18kgl_sqvjvq5kjp/T/stack- upgrade71650/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13794> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12778: Expose variables bound in quotations to reify
by GHC 07 Jun '17

07 Jun '17

#12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{ {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH as TH import Language.Haskell.TH.Syntax as TH foo :: IO () foo = $([| let x = True in $(do addModFinalizer $ do Just name <- TH.lookupValueName "x" TH.reify name >>= runIO . print [| return () |] ) |]) }}} When compiled, {{{TH.lookupValueName}}} fails to find {{{x}}}. {{{ $ inplace/bin/ghc-stage2 A.hs -fforce-recomp [1 of 1] Compiling A ( A.hs, A.o ) A.hs:7:9: error: • Pattern match failure in do expression at A.hs:9:23-31 • In the expression: (let x_a3Jy = True in return ()) In an equation for ‘foo’: foo = (let x_a3Jy = True in return ()) }}} It would make producing bindings in {{{inline-java}}} better if the type of {{{x}}} could be found in the finalizer. According to comments in ghc, {{{[| \x -> $(f [| x |]) |]}}} desugars to {{{ gensym (unpackString "x"#) `bindQ` \ x1::String -> lam (pvar x1) (f (var x1)) }}} which erases any hint that a splice point existed at all. This information is necessary to know which variables were in scope. How about we add a some new methods to the `Q` monad for the sake of marking inner splices: {{{ class Q m where ... qSpliceE :: m Exp -> m Exp qSpliceP :: m Pat -> m Pat qSpliceT :: m Type -> m Type ... }}} Now {{{[| \x -> $(f [| x |]) |]}}} would desugar to {{{ gensym (unpackString "x"#) `bindQ` \ x1::String -> lam (pvar x1) (qSpliceE (f (var x1))) }}} When the renamer executes these primitives, it would be aware of the inner splices and could treat them similarly to top-level splices. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12778> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling)
by GHC 06 Jun '17

06 Jun '17

#13703: Internal libraries regression in GHC 8.2 (ghc-pkg handling) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I register two internal libraries from the same package, they clobber each other. They should not do this. This regression was probably introduced by 579bb7669f40ed01841dd197ee535cf26fa19580. Working on a fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12710: Make some reserved Unicode symbols "specials"
by GHC 06 Jun '17

06 Jun '17

#12710: Make some reserved Unicode symbols "specials" -------------------------------------+------------------------------------- Reporter: JoshPrice247 | Owner: JoshPrice247 Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Unicode, | Operating System: Unknown/Multiple UnicodeSyntax | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following comment is in `compiler/parser/Lexer.x`: > ToDo: ideally, → and ∷ should be "specials", so that they cannot > form part of a large operator. This would let us have a better > syntax for kinds: ɑ∷*→* would be a legal kind signature. (maybe). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code
by GHC 06 Jun '17

06 Jun '17

#10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- `-fwarn-incomplete-patterns` doensn't seem to generate any warnings when `-fno-code` is specified. To reproduce, save this module as `foo.hs`. {{{#!hs module Foo where foo True = 4 }}} and compile with `-fwarn-incomplete-patterns`, with and without `-fno- code`. {{{ % ghc -fwarn-incomplete-patterns -fforce-recomp foo.hs [1 of 1] Compiling Foo ( foo.hs, foo.o ) foo.hs:2:1: Warning: Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: False % ghc -fwarn-incomplete-patterns -fforce-recomp -fno-code foo.hs [1 of 1] Compiling Foo ( foo.hs, nothing ) % }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #13787: The compiler told me to report this. I have no idea what happened
by GHC 06 Jun '17

06 Jun '17

#13787: The compiler told me to report this. I have no idea what happened -------------------------------------+------------------------------------- Reporter: gleb_dianov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, Here is the error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] err_aaeS :: t_aaeR[tau:1] (CHoleCan: err)} {{{#!hs teach :: l ~ S l' => ErrorFunction m -> ErrorFunction o -> LearningRate -> Vector (Example i o) m -> Network i l o -> Either StopCriteria (Either Error Iterations) -> NetowrkArgs i l o -> NetworkArgs i l o teach totalErr errF learnRate examples stopCriteria network args = teachNetwork network 0 where teachNetwork :: Network i l o -> Iterations -> Network i l o teachNetwork net i | not $ shouldStop stopCriteria (networkError net) i = teachNetwork (foldl updateNetworkHelper net examples) (i + 1) | otherwise = net networkError :: Network i l o -> Error networkError = undefined updateNetworkHelper :: Network i l o -> Example i o -> Network i l o updateNetworkHelper net@(layer :~~ netTail) example = if example ^. output == runNetwork net (examples ^. input) then net else snd $ updateNetwork layer netTail errF (example ^. inputs) (example ^. outputs) }}} This function broke the compiler. Here is a link to the git repo with this code (module Network) https://gitlab.com/gleb_dianov/neural-haskell With this project I wanted to show how cool Haskell is, but now I can only show how GHC crashes :( -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13788: TypeInType fails to compile old code
by GHC 06 Jun '17

06 Jun '17

#13788: TypeInType fails to compile old code -------------------------------------+------------------------------------- Reporter: br1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE TypeInType #-} module PP where newtype Field l v = Field { value :: v } label :: Field l v -> l label = undefined class HEq x hEq :: HEq x => x -> Int hEq = undefined class HListGet r where hListGet :: r -> Int instance HEq l => HListGet (Field l v) where hListGet f = hEq (label f) }}} fails with {{{ mini.hs:18:29: error: • Couldn't match type ‘k’ with ‘*’ ‘k’ is a rigid type variable bound by the instance declaration at mini.hs:17:5-33 Expected type: Field * l v Actual type: Field k l v • In the first argument of ‘label’, namely ‘f’ In the first argument of ‘hEq’, namely ‘(label f)’ In the expression: hEq (label f) • Relevant bindings include f :: Field k l v (bound at mini.hs:18:14) hListGet :: Field k l v -> Int (bound at mini.hs:18:5) | 18 | hListGet f = hEq (label f) | }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13788> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13778: explicitly bidirectional patterns should not report Recursive definition" when used in view pattern expression position
by GHC 06 Jun '17

06 Jun '17

#13778: explicitly bidirectional patterns should not report Recursive definition" when used in view pattern expression position -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compile this {{{#!hs pattern One <- ((==One) -> True) where One = 1 }}} I get {{{ test.hs:1:1: error: Recursive pattern synonym definition with following bindings: One (defined at test.hs:(1,1)-(1,15)) | Compilation failed. }}} Note that the error is due to the usage in view pattern **expression position**. But for ''explicitly bidirectional'' patterns, there is no recursivity going on. So this usage should be allowed. I am testing with HEAD, but the issue is probably older. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13778> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13774: Singletons code fails to typecheck when type signature involving type family is added
by GHC 06 Jun '17

06 Jun '17

#13774: Singletons code fails to typecheck when type signature involving type family is added -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Yes, I know "singletons" is in the title... but the code isn't //that// scary, I promise. Here's some code which //does// typecheck: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where data family Sing (a :: k) data Nat = Zero | Succ Nat data instance Sing (b :: Bool) where SFalse :: Sing 'False STrue :: Sing 'True data instance Sing (n :: Nat) where SZero :: Sing 'Zero SSucc :: Sing n -> Sing ('Succ n) type family Not (x :: Bool) :: Bool where Not 'True = 'False Not 'False = 'True sNot :: Sing b -> Sing (Not b) sNot STrue = SFalse sNot SFalse = STrue class PFD a b | a -> b where type L2r (x :: a) :: b instance PFD Bool Nat where type L2r 'False = 'Zero type L2r 'True = 'Succ 'Zero type T2 = L2r 'False class SFD a b | a -> b where sL2r :: forall (x :: a). Sing x -> Sing (L2r x :: b) instance SFD Bool Nat where sL2r SFalse = SZero sL2r STrue = SSucc SZero sT2 = sL2r SFalse }}} It also typechecks if you give `sT2` this particular type signature: {{{#!hs sT2 :: Sing 'Zero sT2 = sL2r SFalse }}} However, if you give it either of these two type signatures: {{{#!hs sT2 :: Sing T2 }}} {{{#!hs sT2 :: Sing (L2r 'False) }}} Then GHC 8.0.1, 8.0.2, 8.2.1, and HEAD will choke: {{{ GHCi, version 8.2.0.20170522: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:46:7: error: • No instance for (SFD Bool k) arising from a use of ‘sL2r’ • In the expression: sL2r SFalse In an equation for ‘sT2’: sT2 = sL2r SFalse | 46 | sT2 = sL2r SFalse | ^^^^^^^^^^^ }}} At this point, I get the urge to yell obscenities at GHC, because there definitely //is// an instance of the form `SFD Bool k` in scope (and moreover, `SFD`'s functional dependency should make sure that `k ~ Nat`). Shouldn't it be using that? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5