Be more transparent about when 'SpendableOut's contain a datum

[carlhammann]

A 'SpendableOut' contains a 'ScriptChainIndexTxOut' which can either contain a Left datumhash or a Right datum. In many cases, the datumHash will be resolvable into a datum if, we're in the context of a MonadMockChain. The question is how/if we should distinguish 'SpendableOut's that

• have a resolved datum of a known type,
• have a resolved datum of unknown type,
• have a resolvable datumHash, or
• have an unresolvable datumHash

on the type level, and how we should make these distinctions in a systematic way.

[Florent C.]

A straightforward low-effort solution to distinguish at the type level "resolved" vs "unresolved (but maybe resolvable)" would be to introduce a CookedSpOut, counterpart of SpendableOut type that mirrors Pl.ChainIndexTxOut apart from the Either datumHah datum which would be datum.

The current functions that resolve the datum in a BlockChain would have types like spOutResolveDatum :: MonadBlockChain m => SpendableOut -> m CookedSpOut, or spOutsFromCardanoTx :: MonadBlockChain m => Pl.CardanoTx -> m [CookedSpOut]. The SpendsScript constraint would require a CookedSpOut. This would bring some more type safety although this does not answer all the items.

[carlhammann]

I like that idea, but I'd like something like TypedSpOut a. Are there any cases where, with normal use of cooked, we know that there is a datum, but don't know its type?

[Florent C.]

When validating a transaction that issues new outputs, the returned transactions CardanoTx from which we can later get the corresponding SpendableOuts do not contain type information anymore about the datum.
It should be possible to retrieve the info if we know which PaysScript led to these different outputs.
I wonder how such an API could look like. But I think there would be a lot of actually unsafe stuff inside the black box if we were to implement it.