Value representation rework

[SeungheonOh]

nothing much yet

closes #630 and probably bunch more

[L-as]

What's your idea?

[SeungheonOh]

Have PStruct and PRec represent any kind of composite data types, and have PDataRec, PScottRec, ... to represent their encoded format. This will give types that encodes same structure differently for free and also conversion from and to different encoding for free.

So let's say Maybe for example, currently, we need PMaybe and PMaybeData. With this design,

data MyPMaybe s a
  = MyJust (Term s a)
  | MyNothing
  deriving stock (GHC.Generic)
instance SOP.Generic (MyPMaybe s a)

type S' = forall s. s

type MyPMaybeRepr a = UnTermStruct (MyPMaybe S' a)

test :: PStruct (MyPMaybeRepr PInteger) s
test = PStruct $ hcoerce $ from $ MyJust (10 :: Term s PInteger)

testData :: Term s (PDataStruct (MyPMaybeRepr PInteger))
testData = pconDataStruct test

testScott :: Term s (PScottStruct (MyPMaybeRepr PInteger))
testScott = pconScottStruct test

handler :: MyPMaybe s PInteger -> Term s PInteger
handler (MyJust x) = 1 + x
handler MyNothing = 0

matchTestData :: Term s PInteger
matchTestData = pmatchDataStruct @(MyPMaybeRepr PInteger) testData (handler . to . hcoerce . unPStruct)

matchTestScott :: Term s PInteger
matchTestScott = pmatchScottStruct @(MyPMaybeRepr PInteger) testScott (handler . to . hcoerce . unPStruct)

pmatchDataStruct pconScottStruct converts encoding for free

[SeungheonOh]

Having to deal with

type MyPMaybeRepr a = UnTermStruct (MyPMaybe S' a)

is kind of annoying : / Any suggestions are welcome

[kozross]

I'd rather we kept existing hashing choices the same. It probably doesn't matter, but I'd rather the hash index of RCompiled stayed as 9.

[kozross]

What does this type class actually mean?

[L-as]

Why does MyPMaybeRepr exist at all? I think there is a way of making the functions generic over it too BTW.

I also think you can do this without having it in the types at all.

[SeungheonOh]

I think there is a way of making the functions generic over it too.
any examples? I don't understand.

Also, I'm somewhat sure this can be done without embedding these into types, but I don't want to use Haskell's generics, they are pain to deal with. Also don't want TH for similar reasons

[L-as]

You can change the AST a bit such that operations over data types are more abstract. Everything could be SOP-like in the AST. When you lower it to UPLC you could choose at each site what is most convenient, and according to user preference.

There are multiple strategies here, some optimize size, some performance, and some of the problems are in NP.

[L-as]

Does this account for stuff like

let x = ... in map (\_ -> x) list

Note that UPLC is strict.

EDIT: Consider the above as pseudo-UPLC.

[SeungheonOh]

yeah, it won't be able to figure out if bound term will be used multiple times or not

[L-as]

The solution is to cover a small set of cases that are useful and happen in practice and are easy enough to detect.
You can replace it with checking whether the bound variable ever appears under a delay or lam. If it does not, that should mean it's always only evaluated exactly once, hence you can inline it without changing almost anything.

Three properties to uphold:

• Algorithmic complexities must not change
• What errs without optimizations must not err with optimizations.
• What succeeds without optimizations must succeed with optimizations.

The bottom two are a very unfortunate side effect of UPLC's design. I made a CIP cardano-foundation/CIPs#469 to fix this, but it wasn't very popular.

[L-as]

The topmost one wouldn't be affected by doing laziness like Haskell though, since sharing doesn't happen under lambdas. It does though on HVM and stuff like that AFAIU.

[SeungheonOh]

Waiting on module restructuring

[SeungheonOh]

superceeded by #767