Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Remove dummy
top
andis_top
implementations from int domains #1727New 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
Remove dummy
top
andis_top
implementations from int domains #1727Changes from all commits
8f99cbd
c9a256f
eda4fe8
4715c07
f5cd945
d4bf659
6c9eff3
1ce9de0
1452a93
e2a74e7
6bc71bb
a968622
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Could we go for
BoundedMeetSemiLattice
andBoundedJoinSemiLattice
here as meaningful mathematical objects? And use this opportunity to actually make our PO a PartialOrder and not some sort of lattice in disguise, i.e., removejoin
,meet
,narrow
andwiden
from it?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 could try that in #1728 to also weaken arguments of
LiftBot
andLiftTop
.Splitting the signatures into precise algebraic structures is nice, but it comes with a cost that we already have with
Printable
andLattice
: to make meaningful use of them, one needs functors for each one, e.g.Printable.Prod
,Lattice.POProd
,Lattice.BoundedMeetSemiLatticeProd
,Lattice.BoundedJoinSemiLatticeProd
,Lattice.Prod
, etc.Of course all code duplication can be avoided by
include
, but they still need to be separate functors with separate names.I've thought about splitting
Printable.S
in the past, because it is even more bloated, but it just leads to a bigger mess.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 question is whether all these lifters are used then. If we don't have a
BoundedMeetSemiLatticeProd
anywhere, no need to provide the functor for it.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.
Of course we don't and by just introducing the signatures, nothing new would be needed: using the most powerful
Lattice.Prod
will suffice because in all such cases the arguments currently already provide dummy implementations which wouldn't then be needed.But it means we have to accept such exponential explosion of functors. For example, you might want
BoundedMeetSemiLattice
which is alsoJoinSemiLattice
(so just withouttop
), etc.Anyway, it's a completely orthogonal matter to this PR.
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.
It's not completely orthogonal: I think introducing ill-defined module signatures such as
Top
(there is a special element intended to be greater than all others and a way to check whether some element is identical to it, but no way to compare elements) only makes it harder to understand what's going on.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 could go back to what I did at first and what matches all the signature duplication happening in
IntDomain
currently: just declareval top: unit -> t
directly, as opposed to putting the signature intoLattice
to reuse.Then we just end up with 5 copies of the
top
type in Goblint, which isn't nice. ButIntDomain
is currently full of such copy-paste signatures, so it wouldn't be worse, but it wouldn't move towards cleaning it up either.I just don't think we have a clean and usable naming scheme: a
Lattice.S
withouttop
would be the combination ofBoundedMeetSemiLattice
and (unbounded)JoinSemiLattice
. What's supposed to be the name for that?BoundedMeetUnboundedJoinSemiLattice
isn't particularly nice.For these one-off combinations it's much cleaner to just include the necessary components, e.g.
PO
andTop
on demand, rather than having to predefine all necessary combinations.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 get what you mean, I just find the notion of having a
Top
signature that one can implement without even having a PO which would seem essential to being able to give such a thing non-helpful. But this is not a hill I am willing to die on!