Rework underlying API for encoding/decoding about chiron HOT 6 OPEN

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...

from chiron.

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.

from chiron.

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...

from chiron.

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.

from chiron.

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.

from chiron.

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...

from chiron.