I can't say for sure, but this could be related to #4012. The order that things appear in lists often depends on the way that uniques get allocated. I know for sure that inferred type signatures are nondeterministic right now, see [1] for an attempt to fix it.
The easiest way to check if it affects you is to reverse the order of allocated uniques by passing `-dunique-increment=-1` on the command line. If you rely on orders lining up I'd also recommend testing with it. See #11148, #11362, #11361 for examples where it failed with reversed uniques. [1] https://phabricator.haskell.org/D1924 2016-04-13 15:12 GMT+01:00 Ryan Scott <[email protected]>: > > I thought that inferred foralls are Invisible binders (see Note > [TyBinders and VisibilityFlags]); and you can't use visible type > application for Invisible binders. > > In this particular case, j, k, l, x, y, and z aren't invisible > binders, but rather specified ones. And you certainly can use visible > type application on specified binders; this is important for my use > case. > > > Also I don't understand why Ryan needs a reliable ordering. > > I guess I should elaborate on what exactly my use case is. I'm trying > to fix Trac #10604 (i.e., make Generic1 poly-kinded). As part of this > effort, I need to generalize the (:.:) type [2] from GHC.Generics like > so: > > newtype (:.:) (f :: k2 -> *) (g :: k1 -> k2) (p :: k1) = Comp1 (f (g > a)) > > I also need to change a part of TcGenGenerics where I apply the (:.:) > type constructor to some other types [3]. Previously, (:.:) was > monokinded, so I only needed to apply (:.:) to some type arguments. > But now that (:.:) is poly-kinded, I need to also apply it to two kind > arguments! > > Now for the interesting part: in which order do you give the kind > arguments for (:.:)? I originally thought the order in which you'd do > it would be [k2,k1] (since that's the order they appear in the > definition from left to right), but in reality, it's actually [k1,k2] > due to the reasons mentioned earlier in this thread. This is quite > bewildering, especially since in GHC 7.10.3, it was the former order, > but in GHC 8.0 it's the latter order. Who's to say that the order > won't change again in a later GHC, and then deriving Generic1 will > silently break as a result? > > So at this point, I see my options as follows: > > 1. Change the definition of (:.:) to use the GADT syntax that Richard > proposed. This would give a stable ordering for the kind variables, > but I'm loathe to make such a drastic change to the surface syntax to > fix a silly problem like this. > 2. Investigate a fix to the implicitly quantified ordering issue. I'm > not sure where the issue could lie, and just from looking at > extract_lty [4], it's not clear at all what causes the current > ordering. > 3. Live with the issue, and just change the code in TcGenGenerics if > the kind variable ordering ever changes. This is a bummer, but looks > like the simplest option. > > Ryan S. > ----- > [1] https://ghc.haskell.org/trac/ghc/ticket/10604 > [2] > http://hackage.haskell.org/package/base-4.8.2.0/docs/GHC-Generics.html#t:: > .: > [3] > http://git.haskell.org/ghc.git/blob/d81cdc227cd487659995ddea577214314c9b4b97:/compiler/typecheck/TcGenGenerics.hs#l526 > [4] > http://git.haskell.org/ghc.git/blob/d81cdc227cd487659995ddea577214314c9b4b97:/compiler/rename/RnTypes.hs#l1611 > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
