February 2015 - ghc-tickets

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

05 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 05 Feb '15

05 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 04 Feb '15

04 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 04 Feb '15

04 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 04 Feb '15

04 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

[GHC] #8266: Dynamic linking on Mac
by GHC 04 Feb '15

04 Feb '15

#8266: Dynamic linking on Mac ------------------------------+-------------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: Priority: highest | Version: 7.7 Component: Build | Operating System: MacOS X System | Type of failure: GHC doesn't work at all Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Many dynamic libraries refer to the build tree. (1) Every ".dylib" installed with GHC head refers to itself in its build directory. E.g. {{{ % otool -L libHSbase-4.7.0.0-ghc7.7.20130909.dylib | grep base libHSbase-4.7.0.0-ghc7.7.20130909.dylib: /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} (2) Some ".dylib" installed with GHC head refers to other libraries in their build directories. E.g. {{{ % otool -L libHSvector-0.9.1-ghc7.7.20130909.dylib | grep /Users /Users/kazu/work/ghc/libraries/vector/dist- install/build/libHSvector-0.9.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/primitive/dist- install/build/libHSprimitive-0.4.0.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} (3) All user installed libraries by cabal-install refer to other libraries in their build directories. E.g. {{{ % otool -L libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib| grep Users /Users/kazu/Library/Haskell/ghc-7.7.20130909/lib/ghc- paths-0.1.0.9/lib/libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/integer-gmp/dist-install/build /libHSinteger-gmp-0.5.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/ghc-prim/dist-install/build /libHSghc-prim-0.3.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8266> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 59

[GHC] #10063: State a law for foldMap
by GHC 03 Feb '15

03 Feb '15

#10063: State a law for foldMap -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: feature | Status: new request | Milestone: 7.12.1 Priority: low | Version: 7.10.1-rc1 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: Documentation Keywords: | bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After being prodded by /u/random_crank on reddit, I realized there is a law we can state for `foldMap`: A monoid homomorphism `g` is a function such that {{{#!hs g mempty = mempty g (mappend a b) = mappend (g a) (g b) }}} holds. For any monoid homomorphism `g`: {{{#!hs foldMap (g . f) = g . foldMap f }}} This isn't strictly a free theorem as it relies on the `Monoid` laws, but it is true and has the same general flavor as the equally complicated free theorem for `foldr`. This law is a bit technical, but is a nice tool for equational reasoning, and gives rise to a much nicer `foldMap`-based version of the "banana split" theorem for `foldr`. {{{#!hs foldMap f &&& foldMap g = foldMap (f &&& g) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10063> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9937: add updated prefetch API mention to the 7.10 release notes
by GHC 02 Feb '15

02 Feb '15

#9937: add updated prefetch API mention to the 7.10 release notes -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9937> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2