May 2014 - ghc-tickets

Re: [GHC] #5757: zero unexpected failures on all tier 1 platforms
by GHC 12 May '14

12 May '14

#5757: zero unexpected failures on all tier 1 platforms -------------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.3 Component: Test Suite | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #5785 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * priority: highest => normal -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5757#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2
by GHC 10 May '14

10 May '14

#7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 ---------------------------------------+----------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by carter): a related instance of spec constr blowup was found in idris when built with O2 where the javascript codegen module https://github.com/idris-lang/Idris- dev/blob/a68c5fa403145e7ce9ea0dc2d369c23ed6854e6d/src/IRTS/CodegenJavaScript.hs likewise http://pastebin.com/cvawjiCc the last line of the log is {{{ *** SpecConstr: }}} not sure if this should be its own ticket or not, for now adding it here -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7898#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7662: Improve GC of mutable objects
by GHC 09 May '14

09 May '14

#7662: Improve GC of mutable objects -------------------------------------+------------------------------------ Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 7.7 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 simonmar): * cc: simonmar (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7662#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 09 May '14

09 May '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): Simon is right about `ifConOcc`. Good point. Rather than pass in the `Name` of the type constructor, you could simply pass in the `Module` in which this `IfaceDecl` lives. Then you can easily make a `Name` for all of these things. It's bit of a nuisance, but perhaps better than making them all `IfaceExtNames`. Perhaps pass in a `Maybe Module`, where `Nothing` means "just print the `OccName`"? > @simonmar suggestion would be easier because we already pass a name to {{{pprIfaceDecl}}} in order to print things in context and elide everything not searched for Not exactly. We pass in a `ShowSub` (or that's what it used to be called in `PprTyThing`. So yes, `ShowSub` could be augmented with that `Maybe Module` and then it is already being plumbed to all the right places. The TH route is certainly a plausible alternative; a good thought. As I say above, I'm not wedded to doing all this via `IfaceSyn`. And better printing for TH stuff would be good; perhaps even better than better printing for Iface stuff (which only hard-core people will look at). The place to look is `TcSplice.reifyThing` which is the moral equivalent of `MkIface.tyThingToIfaceDecl`. You'll see that `reifyThing` is monadic, but the only reason for that is that it can fail, if TH syntax isn't rich enough to deal with the result. Arguably it'd be good to remove the possibility of failure, and thereby force ourselves to enhance TH syntax to cope. I notice also that `reifyThing` is not doing the requisite tidying (which `tyThingToIfaceDecl` is careful to do) so I think there are lurking bugs there. But (and I have not got time to think this through right now), TH syntax models source syntax, and so doesn't have explicit kinds, whereas Iface syntax does.... Probably worth completing the Iface route for now. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 09 May '14

09 May '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): @simonmar suggestion would be easier because we already pass a name to {{{pprIfaceDecl}}} in order to print things in context and elide everything not searched for, so when needing qualified names we could get everything to the left of the last (.) in the supplied name and prefix the occ names with that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 09 May '14

09 May '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonmar): @archblob asked me about this on IRC. I suggested that rather than making `ifName` a qualified name, it would be better to pass in the `Name` when pretty printing the `IfaceDecl`. There's only one `ifName` per `IfaceDecl`, so passing it in separately should be fine. I wonder about things like constructor names (`ifConOcc`), record field names (`ifConFields`), and method names though. Perhaps they need to be qualified too. In which case you'll need to pass in more `Name`s for those. Another thought I had is that perhaps it would be better to reify the stuff into `THSyn` and print that instead. `THSyn` is closer to Haskell than `IfaceSyn`. But perhaps that would mean duplicating the tidying logic? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 08 May '14

08 May '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): I didn't really consider the parsing aspect on the lists although every time I added another abstraction I wondered how much bigger and slower the interface files will get. I'll be changing the representation of {{{IfaceTcArg}}} as we discussed, and I'll also do the necessary measurements of everything I add on top of the existing representation. I also added another field to {{{IfaceClosedSynFamilyTyCon}}} so now it's represented like {{{IfaceClosedSynFamilyTyCon IfExtName [IfaceAxBranch]}}} in order to print closed type families the right way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 08 May '14

08 May '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): Some responses * On the `IfaceTcArg` thing (comment 35), I suggested a whole new list type because it'll be more compact and faster to parse in interface files. Rather than two bytes and two decisions (nil/cons, and type/kind) there'll just be one. But the data type would need a Note to explain that reasoning. * On the qualified names point (also comment 35), I can see that `IfaceDecl`s only have an `OccName` in them because interface declarations "know" their host module. That's no longer true when converting arbitrary `TyThings` to `IfaceSyn`. So the `ifName` field of `IfaceDecl` will have to become `IfExtName`. Probably not too bad. * Re promotion (comment 36), yes I agree. All of these things will make interface files a little more verbose. It probably won't have any effect, but could you do some performance checks? With these changes alone: * Measure the effect on `.hi` file sizes for libraries (eg `base`) * Measure the effect on compile times (or, easier to get at, compiler allocation), say when bootstrapping GHC, or compiling the base libraries. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 07 May '14

07 May '14

#6018: Injective type families -------------------------------+------------------------------------------- Reporter: lunaris | Owner: simonpj Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Injective Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4259 None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by MikeIzbicki): Here's a real worldish use case. Let's try to write a modified Functor class that lets us map over not just the last type variable, but any type variable. This would be useful, for example, with the Either type. The class might look something like: {{{ class Functor loc f where fmap :: proxy loc -> (a -> b) -> SetLocation f loc a -> SetLocation f loc b }}} Where loc is a type that uniquely identifies the position of the argument we want to map over. We can't make an instance of this class unless the SetLocation type family is injective. With a little syntactic sugar, we can convert the above class into something that looks very much like the current Functor class, but is quite a bit more powerful: {{{ class Functor loc f where fmap :: proxy loc -> (a -> b) -> f { loc = a } -> f { loc = b } }}} I don't think you can get something nearly that clean without injective type families. And, of course, this applies to any parametric classes currently in use, not just Functor. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 07 May '14

07 May '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by archblob): We will also need extra information on {{{IfaceTyCon}}}, if it's a promoted data constructor or promoted type constructor in order to quote it when appropriate (promoted type constructors are only quoted when using {{{-dppr-debug}}}). This extra information is only needed in the case of {{{IfaceTyConApp}}} but the current {{{newtype IfaceTyCon = IfaceTc { ifaceTyConName :: IfExtName } }}} is also used for coercion constructors so we might need to use a separate representation for type constructors in the context of {{{IfaceTyConApp}}} that contains this extra information. I was thinking something like: {{{#!haskell -- I'm not really fond of the names IfacePTyCon = IfacePDataCon IfExtName | IfacePTyCon IfExtName | IfaceStdTyCon IfExtName }}} This would not really change things, it is again just more tagging. Andrei -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0