1.5-2.0 compat suggestion

[tomjaguarpaw]

Here is a suggestion for an Aeson 1.5-2.0 compatibilty story. The technique is simple: take Aeson 2.0 and change the version 2 abstract types to type synonyms as below (plus chasing up the ensuing, minor, type errors).

• Since neither 1.5.6.0 nor 2.0.0.0 have branches associated with them I had to target this PR at master. See my branch and the full diff for a much clearer view of what changes this entails.

This backports the 2.0 API to 1.5, and ought to allow Aeson users to write code that works at the same time against version 1.5 and version 2.0, providing a smooth upgrade path and avoiding the need for a "big bang" switch of the entire Aeson ecosystem at once.

-newtype Key = Key { unKey :: Text }
+type Key = Text

-newtype KeyMap v = KeyMap { unKeyMap :: Map Key v }
+type KeyMap v = Map Key v

I don't actually use Aeson myself, so I would welcome the input of Aeson users and maintainers egarding

1. whether this is actually useful, and if so
2. whether I've got everything correct (the tests pass)

• Should this idea be accepted we'd have to come up with a plan for how it should actually be integrated into the repo. Perhaps a long-lived feature branch? I'm happy to retarget this PR at whatever commit makes sense to you.

[phadej]

The idea was to make Key and KeyMap abstract, so their implementation can be changed without affecting external interface(Map or HashMap or Trie or ...)

[tomjaguarpaw]

Could you please take another look? The target of this PR is the 1.5 branch not the 2.0 branch. It is a backport of the 2.0 API to 1.5, where the Key and KeyMap types are not abstract.

EDIT: rather than "target" perhaps I should say "the aim of this PR is to be released in the 1.5 series".

[bergmark]

@phadej I think the point here was to do a patch release of 1.5.x with this forwards compatible shim. I have some dedicated time this weeekend, would you mind if I made a 1.5.7.0 release for this?

I'll reopen this until we make a decision.

[phadej]

@bergmark, I won't use my time on aeson-1.5. I'd advice people just drop aeson-1.5 support instead. (Now as Stackage nightly has updated to use it).

[bergmark]

@phadej that's fine! I wasn't expecting you to put any effort into this.

@tomjaguarpaw I found your 1.5-2.0-compat-on-1.5.6.0 branch and tried it out by removing the CPP from persistent. It works! However looking at the diff, it's hard for me to say what the changes would be if it was released as 1.5.7.0. There is at least one breaking changes included (the removal of the Data.Aeson.Encode module) so that would need to be reverted.

[bergmark]

Should this idea be accepted we'd have to come up with a plan for how it should actually be integrated into the repo. Perhaps a long-lived feature branch? I'm happy to retarget this PR at whatever commit makes sense to you.

We git tag our releases. I created a v1.5.6.0 branch from that which can be targeted by github PRs.

[tomjaguarpaw]

It's great that it works! I can retarget my branch at v1.5.6.0 and then we can see what else needs to be done.

[tomjaguarpaw]

OK, retargeted. This is a big change, but hopefully it makes it clear what the impact is. Do you want to take it from here @bergmark or would you still like my help with something?

[bergmark]

I reverted some of the breaking changes and pushed that to the compat branch (it doesn't compile). The tricky thing that I missed before was

type KeyMap v = Map Key v

I think this has to change to HashMap to stay compatible with 1.5, and that requires a bunch of other changes to be compatible. I might take another look later see if this can be puzzled out.

[phadej]

This change looks too big. It's very hard to verify there aren't accidental breaking changes. I'd suggest to not touch anything that is not required, i.e. no changes from Text to Key in other modules etc.

Just add a compatibility module, and tests that they work.

(I still think this is wasted work to begin with, so don't make it any more burden to maintain).

[m4dc4p]

Really wish this had gone through. Aeson 1.5 no longer compiles with GHC 9.2.2, forcing us to upgrade to 2.0. Having a compat shim would make that so much simpler.

[ysangkok]

@m4dc4p You can easily have Aeson 1.5 compile on 9.2 with this patch: https://github.com/haskell/aeson/pull/935/files