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

GrammaticalExpression should not be a subclass of Expression? #30

Closed
shanest opened this issue Feb 5, 2024 · 1 comment
Closed

GrammaticalExpression should not be a subclass of Expression? #30

shanest opened this issue Feb 5, 2024 · 1 comment

Comments

@shanest
Copy link
Collaborator

shanest commented Feb 5, 2024

Issue: GrammaticalExpression right now is a subclass of Expression, which primarily stores a form and a Meaning. The problem: Meanings are basically a set of Referents. This works well for GrammaticalExpressions that start from bool (e.g. subset(A, B) or all the ones in the indefinites example), since they produce functions that map a Referent to a bool. But sub-expressions thereof (e.g. the A, or an int like 5) may not return bool and so cannot be used to produce a Meaning.

I'm leaning towards making GrammaticalExpression not a busclass of Expression (and so maybe renaming it as well), and then having the evaluate method take a GE and return a Meaning. We could also introduce something like InterpretedGrammaticalExpression as a subclass of Expression which stores the GE + Meaning for GEs that are bool.

@shanest
Copy link
Collaborator Author

shanest commented May 2, 2024

Note: if we adopt the proposal in #40, we can let GrammaticalExpression remain a subclass of expression and modify evaluate to look more like call_on_universe

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

No branches or pull requests

1 participant