ParameterHasEntrypoints doesn't play nice with entryCase
Clarification and motivation
We currently have several standard ways to implement ParameterHasEntrypoints
: EpdNone
, EpdPlain
, EpdRecursive
and EpdDelegate
(also given as options for the entrypointDoc
quasiquoter).
It's possible to use entryCase
(or entryCaseSimple
in some cases) to both pattern-match on such a parameter and also add the documentation accordingly.
However, while there are no issue with the generated docs for "flat"/EpdPlain
entrypoint, there seems to be several hiccups in EpdRecursive
/EpdDelegate
, see this discussion for reference.
Most notably, EpdRecursive
is meant to:
-- In particular, this will traverse sum types recursively, stopping at
-- Michelson primitives (like 'Natural') and constructors with number of
-- fields different from one.
--
-- It does not assign names to intermediate nodes of 'Or' tree, only to the very
-- leaves.
but entryCase
and case_
either produce a documentation with wrapped parameters or one where the intermediate types are treated as entrypoints as well.
Acceptance criteria
There is an easy way to "flatten" a datatype (that uses other datatypes) for the purpose of parameter documentation that:
- does not use intermediate types in the TOC
- does not wrap arguments to call the entrypoints