OKlibrary  0.2.1.6
Literals.hpp File Reference

Plans for concepts for literals. More...

Go to the source code of this file.


Detailed Description

Plans for concepts for literals.

Todo:
Arity
  • Now actually it seems best to have literals with arity n.
  • This is accomplished by using the generalised AtomicConditions-concept (see Concepts/plans/AtomicConditions.hpp), and by generalising traits::var_type so that is actually returns a tuple type (of the same arity as the value-tuple-type in traits::cond_type).
  • For arity 1 there should be also short-cuts, so that the current syntax works (can this be accomplished? there is no conversion from an unary tuple to its value-type?)
Todo:
Generalised literals:
  • More general than above under "Arity" perhaps there should be four types of literals:
    • Unary literals (as the current concept of Literal)
    • Binary literals
    • Literals with arity (that is, with a variable tuple; as under "Arity"); perhaps only allowing arities >= 3 here?
    • Literals with variable sequence (that is, arbitrary and dynamic arities)
  • Literals without atomic conditions:
    • For the case the literal does not need a full-fledged atomic condition, but just expresses a certain fixed relation about the variables (for example "equality" or "disequality"), there is an associated type "literal_type<Lit>::type" usable for tagging-polymorphism.
    • But perhaps the atomic condition should always be available, only for certain literal-types it's not really needed.
    • These literal-types might sometimes make sense only for certain arities (but equality and disequality make sense for arbitrary arities).
  • For unary literals we could have the forms
    • mono-valued (represented by one value)
    • segment-valued (also represented by one value)
    • internal-value (represented by two values)
    • multi-value (represented by sets of values)
    where for the second and third form we could furthermore distinguish between the open and the closed segments resp. intervals.
  • Perhaps a general form of literals does not have negation, but there is a refinement "with_complement". Potentially one could also have the forms "positive" and "negative", which would help for example with equality-literals (the disequality would be the negative form). For the first 3 forms of unary literals the positive and negative forms would be meaningful (while the fourth form is with_complement). So we would have a hierarchy with "no_complement" as the root, two derived forms "positive", "negative", and from both we derive "with_complement" (is this meaningful? perhaps all three forms should be derived directly from the root). For partial assignments we need a distinction between "(potential) decision literals" and "non-decision literals", where the decision literals need negation, but the others do not.
Todo:
Requirements literals
  • It seems best that only refined versions of Literals offer operation static_cast<cond_type&>(OKlib::Literals::cond(l)); while for general literals we have only set_cond(x, cond). On the other hand, not all literal-types allow changing the condition? So perhaps changing the condition is only available for special literal types.
  • A general question is whether literals are assumed to be easily copyable, or should we pass them by reference? For literals like integers, we should pass them by value, but for literals representing sets we should pass them by reference?! So do we need to employ a traits function, which decides whether to pass by value or const reference? Seems to be the case, but would make writing functions using literals a bit more complicated. First we pass them by const reference, and then later we'll see.
  • Out of literals we make partial assignments (DNF-clauses) and (CNF-)clauses.

Definition in file Literals.hpp.