February 2015 - ghc-tickets

[GHC] #10004: rec {} causes "head:empty list" exception
by GHC 09 Feb '15

09 Feb '15

#10004: rec {} causes "head:empty list" exception -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using GHC HEAD 7.11.20150116 (and before) Trying to load the following into ghci {{{#!hs {-# LANGUAGE RecursiveDo #-} bar :: IO () bar = do rec {} return () }}} results in {{{ > :load "/home/alanz/mysrc/github/alanz/ghc- exactprint/tests/examples/Foo.hs" [1 of 1] Compiling Main ( /home/alanz/mysrc/github/alanz/ghc- exactprint/tests/examples/Foo.hs, interpreted ) *** Exception: Prelude.head: empty list > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3)
by GHC 09 Feb '15

09 Feb '15

#4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: task | Status: closed Priority: high | Milestone: 7.10.1 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: #8004 | Test Case: | Blocking: | Differential Revisions: Phab:D13 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4834#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3)
by GHC 09 Feb '15

09 Feb '15

#4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) -------------------------------------+------------------------------------- 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 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:10 Herbert Valerio Riedel <hvr@…>]: > In [changeset:"a741e69a230eb6d6e3373ad1fbe53c73b5f95077/ghc"]: ...also merged to ghc-7.10 via 262f7a85bb1d40770245b990527eb0bee7c20195 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4834#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 09 Feb '15

09 Feb '15

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: high => normal * milestone: 7.10.1 => 7.12.1 Comment: Since this seems to be a regression, but also something of a corner case involving recursive type families, I'm pushing this one out to 7.12 and 'normal' priority (as 7.10 is feature complete). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3)
by GHC 09 Feb '15

09 Feb '15

#4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) -------------------------------------+------------------------------------- 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 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"a741e69a230eb6d6e3373ad1fbe53c73b5f95077/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a741e69a230eb6d6e3373ad1fbe53c73b5f95077" Provide default implementation of `Monad(return)` This was dropped last-minute from d94de87252d0fe2ae97341d186b03a2fbe136b04 (re #4834) together with the default implementation for `(>>)` (see 65f887e1a0d864526f6a2609a3afc2c151c25e38 for explanation). However, the risk of accidental mutually recursive definitions of `return`/`pure` is rather low as unlike with the `(>>) = (*>)` default, any cyclic definitions would necessarily wind up being new ones, rather than changing the semantics for old operations and introducing bottoms. On the other hand, not having the default method implementation in place in GHC 7.10 would complicate/delay any future attempt to clean-up the `Monad`-class. This finally allows (for `base >= 4.8`) to define a F/A/M instance-chain with the following minimal definitions (while ignoring that `return` is still a class-method in `Monad`) instance Functor M where fmap = ... instance Applicative M where pure = ... (<*>) = ... instance Monad M where (>>=) = ... Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D647 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4834#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) (was: New Functor => Applicative => Monad Hierarchy)
by GHC 09 Feb '15

09 Feb '15

#4834: Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3) -------------------------------------+------------------------------------- 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 -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4834#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 09 Feb '15

09 Feb '15

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4834 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: => #4834 Comment: Phase 3 is covered by the (re-purposed) #4834 ticket -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

08 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