- ghc-tickets - Haskell.org

Re: [GHC] #6018: Injective type families
by GHC 18 Sep '14

18 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): Ah, of course. I was thinking about this problem earlier but then I somehow convinced myself that this will not be an issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:72> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 18 Sep '14

18 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by simonpj): The difficulty is that when you say {{{ type family F (a::*) :: * }}} you expect `a` to be a ''type'' variable and `*` to be a ''kind''. So if you say {{{ type family F (a::*) :: (b :: *) }}} it looks as though `b` is a ''kind'' variable, and `*` is a ''sort''. That's why Reid wants to use `=` rather than `::`, and he is right. It's reasonable to have either of these {{{ type family F a :: * type family F a = (b :: *) }}} but not {{{ type family F a :: (b :: *) }}} The merit of the "= blah" notation is that it allows us to give a name to the result, rather than use a magic name. I think it's probably just about worth the syntactic cost. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:71> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 18 Sep '14

18 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:69 rwbarton]: > That reads very oddly to me, but how about...? > {{{ > type family Id a = result | result -> a where > }}} You mean that the `:: result` syntax reads oddly? It is already supported by GHC and the nice thing about this proposal is that we can piggyback on the syntax we already have. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:70> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 18 Sep '14

18 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by rwbarton): That reads very oddly to me, but how about...? {{{ type family Id a = result | result -> a where }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:69> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9592: Add link to wiki index in the ticket view on Trac
by GHC 18 Sep '14

18 Sep '14

#9592: Add link to wiki index in the ticket view on Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I often want to get from the ticket view to index of all wiki pages. Sadly, ticket view only has links to previous ticket/next ticket in the top right of the page. So to get to the index of wiki pages I need to go to any of the wiki pages in the left panel and only then the link to wiki index appears in the top right of the page. Would it be possible to have link to wiki index also in the ticket view? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9592> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #6018: Injective type families
by GHC 18 Sep '14

18 Sep '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): A nice syntax proposal showed up on Haskell-cafe. The idea is to allow user to actually introduce a variable that names the result: {{{#!hs type family Id a :: (result :: *) | result -> a where type family F a b c :: (d :: *) | d -> a b c type family G a b c :: (foo :: *) | foo-> a b where type family Plus a b :: (sum :: Nat) | sum a -> b, sum b -> a where type family H a b c :: (xyz :: *) | xyz a -> b c, xyz b -> a c }}} No new keywords, so we get full backwards compatibility. I'm only wondering how this would interact with kind signatures for the result, which we allow now. Above I assumed that if a programmer wants to name the result she must supply a kind annotation. This might be a bit inconvenient. On the other hand I think that the range of possible names for type variables and kinds is disjoint, so we may actually guess whether the user means the kind of the result or its name by looking whether the identifier is capitalized. So we could just write: {{{#!hs type family Id a :: result | result -> a where type family F a b c :: d | d -> a b c type family G a b c :: foo | foo-> a b where type family Plus a b :: sum | sum a -> b, sum b -> a where type family H a b c :: xyz | xyz a -> b c, xyz b -> a c }}} The only caveat I see is that user might accidentally write `type family Plus a b :: nat` instead of `type family Plus a b :: Nat` and then get some weird compilation errors if the kind signature was essential to make the code compile. Still, I like this proposal best of all made so far. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:68> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8097: internal error: getMBlock: mmap: Operation not permitted
by GHC 18 Sep '14

18 Sep '14

#8097: internal error: getMBlock: mmap: Operation not permitted ------------------------------+---------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+---------------------------------- I get the following: {{{ <interactive>: internal error: getMBlock: mmap: Operation not permitted (GHC version 7.4.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} when running {{{parseOnly queryKeyParse (Data.Text.pack "hello")}}} where: {{{ queryKeyParse :: Attoparsec.Parser [T.Text] queryKeyParse = do top <- Attoparsec.takeTill (=='[') keys <- many key return (top:keys) where key = many (Attoparsec.char '[') *> Attoparsec.takeTill (==']') <* many (Attoparsec.char ']') }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8097> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7353: Make system IO interruptible on Windows
by GHC 18 Sep '14

18 Sep '14

#7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.1 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by martin-bailey): * cc: hvr, ekmett (added) Comment: Is anyone currently working on an IO manager for Windows? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7353#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9559: "Illegal equational constraint" that might not be the users fault
by GHC 17 Sep '14

17 Sep '14

#9559: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you try the latest cabal head and GHC together as of 2014.09.04, and then you try to install statistics, you'll see an error like the following, which does not occur in GHC 7.8.3: {{{ cabal-1.21 install -w ghc-7.9.20140904 Resolving dependencies... Configuring statistics-0.13.2.1... Building statistics-0.13.2.1... Preprocessing library statistics-0.13.2.1... [ 1 of 46] Compiling Statistics.Test.Internal ( Statistics/Test/Internal.hs, dist/build/Statistics/Test/Internal.o ) [ 2 of 46] Compiling Statistics.Test.Types ( Statistics/Test/Types.hs, dist/build/Statistics/Test/Types.o ) [ 3 of 46] Compiling Statistics.Internal ( Statistics/Internal.hs, dist/build/Statistics/Internal.o ) [ 4 of 46] Compiling Statistics.Transform ( Statistics/Transform.hs, dist/build/Statistics/Transform.o ) Statistics/Transform.hs:113:3: Illegal equational constraint Control.Monad.Primitive.PrimState m ~ s (Use GADTs or TypeFamilies to permit this) When checking that ‘bitReverse’ has the inferred type bitReverse :: forall (m :: * -> *) b. (Control.Monad.Primitive.PrimMonad m, Control.Monad.Primitive.PrimState m ~ s) => Int -> Int -> m b In an equation for ‘mfft’: }}} (Indeed, adding the GADTs language pragma makes the type checker happy, as in the commit here: https://github.com/rrnewton/criterion/commit/3a2487176e92b6972560ab1abdfa09… ) Hmm, well, the source code in this case did not explicitly add the "~ s" constraint, the inference cooked it up. Is this a GHC bug in 7.9 or in 7.8? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9560: "Illegal equational constraint" that might not be the users fault
by GHC 17 Sep '14

17 Sep '14

#9560: "Illegal equational constraint" that might not be the users fault -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you try the latest cabal head and GHC together as of 2014.09.04, and then you try to install statistics, you'll see an error like the following, which does not occur in GHC 7.8.3: {{{ cabal-1.21 install -w ghc-7.9.20140904 Resolving dependencies... Configuring statistics-0.13.2.1... Building statistics-0.13.2.1... Preprocessing library statistics-0.13.2.1... [ 1 of 46] Compiling Statistics.Test.Internal ( Statistics/Test/Internal.hs, dist/build/Statistics/Test/Internal.o ) [ 2 of 46] Compiling Statistics.Test.Types ( Statistics/Test/Types.hs, dist/build/Statistics/Test/Types.o ) [ 3 of 46] Compiling Statistics.Internal ( Statistics/Internal.hs, dist/build/Statistics/Internal.o ) [ 4 of 46] Compiling Statistics.Transform ( Statistics/Transform.hs, dist/build/Statistics/Transform.o ) Statistics/Transform.hs:113:3: Illegal equational constraint Control.Monad.Primitive.PrimState m ~ s (Use GADTs or TypeFamilies to permit this) When checking that ‘bitReverse’ has the inferred type bitReverse :: forall (m :: * -> *) b. (Control.Monad.Primitive.PrimMonad m, Control.Monad.Primitive.PrimState m ~ s) => Int -> Int -> m b In an equation for ‘mfft’: }}} (Indeed, adding the GADTs language pragma makes the type checker happy, as in the commit here: https://github.com/rrnewton/criterion/commit/3a2487176e92b6972560ab1abdfa09… ) Hmm, well, the source code in this case did not explicitly add the "~ s" constraint, the inference cooked it up. Is this a GHC bug in 7.9 or in 7.8? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1