Closed atennapel closed 4 years ago
This is already supported in current Agda. See e.g. section 5 of this ("invertible problems"). I think it definitely works in Agda 2.6.1 if decode
is defined with pattern matching, otherwise I'm not sure. It does not lose any unification solutions if implemented conservatively, so it's a reasonable thing to add.
Thanks for the reference!
FWIW, Sixty has this kind of conservative case inversion ~hacked in~ implemented.
It's sometimes surprisingly powerful.
Yeah that's awesome! So in your case I see in:
case scrutinee of
con1 vs1 -> con1' es1
con2 vs2 -> con2' es2
==
con1' es1'
The con1'
is matched by a simple equality check of the constructor? So no unification/backtracking there.
Yeah, that's right. It's a quite superficial test to avoid backtracking.
This is where having native datatypes and a pattern matching construct also seems to make things easier. In "Gentle art of levitation" and my system (unit, bool, fix) even a simple sum type A + B
is (b : Bool) ** if b then A else B
, which makes the same equation look more like ?0 fst (if-then (\a. v1) (\b. v2)) (snd ?0) == v
.
In "Dependently Typed Programming in Agda" (P33) a universe for overloading is shown. Let me give a minimal example (in Agda-like syntax):
Now in Agda apparently the
TYPE
can be inferred. But in the system of this repo obviously it will not:This fails because there is an eliminator in the spine of
?1
. Now I can see a way to solve this in this special case becauseif-then
has exactly two possible results, so we could try to unify the results and see:Does this seem like a reasonable thing to add to you, in order to beef up the unification in some cases? Or do you know of a more general approach to try and solve problems like this?