Why not instead extend the current mechanism to add non-determinism in
#14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:10 simonmar]: the code generator? From my side it's just a limitation of how much time I can sink into it. Making uniques not surface at all in the generated code would be great and cover more use cases, like being able to switch between `-c` and `--make` as you say, but an approach like I suggest would already cover the most common use cases (e.g. libraries and binaries built by cabal, Stack, Linux distributions would be deterministic, as they all use `--make`, and `[TH]` recompilation would be reduced), while (to my knowledge) not regressing any existing functionality (switching between `--make` and `-c` would remain as determinism-destroying as they were so far). Also, the two approaches don't seem to be competing -- it appears to me that in an ideal world, GHC would have neither internal variables appear in outputs, nor use any form of module-spanning "impure" internal state driven by `unsafePerformIO` as it has now. Using the module index is a quickest-and-easiest way to map the modules into a compact range of integers for easy array indexing. If this turns out to not be relevant for performance, then I could imagine also using the fully qualified module name or something similar, which might address the `-c` vs `--make` issue.
Relying on unique determinism is quite fragile and easily broken, and we have no way to know when that happens - at least with the current scheme we have some protection in the APIs for things like `UniqFM` so that it's hard to accidentally introduce non-determinism.
I'd argue that removing the possibility to access an `unsafePerformIO`-based number generator at all would be a much stronger guarantee that non-determinism cannot be introduced, is that not accurate? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14769#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler