March 2013 - ghc-tickets

[GHC] #7642: Nullary type classes
by GHC 15 Mar '13

15 Mar '13

#7642: Nullary type classes -----------------------------+---------------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- GHC supports `MultiParamTypeClasses` with two or more parameters, but it explicitly rejects classes with no parameters. There doesn't seem to be a good reason for that. Some example uses that came up in IRC: {{{ isPrime :: RiemannHypothesis => Integer -> Bool unsafePerformIO :: Unsafe => IO a -> a }}} The main reason to allow it is probably that it's a pointless restriction, like EmptyDataDecls. In fact, the simplest implementation for this patch consists of deleting one line of code. The attached patch is slightly bigger because it also fixes error messages (I also included a detabbing patch). If necessary this can be made a separate `LANGUAGE` flag -- this patch just folds it into `MultiParamTypeClasses`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7642> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #4175: GHCi support for type/data families should match that of related features
by GHC 14 Mar '13

14 Mar '13

#4175: GHCi support for type/data families should match that of related features ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.3 Keywords: FD TF | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by parcs): I incorporated the above comments into the patch and I also uploaded a patch for the testsuite. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4175#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 14 Mar '13

14 Mar '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by jstolarek): > Can you summarise the design you have implemented, on the Wiki page I updated the Wiki page - see [http://hackage.haskell.org/trac/ghc/wiki/PrimBool#Proposedpatch13032013 this new section]. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets
by GHC 14 Mar '13

14 Mar '13

#1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets ----------------------------------------+----------------------------------- Reporter: sorear | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: 6.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: 5498 Related: | ----------------------------------------+----------------------------------- Comment(by simonpj): See also [http://lukepalmer.wordpress.com/2013/03/04/how-gadts-inhibit- abstraction/ How GADTs inhibit abstraction]. I have not studied it closely but it's clearly relevant. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1496#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5550: GHC infinite loop when compiling vector
by GHC 14 Mar '13

14 Mar '13

#5550: GHC infinite loop when compiling vector ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by akio): * cc: tkn.akio@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5550#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 13 Mar '13

13 Mar '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by simonmar): I'd rather see the existing primops changed to return `Int#` (or `Word#`) than to add new primops. There's no need to have both. But of course it's a deeper change - we'd have to add wrappers that implement the old primops and make sure that we have enough RULEs to get rid of any extra `tagToEnum#` calls. But I think it would ultimately be better that way, the Bool-returning primops are a hack. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 13 Mar '13

13 Mar '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by benl): I've got an idea for a concrete benchmark that definitely wants the new primops. Will post here when it works. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4175: GHCi support for type/data families should match that of related features
by GHC 13 Mar '13

13 Mar '13

#4175: GHCi support for type/data families should match that of related features ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.3 Keywords: FD TF | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by parcs): `orphNamesOfClsInst` and `orphNamesOfTyFamInst` collect the names of all the concrete types and type constructors that make up a particular class instance head or family instance head. For example, supposing we have `class Foo a b` and `type family Bar a b`: `instance Foo (Either (Maybe Int) a) Bool where ...` would give `[Either, Maybe, Int, Bool]` `type instance Bar (F (G (H a))) b = ...` would give `[F, G, H]` In `TcRnDriver`, these functions are used to filter the list of in-scope type family instances and class instances, showing only the instances whose heads contain the name that was passed to `:info`. In `InteractiveEval`, the functions are used to filter instances based on whether all their constituent names are currently in scope. So `:i Int` would output the aforementioned class instance since the head of that particular instance contains the name `Int`. Similarly `:i G` would output the above type family instance, but only if `F` and `H` are in scope as well. Note that I didn't change any existing functionality, I only refactored some of the existing code in light of how similar the `:info` logic for type families instances and class instances turned out to be. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4175#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4175: GHCi support for type/data families should match that of related features
by GHC 13 Mar '13

13 Mar '13

#4175: GHCi support for type/data families should match that of related features ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: bug | Status: patch Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.3 Keywords: FD TF | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Thank you parcs! Can you just explain what's going on with the various calls to `orphNamesOfX`? Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4175#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 13 Mar '13

13 Mar '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by simonpj): Why `Int#`? Wouldn't `Word#` be a better fit? We already have logical operations on that type. Can you summarise the design you have implemented, on the Wiki page [http://hackage.haskell.org/trac/ghc/wiki/PrimBool]? it's a bit hard to reverse-engineer it from the patch. Many thanks. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0