Is there anything else that needs to be done for Quotation? about hol-light-qe

[JacquesCarette]

[Excuse the informal syntax, I forget the details]
Can you prove that not (quote (1+1) = quote (2) but unquote (quote (1+1)) = unquote (quote 2)) ?

[laskowsp]

not (quote (1+1) = quote (2)) should be doable, I will test it and reply with the results, but unquote is for taking out holes, not an implementation of eval, so I do not think the second one is provable with the tools at hand.

[laskowsp]

Alright, I have tested the first one and have been able to reduce it to

`~(App
   (App
    (QuoConst "+"
    (TyBiCons "fun" (TyBase "num")
    (TyBiCons "fun" (TyBase "num") (TyBase "num"))))
   (App (QuoConst "NUMERAL" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (App (QuoConst "BIT1" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (QuoConst "_0" (TyBase "num")))))
   (App (QuoConst "NUMERAL" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (App (QuoConst "BIT1" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (QuoConst "_0" (TyBase "num")))) =
   App (QuoConst "NUMERAL" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (App (QuoConst "BIT0" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (App (QuoConst "BIT1" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (QuoConst "_0" (TyBase "num")))))`

but there is no way to prove inequality. The way HOL handles this for defined types such as strings and characters is with a conversion function that accepts an equality and returns a theorem asserting that the equality is either true or false. An example of this would be STRING_EQ_CONV, so I think the best course of action is to emulate the native way of doing it and implement an EPSILON_EQ_CONV which works the same way.

[JacquesCarette]

Re: unquote - yes, I meant eval.

Re: proving inequality. Yes, it is always best to emulate what HOL already does.

[laskowsp]

It appears that I forgot about the two definitions I had HOL generate - epsilonDistinct and epsilonInjective. These are enough to prove that the two terms are unequal without the need to add in extra conversion functions. Here is the complete proof from start to end:

# g(`~(Q_ 1 + 1 _Q = Q_ 2 _Q)`);;
val it : goalstack = 1 subgoal (1 total)

`~(Q_ (1 + 1) _Q = Q_ (2) _Q)`

# e(REPEAT TERM_TO_CONSTRUCTION_TAC);
  ;;
val it : goalstack = 1 subgoal (1 total)

`~(App
   (App
    (QuoConst "+"
    (TyBiCons "fun" (TyBase "num")
    (TyBiCons "fun" (TyBase "num") (TyBase "num"))))
   (App (QuoConst "NUMERAL" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (App (QuoConst "BIT1" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (QuoConst "_0" (TyBase "num")))))
   (App (QuoConst "NUMERAL" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (App (QuoConst "BIT1" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (QuoConst "_0" (TyBase "num")))) =
   App (QuoConst "NUMERAL" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (App (QuoConst "BIT0" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (App (QuoConst "BIT1" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (QuoConst "_0" (TyBase "num")))))`

# e(REWRITE_TAC[epsilonInjective]);;
val it : goalstack = 1 subgoal (1 total)

`~(App
   (QuoConst "+"
   (TyBiCons "fun" (TyBase "num")
   (TyBiCons "fun" (TyBase "num") (TyBase "num"))))
   (App (QuoConst "NUMERAL" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (App (QuoConst "BIT1" (TyBiCons "fun" (TyBase "num") (TyBase "num")))
   (QuoConst "_0" (TyBase "num")))) =
   QuoConst "NUMERAL" (TyBiCons "fun" (TyBase "num") (TyBase "num")) /\
   "NUMERAL" = "BIT0")`

# e(REWRITE_TAC[epsilonDistinct]);;
val it : goalstack = No subgoals

# top_thm();;
val it : thm = |- ~(Q_ (1 + 1) _Q = Q_ (2) _Q)

[JacquesCarette]

That's great. Well done.

[laskowsp]

What should I focus on next?

[JacquesCarette]

start on eval ?

[laskowsp]

Alright, should I make eval an HOL function or another "special" term like Quote and Hole?

[JacquesCarette]

I am not 100% sure. I think it can be made a HOL function (which is preferable), but there might be hiccups. Hopefully Dr. Farmer will chime in at some point.

[laskowsp]

Alright, I'll get started on implementing it as an HOL function but changing it to it's own term shouldn't be too hard if necessary.

[laskowsp]

Is it safe to assume that eval will always be called on a quote? e.g.
eval (Q_ 3 _Q) would be valid but
eval (3 = Q_ 2 _Q) or eval ((f x):epsilon) would not?

[JacquesCarette]

eval can be called on anything which is equivalent to a quote - it does not have to be a quote. Not sure if you can deal with that in the type system?

[laskowsp]

I do not think that is doable in the type system, I think something similar to how holes work would be best here - allow eval to be applied to anything but the theorem that handles performing the evaluation itself requires the user to simplify the thing representing the quote to an actual quote.

[JacquesCarette]

ok

[wmfarmer]

eval needs to be a new term constructor like quote. Its semantics prevents it from being an HOL function. eval has two arguments, a term t of type epsilon and a type alpha. The type of "eval t alpha" is alpha. quote can only be applied to eval-free terms.

[laskowsp]

I see, thank you, I will make the change.