Commit Graph

10 Commits

Author SHA1 Message Date
Patrick Lühne a0fefe9b6a
Improve interface for declaration types 2020-05-21 23:19:18 +02:00
Patrick Lühne c7d79e7b07
Make inner types customizable 2020-05-19 15:39:20 +02:00
Patrick Lühne 15d0d2b76c
Work in progress 2020-04-27 19:36:12 +02:00
Patrick Lühne 1e34d726e1
Export formatting implementation functionality 2020-04-14 01:15:02 +02:00
Patrick Lühne 1e610a77fe
Make variable formatting customizable
This introduces a Format trait, which can be implemented to customize
the appearance of variable declarations right now. The Format trait will
be extended with further customization options in the future.
2020-04-14 01:15:02 +02:00
Patrick Lühne 9216bbbe31
Rename formatter variables
These formatter objects were just named “format,” but there’s no need
to abbreviate that. This renames all occurrences to “formatter” for
clarity.
2020-04-13 23:07:54 +02:00
Patrick Lühne d67e530fec
Rewrite formula and term formatting
The rules for determining required parentheses as opposed to parentheses
that can be omitted are more complicated than just showing parentheses
whenever a child expression has lower precedence than its parent. This
necessitated a rewrite.

This new implementation determines whether an expression requires to be
parenthesized with individual rules for each type of expression, which
may or may not depend on the type of the parent expression and the
position of a child within its parent expression. For example,
implication is defined to be right-associative, which means that the
parentheses in the formula

    (F -> G) -> H

cannot be ommitted. When determining whether the subformula (F -> G)
needs to be parenthesized, the new algorithm notices that the subformula
is contained as the antecedent of another implication and concludes that
parentheses are required.

Furthermore, this adds extensive unit tests for both formula and term
formatting. The general idea is to test all types of expressions
individually and, in addition to that, all combinations of parent and
child expression types.

Unit testing made it clear that the formatting of empty and 1-ary
conjunctions, disjunctions, and biconditionals needs to be well-defined
even though these types of formulas may be unconventional. The same
applies to existentially and universally quantified formulas where the
list of parameters is empty. Now, empty conjunctions and biconditionals
are rendered like true Booleans, empty disjunctions like false Booleans,
and 1-ary conjunctions, disjunctions, biconditionals, as well as
quantified expressions with empty parameter lists as their singleton
argument.

The latter formulas can be considered neutral intermediates. That is,
they should not affect whether their singleton arguments are
parenthesized or not. To account for that, all unit tests covering
combinations of formulas are tested with any of those five neutral
intermediates additionally.
2020-04-13 23:07:54 +02:00
Patrick Lühne 7566fdaa29
Support n-ary biconditionals
For convenience, support biconditionals with more than one argument.
An n-ary “if and only if” statement

    F_1 <-> F_2 <-> ... <-> F_n

is to be interpreted as

    F_1 <-> F_2 and F2 <-> F3 and ... and F_(n - 1) <-> F_n
2020-04-13 21:59:25 +02:00
Patrick Lühne 855fd9abcf
Support right-to-left implications
As right-to-left implications are common in answer set programming, this
adds support for using implications in both directions.
2020-04-13 21:44:02 +02:00
Patrick Lühne 5bbb09eef8
Split formatting utils into separate files
For clarity, this moves the formatting functionality related to formulas
and terms into two separate files.
2020-04-09 22:09:15 +02:00