unicode-fol-kit 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- unicode_fol_kit-0.1.0/.gitattributes +2 -0
- unicode_fol_kit-0.1.0/.gitignore +182 -0
- unicode_fol_kit-0.1.0/LICENSE +21 -0
- unicode_fol_kit-0.1.0/PKG-INFO +302 -0
- unicode_fol_kit-0.1.0/README.md +291 -0
- unicode_fol_kit-0.1.0/pyproject.toml +18 -0
- unicode_fol_kit-0.1.0/requirements.txt +9 -0
- unicode_fol_kit-0.1.0/test.py +7 -0
- unicode_fol_kit-0.1.0/unicode_fol_kit/__init__.py +17 -0
- unicode_fol_kit-0.1.0/unicode_fol_kit/atp/__init__.py +4 -0
- unicode_fol_kit-0.1.0/unicode_fol_kit/atp/prover9_entailment.py +70 -0
- unicode_fol_kit-0.1.0/unicode_fol_kit/atp/z3_equivalence.py +22 -0
- unicode_fol_kit-0.1.0/unicode_fol_kit/fol/__init__.py +15 -0
- unicode_fol_kit-0.1.0/unicode_fol_kit/fol/folparser.py +21 -0
- unicode_fol_kit-0.1.0/unicode_fol_kit/fol/naming.py +174 -0
- unicode_fol_kit-0.1.0/unicode_fol_kit/fol/nodes.py +779 -0
- unicode_fol_kit-0.1.0/unicode_fol_kit/fol/syntax.lark +76 -0
|
@@ -0,0 +1,182 @@
|
|
|
1
|
+
# Byte-compiled / optimized / DLL files
|
|
2
|
+
__pycache__/
|
|
3
|
+
*.py[cod]
|
|
4
|
+
*$py.class
|
|
5
|
+
|
|
6
|
+
# C extensions
|
|
7
|
+
*.so
|
|
8
|
+
|
|
9
|
+
# Distribution / packaging
|
|
10
|
+
.Python
|
|
11
|
+
build/
|
|
12
|
+
develop-eggs/
|
|
13
|
+
dist/
|
|
14
|
+
downloads/
|
|
15
|
+
eggs/
|
|
16
|
+
.eggs/
|
|
17
|
+
lib/
|
|
18
|
+
lib64/
|
|
19
|
+
parts/
|
|
20
|
+
sdist/
|
|
21
|
+
var/
|
|
22
|
+
wheels/
|
|
23
|
+
share/python-wheels/
|
|
24
|
+
*.egg-info/
|
|
25
|
+
.installed.cfg
|
|
26
|
+
*.egg
|
|
27
|
+
MANIFEST
|
|
28
|
+
|
|
29
|
+
# PyInstaller
|
|
30
|
+
# Usually these files are written by a python script from a template
|
|
31
|
+
# before PyInstaller builds the exe, so as to inject date/other infos into it.
|
|
32
|
+
*.manifest
|
|
33
|
+
*.spec
|
|
34
|
+
|
|
35
|
+
# Installer logs
|
|
36
|
+
pip-log.txt
|
|
37
|
+
pip-delete-this-directory.txt
|
|
38
|
+
|
|
39
|
+
# Unit test / coverage reports
|
|
40
|
+
htmlcov/
|
|
41
|
+
.tox/
|
|
42
|
+
.nox/
|
|
43
|
+
.coverage
|
|
44
|
+
.coverage.*
|
|
45
|
+
.cache
|
|
46
|
+
nosetests.xml
|
|
47
|
+
coverage.xml
|
|
48
|
+
*.cover
|
|
49
|
+
*.py,cover
|
|
50
|
+
.hypothesis/
|
|
51
|
+
.pytest_cache/
|
|
52
|
+
cover/
|
|
53
|
+
|
|
54
|
+
# Translations
|
|
55
|
+
*.mo
|
|
56
|
+
*.pot
|
|
57
|
+
|
|
58
|
+
# Django stuff:
|
|
59
|
+
*.log
|
|
60
|
+
local_settings.py
|
|
61
|
+
db.sqlite3
|
|
62
|
+
db.sqlite3-journal
|
|
63
|
+
|
|
64
|
+
# Flask stuff:
|
|
65
|
+
instance/
|
|
66
|
+
.webassets-cache
|
|
67
|
+
|
|
68
|
+
# Scrapy stuff:
|
|
69
|
+
.scrapy
|
|
70
|
+
|
|
71
|
+
# Sphinx documentation
|
|
72
|
+
docs/_build/
|
|
73
|
+
|
|
74
|
+
# PyBuilder
|
|
75
|
+
.pybuilder/
|
|
76
|
+
target/
|
|
77
|
+
|
|
78
|
+
# Jupyter Notebook
|
|
79
|
+
.ipynb_checkpoints
|
|
80
|
+
|
|
81
|
+
# IPython
|
|
82
|
+
profile_default/
|
|
83
|
+
ipython_config.py
|
|
84
|
+
|
|
85
|
+
# pyenv
|
|
86
|
+
# For a library or package, you might want to ignore these files since the code is
|
|
87
|
+
# intended to run in multiple environments; otherwise, check them in:
|
|
88
|
+
# .python-version
|
|
89
|
+
|
|
90
|
+
# pipenv
|
|
91
|
+
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
|
|
92
|
+
# However, in case of collaboration, if having platform-specific dependencies or dependencies
|
|
93
|
+
# having no cross-platform support, pipenv may install dependencies that don't work, or not
|
|
94
|
+
# install all needed dependencies.
|
|
95
|
+
#Pipfile.lock
|
|
96
|
+
|
|
97
|
+
# UV
|
|
98
|
+
# Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
|
|
99
|
+
# This is especially recommended for binary packages to ensure reproducibility, and is more
|
|
100
|
+
# commonly ignored for libraries.
|
|
101
|
+
#uv.lock
|
|
102
|
+
|
|
103
|
+
# poetry
|
|
104
|
+
# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
|
|
105
|
+
# This is especially recommended for binary packages to ensure reproducibility, and is more
|
|
106
|
+
# commonly ignored for libraries.
|
|
107
|
+
# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
|
|
108
|
+
#poetry.lock
|
|
109
|
+
|
|
110
|
+
# pdm
|
|
111
|
+
# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
|
|
112
|
+
#pdm.lock
|
|
113
|
+
# pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
|
|
114
|
+
# in version control.
|
|
115
|
+
# https://pdm.fming.dev/latest/usage/project/#working-with-version-control
|
|
116
|
+
.pdm.toml
|
|
117
|
+
.pdm-python
|
|
118
|
+
.pdm-build/
|
|
119
|
+
|
|
120
|
+
# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
|
|
121
|
+
__pypackages__/
|
|
122
|
+
|
|
123
|
+
# Celery stuff
|
|
124
|
+
celerybeat-schedule
|
|
125
|
+
celerybeat.pid
|
|
126
|
+
|
|
127
|
+
# SageMath parsed files
|
|
128
|
+
*.sage.py
|
|
129
|
+
|
|
130
|
+
# Environments
|
|
131
|
+
.env
|
|
132
|
+
.venv
|
|
133
|
+
env/
|
|
134
|
+
venv/
|
|
135
|
+
ENV/
|
|
136
|
+
env.bak/
|
|
137
|
+
venv.bak/
|
|
138
|
+
|
|
139
|
+
# Spyder project settings
|
|
140
|
+
.spyderproject
|
|
141
|
+
.spyproject
|
|
142
|
+
|
|
143
|
+
# Rope project settings
|
|
144
|
+
.ropeproject
|
|
145
|
+
|
|
146
|
+
# mkdocs documentation
|
|
147
|
+
/site
|
|
148
|
+
|
|
149
|
+
# mypy
|
|
150
|
+
.mypy_cache/
|
|
151
|
+
.dmypy.json
|
|
152
|
+
dmypy.json
|
|
153
|
+
|
|
154
|
+
# Pyre type checker
|
|
155
|
+
.pyre/
|
|
156
|
+
|
|
157
|
+
# pytype static type analyzer
|
|
158
|
+
.pytype/
|
|
159
|
+
|
|
160
|
+
# Cython debug symbols
|
|
161
|
+
cython_debug/
|
|
162
|
+
|
|
163
|
+
# PyCharm
|
|
164
|
+
# JetBrains specific template is maintained in a separate JetBrains.gitignore that can
|
|
165
|
+
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
|
|
166
|
+
# and can be added to the global gitignore or merged into this file. For a more nuclear
|
|
167
|
+
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
|
|
168
|
+
#.idea/
|
|
169
|
+
|
|
170
|
+
# Ruff stuff:
|
|
171
|
+
.ruff_cache/
|
|
172
|
+
|
|
173
|
+
# PyPI configuration file
|
|
174
|
+
.pypirc
|
|
175
|
+
|
|
176
|
+
# Cursor
|
|
177
|
+
# Cursor is an AI-powered code editor.`.cursorignore` specifies files/directories to
|
|
178
|
+
# exclude from AI features like autocomplete and code analysis. Recommended for sensitive data
|
|
179
|
+
# refer to https://docs.cursor.com/context/ignore-files
|
|
180
|
+
.cursorignore
|
|
181
|
+
.cursorindexingignore
|
|
182
|
+
.claude
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Felix Vossel
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
|
@@ -0,0 +1,302 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: unicode-fol-kit
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: Parser and toolkit for first-order logic formulas using Unicode operators
|
|
5
|
+
License: MIT
|
|
6
|
+
License-File: LICENSE
|
|
7
|
+
Requires-Python: >=3.10
|
|
8
|
+
Requires-Dist: lark>=1.1
|
|
9
|
+
Requires-Dist: z3-solver>=4.12
|
|
10
|
+
Description-Content-Type: text/markdown
|
|
11
|
+
|
|
12
|
+
# unicode-fol-kit
|
|
13
|
+
|
|
14
|
+
A Python toolkit for parsing and working with first-order logic (FOL) formulas written with Unicode operators.
|
|
15
|
+
|
|
16
|
+
## Features
|
|
17
|
+
|
|
18
|
+
- **Parser** — parse FOL formulas using natural Unicode symbols (∀, ∃, ∧, ∨, ¬, →, ↔, ⊕, =, ≠, ≤, ≥)
|
|
19
|
+
- **AST** — full abstract syntax tree with all standard FOL constructs
|
|
20
|
+
- **Serialisation** — convert formulas to/from JSON dictionaries
|
|
21
|
+
- **Tree view** — render any formula as a readable ASCII tree
|
|
22
|
+
- **Z3 export** — translate formulas to Z3 expressions for SMT solving
|
|
23
|
+
- **Prover9 export** — translate formulas to Prover9 syntax for automated theorem proving
|
|
24
|
+
- **TPTP export** — translate formulas to TPTP syntax
|
|
25
|
+
- **Equivalence checking** — check if two formulas are logically equivalent via Z3
|
|
26
|
+
- **Entailment checking** — check if a conclusion follows from premises via Prover9
|
|
27
|
+
|
|
28
|
+
## Installation
|
|
29
|
+
|
|
30
|
+
### Via pip
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
pip install unicode-fol-kit
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
### Via git clone
|
|
37
|
+
|
|
38
|
+
```bash
|
|
39
|
+
git clone https://github.com/felixvossel/unicode-fol-kit.git
|
|
40
|
+
cd unicode-fol-kit
|
|
41
|
+
pip install .
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
## Usage
|
|
45
|
+
|
|
46
|
+
### Parsing a formula
|
|
47
|
+
|
|
48
|
+
```python
|
|
49
|
+
from unicode_fol_kit import FOLParser
|
|
50
|
+
|
|
51
|
+
parser = FOLParser()
|
|
52
|
+
formula = parser.parse("∀x (Human(x) → Mortal(x))")
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
### ASCII tree view
|
|
56
|
+
|
|
57
|
+
```python
|
|
58
|
+
print(formula.tree_str())
|
|
59
|
+
# ∀ x
|
|
60
|
+
# └── →
|
|
61
|
+
# ├── Atom: Human
|
|
62
|
+
# │ └── Variable: x
|
|
63
|
+
# └── Atom: Mortal
|
|
64
|
+
# └── Variable: x
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
### Exporting to other formats
|
|
68
|
+
|
|
69
|
+
```python
|
|
70
|
+
formula.to_prover9() # '(all x (Human(x) -> Mortal(x)))'
|
|
71
|
+
formula.to_tptp() # '(![X]: (human(X) => mortal(X)))'
|
|
72
|
+
formula.to_dict() # JSON-serialisable dict
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
### Serialisation
|
|
76
|
+
|
|
77
|
+
```python
|
|
78
|
+
from unicode_fol_kit import Node
|
|
79
|
+
|
|
80
|
+
d = formula.to_dict()
|
|
81
|
+
formula2 = Node.from_dict(d) # round-trip
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
### Equivalence checking (Z3)
|
|
85
|
+
|
|
86
|
+
```python
|
|
87
|
+
from unicode_fol_kit import FOLParser, formulas_are_equivalent
|
|
88
|
+
|
|
89
|
+
parser = FOLParser()
|
|
90
|
+
f1 = parser.parse("¬(P(x) ∧ Q(x))")
|
|
91
|
+
f2 = parser.parse("¬P(x) ∨ ¬Q(x)")
|
|
92
|
+
|
|
93
|
+
formulas_are_equivalent(f1, f2) # True
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
### Entailment checking (Prover9)
|
|
97
|
+
|
|
98
|
+
```python
|
|
99
|
+
from unicode_fol_kit import FOLParser, check_logical_entailment
|
|
100
|
+
|
|
101
|
+
parser = FOLParser()
|
|
102
|
+
premises = [
|
|
103
|
+
parser.parse("∀x (Human(x) → Mortal(x))"),
|
|
104
|
+
parser.parse("Human(socrates)"),
|
|
105
|
+
]
|
|
106
|
+
conclusion = parser.parse("Mortal(socrates)")
|
|
107
|
+
|
|
108
|
+
check_logical_entailment(premises, conclusion, prover9_path="/usr/bin/prover9") # True
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
## Syntax reference
|
|
112
|
+
|
|
113
|
+
This section describes the full surface syntax accepted by the parser: which
|
|
114
|
+
symbols are recognised, how terms and formulas are built, and how operator
|
|
115
|
+
precedence and associativity resolve ambiguous input.
|
|
116
|
+
|
|
117
|
+
### Tokens
|
|
118
|
+
|
|
119
|
+
The lexer distinguishes the following kinds of identifier, each by a strict
|
|
120
|
+
pattern. Because the categories are separated at the token level, a given
|
|
121
|
+
identifier is unambiguously a variable, a constant, a function/predicate name,
|
|
122
|
+
or a number.
|
|
123
|
+
|
|
124
|
+
| Token | Pattern | Examples | Meaning |
|
|
125
|
+
|---|---|---|---|
|
|
126
|
+
| Variable | one lowercase letter, optional trailing digits | `x`, `y`, `x1`, `z42` | a (possibly bound) logical variable |
|
|
127
|
+
| Name | lowercase, at least two letters, may contain digits and uppercase after the first letter | `socrates`, `distance`, `centerOf`, `foo1` | a constant or a function symbol |
|
|
128
|
+
| Constant (`c_`) | `c_` followed by letters/digits | `c_a`, `c_zero`, `c_42` | an explicitly marked constant |
|
|
129
|
+
| Predicate | one uppercase letter, then letters/digits | `P`, `Human`, `OnSurfaceOf` | a predicate symbol |
|
|
130
|
+
| Number | digits, optional decimal part | `0`, `42`, `3.14` | a numeric literal |
|
|
131
|
+
|
|
132
|
+
The `c_` form exists so that **single-letter constants** can be written without
|
|
133
|
+
colliding with variables. A bare `a` is always a variable; if you need the
|
|
134
|
+
constant *a*, write `c_a`.
|
|
135
|
+
|
|
136
|
+
A function or predicate is recognised by being immediately followed by a
|
|
137
|
+
parenthesised argument list, e.g. `distance(x, y)` or `Human(socrates)`.
|
|
138
|
+
The same identifier class (Name) serves both as a bare constant and, when
|
|
139
|
+
applied, as a function symbol.
|
|
140
|
+
|
|
141
|
+
### Terms
|
|
142
|
+
|
|
143
|
+
A term is one of:
|
|
144
|
+
|
|
145
|
+
- a variable (`x`, `x1`)
|
|
146
|
+
- a constant (`socrates`, `c_a`) or number (`42`, `3.14`)
|
|
147
|
+
- a function application (`f(t1, ..., tn)`, e.g. `centerOf(x)`)
|
|
148
|
+
- an arithmetic combination of terms using `+`, `-`, `*`, `/`
|
|
149
|
+
- a parenthesised term (`(t)`)
|
|
150
|
+
|
|
151
|
+
Arithmetic follows the usual precedence: `*` and `/` bind tighter than `+` and
|
|
152
|
+
`-`, and both groups are left-associative. For example `x + y * z` parses as
|
|
153
|
+
`x + (y * z)`.
|
|
154
|
+
|
|
155
|
+
### Atomic formulas
|
|
156
|
+
|
|
157
|
+
An atomic formula is either:
|
|
158
|
+
|
|
159
|
+
- a predicate applied to terms: `P`, `Human(socrates)`, `OnSurfaceOf(y, x)`
|
|
160
|
+
(a predicate may be nullary, i.e. used without arguments)
|
|
161
|
+
- an infix comparison between two terms using `=`, `≠`, `<`, `>`, `≤`, `≥`,
|
|
162
|
+
e.g. `x1 + 1 = y1` or `distance(y, c) > distance(z, c)`
|
|
163
|
+
|
|
164
|
+
### Compound formulas
|
|
165
|
+
|
|
166
|
+
Atomic formulas are combined with the logical connectives and quantifiers:
|
|
167
|
+
|
|
168
|
+
- negation: `¬φ`
|
|
169
|
+
- conjunction: `φ ∧ ψ`
|
|
170
|
+
- disjunction: `φ ∨ ψ`
|
|
171
|
+
- exclusive or: `φ ⊕ ψ`
|
|
172
|
+
- implication: `φ → ψ`
|
|
173
|
+
- biconditional: `φ ↔ ψ`
|
|
174
|
+
- universal quantification: `∀x φ`
|
|
175
|
+
- existential quantification: `∃x φ`
|
|
176
|
+
|
|
177
|
+
A formula may be wrapped in parentheses `( … )` or square brackets `[ … ]`;
|
|
178
|
+
the two are interchangeable for grouping.
|
|
179
|
+
|
|
180
|
+
### Operator precedence
|
|
181
|
+
|
|
182
|
+
From highest (binds tightest) to lowest (binds loosest):
|
|
183
|
+
|
|
184
|
+
| Precedence | Operators | Associativity |
|
|
185
|
+
|---|---|---|
|
|
186
|
+
| 1 (highest) | `¬`, quantifiers `∀` / `∃` | prefix |
|
|
187
|
+
| 2 | `∧`, `∨`, `⊕` | left |
|
|
188
|
+
| 3 | `→` | right |
|
|
189
|
+
| 4 (lowest) | `↔` | right |
|
|
190
|
+
|
|
191
|
+
Worked examples (parenthesised to show how the parser groups them):
|
|
192
|
+
|
|
193
|
+
- `¬P(x) ∧ Q(x)` → `(¬P(x)) ∧ Q(x)` — negation binds tighter than conjunction
|
|
194
|
+
- `P(x) ∧ Q(x) → R(x)` → `(P(x) ∧ Q(x)) → R(x)` — conjunction binds tighter than implication
|
|
195
|
+
- `P(x) → Q(x) ↔ R(x)` → `(P(x) → Q(x)) ↔ R(x)` — implication binds tighter than biconditional
|
|
196
|
+
- `P(x) → Q(x) → R(x)` → `P(x) → (Q(x) → R(x))` — implication is right-associative
|
|
197
|
+
- `P(x) ∧ Q(x) ∧ R(x)` → `(P(x) ∧ Q(x)) ∧ R(x)` — conjunction is left-associative
|
|
198
|
+
|
|
199
|
+
### Mixing ∧, ∨ and ⊕
|
|
200
|
+
|
|
201
|
+
Conjunction, disjunction and exclusive or sit at the **same** precedence level
|
|
202
|
+
and **cannot be mixed without explicit parentheses**. This is deliberate: it
|
|
203
|
+
avoids the silent, easy-to-misread grouping that a default precedence would
|
|
204
|
+
impose. For example:
|
|
205
|
+
|
|
206
|
+
```text
|
|
207
|
+
P(x) ∧ Q(x) ∨ R(x) # rejected — ambiguous
|
|
208
|
+
(P(x) ∧ Q(x)) ∨ R(x) # accepted
|
|
209
|
+
P(x) ∧ (Q(x) ∨ R(x)) # accepted
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
A chain of the *same* operator is fine: `P ∧ Q ∧ R` and `P ∨ Q ∨ R` both parse.
|
|
213
|
+
|
|
214
|
+
### Quantifier scope
|
|
215
|
+
|
|
216
|
+
A quantifier binds **only the immediately following (tightly bound) formula**,
|
|
217
|
+
not the rest of the line. In particular it does *not* automatically extend over
|
|
218
|
+
a following connective. This means:
|
|
219
|
+
|
|
220
|
+
```text
|
|
221
|
+
∀x P(x) ∧ Q(x) # parses as (∀x P(x)) ∧ Q(x)
|
|
222
|
+
∀x P(x) → Q(x) # parses as (∀x P(x)) → Q(x)
|
|
223
|
+
```
|
|
224
|
+
|
|
225
|
+
If you intend the quantifier to range over the whole implication or
|
|
226
|
+
conjunction — which is usually what is meant — **add parentheses**:
|
|
227
|
+
|
|
228
|
+
```text
|
|
229
|
+
∀x (P(x) → Q(x)) # quantifier ranges over the implication
|
|
230
|
+
∀x (P(x) ∧ Q(x)) # quantifier ranges over the conjunction
|
|
231
|
+
```
|
|
232
|
+
|
|
233
|
+
Quantifiers can be stacked directly: `∀x ∀y ∃z φ`.
|
|
234
|
+
|
|
235
|
+
### Supported symbols
|
|
236
|
+
|
|
237
|
+
| Category | Symbols |
|
|
238
|
+
|---|---|
|
|
239
|
+
| Quantifiers | `∀` `∃` |
|
|
240
|
+
| Connectives | `∧` `∨` `⊕` `¬` `→` `↔` |
|
|
241
|
+
| Equality / comparison | `=` `≠` `<` `>` `≤` `≥` |
|
|
242
|
+
| Arithmetic | `+` `-` `*` `/` |
|
|
243
|
+
| Grouping | `(` `)` `[` `]` |
|
|
244
|
+
| Argument separator | `,` |
|
|
245
|
+
|
|
246
|
+
Whitespace is insignificant and may be used freely between tokens.
|
|
247
|
+
|
|
248
|
+
### A complete example
|
|
249
|
+
|
|
250
|
+
```text
|
|
251
|
+
∀x ((Object(x) ∧ HasThreeDimensionalShape(x) ∧
|
|
252
|
+
∀y ∀z ((Point(y) ∧ OnSurfaceOf(y, x) ∧ Point(z) ∧ OnSurfaceOf(z, x))
|
|
253
|
+
→ distance(y, centerOf(x)) = distance(z, centerOf(x))))
|
|
254
|
+
→ Sphere(x))
|
|
255
|
+
```
|
|
256
|
+
|
|
257
|
+
This uses unary predicates (`Object`, `Sphere`, `Point`), a binary predicate
|
|
258
|
+
(`OnSurfaceOf`), functions (`distance`, `centerOf`), an infix equality between
|
|
259
|
+
two function terms, nested quantifiers, and explicit parentheses to control
|
|
260
|
+
both the inner implication and the quantifier scope.
|
|
261
|
+
|
|
262
|
+
## Error handling
|
|
263
|
+
|
|
264
|
+
Parse errors are reported with human-readable messages rather than raw parser
|
|
265
|
+
internals. Lexer-level problems (an invalid character, a malformed name or
|
|
266
|
+
number) raise `NamingError`; structural problems (an incomplete formula, a
|
|
267
|
+
misplaced operator, or an attempt to mix `∧`/`∨`/`⊕` without parentheses) raise
|
|
268
|
+
`ParsingError`. Both report the offending position and, where useful, a hint.
|
|
269
|
+
|
|
270
|
+
```python
|
|
271
|
+
from unicode_fol_kit import FOLParser
|
|
272
|
+
|
|
273
|
+
parser = FOLParser()
|
|
274
|
+
parser.parse("P(x) ∧ Q(x) ∨ R(x)")
|
|
275
|
+
# Parsing/NamingError: SYNTAX_ERROR: Unexpected character '∨' ...
|
|
276
|
+
# Hint: Cannot mix conjunction (∧), disjunction (∨), and exclusive or (⊕) without parentheses
|
|
277
|
+
```
|
|
278
|
+
|
|
279
|
+
## Citation
|
|
280
|
+
|
|
281
|
+
If you use this toolkit in academic work, please cite the accompanying
|
|
282
|
+
preprint:
|
|
283
|
+
|
|
284
|
+
```bibtex
|
|
285
|
+
@misc{vossel2025advancingnaturallanguageformalization,
|
|
286
|
+
title={Advancing Natural Language Formalization to First Order Logic with Fine-tuned LLMs},
|
|
287
|
+
author={Felix Vossel and Till Mossakowski and Björn Gehrke},
|
|
288
|
+
year={2025},
|
|
289
|
+
eprint={2509.22338},
|
|
290
|
+
archivePrefix={arXiv},
|
|
291
|
+
primaryClass={cs.CL},
|
|
292
|
+
url={https://arxiv.org/abs/2509.22338},
|
|
293
|
+
}
|
|
294
|
+
```
|
|
295
|
+
|
|
296
|
+
> Vossel, F., Mossakowski, T., & Gehrke, B. (2025). *Advancing Natural Language
|
|
297
|
+
> Formalization to First Order Logic with Fine-tuned LLMs.* arXiv preprint
|
|
298
|
+
> arXiv:2509.22338.
|
|
299
|
+
|
|
300
|
+
## License
|
|
301
|
+
|
|
302
|
+
MIT
|