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

Desugar == to =!= if it is used at type Prop #363

Closed
byorgey opened this issue Mar 6, 2023 · 2 comments · Fixed by #428
Closed

Desugar == to =!= if it is used at type Prop #363

byorgey opened this issue Mar 6, 2023 · 2 comments · Fixed by #428
Assignees
Labels
C-Project A larger project that may take multiple days. S-Nice to have Minor importance Z-Feature Request Z-Student Good project for a student.

Comments

@byorgey
Copy link
Member

byorgey commented Mar 6, 2023

I think this should get us a lot of the benefits of =!= while allowing students to just use == and not worry about the difference.

@byorgey byorgey added C-Low Hanging Fruit Shouldn't take too much time; ideal issues for new contributors. Z-Feature Request S-Nice to have Minor importance Z-Student Good project for a student. labels Mar 6, 2023
@byorgey
Copy link
Member Author

byorgey commented May 24, 2023

This is actually trickier than I thought. Even when we give an explicit Prop type annotation, the == operator still has type N * N -> Bool; it's only the overall expression that has type Prop:

Disco> :ann (3 == 4 : Prop)
(~==~ : ℕ × ℕ → Bool)((3 : ℕ, 4 : ℕ) : ℕ × ℕ) : Prop

This means e.g. we can't do something simple like just add a special case to compileBOp for == at type Prop, since the == operator actually doesn't have result type Prop.

Perhaps this would be possible if we pushed the Prop type down as far as possible, e.g. if we rewrite the type checker to always use the "propagate types inwards" trick (see swarm-game/swarm#99), though it seems like that could still be somewhat fragile.

@byorgey
Copy link
Member Author

byorgey commented Feb 7, 2024

Alternatively, perhaps we can get this done simply by adding a bit more special cases to the desugarer. We already do have access to type information while desugaring. When desugaring an expression of type Prop we can propagate that information downward and desugar it specially. In other words, even when desugaring an expression of type Bool we can remember the fact that it is embedded within a larger expression of type Prop. It may be that we can also do something special for /\ and \/ in addition to ==.

@byorgey byorgey self-assigned this Feb 7, 2024
@byorgey byorgey added C-Project A larger project that may take multiple days. and removed C-Low Hanging Fruit Shouldn't take too much time; ideal issues for new contributors. labels Apr 11, 2024
byorgey added a commit that referenced this issue Dec 27, 2024
…#428)

Technically, this is achieved by desugaring boolean comparison operators inside a `Prop` into operators wrapped in `Should`, which triggers the testing framework to report the value on both sides of the operator.  This means (1) there is no longer any needed distinction at the surface language level between `==` and `=!=` (indeed, the latter is now a syntax error), and it also generalizes to work with any comparison operator, not just `==` and `<`.

Also generally improve test result reporting.

Closes #363 .
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Project A larger project that may take multiple days. S-Nice to have Minor importance Z-Feature Request Z-Student Good project for a student.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant