Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Competing conventions for operations on propositions #984

Closed
fredrik-bakke opened this issue Dec 12, 2023 · 5 comments · Fixed by #1008
Closed

Competing conventions for operations on propositions #984

fredrik-bakke opened this issue Dec 12, 2023 · 5 comments · Fixed by #1008

Comments

@fredrik-bakke
Copy link
Collaborator

fredrik-bakke commented Dec 12, 2023

The competing conventions are as follows:

  1. use special binary operators taking values in types: _⇔_ : Prop → Prop → UU
  2. use special binary operators taking values in propositions: _∧_ : Prop → Prop → Prop
  3. Use unicode symbol in name for operators with minimal assumptions of propositions. E.g. Π-Prop : (X : UU) → (X → Prop) → Prop and use textual name for the construction where more types are assumed to be props.
    E.g. ∃-Prop : (X : UU) → (X → UU) → Prop while exists-Prop : (X : UU) → (X → Prop) → Prop

Originally posted by @fredrik-bakke in #983 (comment)

@fredrik-bakke
Copy link
Collaborator Author

fredrik-bakke commented Dec 12, 2023

We could reconcile 1 and 2 by introducing some modifier symbol like for operators that take values in propositions. Although this does not feel very agda-unimathy to me, we do do something similar for decidable embeddings already with ↪ᵈ

@VojtechStep
Copy link
Collaborator

I don't have experience with that part of the codebase, but I think I'd expect logical connectives to be composable. It's kinda surprising to not be able to do A ∧ B ∧ C (what's the point of specifying fixity then?), so I'd be in favor of having infix operators valued in Prop

@fredrik-bakke
Copy link
Collaborator Author

I want to note that there is still a conflict that arises when considering the current usage of . There is also a conflict with the hypothetical _∈_. This leads me to believe that perhaps precisely what we need is adding a disambiguative symbol like .

@fredrik-bakke
Copy link
Collaborator Author

We also do this for pointed types I just realized.

@fredrik-bakke
Copy link
Collaborator Author

Here's an example usage for size:

  is-dedekind-cut-Prop : Prop (l1 ⊔ l2)
  is-dedekind-cut-Prop =
    ( ∃ᴾ ℚ L ∧ᴾ ∃ᴾ ℚ U) ∧ᴾ
    ( ∀ᴾ ℚ (λ q  L q ⇔ᴾ (∃ᴾ ℚ (λ r  (q <ᴾ-ℚ r) ∧ᴾ L r)))) ∧ᴾ
    ( ∀ᴾ ℚ (λ r  U r ⇔ᴾ (∃ᴾ ℚ (λ q  (q <ᴾ-ℚ r) ∧ᴾ U q)))) ∧ᴾ
    ( ∀ᴾ ℚ (λ q  ¬ᴾ (L q ∧ᴾ U q))) ∧ᴾ
    ( ∀ᴾ ℚ (λ q  ∀ᴾ ℚ (λ r  (q <ᴾ-ℚ r) ⇒ᴾ (L q ∨ᴾ U r))))

It goes without saying that I would still much rather have this definition be in terms of conjunctions of more general predicates like is-lower-set-Subposet and so on (perhaps with intermediate definitions for is-lower-rounded and so on)

EgbertRijke added a commit that referenced this issue Apr 11, 2024
## Summary
- Introduce a general naming scheme for infix endooperations on
propositions and the corresponding endooperations on types
- Remove uses of `∀`
- remove the redundant `implication-Prop`
- Add table for propositional logic
- Add table for operations on propositions
- Correct the definition of exclusive disjunction. It is now named
"exclusive sum" (up for discussion)
- Introduce _disjunction_, (the correct definition of) _exclusive
disjunction_, and _mere logical equivalence_ of types
- Introduce _coinhabitedness_ of types
- Introduce universal quantification
- Define the homotopy preorder of types
- Prove that existential quantification of type families agrees with
existential quantification of the propositional reflection of the type
family
- Prove that disjunction of types agree with disjunction of the
propositional reflections of the summands

Intersects with #1060.
Resolves #984.

---------

Co-authored-by: Egbert Rijke <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants