Missing "Show" instance for UtxoState about cooked-validators HOT 14 CLOSED

If that suits your needs, why not?

from cooked-validators.

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

from cooked-validators.

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

from cooked-validators.

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

from cooked-validators.

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?

from cooked-validators.

You can use putDoc from Prettyprinter

from cooked-validators.

How can I convince the repl to use putDoc?

from cooked-validators.

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.

from cooked-validators.

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?

from cooked-validators.

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.

from cooked-validators.

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.

from cooked-validators.

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.

from cooked-validators.

The "bug" being

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

from cooked-validators.

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.

from cooked-validators.