Skip to content

feat(Logic): logical operators#607

Open
fmontesi wants to merge 15 commits into
mainfrom
fmontesi/connectives
Open

feat(Logic): logical operators#607
fmontesi wants to merge 15 commits into
mainfrom
fmontesi/connectives

Conversation

@fmontesi

Copy link
Copy Markdown
Collaborator

This PR introduces typeclasses for logical operators (connectives and modalities) and refactors modal and propositional logics with appropriate instances to these.

@fmontesi fmontesi requested a review from chenson2018 as a code owner May 29, 2026 12:56
@fmontesi fmontesi changed the title feat (Logic): logical operators feat(Logic): logical operators May 29, 2026
Comment thread Cslib/Logics/Modal/Basic.lean Outdated
public import Cslib.Foundations.Logic.Operators.Not
public import Cslib.Foundations.Logic.Operators.Box
public import Cslib.Foundations.Logic.Operators.Diamond
public import Cslib.Foundations.Logic.Operators.Iff

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to just have one file for these? If they're just notation typeclasses it seems unlikely to be heavyweight and they're likely to be used together.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know yet. We will expand these files with extended classes for expected properties about these operators, but you're right that some will require importing more than one.. I think we'll know more once we get there.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose 3 files:

  • Modal containing box and diamond.
  • Tensor by itself.
  • Propositional for the reset.

BTW, do we need parameterized box and diamond for HML?

Comment thread Cslib/Logics/Modal/Basic.lean Outdated
benbrastmckie added a commit to benbrastmckie/cslib that referenced this pull request Jun 13, 2026
The class was intentionally uninstantiated dead code. Its neg/top
rationale (minimal-logic validity) now lives in the module docstring;
formula types define neg/top as abbrevs directly. Future generic
abstractions should use PR leanprover#607-style HasNeg/HasTop atomic classes.

Session: sess_1781312776_63c955
benbrastmckie added a commit to benbrastmckie/cslib that referenced this pull request Jun 14, 2026
The class was intentionally uninstantiated dead code. Its neg/top
rationale (minimal-logic validity) now lives in the module docstring;
formula types define neg/top as abbrevs directly. Future generic
abstractions should use PR leanprover#607-style HasNeg/HasTop atomic classes.

Session: sess_1781312776_63c955
benbrastmckie added a commit to benbrastmckie/cslib that referenced this pull request Jun 15, 2026
Upstream PR landscape audit for Modal/ logic. No competing
signature-change PRs. PR leanprover#607 stalled with CHANGES_REQUESTED.
Recommends stacking Modal PR on feat/temporal-formula-propositional.

Session: sess_1781531573_4cdbb4
benbrastmckie added a commit to benbrastmckie/cslib that referenced this pull request Jun 15, 2026
Diplomatic PR description for Modal/ formula primitives refactoring,
stacking on PR leanprover#648. Coordinates with PRs leanprover#607, leanprover#528, leanprover#535, leanprover#649.

Session: sess_1781535860_c7d8e9
@fmontesi fmontesi requested a review from arademaker as a code owner June 16, 2026 06:37
@benbrastmckie

Copy link
Copy Markdown

Hi @fmontesi — I wanted to flag some overlap with PR #648 so we can coordinate.

PR #648 includes Connectives.lean with a single-file approach to connective typeclasses (HasBot, HasImp, HasAnd, HasOr), following @chenson2018's consolidation suggestion. A planned Modal follow-up would extend it with HasBox/ModalConnectives.

The main naming difference is HasImpl/impl here vs HasImp/imp in #648. I went with imp for consistency with FormalizedFormalLogic and the rule name prefix convention (impI/impE), but happy to align whichever way you and other reviewers prefer.

A follow-up to #648 would refactor the Modal constructors from {atom, not, and, diamond} to {atom, bot, imp, box}. The case for primitive bot is in this Zulip message (substitution invariance, free algebra property). Related reasoning favors primitive box: necessitation becomes a pure rule — ⊢ φ → ⊢ □φ — stated in terms of box alone, rather than an interaction rule requiring dia and neg, or dia, bot, and imp. This would affect how typeclass instances are written. I'd welcome your input on this issue and will post on the Modal Zulip thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants