Open ocharles opened 12 months ago
@ocharles perhaps I'm misunderstanding your question, but it sounds like you should be depending on cborg
directly, rather than using serialise
? Essentially all serialise
includes is the Serialise
class/instances and a few utility functions; all the encoding/decoding stuff lives in cborg
.
Yes and no. I do want access to Serialise
(the class), because then I can easily whip up a decoder for [[Foo]]
, for example. However, cborg
's documentation states:
Note, however, that cborg does not itself aim to be a serialisation library; it merely serves as the substrate on which such a library might be built. See the serialise library if you are looking for convenient serialisation of Haskell values.
Which makes me think I shouldn't directly use cborg
, unless I really need to.
I did also see that https://hackage.haskell.org/package/serialise-0.2.6.1/docs/src/Codec.Serialise.html#deserialise is an actual implementation and not a proxy to something in cborg
, which makes me think I should be using serialise
.
It's also a minor annoyance to need two dependencies, but at the end of the day that's very minor.
So I guess it mostly comes down to either only needing to depend on serialise
. Happy for it to be closed if it doesn't seem worth expanding the API just for that!
I suspect (but have not carefully verified) that there is not much difference in practice between Codec.Serialise.deserialise[OrFail]
vs. Codec.CBOR.Read.deserialiseFromBytes decode
, and I don't think depending on both packages is a big problem. But I do agree that since e.g. Codec.Serialise.Decoding
exposes a Decoder
-based interface, it would make sense for serialise
to expose deserialiseFromBytes
and better encapsulate the cborg
interface.
(A similar issue I've faced is wanting to encode a list [T]
with a custom encoder rather than the one from the Serialise T
instance, where ideally I wanted defaultEncodeList
to be slightly generalised to encodeListWith :: (a -> Encoding) -> [a] -> Encoding
.)
From what I can tell, the
serialise
library requires instances ofSerialise
. This is unfortunate as it requires:Serialise
instances at the point where types are defined, but the project otherwise has no requirement for serialisation. This requires us to pick an encoding in an application that is otherwise not really responsible for serialisation.It would be great if
serialise
hadserialiseEncoding :: Encoding -> ByteString
anddeserialiseWith :: Decoder s a -> Bytestring -> a
.Alternatively, we would need a type that has
id
implementations