No. It’s a more complicated structure because you need the return type of the application when you apply members. The return type is used by member specifications to specify the projection function used on the result of the application when it’s time to encode back to JSON.
It all started with a simple applicative for decoding generic JSON in memory, but as I wrote here I was frustrated that these applicative decodes specifications would not allow me to encode. Having solved the encode (an the ability to support a few other JSON object codec patterns) I lost the obvious applicative on the way – and my attempts at reframing it as an applicative were not successful.
Now @art-w with some contorsions managed to reframe it as an applicative. But in my enthusiasm for his proposal I failed to see that it seems that he his repeatedly constructing pairs for applying the object constructor which I’m not really happy with as it brings quite a few more allocations for object construction that are not there with the API I settled on. I will have a look in the upcoming days if we keep the current way or switch to @art-w’s scheme.