Making compilation results deterministic (#4012)

[Simon Peyton Jones]

| We don't currently have a good way to reproduce the problem from a
| completely clean build, however it's easy to reproduce by doing two
| builds and leaving the .hi files from the first build in place while
| removing the .o files

Indeed.  But is determinism in the face of .hi file changes Part of the Goal?

| So we concluded that it was probably futile to aim for
| fully-deterministic compilation by making the uniques the same every
| time, and instead we should try to make compilation deterministic in the
| face of non-deterministic uniques.

Well that is bound to be fragile too.  IF the uniques could be made deterministic, for the use-cases that are part of The Goal, then it would be a simple solution.

Determinism in the face of non-det uniques.  I suggest NOT monkeying with UniqFM or Data.Map.  Rather, I think you should focuse on every use of ufmToList.  There are a lot of these, and many of them will be totally fine to be non-deterministic.  On a case-by-case basis (fragile) I guess you can find some canonical ordering.  That might be hard in the case, say, of identical OccNames with different uniques (e.g. ds_343, ds_324).  I suppose that in every case we'd have to look for some other way to canonicalise. Ugh.

Still, one step at a time.  Wiki page would be good.

Simon