The InsOrdHashMap instances for ToJSON/FromJSON will silently reorder the keys because the data is encoded with a JSON object, and Aeson doesn't support (AFAIK) field-order-preserving decoding of JSON objects. I would expect that a map data structure explicitly designed to preserve entry order would use a field-preserving decoding, but I don't know how to do this in a backwards compatible way. I guess this could be fixed with a breaking change, or maybe with a cabal flag for opting-in to an order-preserving decoding that is not backwards compatible with the object encoding. I would be open to implementing these alternative Aeson instances in a PR if that is something you want.
Here's a simple example to demonstrate:
> Data.Aeson.encode $ fromList [(2, True), (1, False)]
"{\"2\":true,\"1\":false}" -- order is preserved by encoding
> Data.Aeson.decode @(InsOrdHashMap Int Bool) $ Data.Aeson.encode $ InsOrd.fromList [(2, True), (1, False)]
Just (fromList [(1,False),(2,True)]) -- decoding loses order
The InsOrdHashMap instances for ToJSON/FromJSON will silently reorder the keys because the data is encoded with a JSON object, and Aeson doesn't support (AFAIK) field-order-preserving decoding of JSON objects. I would expect that a map data structure explicitly designed to preserve entry order would use a field-preserving decoding, but I don't know how to do this in a backwards compatible way. I guess this could be fixed with a breaking change, or maybe with a cabal flag for opting-in to an order-preserving decoding that is not backwards compatible with the object encoding. I would be open to implementing these alternative Aeson instances in a PR if that is something you want.
Here's a simple example to demonstrate: