- ghc-tickets - Haskell.org

Re: [GHC] #4834: New Functor => Applicative => Monad Hierarchy
by GHC 09 Feb '15

09 Feb '15

#4834: New Functor => Applicative => Monad Hierarchy -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: 7.0.1 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #8004 | Test Case: | Blocking: | Differential Revisions: Phab:D13 -------------------------------------+------------------------------------- Changes (by hvr): * status: closed => new * cc: ekmett, thoughtpolice, hvr (added) * type: proposal => task * differential: => Phab:D13 * related: => #8004 * priority: normal => high * milestone: Not GHC => 7.10.1 * keywords: => report-impact * resolution: invalid => Comment: Reusing this old AMP ticket so I don't have to create a new one to track AMP progress; AMP phase 1 was covered by #8004, while this ticket is about phase 3 (actually implementing the change) The AMP was implemented in a single monolithic commit, followed by AMP- related follow-up patches fixing up things as well as generalising some type signatures from Monad to Applicative: - d94de87252d0fe2ae97341d186b03a2fbe136b04 ("Make Applicative a superclass of Monad") - 65f887e1a0d864526f6a2609a3afc2c151c25e38 ("base: Add some notes about the default impl of `(>>)`") - 6477b3dc058a92b825ef30d98797603b4a44a001 ("testsuite: AMPify ioprof.hs") - 29e50da4c274eba0e444ce4b95294a76832908f2 ("testsuite: AMPify T3001-2") - f636faa7b2b7fc1d0663f994ad08f365d39a746d ("Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA`") - a07ce1654ac5b8033f2daf9270c6e182415b69ca ("Generalise `Control.Monad.{when,unless,guard}`") - bf3329104c971c84ab178f3ded88254b9594f9cc ("Generalise `guard` for real this time") - a1b539142d7853bc02c36f1b3e8d489a9864f0e9 ("testsuite: fix T5751 build failure (AMP)") - b30b185e5c653dfed948d71ce2336be70be3b418 ("testsuite: fix T1735_Help/State.hs build failure (AMP)") - abba3812e657a5267bba406d2c877c1cb5d978f9 ("Improve Applicative definitions") -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4834#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9337: Add `sortOn` function to Data.List
by GHC 09 Feb '15

09 Feb '15

#9337: 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.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Easy (less Blocking: | than 1 hour) | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- This passed the vote on the libraries list a while ago, but I forget to add a ticket. The request was to add `sortOn` to `Data.List`: {{{ -- | Sort a list using a key on each element. This implements the -- decorate-sort-undecorate paradigm, also called a Schwarzian transform. sortOn :: Ord b => (a -> b) -> [a] -> [a] sortOn f = map snd . sortBy (comparing fst) . map (\x -> (f x, x)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9337> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9806: malloc and mallocArray ignore Storable alignment requirements
by GHC 09 Feb '15

09 Feb '15

#9806: malloc and mallocArray ignore Storable alignment requirements -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 8627 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Not sure if this is a bug or a feature request: `allocaBytesAligned` exists and allocates a new pinned byte array with a given alignment. It is used for both `alloca` and `allocaArray`. However, we don't currently have such a facility with `malloc`. `malloc` and `mallocArray` currently just invoke `mallocBytes`, and `mallocBytes` requests memory without alignment guarantees, so the resulting memory might well violate required `Storable` `alignment` for the result. We don't currently pad things out or get properly aligned memory. It strikes me that we should in theory add `mallocBytesAligned`, and switch `malloc` and `mallocArray` to invoke it instead of `mallocBytes`. `Foreign.Marshal.Alloc.mallocBytes` just invokes system `malloc`, so it seems that `memalign` or `posix_memalign` would be suitable. In theory `_malloc` on the system is probably aligning to a pretty common unit size, but if you start doing SIMD stuff you'll start seeing 16 byte alignment requirements, folks who care about cache architecture for example can have 128 byte alignments to pad things to separate cache lines. We probably haven't noticed since you likely get back bytes with slot- sized alignment just by construction, so if your alignment requirements stay in the <= 8 range you'll be okay, but for larger alignments it appears you'd just get wrong answers. If something more subtle is going on here (e.g. an `alignment` bigger than some threshold wont be respected or that users should explicitly expect `mallocArray` to silently allocate an array with the wrong alignment) that I missed then we definitely need better documentation to address the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9806> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #2917: alloca and allocaArray do not respect alignment
by GHC 08 Feb '15

08 Feb '15

#2917: alloca and allocaArray do not respect alignment -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler (FFI) | Version: 6.12.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: reported as #9806 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2917#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

08 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 goldfire): Replying to [comment:105 dorchard]: > what about adding a kind of injectives `>->`? e.g.`* >-> *`is the kind of injective type functions This is very much along the lines of what Jan and I proposed in our "Promoting Functions to Type Families" paper ([http://www.cis.upenn.edu/~eir/papers/2014/promotion/promotion.pdf here]). But, there is some subtlety. GHC assumes all function types (that is, types with kinds that are headed by `->`) are ''generative'' and ''injective''. Generativity means that, given `a b ~ c d`, you can conclude `a ~ c`. Injectivity means that, given `a b ~ a d`, you can conclude `b ~ d`. Indeed, putting these together and assuming `a b ~ c d`, you can conclude `b ~ d`. Thus, the kind `->` denotes a generative, injective function. We could imagine a new classifier `~>` that denotes an ordinary function, with no assumptions. GHC would then be careful not to decompose such things. This is exactly the situation today with type families. Note that, short of GHCi's `:kind` command, there is no way to work with the kind of an unapplied type family. If I say `type family F (a :: *) :: *`, we often colloquially say that `F :: * -> *`, but there is no way to use this knowledge in a Haskell program, because `F` can never appear unsaturated. Thus, it is more accurate to say that `F` is just ill-formed, and `F a :: *` as long as `a :: *`. All of this is to say that the new arrow would have to denote ''non''-injective functions. And, I could easy say that GHC today supports such a thing, because there's no way to take advantage of it anyway. What we really need in this direction is unsaturated type functions, but that's a story for another day. (A story I'd love to think more about... on that other day!) So, taking all of this into account, dorchard's proposal is a different syntax for denoting injectivity, and I personally prefer the functional- dependency-like one more. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10041: Instance signatures (InstanceSigs) don't accept '[] :: [ĸ]
by GHC 06 Feb '15

06 Feb '15

#10041: Instance signatures (InstanceSigs) don't accept '[] :: [ĸ] -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Operating System: Linux (Type checker) | Type of failure: GHC rejects Keywords: | valid program Architecture: x86 | Blocked By: Test Case: | Related Tickets: #9582 #9833 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following doesn't compile with 7.8.3: {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} {-# LANGUAGE TypeOperators, GADTs, InstanceSigs #-} data family Sing (a :: ĸ) data instance Sing (xs :: [k]) where SNil :: Sing '[] class SingI (a :: ĸ) where sing :: Sing a instance SingI '[] where sing :: Sing '[] sing = SNil }}} and the error message suggests the very type provided (`Sing '[]`): {{{#!hs /tmp/Error.hs:11:11: Method signature does not match class; it should be sing :: Sing '[] In the instance declaration for ‘SingI '[]’ Failed, modules loaded: none. }}} Creating a local variable with the same type signature works fine: {{{#!hs instance SingI '[] where sing = tmp where tmp :: Sing '[] tmp = SNil }}} This is '''not''' a problem for other data kinds such as `Bool` though: {{{#!hs data instance Sing (xs :: Bool) where STrue :: Sing True SFalse :: Sing False instance SingI True where sing :: Sing True sing = STrue instance SingI False where sing :: Sing False sing = SFalse }}} This resembles #9582 but I don't believe it is the same error, it has possibly been fixed i 7.10 but unfortunately I don't have a more recent version of GHC to check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10041> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #4865: Deprecate and remove Prelude.catch and System.IO.Error.{catch, try}
by GHC 06 Feb '15

06 Feb '15

#4865: Deprecate and remove Prelude.catch and System.IO.Error.{catch,try} -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 7.0.1 Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, ekmett (added) * keywords: => report-impact -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4865#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5414: Add unsafeShift to Data.Bits
by GHC 06 Feb '15

06 Feb '15

#5414: Add unsafeShift to Data.Bits -------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 7.4.1 Component: libraries/base | Version: 7.2.1 Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, ekmett (added) * keywords: => report-impact -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5414#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5593: Proposal: Remove Num superclass of Bits
by GHC 06 Feb '15

06 Feb '15

#5593: Proposal: Remove Num superclass of Bits -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 7.2.1 Resolution: fixed | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, ekmett (added) * keywords: => report-impact -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5593#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7434: Add (&) to Data.Function
by GHC 06 Feb '15

06 Feb '15

#7434: Add (&) to Data.Function -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9008 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => duplicate * related: => #9008 Comment: this was actually addressed via #9008 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7434#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0