-
Notifications
You must be signed in to change notification settings - Fork 13
Expr & Sort class hierarchy #2
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
Conversation
We want sort-specific operator overloading, but Python operator overloading is based on classes. Thus, we create (a) class hierarchies which match the Sort hierarchy (b) functions to construct the correct class based on the sort Expr hierarchy also has elements for concrete values. This will be useful for interacting with models. Actual overloading is still a ways off...
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 looks pretty good to me, I left a few general comments. One higher-level question is about the class hierarchy: is that from the Z3 API? It makes sense, although you could also do a case split within the comparison operator. I suppose that might be less efficient.
I'm wondering when would you do the cast to the specific sort class? Will all sort objects that a user interacts with be an instance of one of the specific classes?
I'm interested in the rationale, although if this is just to best match the API, then I recognize that we don't really have a choice.
True | ||
>>> is_sort(Int('x')) | ||
False | ||
>>> is_expr(Int('x')) |
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.
Do you have an is_expr
? Maybe remove that from the example if not.
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 don't have it yet, but we will.
My instinct is to leave this here for now; that will ensure that we're reminded of this when we enable doc-testing. Thoughts?
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.
Sounds good!
Yeah, this class hierarchy is from the Z3 API, so we're stuck with it. I'm not sure about the comparative efficiency of this approach v. a case-split. Perhaps Leo thought this approach would produce better error messages (e.g., a boolean expression doesn't have a "+" operation). It might make for nicer code, too. While I generally prefer the case-split (FP) approach to the sub-class (OO) approach, the latter is the strongest when you want extensibility to new kids of data, which is our situation here.
Anything given the user will be run through |
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.
Cool, thanks for your responses! It looks good to me.
We want sort-specific operator overloading, but Python operator
overloading is based on classes. Thus, we create
(a) class hierarchies which match the Sort hierarchy
(b) functions to construct the correct class based on the sort
Expr hierarchy also has elements for concrete values.
This will be useful for interacting with models.
Actual overloading is still a ways off...