- ghc-tickets - Haskell.org

[GHC] #11080: Open data kinds
by GHC 07 May '18

07 May '18

#11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- When we need type level symbols, we used to only have one option, `EmptyDataDecls`. The symbolic type parameters would be given kind `*`, but the convention would be to use types that are (mostly) uninhabited and that were made for the purpose of serving as symbols. For an example of this see http://hackage.haskell.org/package/servant-0.4.4.5/docs/Servant- API-ContentTypes.html. Now we also have the `Symbol` kind which can serve a similar purpose. Neither of these options is fully satisfactory for examples like servant's type-level encoding of content types, or the `units` libraries type-level encoding of physical dimensions, for the following reasons: We would prefer to give these types a kind other than `*` both because they are uninhabited and because we wish to provide documentation of what types are acceptable in these parameter positions. But the only facility we have for creating new kinds is `DataKinds`, and the kinds it creates are all closed. This is problematic because we wish to allow client modules to declare new content types or new physical dimensions. We could provide "newkind" wrappers around `Symbol` using `DataKinds`, but that runs in to name collision issues. The `EmptyDataDecls` solution is superior here because types with the same name declared in different modules remain distinct. Instead I propose the addition of a new feature where data kinds can be open. In a discussion at https://github.com/bjornbm/dimensional-dk/issues/96 in which @goldfire participated, we arrived at the following proposal for concrete syntax, but certainly there are many possible variations one could imagine which might have equal or greater merit: {{{#!hs -- declares a new kind which initially has no inhabitants data open ContentType -- declares a new type of kind ContentType, which is distinct -- from any others that may have been declared elsewhere, -- even if they have the same non-module-qualified name data constructor JSON :: ContentType }}} (@goldfire raised the possibility of one day interpreting the same `data constructor ...` syntax at the type level to declare inhabited types for which some constructors are defined in one module but which are open to extension with new constructors by other modules, but that is a distinct issue in all other ways apart from possibly wishing to share syntax.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11080> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 07 May '18

07 May '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * owner: (none) => tdammers -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 07 May '18

07 May '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): The relevant Core for the unoptimized run: {{{ main = evaluate (deepseq ($fNFData[] $fNFDataChar) (: (C# 'a'#) (undefined ((pushCallStack (unpackCString# "undefined"#, SrcLoc (unpackCString# "main"#) (unpackCString# "Main"#) (unpackCString# "example.hs"#) (I# 4#) (I# 25#) (I# 4#) (I# 34#)) emptyCallStack) `cast` <Co:4>))) (return $fMonadIO ())) }}} As expected, `deepseq` is retained. However, in the optimized version, we get this: {{{ Rec { main_go main_go = \ ds_a2Nc -> case ds_a2Nc of { [] -> (); : x_a2Ng xs_a2Nh -> case x_a2Ng of { C# ipv_s2Np -> main_go xs_a2Nh } } end Rec } main2 main2 = undefined (lvl10_r4dT `cast` <Co:4>) lvl11_r4dU lvl11_r4dU = C# 'a'# lvl12_r4dV lvl12_r4dV = : lvl11_r4dU main2 lvl13_r4dW lvl13_r4dW = \ eta_B1 -> case main_go lvl12_r4dV of { () -> (# eta_B1, () #) } main1 main1 = \ s_a2Nw -> (# s_a2Nw, lvl13_r4dW `cast` <Co:3> #) }}} (boilerplate stripped for clarity) Which, IIUC, does not respect the spirit of `deepseq` - specifically, the list construction in `lvl12_r4dV` isn't strict, so the `undefined` that `main2` produces isn't being forced. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 07 May '18

07 May '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Compiling on GHC HEAD reproduces the problem: `../ghc/HEAD/_build/stage1/bin/ghc example.hs -fforce-recomp -O` produces a program that runs without error, while `../ghc/HEAD/_build/stage1/bin/ghc example.hs -fforce-recomp` behaves as it should. Comparing simplified Core shows that with `-O`, `deepseq` no longer appears in the output, so it seems that inlining `deepseq` is part of the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11953: Export Word32#, Word64# on all architectures
by GHC 06 May '18

06 May '18

#11953: Export Word32#, Word64# on all architectures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Currently we have no always-available fixed-width primitive types. For instance, if you want a 64-bit unsigned integer you need to use `Word#` on 64-bit targets and `Word32#` otherwise. This adds a fair bit of complexity in places which really should be simple (e.g. `Data.Word`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11953> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments.
by GHC 06 May '18

06 May '18

#14927: Hyperbolic area sine is unstable for (even moderately) big negative arguments. -------------------------------------+------------------------------------- Reporter: | Owner: (none) leftaroundabout | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `asinh` is supposed to be the inverse of `sinh`, and this works pretty reliable for positive arguments. However, for negative arguments, the [http://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.Float.html#li… currently used formula] {{{ asinh x = log (x + sqrt (1.0+x*x)) }}} gets unstable much earlier than necessary, namely when the summands in the logarithm cancel almost to zero, dominated by the numerical error of the square root. This is particularly troubling because mathematically **a)** `asinh` is a very “inert” function (i.e. you can carelessly put in huge numbers and – as long as they're not outright `Infinity` – always get a somewhat sane result), pseudo-sigmoidal as it were **b)** it is an ''odd function'', fulfilling `asinh (-x) = -asinh x`. Both is reflected in other implementations, e.g. Python, but not in GHC Haskell: {{{ GHCi, version 8.2.1 Python 3.5.2 (default, Nov 23 2017, 16:37:01) In [1]: from math import * Prelude> asinh 1e6 In [2]: asinh(1e6) 14.50865773852447 Out[2]: 14.50865773852447 Prelude> asinh (-1e6) In [3]: asinh(-1e6) -14.50865012405984 Out[3]: -14.50865773852447 Prelude> asinh 1e9 In [4]: asinh(1e9) 21.416413017506358 Out[4]: 21.416413017506354 Prelude> asinh (-1e9) In [5]: asinh(-1e9) -Infinity Out[5]: -21.416413017506354 Prelude> asinh 1e76 In [6]: asinh(1e76) 175.6896142481074 Out[6]: 175.68961424810743 Prelude> asinh (-1e76) In [7]: asinh(-1e76) -Infinity Out[7]: -175.68961424810743 }}} Demo of non-inverse property: {{{ Prelude> [(x, asinh $ sinh x) | x <- [-25..25]] [(-25.0,-Infinity) ,(-24.0,-Infinity) ,(-23.0,-Infinity) ,(-22.0,-Infinity) ,(-21.0,-Infinity) ,(-20.0,-Infinity) ,(-19.0,-18.021826694558577) ,(-18.0,-18.021826694558577) ,(-17.0,-17.0102257828801) ,(-16.0,-15.998624871201619) ,(-15.0,-14.999878578873695) ,(-14.0,-13.999968823323222) ,(-13.0,-12.999991335176079) ,(-12.0,-12.000000137072186) ,(-11.0,-10.999999903206444) ,(-10.0,-10.000000013503529) ,(-9.0,-9.000000000551713) ,(-8.0,-8.00000000017109) ,(-7.0,-7.000000000036329) ,(-6.0,-5.999999999998066) ,(-5.0,-5.000000000000641) ,(-4.0,-4.000000000000046) ,(-3.0,-2.999999999999989) ,(-2.0,-1.9999999999999991) ,(-1.0,-1.0) ,(0.0,0.0) ,(1.0,1.0) ,(2.0,2.0) ,(3.0,3.0) ,(4.0,4.0) ,(5.0,5.0) ,(6.0,6.0) ,(7.0,7.0) ,(8.0,8.0) ,(9.0,9.0) ,(10.0,10.0) ,(11.0,11.0) ,(12.0,12.0) ,(13.0,13.0) ,(14.0,14.0) ,(15.0,15.0) ,(16.0,16.0) ,(17.0,17.0) ,(18.0,18.0) ,(19.0,19.0) ,(20.0,20.0) ,(21.0,21.0) ,(22.0,22.0) ,(23.0,23.0) ,(24.0,24.0) ,(25.0,25.0)] }}} Those results are less than satisfying, even for inputs that aren't astronomically big at all. A simple fix would be to “copy” the sane positive-number behaviour to the negative side: {{{ asinh x | x < 0 = -asinh (-x) | otherwise = log (x + sqrt (1.0+x*x)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14927> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15123: mg_arg_tys in MatchGroup should be a PostTc field
by GHC 05 May '18

05 May '18

#15123: mg_arg_tys in MatchGroup should be a PostTc field -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It appears that `mg_arg_tys` is only populated after typechecking but the type does not indicate this. Instead of {{{ mg_arg_tys :: [PostTc p Type] }}} the type should be {{{ mg_arg_tys :: PostTc p [Type] }}} All that needs doing is modifying this type in compiler/HsSyn/HsExpr.hs and then fixing the resulting compiler errors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15082: Split the TrieMap module into a generic and core specific part.
by GHC 05 May '18

05 May '18

#15082: Split the TrieMap module into a generic and core specific part. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4618 | Wiki Page: -------------------------------------+------------------------------------- == Split the module into two parts. Motivation: I came across a situation where I would have liked to make LabelMap a instance of TrieMap. However this would create a transitive dependency on CoreSyn for essentially all Cmm related Modules which seemed excessive. Splitting TrieMap into a general and Core specific part changes this. It also leads to a nicer separation of concerns. I have implemented a first version of this in D4618. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14982: LLVM default -mcpu setting inhibits customization
by GHC 05 May '18

05 May '18

#14982: LLVM default -mcpu setting inhibits customization -------------------------------------+------------------------------------- Reporter: tommd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (LLVM) | 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: -------------------------------------+------------------------------------- With GHC 8.4.1 we are now passing a default `-mcpu` selection to llvm. This default is passed regardless of any explicit command line option such as `-optlc=-mcpu=native`. If/when the user explicitly specifies the architecture we now get a failed build. The error message from LLVM is: {{{ llc: for the -mcpu option: may only occur zero or one times! `llc' failed in phase `LLVM Compiler'. (Exit code: 1) }}} This is when compiling with GHC 8.4.1 as such: {{{ ghc-8.4.1 -fforce-recomp -fllvm -optlc=-mcpu=native -O2 tt.hs }} I suggest we either check for a user option of `mcpu` before adding the default or revert this behavior and allow llvm to take it's (optimistic and less portable) default. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8995: When generalising, use levels rather than global tyvars
by GHC 05 May '18

05 May '18

#8995: When generalising, use levels rather than global tyvars ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A long time ago Didier Remy described how to use 'ranks' or 'levels' to make the test "is this type variable free in the environment" when generalising a type. Oleg gives a [http://okmij.org/ftp/ML/generalization.html great explanation here]. GHC still uses the old "find the free type variables in the environment" method. But in fact GHC ''does'' maintain levels, just as Didier explains. The level is called `Untouchables` and is used to make sure we don't infer non-principal types for things involving GADTs. The same level stuff is used to prevent skolem-escape. Details with `Note [Untouchable type variables]` and `Note [Skolem escape prevention]` in `TcType`. So it ought to be straightforward to use the same levels for generalisation. I had a go, and came across the following tricky points: * We need to bump the level (`pushUntouchables`) when starting to typecheck a let RHS. Currently we don't. That will be a bit less efficient, because we'll end up deferring unification constraints that currently get solved immediately. * However the current set up is actually wrong. In particular, we generate a constraint where the implications do not have monotonically increasing level numbers (invariant `(ImplicInv)` in `TcType`). Try this program with `-ddump-tc-trace`. {{{ {-# LANGUAGE GADTs #-} module Bar where data T where MkT :: a -> (a->Int) -> T f x z = case x of MkT _ _ -> let g y = (y, [z,Nothing]) in (g True, g 'c') }}} I don't know how to make this bug cause an actual problem, but it's very unsettling. Bumping the level before doing the RHS would solve this. * Once we have bumped the level, we then have to do some more type- variable promotion, especially of type variables free in the finally- chosen type of the binder. This came out rather awkwardly in the code. * Because we now get more deferred equality constraints, there's a real risk that we'll end up quantifying over them. If we get, say `(gbl ~ Maybe lcl)`, where `gbl` is a type var free in the envt, we '''do not''' want to quantify over it! (It would be sound, but would lead to horrible types.) A long time ago Didier Remy described how to use 'ranks' or 'levels' to make the test "is this type variable free in the environment" when generalising a type. Oleg gives a [http://okmij.org/ftp/ML/generalization.html great explanation here]. GHC still uses the old "find the free type variables in the environment" method. But in fact GHC ''does'' maintain levels, just as Didier explains. The level is called `Untouchables` and is used to make sure we don't infer non-principal types for things involving GADTs. The same level stuff is used to prevent skolem-escape. Details with `Note [Untouchable type variables]` and `Note [Skolem escape prevention]` in `TcType`. So it ought to be straightforward to use the same levels for generalisation. I had a go, and came across the following tricky points: * We need to bump the level (`pushUntouchables`) when starting to typecheck a let RHS. Currently we don't. That will be a bit less efficient, because we'll end up deferring unification constraints that currently get solved immediately. * However the current set up is actually wrong. In particular, we generate a constraint where the implications do not have monotonically increasing level numbers (invariant `(ImplicInv)` in `TcType`). Try this program with `-ddump-tc-trace`. {{{ {-# LANGUAGE ExistentialQuantification #-} module Bar where data T = forall a. MkT a f x z = case x of MkT y -> let g y = [y,Nothing] in g True }}} Look for the `reportUnsolved` trace and you'll nested implications, both with level 1. I don't know how to make this bug cause an actual problem, but it's very unsettling. Bumping the level before doing the RHS would solve this. * Once we have bumped the level, we then have to do some more type- variable promotion, especially of type variables free in the finally- chosen type of the binder. This came out rather awkwardly in the code. * Because we now get more deferred equality constraints, there's a real risk that we'll end up quantifying over them. If we get, say `(gbl ~ Maybe lcl)`, where `gbl` is a type var free in the envt, we '''do not''' want to quantify over it! (It would be sound, but would lead to horrible types.) Rather we want to promote `lcl`, and not quantify. Currently we don't get many deferred equality constraints, becuase they all get done "on the fly". But if we do get one, we do quantify over it, which yields a rather stupid type. Try this: {{{ {-# LANGUAGE ExistentialQuantification #-} module Bar where data T = forall a. MkT a f x z = case x of MkT _ -> let g y = [z,Nothing] in (g True, g 'c') }}} We get this `g :: forall t a2. Maybe a ~ Maybe a2 => t -> [Maybe a2]`, where `x::a` is in the envt. Not very clever! This only shows up with existentials and In general I think we want to find all the type variables reachable by equality constraints from the environment, and not quantify over them. * We also use the type environment `getGlobalTyVars` in ''kind'' generalisation, and kind inference currently does not use the untoucahble story. Adapting it to use levels might be tricky because we currently assume we solve all kind equality constraints on-the-fly, and don't gather any deferreed constraints. Maybe it's easy, but needs thought. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5