Skip to content

Document behaviour of `Ord TypeRep` instance (inconsistent across compilations)

Summary

Data.Typeable has an instance Ord TypeRep that we suspect is not lawful across compiler invocations.

It compares typeRepFingerprint.

We have a servant-like web server with type-defined routes, and a function that can generate TypeScript type definitions from it (code). It uses the aeson-typescript package that provides functions based on Data.Set.Set TSType; the Ord instance of TSType compares typeReps.

As such, the generated .ts files have different contents depending on whether they are generated in ghc or ghci, even though the code that produces their contents is pure (no IO). This is bad.

Proposed improvements or changes

  • Somebody to confirm if the above is correct.
    • If yes, document it.
  • Is it possible to write an Ord instance that is lawful/consistent across different ways of compilation?

Environment

  • Current and older versions of base (currently 4.17.0.0).
Edited by Niklas Hambüchen
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information