Vicente J. Botet Escriba
[...]
My concern was about documenting these more generic cases as Hana has made the decision to document the models of relationship. Both will are subject to the same problems, this information can not be complete, but it can be for the types and concepts in Hana.
That is correct; we could at least provide an exhaustive list of sub-concepts provided by Hana. It is also true that the "concrete models" are subject to the same problem, since models can be added without Hana's knowledge. That went under my radar when I gave the (2) argument, since Hana provides a (non-exhaustive) list of the concrete models.
Another example that is not missing as Hana don't see Optional as a Monoid. Imagine that it was the case, and Hana contained a such a mapping.
I would find normal to find this in the Optional documentation on the section Modeled concepts
Monoid(T) => Monoid(Optional(T))
The question is if this should also appear as well a on the Monoid one.
That is a bit different because Optional is a data type and Monoid is a concept. Instead, if that was something like Monoid(T), SomeConcept(F) => Monoid(F(T)) I think I would just expect to see this on the Monoid's documentation, not on SomeConcept's. This is how Haskell's documentation works, anyway.
P.S. All this is no more than a cross reference between the Concepts and the models.
I thought it was cross-referencing between the super- and sub- concepts? Cross-referencing between concepts and models is already done: - Concepts have a list of their models - Data types have a list of the concepts they are a model of
P.S.S. I recognize that maintaining this information manually is subject to errors, but I know that we are talking with experts that know how to generate these kind of cross reference information automatically
Lol. I think it's time for me to move away from Doxygen. I literally have __no clue__ how to do this with Doxygen, or if it's even possible. Regards, Louis