Fix termdefs for specialised types

[andrevidela]

The last PR allows to generate specialised type signatures in haskell but does not allow them to be serialized and deserialized.

for example

(name intList (mu (Nil 1) (Cons (* (ref int) (var 0)))

the type will be correctly generated

data IntList = Nil | Cons Int IntList

but the serializer will fail since it will rely on int having a serializer function which is doesnt.

encodeList :: Serialiser IntList
encodeList encode Nil = word8 (fromIntegral 0)
encodeList encode (Cons x x0) = mconcat [(word8 (fromIntegral 1)),(encodeInt x),(encodeList x0)]

but encodeInt isn't defined anywhere.

Should we:

• generate encodeInt as part of the term definition and generate code for this?
• write a Haskell library with the relevant functions and import it inside the generated file?

edit:

let's go for built-in types first and open up an API for library types later (this will be a lot more work). Once library types are supported we can release the built-in types as a "prelude" of some sort.

[andrevidela]

I would personally vote for the 1st one at least as a first implementation of the solution. It reduces the amount of moving parts and fits in the existing framework we're working with.

The second solution might be viable once we implement #167 and/or #188

what do you think @fredrikNordvallForsberg @clayrat ?

[fredrikNordvallForsberg]

Amazing how the generated type even fixed the typo in "intLint"! ;-) more seriously, I'm not sure exactly what you mean: obviously the user has to give some more information, because we don't know what int is, so cannot generate serialisation code for it. The easiest thing to do would be to extend the specialisation interface to require the name of the encoding and decoding functions, is this what you meant?

At first, I was worried that the users then need to know our binary serialisation format, but after some thought, I think it is okay: the user can use whatever schema they want, since serialisation is type directed. So even if they have their own format, as long as we consistently deploy their functions, we will never notice.

[andrevidela]

Amazing how the generated type even fixed the typo in "intLint"! ;-)

My copy paste could use some improvement :)

There are two issues at hand:

• User defined types
• primitively defined types

In the first case I think what you propose (asking for a name and encoding/decoding functions) would work but I fear it would be too cumbersome to use in practice. I would advocate for something more automated like asking them to implement an orphan instances (maybe combining it with #188)

In the second case, we already know how to generate serialisation functions for types like Int, List, Maybe etc, we could already provide those through the specialisation mechanism. My comment was essentially addressing this concern. Should we provide them with generated core, or should we provide them with a library?

the user can use whatever schema they want, since serialisation is type directed.

I personally can't wait until a user mixes and matches JSON, XML and binary formats in the same typedefs

[andrevidela]

I personally can't wait until a user mixes and matches JSON, XML and binary formats in the same typedefs

spoilers: I might be that user

[andrevidela]

@fredrikNordvallForsberg ping

[fredrikNordvallForsberg]

Sorry, I didn't realise that you were waiting for input from me... I would say that shipping serialisation functions for Int etc in the generated code only makes sense if these specialisations are also "builtin", otherwise the library route seems to be the obvious choice to me.

Did I miss to comment on anything else?

[andrevidela]

@fredrikNordvallForsberg alright, since we aren't implementing library types immediately I'll add them as "built-in", they should be easy to update to "library-imports" once the "typedefs library" api is created.

I dont think you missed anything, thank you for your help!