- ghc-tickets - Haskell.org

[GHC] #14049: relax -Wmissing-import-lists to allow one module without implicit imports when using NoImplicitPrelude
by GHC 28 Jul '17

28 Jul '17

#14049: relax -Wmissing-import-lists to allow one module without implicit imports when using NoImplicitPrelude -------------------------------------+------------------------------------- Reporter: cdepillabout | Owner: (none) Type: feature | Status: new request | Priority: normal | 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: -------------------------------------+------------------------------------- It would be nice to modify the `-Wmissing-import-lists` warning flag to allow one module with implicit imports when using the `NoImplicitPrelude` pragma. For example, imagine the following program: {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} module Main where import MyCustomPrelude import Control.Monad.Trans.Reader (Reader, runReader) what :: Reader Int String -> String what x = runReader x 3 main :: IO () main = print "hello" }}} If this program is compiled with the `-Wmissing-import-lists` flag, the following warning will be produced: {{{ example.hs:5:1: warning: [-Wmissing-import-lists] The module ‘MyCustomPrelude’ does not have an explicit import list }}} I think it would be nice if this warning did not appear. Ideally, when using `NoImplicitPrelude` and `-Wmissing-import-lists` together, I would want one import per module to be permitted not to be explicit. This would make it possible to use an alternative Prelude and `-Wmissing-import-lists` at the same time. Alternatively, a new warning flag could be created with the above behavior. Maybe it could be called something like `-Wmulti-implicit- imports` or `-Wmulti-open-imports`. I would appreciate feedback/suggestions for the name. ---- PureScript currently works like I have described above. By default the `Prelude` module is not imported (so you must explicitly import it), and the compiler will warn you if you have more than one implicit import. I really like this combination and it would be nice to be able to get the same thing in Haskell. In case anyone is interested, [https://github.com/purescript/purescript/issues/1869 here] is the issue for PureScript where they talked about making this change. ---- If it seems like this is a good idea and other people are onboard, I'd be willing to implement it. I think it would be a relatively easy change, so it would be good for a first-time contributor. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 28 Jul '17

28 Jul '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): jscholl, I'd like to participate on the proposal, bgamari mentioned above. I really think we (= community) should design this properly, as you mentioned `Addr#` and `ByteArray#` are confusing. Also Unicode/encodings add some complexity. The reward, is that we can close many tickets (at least #11312 with "single" change. I still try to wrap my head around internals, and my friends' weading is in 20 hours, so I'll return to this only next week -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:76> 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 28 Jul '17

28 Jul '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): jscholl, I was speaking to phadej yesterday and he also sounded interested in looking at this problem. Regardless of what happens, this is a change to the user-facing interface provided by the compiler and consequently falls under the [[https://github.com/ghc-proposals/ghc-proposals|GHC proposal process]]. Do you think you could write a proposal explaining your approach? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:75> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13768: Incorrect warnings generated by exhaustiveness checker with pattern synonyms / GADT combination
by GHC 28 Jul '17

28 Jul '17

#13768: Incorrect warnings generated by exhaustiveness checker with pattern synonyms / GADT combination -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- The module {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE ViewPatterns #-} module PatSynEx where data NS (f :: k -> *) (xs :: [k]) = NS Int data IsNS (f :: k -> *) (xs :: [k]) where IsZ :: f x -> IsNS f (x ': xs) IsS :: NS f xs -> IsNS f (x ': xs) isNS :: NS f xs -> IsNS f xs isNS = undefined pattern Z :: () => (xs' ~ (x ': xs)) => f x -> NS f xs' pattern Z x <- (isNS -> IsZ x) pattern S :: () => (xs' ~ (x ': xs)) => NS f xs -> NS f xs' pattern S p <- (isNS -> IsS p) {-# COMPLETE Z, S #-} data SList :: [k] -> * where SNil :: SList '[] SCons :: SList (x ': xs) go :: SList ys -> NS f ys -> Int go SCons (Z _) = 0 go SCons (S _) = 1 go SNil _ = error "inaccessible" }}} produces the following warnings with both GHC 8.2 and 8.3: {{{ PatSynEx.hs:31:1: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In an equation for ‘go’: go SCons (Z _) = ... | 31 | go SCons (Z _) = 0 | ^^^^^^^^^^^^^^^^^^ PatSynEx.hs:32:1: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘go’: go SCons (S _) = ... | 32 | go SCons (S _) = 1 | ^^^^^^^^^^^^^^^^^^ }}} Neither warning seems correct. The first case is not inaccessible, the second case is not redundant. The catch-all case has always been required with GHC even though it is not really reachable, but that's not the subject of this issue. I tried to simplify the issue further by getting rid of the `f` argument in `NS` and `IsNS`, but that made the issue disappear. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13768> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2893: Implement "Quantified contexts" proposal
by GHC 28 Jul '17

28 Jul '17

#2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > See: http://haskell.org/haskellwiki/Quantified_contexts > > Motivating example is collapsing insomeway-identical classes such as > Monoid and MonadPlus into a single class (with accompanying functions). New description: See: [wiki:QuantifiedContexts] -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2893#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12018: Equality constraint not available in pattern type signature (GADTs/ScopedTypeVariables)
by GHC 28 Jul '17

28 Jul '17

#12018: Equality constraint not available in pattern type signature (GADTs/ScopedTypeVariables) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: GADTs, | Operating System: Unknown/Multiple ScopedTypeVariables | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data Exp a where Tru :: Ty Bool eval :: Exp a -> a eval Tru = True }}} Works fine, as does {{{#!hs eval :: Exp a -> a eval (Tru :: Exp _) = True }}} But {{{#!hs eval :: Exp a -> a eval (Tru :: Exp Bool) = True }}} doesn't, is this an intended design of GADTs/ScopedTypeVariables that the type equality constraint isn't in scope in the type signature of the pattern match, I would like to match on an existential type in my own code: {{{#!hs compile (ArrIx arr index :: Exp (Sca elt)) = do ... }}} It can be worked around by writing: {{{#!hs eval a@Tru = case a :: Exp Bool of }}} but for my own code it seems I must write {{{#!hs compile uuu@(ArrIx arr index :: Exp a) = do case uuu :: (a ~ Sca elt) => Exp (Sca elt) of }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 28 Jul '17

28 Jul '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): Thinking about the problem again I decided to try to add {{{ByteArray#}}} literals to GHC. The idea is the following: - Use {{{"foo"##}}} as syntax for {{{ByteArray#}}}s. This is in essence my try for a {{{String#}}} type. - Provide {{{#!haskell unpackStringLit# :: ByteArray# -> [Char] {-# INLINE[1] unpackStringLit# #-} unpackStringLit# ba# = unpackCStringWithLen# (byteArrayContents# ba#) (sizeofByteArray# ba#) }}} - Compile {{{"foo"}}} as {{{unpackStringLit# "foo"##}}} - Let rewrites fire in phase 2. - In phase 1, inline {{{unpackStringLit#}}} and let rules rewrite it to {{{unpackCStringWithLen# "foo"# 3#}}} - Thus most {{{ByteArray#}}}s should get eliminated and binary size should stay more or less the same. - If someone rewrites something like {{{ByteString.pack (unpackStringLit# lit)}}}, the literal is not eliminated and emitted to the binary. Thus a {{{ByteString}}} literal can increase binary size. However, I think this is what we want because we save making a copy of the data. - The downside is that turning optimization off causes the compiler to create a {{{ByteArray#}}} for every string literal instead of a c-string. GHCi will also allocate {{{ByteArray#}}}s instead of string literals directly. I currently implemented the new literal type, extended the parser, changed the desugaring, added the needed rules, taught GHCi to handle {{{ByteArray#}}} literals, and generated cmm Code for them. I still have to look at all parts involved for fusion and other string rules to work, check how the change affects bootstrapping with an older compiler, take a look at template haskell, and whether there are any typeable/generic things involved. I don't know how everyone feels about adding another literal type (especially because there are now two similar types, {{{Addr#}}} and {{{ByteArray#}}}, but if we want to keep binary sizes down, we need some form of {{{Addr#}}}, and it seems like having {{{ByteArray#}}} is beneficial too). Or whether it is reasonable to provide syntax for {{{ByteArray#}}}s (letting the compiler generate them would be enough for this ticket). But right now implementing it like this feels a lot better than my previous approach using unboxed tuples. And I am sorry for not saying or doing anything such a long time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:74> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13430: Can't scope type variables when pattern matching on GADTs
by GHC 27 Jul '17

27 Jul '17

#13430: Can't scope type variables when pattern matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was very surprised that the following doesn't compile: {{{ {-# LANGUAGE GADTs, ScopedTypeVariables #-} data Foo x where A :: Foo Bool B :: Foo Int foo :: Foo x -> () foo (A :: Foo Bool) = () }}} GHC says that it couldn't match the type `y` with `Bool`. See [this question](http://stackoverflow.com/questions/42824949/type-inference-with- gadts) for a simple motivating example. As someone there pointed out, the situation would be improved with type application (#11350), but this ticket is about bringing the output type in scope with `ScopedTypeVariables`. This most closely reminds me of #1823 (!), but that was resolved many moons ago. This behavior also exists in 7.10.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13940: Reduce duplicate implementations of argument handling on Windows
by GHC 27 Jul '17

27 Jul '17

#13940: Reduce duplicate implementations of argument handling on Windows ----------------------------------------+--------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Runtime System | Version: Keywords: unicode windows | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #12870 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- On windows we currently ignore arguments to hs_init/main's argv and instead get the arguments from the windows api when they are requested from the Haskell side. This means * Passing custom arguments to hs_init when not using hs_main might behave unexpected (The haskell und RTS side see different arguments). * Duplication of code to simulate filtering of Arguments by the RTS on the Haskell side. * Behavior between Linux and Windows might differ as result of the above (eg #13287) Instead we can get the UTF16 encoded arguments inside of hs_main from the windows API and pass them along to the RTS UTF8-encoded. This allows argument handling to be fairly uniform between Linux and Windows and enables us to accept hs_init arguments on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12369: data families shouldn't be required to have return kind *, data instances should
by GHC 27 Jul '17

27 Jul '17

#12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- I'd like to be able to define {{{#!hs {-# language PolyKinds, KindSignatures, GADTs, TypeFamilies #-} data family Fix :: (k -> *) -> k newtype instance Fix f = In { out :: f (Fix f) } }}} But currently this is disallowed: {{{ Fix.hs:2:1: error: • Kind signature on data type declaration has non-* return kind (k -> *) -> k • In the data family declaration for ‘Fix’ }}} Ultimately I think the issue here is that data __instances__ should be required to end in kind *, not the families, but this generalization didn't mean anything until we had `PolyKinds`. As an example of a usecase, with the above, I could define a bifunctor fixed point such as {{{#!hs newtype instance Fix f a = In2 { out2 :: f (Fix f a) a } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15