- ghc-tickets - Haskell.org

Re: [GHC] #6018: Injective type families
by GHC 31 Oct '14

31 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by simonpj): My instinct is (a) because finding all pairs is potentially quite expensive, and repeating all that code seems a shame -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 31 Oct '14

31 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): Oh, and while we're talking about open type families, there's a design decision to make. Verifying user-supplied injectivity condition requires comparing the same equations that are compared by compatibility check. Should we: a) verify injectivity at the same time we verify compatibility? b) verify injectivity in a separate pass? a) might seem like an obvious answer because it allows us to avoid traversing the equation pairs twice. However, that makes compatibility checking code in `FamInstEnv.lookup_fam_inst_env'` a bit more complicated. b) on the other hand can allow us to skip the injectivity checking altogether if the user did not supply any injectivity declarations. This would be a big win since compilation performance would not be degraded for already existing code (since there are no injectivity declarations). I am in favour of option b). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:99> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 31 Oct '14

31 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): I'm implementing injectivity checking for open type families and got stuck on some nonsense problem (described on Phab) so I diverted to #8326 this week. Will resume work on this next week. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:98> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 31 Oct '14

31 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by simonpj): What's the status on injective type families? Stalled? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:97> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7944: GHC goes into an apparently infinite loop at -O2
by GHC 31 Oct '14

31 Oct '14

#7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: 5550 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new Comment: I don't think this is fixed yet. Steps to reproduce (with a quick build of today's ghc master in directory ~/ghc-build, on Linux): {{{ cabal install --with-ghc=ghc-build/inplace/bin/ghc-stage2 vector git clone https://github.com/thomie/inttable cd inttable ~/ghc-build/inplace/bin/ghc-stage2 -O2 -v3 --make Repro }}} This last step freezes after about 1 second, with final output: {{{ *** SpecConstr: Result size of SpecConstr }}} CPU is at 100%, until I kill it after a few minutes. Contrary to Brian's observation, I do see an increase in memory usage over time. I get the same results when using ghc-7.8.3 instead of current ghc master. I had to make a small change to Bryan's `inttable` repository (hide some imports from base). See the mentioned github url. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7944#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9236: hGetContents leads to late/silent failures
by GHC 31 Oct '14

31 Oct '14

#9236: hGetContents leads to late/silent failures ------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A common newbie error: {{{ #!haskell withFile "file" ReadMode hGetContents >>= putStr }}} The problem, of course, is that the result of `withFile "file" ReadMode hGetContents` isn't forced until `putStr` is executed, at which point the file has already been closed. The Haskell report doesn't specify what it will find, and, at least in 7.6.3, it finds the string empty. The behavior that seems most correct to me would be to guarantee that if a file has not been completely read (or read up to an I/O error) when it is closed, then its contents should be reported as something like `"Four score and seven years ag"++error "Forcing a suspended computation led to an attempted read from a handle that was already closed."` Since the current system apparently puts an `[]` as a temporary marker while waiting to see what the rest of the list will be, I imagine that the fix is as simple as putting the error thunk there instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas
by GHC 31 Oct '14

31 Oct '14

#9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- The language extensions `-XIncoherentInstances` and `-XOverlappingInstances` (described in [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap the user manual]) apply to every instance declaration in the module. Internally, however, GHC records this information on a per-instance-declaration basis. It would be much better for the programmer to be able to control these matters on a per-instance-declaration basis. Thus: {{{ instance Show a => Show [a] where {-# OVERLAPPABLE #-} ... instance Show [Char] where ... }}} We came across the need for this when discussing the `Typeable` instances. We have a generic instance like this: {{{ instance (Typeable f, Typeable a) => Typeable (f a) where .... }}} but also want {{{ instance KnownNat n => Typeable (n :: Nat) where ... }}} If we seek `(Typeable (x::Nat))`, we should pick the second instance even though in principle you might imagine that `x` might be instantiated to `(f a)`, for some `f` and `a`. But we know that there are no type constructors `f` of kind `blah -> Nat`, so this can never happen and it's safe to pick the second instance. So a local `{-# INCOHERENT #-}` pragma for this particular instance declaration would be very useful to express this fact. {{{ instance KnownNat n => Typeable (n :: Nat) where {-# INCOHERENT #-} ... }}} Quite apart from this special case, it's plain better to have per-instance control * Rather than a remote per-module flag, the pragma draws attention that ''this particular instance'' is incoherent, overlappable or whatever. * The current situation almost certainly means that more instances are marked overlapping than are really necessary. I have some design questions. * Where should the pragma appear, syntactically? {{{ instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... or instance Show a => Show [a] {-# OVERLAPPABLE #-} where ... or instance Show a => Show [a] where {-# OVERLAPPABLE #-} }}} Remember that `SPECIALISE INSTANCE` pragmas appear in the third of the above positions, so I mildly favour that. * The user manual (link above) allows overlap if ''either'' instance is compiled with `-XOverlappingInstances` (see the rules towards the end of [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap 7.6.3.5). It would be more explicit to have two pragmas, one to say "I can be overlapped" and one to say "I can overlap something else". The rule would then be that "either IX is marked `{-# OVERLAPPABLE #-}` or IY is marked `{-# OVERLAPPING #-}`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

Re: [GHC] #7191: hsc2hs can't treat absolute path correctly on Windows.
by GHC 31 Oct '14

31 Oct '14

#7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:10 gintas]: > What needs to be done to get it released? Well, `hsc2hs` was never meant to be released independently from GHC to http://hackage.haskell.org/package/hsc2hs (and GHC's `hsc2hs` hasn't had its version number incremented for ages, because it's only an internal helper of the GHC distribution) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7191#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7381: Build failure with BuildFlavour = prof
by GHC 31 Oct '14

31 Oct '14

#7381: Build failure with BuildFlavour = prof -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nh2): * owner: igloo => * status: closed => new * resolution: fixed => * milestone: => 7.8.4 Comment: This change is undocumented in the 7.6 to 7.8 changelog and breaks existing behaviour. As mentioned by David Terei in March 2013 (https://www.haskell.org/pipermail/ghc-devs/2013-March/000677.html) you now have to write `ghc -M [files] -dep-suffix=''` to get the old `ghc -M [files]` behaviour. This hit me badly since I was using some other `-dep-suffix` flags already, so I didn't get the `"You must specify at least one -dep-suffix"` warning, and the `.o` files were simply missing from my output Makefile. I'm reopening this ticket so that we can mention this change at least in the changelog for 7.8.4 if that's OK. And as David wrote, the user guide should probably also be updated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7381#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9681: Printing of "\n" in error messages is broken
by GHC 31 Oct '14

31 Oct '14

#9681: Printing of "\n" in error messages is broken -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: 1+"\n" | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The code excerpts in error messages from GHC 7.8.3 are misformatted when the original code contains the string "\n" - the \n escape is simply lost. Example with GHCi: {{{ Prelude> 1+"\n" <interactive>:2:2: No instance for (Num [Char]) arising from a use of `+' In the expression: 1 + "" In an equation for `it': it = 1 + "" }}} The printing of the string "\n " is also strangely formatted, although technically equivalent: {{{ Prelude> 1+"\n " <interactive>:3:2: No instance for (Num [Char]) arising from a use of `+' In the expression: 1 + "\n\ \ " In an equation for `it': it = 1 + "\n\ \ " }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9681> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5