@michaelpj what about size?

We're encoding a lazy bytestring, so presumably size @ByteString. Or you could call https://hackage.haskell.org/package/flat-0.4.4/docs/Flat-Encoder-Strict.html#v:sLazyBytes which is how size is implemented for lazy bytestrings.

This:

newtype AsSerialize a = AsSerialize
    { unAsSerialize :: a
    } deriving newtype (Serialise)

instance Serialise a => Flat (AsSerialize a) where
    encode = encode . serialise
    decode = deserialise <$> decode
    size = size . serialise

? Also pinging @kwxm and @raduom who I think also did something with flat (for context: we're trying to write a Flat instance for things that already have a Serialize instance).

[Comment deleted: I didn't understand what was going on here, but then spotted the previous conversation with @michaelpj.]

I wonder if doing it this way is significantly more expensive or larger than having a special instance?

Also, how are Data objects going to be transmitted? I had a vague idea that they were going to be Flat wrapped in CBOR, but the earlier conversation above suggests that there's already a full CBOR instance. What is that for? If it's for transmission, why do we need a Flat instance at all? Because we might have programs with Data objects inside them?

I've no idea what I'm doing, I only implemented @michaelpj's suggestion.

• Data has a CBOR instance, because it's going to appear in a number of other places in transactions etc, and also it's literally designed to be a subset of CBOR. People may want to generate it using other tools etc.
• We need all types in the builtin universe to have Flat instances, so Data also needs a Flat instance. As Kenneth says, indeed this is so that we could serialize a program with a Data literal in it. For example, the fully-applied scripts produced by the plutus-use-cases-scripts thing will be like that.
• We could give Data a new Flat instance, but given that we already have a way of serializing it, we might as well just dump it in as an opaque serialized bytestring. That has the advantage that you could in principle fish it out and work with it separately, or whatever.

Could we have uncurry too? I think that's probably the most useful function for me, since I'll want to write builtinPairToHaskellPair which is more-or-less uncurryBuiltin haskellPairConstructor

Oh, it's in the stdlib bit. I don't really understand why this isn't there, then? Whatever.

So stdlib is for people to use, examples is for me to write tests. Monomorphic mapping is a weird thing, so I don't want people to use it (unless they really need to, in which case it should be moved to stdlib), hence it lives in examples.

This makes me wonder whether we should have chooseList instead of null for consistency (noting that ifThenElse is exactly chooseBool). That would give us a consistent story for "how to do built-in datatypes": have a chooseFoo function and then an unsafeUnConstrX function for each constructor.

I kinda like how if null xs then z else f (head xs) (tail xs) reads, but I wouldn't mind using chooseList. But let's do that separately then.

• Data has a CBOR instance, because it's going to appear in a number of other places in transactions etc, and also it's literally designed to be a subset of CBOR. People may want to generate it using other tools etc.
• We need all types in the builtin universe to have Flat instances, so Data also needs a Flat instance. As Kenneth says, indeed this is so that we could serialize a program with a Data literal in it. For example, the fully-applied scripts produced by the plutus-use-cases-scripts thing will be like that.
• We could give Data a new Flat instance, but given that we already have a way of serializing it, we might as well just dump it in as an opaque serialized bytestring. That has the advantage that you could in principle fish it out and work with it separately, or whatever.