Rework underlying API for encoding/decoding

[neoeinstein]

The current primary interface for using Chiron is based around functions which use statically-resolved type parameters (SRTP). This API should remain in place, but it should instead be based on an API that doesn't rely on SRTP.

• Add symmetric encoder and decoder types:
  • type Decoder<'a> = Json -> JsonResult<'a>
  • type Encoder<'a> = 'a -> Json -> Json
• Extract the default encoder/decoder functions from ToJsonDefaults and FromJsonDefaults into functions under Encode and Decode modules, respectively
• Add monadic and applicative functions for Decoder<'a>
• Add monadic functions for Encoder<'a>
• Create a fromJson {} computation expression, adapted from json {}
• Create a toJson {} computation expression.

[kolektiv]

If we're going to have a fromJson CE (not a bad idea) would it make sense to introduce a toJson CE as well? The json CE would probably remain as a more "general" CE perhaps...

[neoeinstein]

Yeah. I've just been re-looking at the Encoder<'a> type and thinking that it should also accept in the Json context instead of just the function it is now, so as to support "mixin" encoders. If so, then that leads to a toJson {} CE to support that. We could still have the json {} CE supported. Though I'm of two minds on retiring it, I'll default to keeping it supported.

[kolektiv]

The json {} CE does support more than just mapping to/from. With the Json.Optic.* support, etc. it supports querying and modification of JSON structures. There is an argument as to whether that's needed outside of a mapping context, but it does so at the moment...

[neoeinstein]

Right. I can see that. Maybe I just haven't had a use case for doing reading during a ToJson or writing during a FromJson. The Json.Optic.* support is definitely still going to be useful. This may be something that I need to throw against the wall to really see what it looks like.

[neoeinstein]

Ok, I can see a reason for the json {} CE. It exists as a composition of the "state" and "either" monads. What we really need is to "run" the CE. The CE needs to be extended so that it can bind to Encoders and Decoders. That would allow the more direct serialization/deserialization method to live along side the more general-purpose json {} method.

[kolektiv]

Yeah that sounds about right. Your point about reading in a ToJson or writing in a FromJson is completely valid - optics are just general like that. It'll be interesting to see how it works out - I can see ending up with two special case CEs and a general "work with JSON" CE - that might not be a bad thing (I don't tend to use the CEs anyway, but I know they are used).

Saying that does raise one issue in my head. At the moment there's only one type signature for all operations. Breaking that down in to multiple may make the maintenance of operators more complex - you would potentially introduce a requirement to have separate operators for each type. One way round that might be statically resolved operators, but it remains to be seen...