search

haskellfoundation / stability

Issues and proposals related to the HF Stability Working Group
25 stars 2 forks source link

Aeson 1.5-2.0 compat #9

Open tomjaguarpaw opened 2 years ago

tomjaguarpaw commented 2 years ago

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

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 (esp. @bergmark) regarding

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

+1 for a CPP-less migration option!

bergmark commented 2 years ago

I think this is a good addition.

One upside is that it doesn't require usage of a compat package.

The downside is that every major aeson series we wish to support for this migration needs to be amended with this patch. Bounds on dependents would need to be adjusted to e.g. ^>= 1.5.7 || ^>= 2.0. I think that would be fine, as aeson 1.5.x has been out for almost two years and has pretty good backwards compat for its dependencies. And if someone needs more backwards compat on aeson they are free to not use this.

The compat package approach (we could always do both) would allow us to support more versions of aeson (bounds could be simplified to e.g. >= 1 && < 1.6 || ^>= 2.0) with only one release of that package.

FWIW I think that filing this directly against aeson would be better. I'm one of three maintainers but I'm currently the least active one so I think it's better to discuss it over there.

Just noting a detail in case this turns into a full PR: The change should probably be made against the latest 1.5.x commit.

tomjaguarpaw commented 2 years ago

OK, migrated to Aeson at https://github.com/haskell/aeson/pull/932

cdornan commented 2 years ago

Reopening as there seems to be some difference of opinion as to whether this belongs in Aeson.

tomjaguarpaw commented 2 years ago

I think I may not have explained very well what my suggestion actually is. It seems that it was interpreted to be a change to 2.0 to revert making Key and KeyMap abstract.

cdornan commented 2 years ago

Indeed! Context is key -- we all understood what you intended but Oleg will have been missing that context.

Let's discuss later.

On 2022-03-07, at 11:02, tomjaguarpaw @.***> wrote:

I think I may not have explained very well what my suggestion actually is. It seems that it was interpreted to be a change to 2.0 to revert making Key and KeyMap abstract.

— Reply to this email directly, view it on GitHub https://github.com/haskellfoundation/stability/issues/9#issuecomment-1060524115, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG7BSQ24UQVYN2FGLJZ2NLU6XO5TANCNFSM5PPMPETQ. You are receiving this because you modified the open/close state.