Switch to use lens and eons for txbody construction

[newhoggy]

Changelog

- description: |
    Switch to use lens and eons for txbody construction
# 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 PR follows on from #333 and includes commits from that PR. Review that PR first.

How to trust this PR

Highlight important bits of the PR that will make the review faster. If there are commands the reviewer can run to observe the new behavior, describe them.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. See Running tests for more details
• Self-reviewed the diff

[newhoggy]

Because the lenses we use take an eon we can use forShelleyBasedEraInEon and not care about what eons the field is valid for.

This is one of the advantages of using eons over constraints.

In a future era the ledger ends support for a field, then only the lens need change. This code will not need to change at all, reducing the blast radius of ledger changes.

Take for instance https://github.com/input-output-hk/cardano-api/pull/334/files#r1367683063

The updateTxBodyL lens takes ShelleyToBabbageEra eon as its argument, but you wouldn't know it from here - nor do you need to because forShelleyBasedEraInEon selects that eon automatically for you and only sets the field in the tx body when the era is in that eon relieving the developer from maintaining that detail.

[carbolymer]

Tbh I'd prefer using:

setUpdateProposal <- forEraInEon (cardanoEra @era) (pure id) $ \w ->
  ...

Removes the need for maintaining multiple specialized functions for each eon.

[newhoggy]

I wasn't intending to create one for each eon. Just CardanoEra and ShelleyBasedEra. We can promote sbe to era as well.

[newhoggy]

How does it look now?

[newhoggy]

Notice that updateBodyL takes a ShelleyToBabbageEra eon and internally summons the necessary constraint so the caller doesn't have to.

[carbolymer]

This includes #333, so I have the same remark here https://github.com/input-output-hk/cardano-api/pull/333/files#r1368451851

[Jimbo4350]

Why are we making this change that depends more on the eons when we intend to remove them?

[newhoggy]

We hadn't yet planned how much we're going to trim which may affect what we keep and what we don't, so I did the conservative thing and kept all the features as is.

We should have that discussion.

But I think if even if we dropped support for invalidBeforeTxBodyL in eras before Babbage, that doesn't mean eons go it away, it would just mean for example:

invalidBeforeTxBodyL :: AllegraEraOnwards era -> Lens' (TxBody era) (Maybe SlotNo)

becomes

invalidBeforeTxBodyL :: BabbageEraOnwards era -> Lens' (TxBody era) (Maybe SlotNo)

[carbolymer]

There's a lot of repetition of functions like:

forShelleyBasedEraInEon sbe (pure id) $ \w -> ...

It feels that we could use a Monoid (Ap f (Endo a)) here. For example:

whenShelleyBasedEraInEon :: ()
  => Eon eon
  => Monoid a
  => ShelleyBasedEra era
  -> (eon era -> a)
  -> a
whenShelleyBasedEraInEon sbe f = forShelleyBasedEraInEon sbe mempty f

then

let setMint = whenShelleyBasedEraInEon sbe $ Endo $ \w ->
  A.mintTxBodyL w .~ convMintValue apiMintValue

or

  setUpdateProposal <- fmap getAp . whenShelleyBasedEraInEon sbe $ Ap $ \w ->
    (Endo $ A.updateTxBodyL w .~) <$> convTxUpdateProposal sbe (txUpdateProposal bc)

and then when constructing the txbody use <> instead of &.

(This could be simplified further using do notation from Monad f => Monad (Ap f) and we can create specialized funcitons already wrapping arguments into Ap f (Endo a))

What do you think?

[newhoggy]

Possible follow up step.

[newhoggy]

I pushed the suggested change with some slight changes.

Responded