#12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Excellent example! It seems clear that there is going to be no reasonable "always-right" solution to this. Moreover, here is another horrible example {{{ data T1 = MkT1 (...something requiring IA...) data T2 = MkT2 (...something requiring IB...) type instance F1 Int = ...T2... -- IA type instance F2 Int = ...T1... -- IB }}} Here F1 and F2 are supposed to be like Open1 and Open2 in your example; they must be processed in the right order. But T1 and T2 appear to be entirely independent of each other, so SCC analysis will put them in some arbitray order; and that order in turn determines which of IA and IB can be processed because IA mentions T2 and IB mentions T1. So only one ordering of the apparently un-ordered T1, T2 will work. Can you turn that sketch into a concrete example? It's even more horrible than yours because the invisible ordering of instances seems to force an equally-invisible ordering of the data declarations too. Sigh. I'm not sure what to do. The only simple, predictable thing I can think of is this: * Perform SCC analysis on each group of data/type/class/data-instance decls that lie between successive `type instance` decls. * Otherwise process the file in the order writtten, from top to bottom. That is, divide the file into segments, delimited by `type instance` decls. Process the file top-to-bottom, one segment at a time, processing the `type instance` decls in the order they are written. That's simple, easy to specify, and easy to implement. Where there are no `type instance` decls, we get full SCC analysis across the entire module. The big disadvantage is that where you have a forward reference, kind checking will just fail: {{{ data T = MkT S -- Forward reference type instance F Int = Bool data S = MkS Int }}} That is pretty bad. Can you think of an alternative rule? The goal is NOT to be as clever as possible. THe goal is to be as stupid, straightforward, and predictable as possible, even if that might mean a little manual labour on the part of the programmer. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12088#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler