- ghc-tickets - Haskell.org

[GHC] Batch modify: #9385, #9586, #9588, #9590, #9664, #9816, #10039
by GHC 06 Feb '15

06 Feb '15

Batch modification to #9385, #9586, #9588, #9590, #9664, #9816, #10039 by hvr: keywords to report-impact -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=9385%2C9586%2C9588%2C9590%2C9664%2…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #7530, #8302, #9008, #9016, #9531, #9532, #9550
by GHC 06 Feb '15

06 Feb '15

Batch modification to #7530, #8302, #9008, #9016, #9531, #9532, #9550 by hvr: keywords to report-impact -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=7530%2C8302%2C9008%2C9016%2C9531%2…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9004: Add sortOn function to Data.List
by GHC 06 Feb '15

06 Feb '15

#9004: Add sortOn function to Data.List -------------------------------------------+------------------------------- Reporter: JohnWiegley | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- The following passed for two weeks on the libraries mailing list without any dissenting votes. The request is to add the following function to Data.List: {{{ -- | Sort a list by comparing the results of a key function applied to each -- element. @sortOn f@ is equivalent to @sortBy . comparing f@, but has the -- performance advantage of only evaluating @f@ once for each element in the -- input list. This is called the decorate-sort-undecorate paradigm, or -- Schwartzian transform. sortOn :: Ord b => (a -> b) -> [a] -> [a] sortOn f = map snd . sortBy (comparing fst) . map (\x -> let y = f x in y `seq` (y, x)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9767: Add isSubsequenceOf to Data.List
by GHC 06 Feb '15

06 Feb '15

#9767: Add isSubsequenceOf to Data.List -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Niklas Hambüchen suggested that we add the dual of subsequences, isSubsequenceOf (like isPrefixOf to inits & isSuffixOf to tails)[1]. It was a simple and noncontroversial proposal which received unanimous +1s. [1] https://www.haskell.org/pipermail/libraries/2014-November/024063.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1990: Add 'subsequences' and 'permutations' to Data.List
by GHC 06 Feb '15

06 Feb '15

#1990: Add 'subsequences' and 'permutations' to Data.List -------------------------------------+------------------------------------- Reporter: twanvl | Owner: igloo Type: proposal | Status: closed Priority: high | Milestone: 6.10 Component: libraries/base | branch Resolution: fixed | Version: 6.8.1 Operating System: Unknown/Multiple | Keywords: report- Type of failure: None/Unknown | impact Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, ekmett (added) * failure: => None/Unknown * keywords: => report-impact -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1990#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 05 Feb '15

05 Feb '15

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | TypeFamilies, Injective Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4259 | Test Case: | Blocking: | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by jstolarek): Dominic, do throw in thoughts at any time. My patch will be ready Real Soon Now but after the merge there will be room for further development of this feature. I will not comment on the proposal of having a separate kind for injective type families. I don't have sufficient knowledge of typechecker to judge whether this would make things easier. Perhaps Simon or Richard can offer some insight here. Regarding your proposed new syntax I believe it does not offer anything new compared to the syntax we decided to use (unless I missed something?). These pairs of definitions would be equivalent: {{{#!hs type family Id a = result | result -> a where {...} type family (Id :: * >-> *) a where {...} type family F a b c = d | d -> a b c type family (F :: * >-> * >->) a b c type family G a b c = foo | foo -> a b where type family (G :: * >-> * -> *) a b c }}} Your syntax however does not extend to injectivity where knowing the result and some of the arguments allows to determine some other arguments: {{{#!hs 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 }}} This kind of injectivity is not implemented in my patch but we want to leave the door open for such a possibility in the future. I'm also not sure if I like how your proposed syntax interacts with PolyKinds: it seems that there would be two alternative places to specify kinds. David, what do you mean by injectivity lemmas? At the moment I don't have a solid stance on the subject of calling type families in the RHS of injective type families. When I started this work it seemed to me that this is not possible. Now I have some more experience so I plan to revisit my earlier decisions. Incidentally, now it seems to me that self-recursion might actually be doable. Calling other type families in the RHS still seems very problematic. First of all called families would have to be injective to declare that a type family that calls them is also injective*. This implies that type families would have to be typechecked in dependency order, which sounds lika a non-trivial technical obstacle. Of course this would prevent type families that form cycles (including mutual recursion) from being injective. Another problem is issue of overlap: {{{#!hs type family Foo a = r | r -> a where Foo (Bar a) = X a Foo (Baz a b) = Y a b }}} To determine whether `Foo` is injective or not we must know whether `X a` and `Y a b` can have identical values (well, types not values). Given that `X` and `Y` can also call other type families I don't see a simple way of checking this. Anyway, the ice here seems very thin and I don't feel confident proceeding further with calling type families by injective type families without formal proof. *) This is a simplifying assumption. It is possible to write a type family that is injective despite calling non-injective type families. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:107> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 05 Feb '15

05 Feb '15

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | TypeFamilies, Injective Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4259 | Test Case: | Blocking: | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by dfeuer): I don't see the problem with letting injective families call other type families as long as there is no recursion—can't GHC follow all paths to the end when necessary, and use injectivity "lemmas" when possible for efficiency? Or does this end up not being useful/efficient/possible for some reason? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 05 Feb '15

05 Feb '15

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | TypeFamilies, Injective Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4259 | Test Case: | Blocking: | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by dorchard): Hi, Sorry to throw in a late thought, but what about adding a kind of injectives `>->`? e.g.`* >-> *`is the kind of injective type functions (as proved by the compiler, and perhaps as explicitly annotated by the user). This would provide a way to propagate the injectivity information within the type checker, and could also be an alternative (replacement?) for using the functional dependency syntax here (although, I think that syntax makes a lot of sense). I suppose it is not currently possible to specify this for a type family, unless kind signatures on type family names were possible, e.g. {{{ type family (Id :: * >-> *) a where Id a = a }}} but this wouldn't be hard to add I don't think. Note that data family could then be given the injective kind too. This might provide some simplification in the type checker? I don't know for sure though. Just a thought, but thought it worth mentioning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10065: Definition of fix lacks commentary
by GHC 05 Feb '15

05 Feb '15

#10065: Definition of fix lacks commentary -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.11 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In `Data.Function`, {{{#!hs fix :: (a -> a) -> a fix f = let x = f x in x }}} It is not immediately obvious why it is defined like this, rather than the more natural {{{#!hs fix f = f (fix f) }}} There are very good reasons for this; notably, it allows for the definition of circular data structures. But there should be a comment explaining this, preferably in the Haddocks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 04 Feb '15

04 Feb '15

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | thoughtpolice Priority: normal | Status: new Component: Compiler | Milestone: 7.12.1 Resolution: | Version: 7.0.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Runtime | Architecture: performance bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #5877 #10064 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: 5877 => #5877 #10064 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0