December 2016 - ghc-tickets

[GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P`
by GHC 01 Dec '16

01 Dec '16

#11744: Latest Xcode update violates POSIX compliance of `nm -P` ----------------------------------------+--------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- TLDR: Apple messed up again and broke POSIX compliance luite ran into problems when he installed the latest Xcode update because the derived platform constants were off. He provided me the output of `nm -P ./includes/dist- derivedconstants/header/tmp.o` which turned out have numbers which didn't make sense: {{{ _derivedConstantAP_STACK_SPLIM C 1025 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C 253 0 _derivedConstantBLOCK_SIZE C 4097 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} Which with an older Xcode version would have looked like {{{ _derivedConstantAP_STACK_SPLIM C 401 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C fd 0 _derivedConstantBLOCK_SIZE C 1001 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ... }}} So obviously `nm -P`'s output changed from hexadecimal to (non-compliant) decimal formatting of numbers. For reference, here's how POSIX specifies the semantics of `nm`: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html > `-P` > Write information in a portable output format, as specified in the STDOUT section. ... > If the `-P` option is specified, the previous information shall be displayed using the following portable format. The three versions differ depending on whether `-t d`, `-t o`, or `-t x` was specified, respectively: > > {{{"%s%s %s %d %d\n", <library/object name>, <name>, <type>, <value>, <size>}}} > > {{{"%s%s %s %o %o\n", <library/object name>, <name>, <type>, <value>, <size>}}} > > {{{"%s%s %s %x %x\n", <library/object name>, <name>, <type>, <value>, <size>}}} In the event that Apple can't be bothered to fix this bug (I've had bad experience with Apple and standard-compliance in the past, hence my pessimism) we could try to workaround by using `nm -P -t x` when building on OSX... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #11724: Must check for representation polymorphism in datatype declarations
by GHC 01 Dec '16

01 Dec '16

#11724: Must check for representation polymorphism in datatype declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data Foo (r :: RuntimeRep) (a :: TYPE r) = Foo a }}} panics. It should error instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12668: Program that fails Core Lint terribly
by GHC 01 Dec '16

01 Dec '16

#12668: Program that fails Core Lint terribly -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While looking for a testcase for another unrelated compiler bug (see Phab:D2577) I had the pleasure of encountering this specimen, {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} module Hi where import GHC.Exts data Some r = Some (TYPE r -> TYPE r) doSomething :: forall (r :: RuntimeRep). forall (a :: TYPE r). () => Int -> (a -> Int) -> a -> a doSomething n f = case n of 1 -> error "hello" 3 -> error "hello" }}} GHC 465c6c5d15f8fb54afb78408f3a79e75e74d2cd4 seems to let this program typecheck, but if you enable Core Lint it soon becomes clear that not all is well. Here's a sampling of the carnage, {{{ $ ghc hi.hs -fforce-recomp -dcore-lint -O0 [1 of 1] Compiling Hi ( hi.hs, hi.o ) *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: In the type ‘a_a2ON -> Int’ Ill-kinded argument in type or kind ‘a_a2ON -> Int’ type or kind ‘a_a2ON -> Int’ kind: TYPE r_a2OM <no location info>: warning: In the type ‘a_a2ON -> a_a2ON’ Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM <no location info>: warning: In the type ‘a_a2ON -> a_a2ON’ Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM <no location info>: warning: In the expression: patError @ 'PtrRepLifted @ (a_a2ON -> a_a2ON) "hi.hs:(12,5)-(14,24)|case"# Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8848: Warning: Rule too complicated to desugar
by GHC 01 Dec '16

01 Dec '16

#8848: Warning: Rule too complicated to desugar ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've a very very modest application of Specialize to fixed sized lists in some of my code which seems to trip up the specialization machinery. Is there any flags I can pass GHC to make sure it doesn't give up on these specialize calls? is the only work around to write my own monomorphic versions and add some hand written rewrite rules?! {{{ rc/Numerical/Types/Shape.hs:225:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor_a3XB :: Functor (Shape ('S 'Z)) [LclId, Str=DmdType] $dFunctor_a3XB = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor_a3Rn } in map2 @ a @ b @ c @ ('S ('S 'Z)) (Numerical.Types.Shape.$fApplicativeShape @ ('S 'Z) (Numerical.Types.Shape.$fFunctorShape @ ('S 'Z) $dFunctor_a3XB) (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor_a3XB Numerical.Types.Shape.$fApplicativeShape0)) src/Numerical/Types/Shape.hs:226:1: Warning: RULE left-hand side too complicated to desugar let { $dFunctor_a3XG :: Functor (Shape ('S 'Z)) [LclId, Str=DmdType] $dFunctor_a3XG = Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor_a3Rn } in let { $dFunctor_a3XF :: Functor (Shape ('S ('S 'Z))) [LclId, Str=DmdType] $dFunctor_a3XF = Numerical.Types.Shape.$fFunctorShape @ ('S 'Z) $dFunctor_a3XG } in map2 @ a @ b @ c @ ('S ('S ('S 'Z))) (Numerical.Types.Shape.$fApplicativeShape @ ('S ('S 'Z)) (Numerical.Types.Shape.$fFunctorShape @ ('S ('S 'Z)) $dFunctor_a3XF) (Numerical.Types.Shape.$fApplicativeShape @ ('S 'Z) $dFunctor_a3XF (Numerical.Types.Shape.$fApplicativeShape @ 'Z $dFunctor_a3XG Numerical.Types.Shape.$fApplicativeShape0))) }}} the associated code (smashed into a single module ) is {{{ {-# LANGUAGE DataKinds, GADTs, TypeFamilies, ScopedTypeVariables #-} {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE CPP #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoImplicitPrelude #-} module Numerical.Types.Shape where import GHC.Magic import Data.Data import Data.Typeable() import Data.Type.Equality import qualified Data.Monoid as M import qualified Data.Functor as Fun import qualified Data.Foldable as F import qualified Control.Applicative as A import Prelude hiding (foldl,foldr,init,scanl,scanr,scanl1,scanr1) data Nat = S !Nat | Z deriving (Eq,Show,Read,Typeable,Data) #if defined(__GLASGOW_HASKELL_) && (__GLASGOW_HASKELL__ >= 707) deriving instance Typeable 'Z deriving instance Typeable 'S #endif type family n1 + n2 where Z + n2 = n2 (S n1') + n2 = S (n1' + n2) -- singleton for Nat data SNat :: Nat -> * where SZero :: SNat Z SSucc :: SNat n -> SNat (S n) --gcoerce :: (a :~: b) -> ((a ~ b) => r) -> r --gcoerce Refl x = x --gcoerce = gcastWith -- inductive proof of right-identity of + plus_id_r :: SNat n -> ((n + Z) :~: n) plus_id_r SZero = Refl plus_id_r (SSucc n) = gcastWith (plus_id_r n) Refl -- inductive proof of simplification on the rhs of + plus_succ_r :: SNat n1 -> Proxy n2 -> ((n1 + (S n2)) :~: (S (n1 + n2))) plus_succ_r SZero _ = Refl plus_succ_r (SSucc n1) proxy_n2 = gcastWith (plus_succ_r n1 proxy_n2) Refl type N0 = Z type N1= S N0 type N2 = S N1 type N3 = S N2 type N4 = S N3 type N5 = S N4 type N6 = S N5 type N7 = S N6 type N8 = S N7 type N9 = S N8 type N10 = S N9 {- Need to sort out packed+unboxed vs generic approaches see ShapeAlternatives/ for -} infixr 3 :* {- the concern basically boils down to "will it specialize / inline well" -} newtype At a = At a deriving (Eq, Ord, Read, Show, Typeable, Functor) data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a --deriving (Show) #if defined(__GLASGOW_HASKELL_) && (__GLASGOW_HASKELL__ >= 707) deriving instance Typeable Shape #endif instance Eq (Shape Z a) where (==) _ _ = True instance (Eq a,Eq (Shape s a))=> Eq (Shape (S s) a ) where (==) (a:* as) (b:* bs) = (a == b) && (as == bs ) instance Show (Shape Z a) where show _ = "Nil" instance (Show a, Show (Shape s a))=> Show (Shape (S s) a) where show (a:* as) = show a ++ " :* " ++ show as -- at some point also try data model that -- has layout be dynamicly reified, but for now -- keep it phantom typed for sanity / forcing static dispatch. -- NB: may need to make it more general at some future point --data Strided r a lay = Strided { getStrides :: Shape r a } {-# INLINE reverseShape #-} reverseShape :: Shape n a -> Shape n a reverseShape Nil = Nil reverseShape list = go SZero Nil list where go :: SNat n1 -> Shape n1 a-> Shape n2 a -> Shape (n1 + n2) a go snat acc Nil = gcastWith (plus_id_r snat) acc go snat acc (h :* (t :: Shape n3 a)) = gcastWith (plus_succ_r snat (Proxy :: Proxy n3)) (go (SSucc snat) (h :* acc) t) instance Fun.Functor (Shape Z) where fmap = \ _ Nil -> Nil --{-# INLINE fmap #-} instance (Fun.Functor (Shape r)) => Fun.Functor (Shape (S r)) where fmap = \ f (a :* rest) -> f a :* Fun.fmap f rest --{-# INLINE fmap #-} instance A.Applicative (Shape Z) where pure = \ _ -> Nil --{-# INLINE pure #-} (<*>) = \ _ _ -> Nil --{-# INLINE (<*>) #-} instance A.Applicative (Shape r)=> A.Applicative (Shape (S r)) where pure = \ a -> a :* (A.pure a) --{-# INLINE pure #-} (<*>) = \ (f:* fs) (a :* as) -> f a :* (inline (A.<*>)) fs as --{-# INLINE (<*>) #-} instance F.Foldable (Shape Z) where foldMap = \ _ _ -> M.mempty --{-# fold #-} foldl = \ _ init _ -> init foldr = \ _ init _ -> init foldr' = \_ !init _ -> init foldl' = \_ !init _ -> init instance (F.Foldable (Shape r)) => F.Foldable (Shape (S r)) where foldMap = \f (a:* as) -> f a M.<> F.foldMap f as foldl' = \f !init (a :* as) -> let next = f init a in next `seq` F.foldl f next as foldr' = \f !init (a :* as ) -> f a $! F.foldr f init as foldl = \f init (a :* as) -> let next = f init a in F.foldl f next as foldr = \f init (a :* as ) -> f a $ F.foldr f init as -- map2 :: (A.Applicative (Shape r))=> (a->b ->c) -> (Shape r a) -> (Shape r b) -> (Shape r c ) map2 = \f l r -> A.pure f A.<*> l A.<*> r {-# SPECIALIZE map2 :: (a->b->c)-> (Shape Z a )-> Shape Z b -> Shape Z c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S Z) a )-> Shape (S Z) b -> Shape (S Z) c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S (S Z)) a )-> Shape (S (S Z)) b -> Shape (S (S Z)) c #-} {-# SPECIALIZE map2 :: (a->b->c)-> (Shape (S (S(S Z))) a )-> Shape (S (S (S Z))) b -> Shape (S (S(S Z))) c #-} -- {-# INLINABLE map2 #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 01 Dec '16

01 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): If somebody wants to enjoy the benefits of `-split-sections` vs `-split- objs` (they are tremendous) '''immediately''', she has the following options: 1. I could try to put linker script patches to upstream `binutils`. Honestly, I don't want to bother with this ATM; 2. I could publish these patches for those interested to build their own `binutils`; 3. I could publish linker scripts which could be used with existing `binutils`. Since all options require (at least) to modify any existing build scripts, I believe that, perhaps, the option 3 might be the most welcomed one. OTOH, options 2 and 3 require more involvement than the first one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12901: Levity polymorphic expressions mustn't be floated out
by GHC 01 Dec '16

01 Dec '16

#12901: Levity polymorphic expressions mustn't be floated out -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have been trying to add the following code into GHC: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} pattern AppOp1 :: PrimOp -> Arg CoreBndr -> CoreExpr pattern OpVal :: PrimOp -> Arg CoreBndr pattern AppOp1 op x = App (OpVal op) x pattern OpVal op <- Var (isPrimOpId_maybe -> Just op) where OpVal op = Var (mkPrimOpId op) }}} It triggers the following CoreLint error: {{{ <no location info>: warning: [RHS of lvl_spfb :: r] RuntimeRep-polymorphic binder: lvl_spfb :: (r :: TYPE rep) }}} Indeed: {{{#!hs $mAppOp1 :: forall (r :: TYPE rep). CoreExpr -> (PrimOp -> Arg CoreBndr -> r) -> (Void# -> r) -> r [LclIdX, Arity=3] $mAppOp1 = \ (@ (rep_agRe :: RuntimeRep)) (@ (r_agRf :: TYPE rep)) (scrut_agRh :: CoreExpr) (cont_agRi :: PrimOp -> Arg CoreBndr -> r) (fail_agRj :: Void# -> r) -> let { fail_spbW :: Void# -> r [LclId, Arity=1] fail_spbW = \ _ [Occ=Dead, OS=OneShot] -> fail_agRj void# } in let { lvl_spfb :: r [LclId] lvl_spfb = fail_spbW void# } in case scrut_agRh of { __DEFAULT -> fail_spbW void#; App ds_dj2u x_afoV -> $mOpVal @ rep @ r ds_dj2u (\ (op_afoU :: PrimOp) -> cont_agRi op_afoU x_afoV) (\ _ [Occ=Dead] -> lvl_spfb) }}} According to the levity polymorphism paper `lvl_spfb` shouldn't have been floated out in a let-binding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12865: POSIX osDecommitMemory has nasty compatibility problems
by GHC 01 Dec '16

01 Dec '16

#12865: POSIX osDecommitMemory has nasty compatibility problems ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- `osDecommitMemory` in `rts/posix/OSMem.c` currently does the following, {{{#!c #ifdef MADV_FREE // Try MADV_FREE first, FreeBSD has both and MADV_DONTNEED // just swaps memory out r = madvise(at, size, MADV_FREE); #else r = madvise(at, size, MADV_DONTNEED); #endif if(r < 0) sysErrorBelch("unable to decommit memory"); }}} As it turns out, the Linux kernel as of 4.5 supports `MADV_FREE`. This means that binary distributions built in such environments will use `MADV_FREE`, even if running on an older kernel that does not support this advice. Ultimately this means that any attempt to decommit will fail. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12865> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9184: Allow the use of Python 3 when building GHC
by GHC 01 Dec '16

01 Dec '16

#9184: Allow the use of Python 3 when building GHC -------------------------------------------+------------------------------- Reporter: aspidites | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: python | 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: -------------------------------------------+------------------------------- According to the [https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows wiki], it is preferred that a user have Python 2.7 installed before attempting to build GHC. As I'm on Arch Linux the default Python version is 3.4. As such, rather than simply changing the shebang line to explicitly ask for version 2, I made it so that the scripts all use syntax that works properly for versions 2.7 to 3.4. I don't think I've used anything that disallows 2.6, but don't have that version available to check against. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 01 Dec '16

01 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Well, things are absolutely OK with `-split-sections` for 64-bit PECOFF obj files, but there exist a critical problem for the 32-bit case. The problem is that to realistically work with `-split-sections` (even to build `GHC` itself, particularly `template-haskell` package, particularly `Language.Haskell.TH.Syntax` module compiled in profiling mode) we need `big-obj` support (to have more than 32K sections per object file), but `binutils` '''has no''' `big-obj` support for 32-bit PECOFF object files. Perhaps, the simplest solution would be to have another splitter, which would split the whole assembly to chunks with no more than 32K sections in each. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12886: Proposal for throwLeft and throwLeftIO in Control.Exception
by GHC 01 Dec '16

01 Dec '16

#12886: Proposal for throwLeft and throwLeftIO in Control.Exception -------------------------------------+------------------------------------- Reporter: yfeldblum | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There already exist some functions to translate between `Maybe` and `Exception`, and between `Either` and `Exception` in the module `Control.Exception`. Given an API like: {{{#!hs data MyException --... instance Exception MyException --... myUsefulFunction :: a -> b -> c -> Either MyException d myUsefulAction :: a -> b -> c -> IO (Either MyException d) }}} It sometimes the case that calling code that cannot sensibly handle `Left` results directly. This proposal is to add standard library functions that let calling code easily to turn `Left` results into thrown runtime exceptions, which might be caught and handled further up the call stack. {{{#!hs throwLeft :: Exception e => Either e a -> a throwLeftIO :: Exception e => Either e a -> IO a }}} Note that examples of functions named `throwLeft` may be found in the wild: https://www.stackage.org/lts-7.10/hoogle?q=throwLeft. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12886> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4