Skip to content

Support for equality constraints#455

Open
zeroeightysix wants to merge 6 commits intoagda:masterfrom
zeroeightysix:feat/instance-equality-constraint
Open

Support for equality constraints#455
zeroeightysix wants to merge 6 commits intoagda:masterfrom
zeroeightysix:feat/instance-equality-constraint

Conversation

@zeroeightysix
Copy link
Contributor

This PR adds rudimentary (but unfortunately, not very useful - at the moment) support for generating equality constraints.

Any occurrence of a non-erased propositional equality in an instance argument is treated as being an equality constraint. The following compiles as such:

f : ⦃ a ≡ b ⦄  c
f :: a ~ b => c

The reason I say this isn't very useful yet is because you're not allowed to actually learn anything from the equality yet, due to #168.

(If the changes are okay, best to squash, as the git history isn't the cleanest)

-- The arguments to equality are _a_ (level), _A_ (the type of elements), x (: A), and y (: A)
-- We want to compile x and y
let Just (_:_:x:y:_) = allApplyElims es
hsX <- compileType (unArg x)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are compiling x and y as types, should we have a check that their type A is indeed compiling to a Haskell kind?

@jespercockx
Copy link
Member

Thank you for the PR! I'm happy with the feature but I'm not yet convinced that it is really necessary to treat equality constraints different from other (class) constraints in the translation. In particular, I don't really see why we need new constructors DomEquality and DOEquality instead of just using the ones for constraints, could you explain the reasoning behind that?

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

Successfully merging this pull request may close these issues.

2 participants