- ghc-tickets - Haskell.org

Re: [GHC] #4426: Simplify the rules for implicit quantification
by GHC 12 Sep '13

12 Sep '13

#4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7880 -------------------------------------+------------------------------------ Changes (by monoidal): * difficulty: => Unknown * related: => #7880 Comment: See also comments at #7880. This change is not hard (I had a very rough sketch that detected ~4 missing quantifier errors in GHC tree) but it's too late for 7.8. Maybe I'll do it such that 7.10 will give a warning and 7.12 an error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4426#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7880: Require "forall" in definitions of polymorphic types
by GHC 12 Sep '13

12 Sep '13

#7880: Require "forall" in definitions of polymorphic types ------------------------------------------------+-------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: I see this exact proposal was created earlier: #4426. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7880#comment:7> 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 12 Sep '13

12 Sep '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: quchen Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by milan): * cc: fox@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7633: Checkable "minimal complete definitions"
by GHC 12 Sep '13

12 Sep '13

#7633: Checkable "minimal complete definitions" -------------------------------------+------------------------------------ Reporter: shachaf | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #6028 -------------------------------------+------------------------------------ Changes (by twanvl): * status: new => patch Comment: I found some time to polish the patch. I tried to address the points mentioned on this ticket. * The pragma is now parsed as a Sig instead of a separate declaration. * The minimal complete definitions are now specified with a boolean formula. For example {{{ {-# MINIMAL return, ((>>=) | (join,fmap)) #-} }}} * A warning is generated if the MINIMAL pragma does not cover all methods without defaults. * I have added documentation to the user_guide. * I have added some tests to the testsuite. The things I did not do: * dmwit sugested that the check should also extend to parent classes. I did not implement this, because it would complicate the patch significantly. Right now names are resolved locally to a class, and the information about whether a method is implemented is also kept per instance. * simonpj sugested that the check be moved from the typechecker to the renamer. However, to check that an instance satisfies the minimal complete definition, you need the `Class`. But that is only known after (or during) typechecking. The typechecker also does things like collecting default implementations. All of that is needed before the minimal complete check can be performed. In the end the in `TcInstDcl` check is only a couple of lines, I doubt it can be done much simpler. Some other remarks: * I put the function `defaultClassMinimalDef`, which constructs a default minimal complete definition, in `BuildTyCl`. It would be more at home in `TcClassDcl`. But there is also a function in vectorize that constructs Classes and so it also needs defaultClassMinimalDef. * I had to change the interface format. So a full rebuild is needed. * It would be nice to include the minimal complete definitions in Haddock documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7633#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5289: Can't use ghci with a library linked against libstdc++
by GHC 12 Sep '13

12 Sep '13

#5289: Can't use ghci with a library linked against libstdc++ -------------------------------------+------------------------------------ Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by MichalGajda): On Windows, this bug seems also to prevent linking libraries that depend on double-conversion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5289#comment:48> 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 12 Sep '13

12 Sep '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: quchen Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Let me clarify what my concern here is: there are two ways to future proof your code against the upcoming export of `join` et al in 7.10: * Rename your local `join` function. * Hide the import from the `Prelude` (this is what the example above does). Both will work when 7.10 comes around. The problem is that the warning is overly trigger-happy; it warns if you go for option 2. Since people like to have warning free code, this means that in practice you have to go with the first option. There might be a good reason to have a function called `join` in your module, just like there might be a good reason to have a function called `map` (or any other `Prelude` name). I think the warning should be fixed such that it only happens if the code would actually break in 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:16> 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 12 Sep '13

12 Sep '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: quchen Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * cc: johan.tibell@… (added) Comment: We're now seeing this warning in containers, but the obvious fix (hide `join` from the Prelude) does silence it! I expect this module to not generate a warning: {{{ module Foo (join) where import Prelude () join :: () join = () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8271: missing semicolon in rts/Linker.c
by GHC 12 Sep '13

12 Sep '13

#8271: missing semicolon in rts/Linker.c ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ --- /home/rwbarton/dist/ghc4/rts/Linker.c 2013-09-12 00:02:00.000000000 -0400 +++ /tmp/Linker.c 2013-09-12 00:14:57.000000000 -0400 @@ -1706,7 +1706,7 @@ return v; } } - v = dlsym(hdl, symbol) + v = dlsym(hdl, symbol); RELEASE_LOCK(&dl_mutex); return v; } }}} The missing ; is harmless when LOCK_DEBUG is not defined, because then the expansion of RELEASE_LOCK starts with a ; token. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #2496: Invalid Eq/Ord instances in Data.Version
by GHC 12 Sep '13

12 Sep '13

#2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------ Reporter: guest | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by duncan): Note that that is a different can of worms, trailing zeros. My suggestion is to remove the unused (and useless) tag field, then the derived Eq and Ord will be fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2496#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2496: Invalid Eq/Ord instances in Data.Version
by GHC 12 Sep '13

12 Sep '13

#2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------ Reporter: guest | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): Related thread: - [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/7847 proposal: in base, for Data.Version, change the meaning of comparisons] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2496#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0