Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

quantifyType' is non-deterministic #669

Closed
niteria opened this issue Aug 11, 2016 · 2 comments
Closed

quantifyType' is non-deterministic #669

niteria opened this issue Aug 11, 2016 · 2 comments

Comments

@niteria
Copy link

niteria commented Aug 11, 2016

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 a Unique. For various reasons Uniques 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:

  1. TH is nondeterministic anyway, so why bother fixing this
  2. This is bad and should be fixed on GHC side
  3. This is bad, but GHC shouldn't bother fixing it, it's up to the library to ensure the determinism

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

@neongreen
Copy link
Contributor

neongreen commented Aug 11, 2016

You weren't fast enough, it already got fixed. (Well, probably. You should check.)

@niteria
Copy link
Author

niteria commented Aug 11, 2016

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!

@niteria niteria closed this as completed Aug 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants