search

tweag / cooked-validators

MIT License
39 stars 11 forks source link

Store datum type information in the chain state #235

Closed florentc closed 1 year ago

florentc commented 1 year ago

Right now, we lose type information after we validate a transaction skeleton. Only values with type Pl.Datum persist in the state of our chain inside the map that resolves datum hashes to Pl.Datum.

Unfortunately, that information is valuable. For example, it is useful in order to know how to pretty print those datums when needed.

In order to answer that specific need, we keep the pretty printed representation of the datum inside the map. In V1 we had (Pl.Datum, String). In V2 we have (Pl.Datum, Doc ()).

In order to decouple pretty-printing concerns from modules such as Skeleton and Direct, it would be interesting to store the type information itself (TypeRep) instead, thanks to the fact datums are Typeable. This may make it possible to decouple pretty-printing from the aforementioned modules while easing implementation of other features which may suffer from the type information loss after validating skeletons.

See branch ch/typeref-in-mockchain for experimentation on this idea.

carlhammann commented 1 year ago

With the latest commit on ch/typerep-in-mockchain, I think I've got a complete solution sketched. The missing part so far was that the TypeRep alone is not sufficient; we also have to keep track of at least the FromData and Pretty contsraints. The idea is to use Data.Constraint and define

data SomeTypeRepWithConstrs where
  SomeTypeRepWithConstrs :: Dict (PP.Pretty a, Pl.FromData a) -> TypeRep a -> SomeTypeRepWithConstrs

which gets stored alongside every Pl.Datum. This allows us then write functions like 

prettyDatumWithType :: SomeTypeRepWithConstrs -> Pl.Datum -> Maybe (PP.Doc ())

(which is defined here) and use them in places where we have to get the pretty-printed representation, for example here and here.

A benefit we get already only from storing the TypeRep is that, upon retreiving data from the MockChain, we can check that they are of the correct type, as shown here.

carlhammann commented 1 year ago

I just realised that we could (should?) probably do the same thing for validator types, as that's some type information we're currently also throwing away. (This would maybe allow pretty-printing the validator's type alongside its hash.)