- ghc-tickets - Haskell.org

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

[GHC] #9082: Unexpected behavior involving closed type families and repeat occurrences of variables
by GHC 07 May '14

07 May '14

#9082: Unexpected behavior involving closed type families and repeat occurrences of variables -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I'd expect both of these to work fine, but GHC always picks the instance that is mentioned first: {{{ {-# LANGUAGE TypeFamilies, DataKinds #-} type family Bad a b where Bad (f a) a = False Bad a a = True bad :: ( Bad (f a) a ~ False , Bad a a ~ True ) => () bad = () -- Swapping the lines around does not change the behavior much: type family Bad' a b where Bad' a a = True Bad' (f a) a = False bad' :: ( Bad' (f a) a ~ False , Bad' a a ~ True ) => () bad' = () {- ctf.hs:7:8: Could not deduce (Bad a0 a0 ~ 'True) from the context (Bad (f a) a ~ 'False, Bad a a ~ 'True) bound by the type signature for bad :: (Bad (f a) a ~ 'False, Bad a a ~ 'True) => () at ctf.hs:(7,8)-(9,14) The type variable ‘a0’ is ambiguous In the ambiguity check for: forall (f :: * -> *) a. (Bad (f a) a ~ 'False, Bad a a ~ 'True) => () To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ‘bad’: bad :: (Bad (f a) a ~ False, Bad a a ~ True) => () ctf.hs:18:9: Could not deduce (Bad' (f0 a0) a0 ~ 'False) from the context (Bad' (f a) a ~ 'False, Bad' a a ~ 'True) bound by the type signature for bad' :: (Bad' (f a) a ~ 'False, Bad' a a ~ 'True) => () at ctf.hs:(18,9)-(20,14) The type variables ‘f0’, ‘a0’ are ambiguous In the ambiguity check for: forall (f :: * -> *) a. (Bad' (f a) a ~ 'False, Bad' a a ~ 'True) => () To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ‘bad'’: bad' :: (Bad' (f a) a ~ False, Bad' a a ~ True) => () -} }}} Trying to turn this into an open type family instead somewhat hints at the issue: {{{ type family Bad'' a b :: Bool type instance Bad'' a a = True type instance Bad'' (f a) a = False {- ctf.hs:58:15: Conflicting family instance declarations: Bad'' a a -- Defined at ctf.hs:58:15 Bad'' (f a) a -- Defined at ctf.hs:59:15 -} }}} It seems like GHC thinks these two family definitions conflict, yet to me they seem distinct - as a type that would match both would imply f a ~ a and hence be infinite. Can anybody offer insight into this issue? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9083: symbol constructors declared prefix missing a leading colon are accepted
by GHC 07 May '14

07 May '14

#9083: symbol constructors declared prefix missing a leading colon are accepted -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | 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: | -------------------------------------+------------------------------------- {{{ data M = (++) Int data N = (⌐) Int data Ok = (:++) Int -- correctly accepted }}} I believe ghc should reject M and N. Instead `M` and `N` are accepted, but there seems to be no way to use that constructor (besides say a Data instance) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1