You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: I'm doing creating this issue to raise awareness and to determine if this is something that could be fixed on the lens side.
Background: For various reasons it's desirable to have GHC produce ABI-compatible binaries given the same input, flags and the environment.
Now, TemplateHaskell gives no guarantees about this, you could generate different code depending on the phase of the moon.
As it turns out quantifyType' is unintentionally nondeterministic. There's no code that accesses the environment nor does some suspect thing and yet, it will not always produce the same code in the same conditions.
The core of the issue is that GHC exposes a bit more about the internals than it should. Its Name type holds a Unique. For various reasonsUniques are not stable across recompilations. As it happens the Ord instance for Name is based on Unique meaning that the relative order Names might change between compilations.
As it happens quantifyType' holds a Set/Map of these names that later determines the order of type variables in the generated definition.
There are multiple valid stances to take here:
TH is nondeterministic anyway, so why bother fixing this
It looks OK, I'm not that familiar with that code, so I will trust you that this is the only place where Set Name and Map Name a get turned into lists.
Thanks for the quick fix!
This is copied from stevenfontanella/microlens#83 (comment) as the code originated in
lens
.Note: I'm doing creating this issue to raise awareness and to determine if this is something that could be fixed on the lens side.
Background: For various reasons it's desirable to have GHC produce ABI-compatible binaries given the same input, flags and the environment.
Now, TemplateHaskell gives no guarantees about this, you could generate different code depending on the phase of the moon.
As it turns out
quantifyType'
is unintentionally nondeterministic. There's no code that accesses the environment nor does some suspect thing and yet, it will not always produce the same code in the same conditions.The core of the issue is that GHC exposes a bit more about the internals than it should. Its
Name
type holds aUnique
. For various reasonsUniques
are not stable across recompilations. As it happens theOrd
instance forName
is based onUnique
meaning that the relative orderNames
might change between compilations.As it happens
quantifyType'
holds aSet/Map
of these names that later determines the order of type variables in the generated definition.There are multiple valid stances to take here:
Now I'm leaning towards 2., but the problem with that approach is that the soonest this can get fixed is for GHC 8.2, which is probably a year away.
Related discussions:
https://mail.haskell.org/pipermail/ghc-devs/2016-May/012163.html
https://mail.haskell.org/pipermail/ghc-devs/2016-June/012181.html
The text was updated successfully, but these errors were encountered: