Use machine readable output for ToJSON ScriptWitnessIndex

[newhoggy]

Description

• New ToJSON ScriptWitnessIndex instance
• Any JSON output uses this instance.
• In JSON logging, "ExtraRedeemers" object contents are machine readable rather than difficult-to-parse user-friendly-string.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. These may include:
  • golden tests
  • property tests
  • roundtrip tests
  • integration tests
    See Runnings tests for more details
• Any changes are noted in the CHANGELOG.md for affected package
• 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

Note on CI

If your PR is from a fork, the necessary CI jobs won't trigger automatically for security reasons.
You will need to get someone with write privileges. Please contact IOG node developers to do this
for you.

[carbolymer]

Manual instances are cumbersome in maintenance and error-prone. Maybe genericToJSON would be better here instead? For example:

data Foo = Foo !Text | Bar !Text | Baz !Text deriving (Generic)
genericToJSON (defaultOptions{sumEncoding=TaggedObject{tagFieldName="kind", contentsFieldName="value"}}) (Bar "barbar")

produces

{"kind":"Bar","value":"barbar"}

[newhoggy]

I'm not certain that buys enough to justify the cost for a number of reasons.

We need to do this for LogFormatting and have no generic facility for that type class. If we have to manually type it out in one instance we may as well do it for both.

I use my editor's multi-cursor support and it takes very little time for something this regular.

My previous experience with aeson generic generation was that the compile time was quadratic and with a large enough type that actually became a problem.

I'm not sure if this particular case is quadratic, but that the problem exists gives me sufficient hesitation.

[carbolymer]

My main concern here is just an extra mental burden coming from the requirement to make proper changes in multiple places - what if you accidentally omit one place with your multi-cursor support? 😄

My previous experience with aeson generic generation was that the compile time was quadratic and with a large enough type that actually became a problem.

Fair point, and I agree that it matters here. I'm not insisting on using Generic here, but it would be better to have more safety either by using automatic generation of instances, or testing them in property tests.

PS. I had to roll-back prod deployment in the past once, because of faulty, manually written FromJSON instance, which was undetected for over a year, so I guess I'm a bit oversensitive on this topic. 😄

[newhoggy]

This might be worth doing a golden test for, so waiting on this input-output-hk/hedgehog-extras#31