Can we derive function extensionality from self types only? about formality-core

[johnchandlerburnham]

We have internal proofs of UIP/K with erased rewrite, Victor's proof above, but also

K: Type
  (A : Type) ->
  (x : A) ->
  (p: Id(A)(x)(x)) ->
  Id(Id(A)(x)(x))(p)(refl<A><x>)

k : K
  (A) (x) (p)
  p<(eb) (e) Id(Id(A)(x)(eb))(e)(rewrite<A><x><eb><(y) Id(A)(x)(y)><e>(refl<A><x>))>
  | refl<Id(A)(x)(x)><refl<A><x>>;

Non-erased rewrite can't be proven internally, due to the p in K being a variable you can't expand. Formality gets stuck on

Reduced to... e<P: (b: Id(A)(x)(x)) -> Id(Id(A)(x)(x))(p)(b) -> Type> -> (Refl: P(p)(refl)) -> P(rewrite(p)(refl))(e)
Instead of... e<P: (b: Id(A)(x)(x)) -> Id(Id(A)(x)(x))(p)(b) -> Type> -> (Refl: P(p)(refl)) -> P(refl)(e)

However, I think an external statement of canonicity would follow from noticing that if e : Id(A)(x)(y) then

e : <A: Type> -> <a : A> -> <b: A> -> 
     e<P: (b: A) -> Id(A)(a)(b) -> Type> -> 
     (Refl: P(a)(refl<A><a>)) ->
     P(b)(e)
<A> <a> <b> <P> (Refl) Refl

which, unless you break consistency, has to be structurally equal after erasure to (x) x (I did a short write-up here that explains a little why that expansion of e makes sense: https://gist.github.com/johnchandlerburnham/1ac8ee3690917a144b69667359afd6a7)

[jasoncarr0]

@johnchandlerburnham Ah I think I misread your comment a bit. Thanks for the great write-up

[VictorTaelin]

I think this is relevant (UIP):

same
  : <A: Type> ->
    <a: A> ->
    <b: A> ->
    <e0: Id(A)(a)(b)> ->
    <e1: Id(A)(a)(b)> ->
    Id(Id(A)(a)(b))(e0)(e1)
  <A> <a> <b> <e0> <e1>
  e0<(x) (e) (e1: Id(A)(a)(x)) -> Id(Id(A)(a)(x))(e)(e1)>
  | (e1) e1<(x) (e)
      Id(Id(A)(a)(x))
      | rewrite<A><a><x><(x) Id(A)(a)(x)><e>(refl<A><a>);
      | e;>
    | refl<Id(A)(a)(a)><refl<A><a>>;;
  | e1;

Note this only holds if we allow the erasure of functions (i.e., accept f(x) ~> x for an erased argument f instead of raising an error). This causes rewrite to become identity (note that the e argument of rewrite is erased). I just experimentally added this on the last version (0.2.71). But if I understand correctly, UIP is incompatible with intervals. To revert, we just need to remove this change and convert rewrite back to its former representation (since we'll not be able to erase e anymore).

[jasoncarr0]

But if I understand correctly, UIP is incompatible with intervals

I don't believe this is true. Intervals have no more than 1 equality between two values, and there have been systems with quotient types and UIP iirc.

Of note: the standard proof of funext from the existence of an interval requires that you have eta-equivalence (i.e. f = \x -> f x definitionally) in addition to definitional pattern matching on the interval.

That said I think it's not easy to answer one way or another easily without proper consistency, but pretending that it was consistent, you most likely you cannot prove function extensionality as it implies the existence of non-canonical identity proofs (that is, closed terms of type f = g which are not an application of refl), so the way you can prove one way or another is by proving the existence/non-existence of such equalities. There's no evidence to me that they exist (besides non-terminating examples), and you very likely do not want them to exist.

[johnchandlerburnham]

@MaiaVictor Here is my proof that given ie : Id(I)(i1)(i0) we can prove the non-eta-reduced version of functional extensionality: https://gist.github.com/johnchandlerburnham/3f972bc481c41f142add2b3c9087d5e6

@jasoncarr0 It's true that the usual funext proof (I've adapted mine from here: https://people.csail.mit.edu/jgross/CSW/csw_paper_template/paper.pdf) uses the eta-reduced form, but even without eta-reduction I think that ∀x:A. f(x) == g(x) -> λx.f(x) == λx.g(x) is still meaningful (and we can always add eta-reduction to Formality later on if we want the usual form).

That said, your comment about non-canonical identity proofs is exactly in line with my thinking as to why we won't actually be able to instantiate ie. I think that proving that all x : Equal... are refl (which it probably is) is effectively just proving the K axiom, which does imply UIP.

[jasoncarr0]

I think that proving that all x : Equal... are refl (which it probably is) is effectively just proving the K axiom, which does imply UIP.

The difference here is UIP/K is an internal statement, whereas canonicity is an external statement. Here since you have UIP you could still prove propositional equality of any proofs of equality. I don't know that you'll get any farther with that eta-expanded funext form.

[johnchandlerburnham]

@MaiaVictor The linked gist https://gist.github.com/MaiaVictor/28e3332c19fbd80747a0dceb33896b6b now type errors on latest formality-core with

Inside i_to_true:
Found type... Id(Bool)(true)(true)
Instead of... Id(Bool)(true)(rewrite<I><i1><i0><() Bool><ie>(true))
With context:
- i : I
On line 145:
   141|   (i)
   142|   i<() Bool>
   143|   | true;
   144|   | true;
   145|   | refl<Bool><true>;
   146| 

[johnchandlerburnham]

Having investigated this, the issue is caused by the removal of an experimental typechecking feature that allowed an application of an erased lambda to equal its argument: <f> f(x) ~> x.

So you have to use [email protected] to run the file. (If this conflicts with your global fm/fmc executable, run npm i [email protected] in your local directory without the -g flag and run with `./node_modules/formality-core/bin/fmc.js)