Changes to Logical classes

[ariadne-cps]

Changes to Logical classes

[lgeretti]

Original comment by Pieter Collins (Bitbucket: pietercollins, GitHub: pietercollins)

---

I've updated the docs; hope this answers your questions.

[lgeretti]

Original comment by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

---

Some questions:

1. The relationship between Approximate and Naive is not so clear from the doc. Does for example ApproximateKleenean relate to NaiveKleenean as ValidatedKleenean does to Kleenean?

2. I do not understand when a method should return an Effective type rather than a Validated one.

3. When can we neglect to specify the Effort, if we return a Validated type?

[lgeretti]

Original comment by Pieter Collins (Bitbucket: pietercollins, GitHub: pietercollins)

---

I've made a first implementation (in working-logical) including documentation; please let me know what you think.

The implementation uses custom classes at the user level rather than templates and typedefs. However, there are some generic constructs in use here, and it may be worth seeing to what extent these can be exploited:

• Kleenean is OrderCompletion, just as Real is an Order/MetricCompletion.
• We have Lower/Upper classes, just as Lower/Upper, and a Negated.
• We have a relationship between Effective, Validated and Approximate classes.

[lgeretti]

Original comment by Luca Geretti (Bitbucket: lgeretti, GitHub: lgeretti)

---

I am favorable to a more detailed definition of the logical classes and their enforcement throughout the library. So every development towards it is welcome. In general I am against typedefs, so custom classes are ok with me. Could you use this chance to write down a strong definition of their semantics in the API docs, when you write the classes? I am still at a loss regarding their specific role within the library, and a good hint on their proper usage would be nice.

[lgeretti]

What is the status of this issue?