In amazonka-emr-containers, there is the following set of mutually-recursive shapes:
Configuration contains ConfigurationList and a Sensitive field.
ConfigurationList contains Configuration
Under #862 , the map of shapes was populated in such a way that ConfigurationList held a Ptr to Configuration, which meant that it generated a deriving clause containing a static set of class names, including Read. This fails to compile, as Configuration contains a Sensitive field, and so cannot have a Read instance.
The correct fix is to determine the set of deriving clauses by constraint solving — https://github.com/endgame/amazonka/commit/bdcba74b64d536d303be99cf9ecdd781766c770d was an attempt at this, but I am abandoning it after a week and a half because it's still broken. Supporting #872 will require a serious re-architecting of the generator anyway, so let's do it properly:
[X] Build out a botocore library which is a direct representation of the data files provided by AWS - service, paginators, waiters, and the new endpoint-rule-set type.
[ ] Add some sort of "JSON deep-merge" functionality to botocore to support the splicing in of annexes.
[ ] Rewrite the generator to read from botocore types
[ ] Rewrite the generator to use botocore, and differentiate each stage (classifying shapes; applying renames/overrides; generating code)
[ ] Consider a more modern lib than haskell-src-exts for code generation (maybe ghc-exactprint?)
[ ] Kill the cofree comonad of shapes once and for all. it was a defensible idea when the inclusion graph of shape definitions was a DAG, but that has not been true for a very long time. If every shape reference is handled as if it were a Ptr by looking it up in a MonadReader context, edge cases like this will stop happening.
In
amazonka-emr-containers
, there is the following set of mutually-recursive shapes:Configuration
containsConfigurationList
and aSensitive
field.ConfigurationList
containsConfiguration
Under #862 , the map of shapes was populated in such a way that
ConfigurationList
held aPtr
toConfiguration
, which meant that it generated aderiving
clause containing a static set of class names, includingRead
. This fails to compile, asConfiguration
contains aSensitive
field, and so cannot have aRead
instance.The correct fix is to determine the set of deriving clauses by constraint solving — https://github.com/endgame/amazonka/commit/bdcba74b64d536d303be99cf9ecdd781766c770d was an attempt at this, but I am abandoning it after a week and a half because it's still broken. Supporting #872 will require a serious re-architecting of the generator anyway, so let's do it properly:
botocore
library which is a direct representation of the data files provided by AWS - service, paginators, waiters, and the new endpoint-rule-set type.botocore
to support the splicing in of annexes.botocore
typesbotocore
, and differentiate each stage (classifying shapes; applying renames/overrides; generating code)haskell-src-exts
for code generation (maybeghc-exactprint
?)Ptr
by looking it up in aMonadReader
context, edge cases like this will stop happening.