-
Notifications
You must be signed in to change notification settings - Fork 253
[Add] Initial files for Domain theory - Continuation of #2721 #2809
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
base: master
Are you sure you want to change the base?
[Add] Initial files for Domain theory - Continuation of #2721 #2809
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for picking up from @jmougeot 's initial contribution.
I don't think this design is quite ready yet, and needs more thought wrt:
- placement of concepts
- naming of them
- parametrisation of them
At a first cut, I'm not quite clear what should go where, so will need to think about this more, but this is a prompt to other reviewers also to think about these questions. It seems that I might be in conflict with @JacquesCarette over what the right answers might be!?
record IsDirectedFamily {b : Level} {B : Set b} (_≤_ : Rel A ℓ₂) (f : B → A) : | ||
Set (a ⊔ b ⊔ ℓ₂) where | ||
field | ||
elt : B |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to revisit this name before committing to it? eg inhabitant
as an alternative?
Set (a ⊔ b ⊔ ℓ₂) where | ||
field | ||
elt : B | ||
isSemidirected : SemiDirected _≤_ f |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem to be consistent... wrt our naming conventions camelCase : CamelCase
, nor wrt use of isX
to refer to an IsX
*structure...
isSemidirected : SemiDirected _≤_ f | |
semiDirected : SemiDirected _≤_ f |
module _ (P : Poset c ℓ₁ ℓ₂) where | ||
open Poset P |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that this has come up before in this context; we tend to define this kind of parametrised record on the underlying Raw structure (because none of the axioms for a Poset
are involved in the definition, only the underlying relations).
Not least because domain theory ought better to be built on Preorder
-based foundations? Antisymmetry plays almost no direct role in the axiomatisation of the concepts you define?
Anyway: meta design principle is/ought to be 'structures don't depend on bundles'
I think (but happy to be contradicted) that UpperBound
, Lub
, DirectedFamily
all belong in Relation.Binary.Domain.Definitions
module _ (P : Poset c ℓ₁ ℓ₂) where | ||
open Poset P | ||
|
||
record IsLub {b : Level} {B : Set b} (f : B → Carrier) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
b
is already implicitly bound by a variable
declaration, so shouldn't need explicit mention here.
record IsLub {b : Level} {B : Set b} (f : B → Carrier) | ||
(lub : Carrier) : Set (b ⊔ c ⊔ ℓ₁ ⊔ ℓ₂) where | ||
field | ||
isUpperBound : UpperBound _≤_ f lub |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
camelCase : CamelCase
is the usual convention in stdlib
, accordingly:
isUpperBound : UpperBound _≤_ f lub | |
upperBound : UpperBound _≤_ f lub |
(lub : Carrier) : Set (b ⊔ c ⊔ ℓ₁ ⊔ ℓ₂) where | ||
field | ||
isUpperBound : UpperBound _≤_ f lub | ||
isLeast : ∀ y → UpperBound _≤_ f y → lub ≤ y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isLeast : ∀ y → UpperBound _≤_ f y → lub ≤ y | |
minimal : ∀ y → UpperBound _≤_ f y → lub ≤ y |
because being least only follows from the Poset
axioms, whereas in their absence (as above), we only have/need a minimal upper bound?
field | ||
⋁ : ∀ {B : Set c} → | ||
(f : B → Carrier) → | ||
IsDirectedFamily _≈_ _≤_ f → |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The definition you give of IsDirectedFamily
is only accidentally dependent on the underlying Setoid
equality relation _≈_
, so either you need to involve it by making f
a suitable congruence wrt it, or else reconsider whether IsDirectedFamily
really belongs in Relation.Binary.Structures
?
As this stands, I think the design doesn't quite fit properly with the existing stdlib
hierarchy.
-- DirectedFamily | ||
------------------------------------------------------------------------ | ||
|
||
record IsDirectedFamily {b : Level} {B : Set b} (_≤_ : Rel A ℓ₂) (f : B → A) : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that this definition belongs in Relation.Binary.Structures
, because it's not actually (an extension of) any of the existing relational structures, rather it's a property that any one of them might additionally possess?
This pull request aims to continue and complete the work started in #2721
The first version already includes changes requested by @JacquesCarette, such as moving the definition of
DirectedFamily
toRelation.Binary.Definitions.agda
andIsDirectedFamily
toRelation.Binary.Structures.agda
, as well as the proper bundling ofLub
.