Missing "Show" instance for UtxoState

[gabrielhdt]

As the title says. Furthermore, interaction with the repl fails because of that, see the steps to reproduce.

To Reproduce Use cabal repl in cooked-validators, then

Prelude Cooked> :l Cooked
[...]
Ok, 31 modules loaded.
Prelude Cooked> import Data.Default
Prelude Data.Default Cooked> Cooked.runMockChainFrom def (Cooked.validateTxSkel $ Cooked.txSkelTemplate)

<interactive>:4:1: error:
    • No instance for (Show UtxoState) arising from a use of ‘print’
    • In a stmt of an interactive GHCi command: print it

Expected behavior ~There should be an instance of Show, shouldn't it?~ I would expect that function to not fail and show me a representation of UtxoState.

Environment cooked-validators, commit 094fdcf7be5d897d8b921e8fbbc2eb1891c8fb61, using the development shell provided by the flake (on a Void Linux).

[carlhammann]

There's pretty-printing for UtxoState, though, which we could use to implement Show. Probably Show was deepened unnecessary after we implemented pretty printing?

[gabrielhdt]

So should we use the prettyCooked instance for Show as well?

[carlhammann]

If that suits your needs, why not?

[florentc]

This is intended. In the end the plan is to remove requirements about Show instances for datum and redeemers (we already require PrettyCooked). So UtxoState will no longer be showable. Also, implementing Show from Pretty/PrettyCooked does not seem, if I am not mistaken, in the philosophy of what Show is usually expected to be: a raw printing of information. The pretty printing, on the other hand, takes liberties when it comes to printing, it omits info on purpose, etc. Besides, for your use case, in a repl, pretty-printing has upsides: for example it will adapt to your window size and line break when necessary while a conversion to string will blindly assume 80col-long lines.

I think this may be related to #234 in a way. Solving #234 would probably be the occasion to introduce some wrapper function or PrettyCooked instance to introduce convenient runAndPrettyPrint functions to use during experiments in the REPL

[gabrielhdt]

if I am not mistaken, in the philosophy of what Show is usually expected to be: a raw printing of information

This is my opinion too, using pretty for Show seemed a bit strange to me. But how should I solve my problem? Is there a way to use the pretty function in the repl?

[florentc]

You can use putDoc from Prettyprinter

[gabrielhdt]

How can I convince the repl to use putDoc?

[florentc]

By default Doc a, so DocCooked as well, are showable so you should see something if you just prettyCooked. Alternatively, import Prettyprinter and putDoc . prettyCooked.

[gabrielhdt]

I'm afraid I can't make things work out, could you tell me precisely how I should modify my snippet above to make it work?

[gabrielhdt]

I see what you meant: but prettyCooked cannot work right away because the value returned is an Either ... ..., so this doesn't have any prettyCooked instance.

[florentc]

There is prettyEndState in Pretty.Cooked. I could introduce a prettyRunResult :: Show a => PrettyCookedOpts -> (a, Either MockChainError UtxoState) -> DocCooked if you want. We already have pretty printing functions for state and mock chain error.

[gabrielhdt]

Why not, but actually I'm more interested in knowing whether you think the behaviour I described in this bugreport is the expected one, or whether you think it's a bug.

[gabrielhdt]

The "bug" being

cabal repl fails upon evaluation of some data of type Either ... UtxoState

[florentc]

I think it is expected since UtxoState is no longer showable. The repl implicitly requires the returned value to be showable in order to print it. It does the same when evaluating any non Showable value.

It is now a matter of whether (and how) we want to restore an instance of Show for UtxoState.

In my opinion we should not for the reason I talked about above:

• We have what we need to pretty print stuff better than what we would have using Show, we just lack wrapper functions in the user-facing API (see #234). @carlhammann and I plan to refresh the Testing module that has remained the same since V1. This would be the occasion to introduce functions dedicated to tinkering in the repl: they would run a mockchain and pretty print the result (IO ()) in addition to current functions that are expected to be used in test trees.
• Basing Show on Pretty is not really what Show is about
• Deriving Show would require datums to be Showable, which is currently the case but actually no longer relevant because they must implement PrettyCooked too.