How to deal with existing (incompatible) instances?

[paulyoung]

For example, this existing EncodeJSON instance for Either:

instance encodeJsonEither :: (EncodeJson a, EncodeJson b) => EncodeJson (Either a b) where
  encodeJson = either (obj "Left") (obj "Right")
    where
    obj :: forall c. EncodeJson c => String -> c -> Json
    obj tag x =
      fromObject $ FO.fromFoldable $
        Tuple "tag" (fromString tag) : Tuple "value" (encodeJson x) : Nil

[paulyoung]

Maybe is another one.

Right now I'm leaning towards special casing these on the Haskell side, although that seems very error prone.

It would be great if we could have total control over all instances. Perhaps this package should introduce its own type classes?

[kindaro]

Truly Aeson encoding is very complicated and there are many special cases. For example, I checked how Maybe gets encoded.

This is what Haskell gives us:

λ (encode . genericToJSON defaultOptions) (Just 1)
"{\"tag\":\"Just\",\"contents\":1}"
λ encode (Just 1)
"1"

— Already not simple.

This is what PureScript gives:

> (stringify <<< genericEncodeAeson defaultOptions) (Just 1)
"{\"tag\":\"Just\",\"contents\":1}"

> (stringify <<< encodeJson) (Just 1)
"1"

— The first one here is from the present package, and the second is from argonaut-codecs.

In some way, the results line up.

So Paul, can I ask you to explain in more detail what your circumstances are and how exactly things fail?

[paulyoung]

The problems I encountered were with trying to use encodeJson and decodeJson which deferred to the existing instances, like the one in the file I linked to above.

> (stringify <<< encodeJson) (Right 1 :: Either String Int)
"{\"tag\":\"Right\",\"value\":1}"

I think you're saying that the way to ensure the correct encoding is always used is to call genericEncodeAeson and genericDecodeAeson explicitly. I think this makes sense, and it's actually what I'm already doing on the Haskell side.

I immediately run into problems if I try to do this for Either though:

> (stringify <<< genericEncodeAeson defaultOptions) (Right 1 :: Either String Int)
Error found:
in module $PSCI
at <internal>:0:0 - 0:0 (line 0, column 0 - line 0, column 0)

  No type class instance was found for

    Data.Generic.Rep.Generic (Either String Int)
                             t1

  The instance head contains unknown type variables. Consider adding a type annotation.

while checking that expression it
  has type t0
while applying a function eval
  of type Eval t0 => t0 -> Effect Unit
  to argument it
in value declaration $main

where t0 is an unknown type
      t1 is an unknown type

See https://github.com/purescript/documentation/blob/master/errors/NoInstanceFound.md for more information,
or to contribute content related to this error.

I'm not sure what I need to do here.

[kindaro]

So the problem is that one cannot have a generic encoding for Either because it is not an instance of Generic. This appears to be simply an omission, and you may see that I have opened an issue purescript-deprecated/purescript-generics-rep#43 to discuss the possibility of adding the missing instance. The fix is trivial and hopefully will be accomplished in a matter of days. Then you would be able to use the generic encoding.

---

In the mean time, let us to contemplate the other way: to use the «standard» encoding given by encodeJson from Data.Argonaut.Encode.Class. Unfortunately, it is not compatible with either the default or the generic encoding on the Haskell side. See PureScript:

> (stringify <<< encodeJson) (Right 1 :: Either Int Int)
"{\"tag\":\"Right\",\"value\":1}"

— And Haskell:

λ (encode . genericToJSON defaultOptions) (Right 1 :: Either Int Int)
"{\"tag\":\"Right\",\"contents\":1}"
λ encode (Right 1 :: Either Int Int)
"{\"Right\":1}"

The right way to fix this is, as proposed by Paul above, to define a pair of type classes that provide methods for coding things in a way that is compatible with Aeson, then give instances for possibly more «standard» types, such as Maybe, Either and such.

The right place for such classes is a package such as argonaut-aeson with a wider design goal than the present package, which is limited to coding types for which Generic is defined. The classes EncodeAeson and DecodeAeson, currently defined in the present package, would then live there.

Am I up to the task? I am not sure. I see that any non-trivial project using Aeson and PureScript (and I am involved in some such) will eventually want to send around some Either values. But I am not done with #5 yet, so it would be unwise to take more on myself at the present time.