Rename AnyEraInEon to EraInEon

[newhoggy]

Changelog

- description: |
    Rename `AnyEraInEon` to `EraInEon`
# uncomment types applicable to the change:
  type:
  # - feature        # introduces a new feature
  - breaking       # the API has changed in a breaking way
  # - compatible     # the API has changed but is non-breaking
  # - optimisation   # measurable performance improvements
  - improvement    # QoL changes e.g. refactoring
  # - bugfix         # fixes a defect
  # - test           # fixes/modifies tests
  # - maintenance    # not directly related to the code
  # - release        # related to a new release preparation
  # - documentation  # change in code docs, haddocks...

Context

This simplifies the type name. The Any prefix is not needed to understand what the type does.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• The change log section in the PR description has been filled in
• New tests are added if needed and existing tests are updated. These may include:
  • golden tests
  • property tests
  • round trip tests
  • integration tests
    See Running tests for more details
• The version bounds in .cabal files are updated
• CI passes. See note on CI. The following CI checks are required:
  • Code is linted with hlint. See .github/workflows/check-hlint.yml to get the hlint version
  • Code is formatted with stylish-haskell. See .github/workflows/stylish-haskell.yml to get the stylish-haskell version
  • Code builds on Linux, MacOS and Windows for ghc-8.10.7 and ghc-9.2.7
• Self-reviewed the diff

[carbolymer]

I think Any prefix was useful here, we were using it to denote an existential.

[newhoggy]

I originally thought of Any as representing the existential, but it doesn't have to be the only way to represent the existential.

We can review some examples:

data AnyConsensusModeParams where
  AnyConsensusModeParams :: ConsensusModeParams mode -> AnyConsensusModeParams

data AnyConsensusMode where
  AnyConsensusMode :: ConsensusMode mode -> AnyConsensusMode

data AnyScriptLanguage where
     AnyScriptLanguage :: ScriptLanguage lang -> AnyScriptLanguage

data AnyPlutusScriptVersion where
     AnyPlutusScriptVersion :: PlutusScriptVersion lang -> AnyPlutusScriptVersion

I think in all the above cases, the Any prefix fits because they match the pattern AnyX where X is the thing we are quantifying over.

These however, I think are different:

data AnyEraInMode mode where
     AnyEraInMode :: EraInMode era mode -> AnyEraInMode mode

data AnyEraInEon eon where
  AnyEraInEon
    :: ( Typeable era
       , Typeable (eon era)
       , Eon eon )
    => eon era
    -> AnyEraInEon eon

We are not quantifying over EraInMode or EraInEon, we are just quantifying over the era. The Eon part or the Mode part continues to be parameterised.

I think in these cases, it is appropriate to just call it EraInMode or EraInEon where pattern XInY means quantifying X for a given Y.

data AnyScriptWitness era where
     AnyScriptWitness :: ScriptWitness witctx era -> AnyScriptWitness era

This one is a bit special. The only way it makes sense for me is if it were named ScriptWitnessInAnyWitnessContext, so it doesn't follow either of the two conventions above.

[carbolymer]

I'm still not convinced and I think in your example both are the same - in both cases in AnyEraInMode mode and AnyEraInEon eon we're quantifying over eras.

[carbolymer]

Either we should remove Any prefixes from all existentials, or leave it as it is.

not blocking if you guys feel that's the way

[newhoggy]

Okay. Making the call to merge since I'm leaning towards the change and have the casting vote.