User:GrafZahl/Dan Krejsa's Ghilbert unsoundness proof.gh


 * 1) This is a 2007 e-Mail from Dan Krejsa to Raph and Norm proving definition unsoundness in GHilbert.
 * 2) Many thanks go to Raph for providing me with this communication. I took the liberty to add hash
 * 3) marks, so this page can be directly fed to Ghilbert. I also scrubbed the e-Mail addresses.
 * 4) -- GrafZahl


 * 1) From: *Dan Krejsa*
 * 2) Date: Sat, Jan 20, 2007 at 12:04 PM
 * To: raph, nm
 * Hi,
 * 1) Well, here's the proof:
 * 1) Well, here's the proof:
 * 1) Well, here's the proof:

import (PROP pax/prop "") import (SET_MM_AX zfc/set_mm_ax (PROP) "")

var (wff ph ps ch) var (set w x y z) var (class A B)

import (SET_MM zfc/set_mm (PROP SET_MM_AX) "")


 * 1) One has to resort to the truly ugly:

def ((ugh) x)

thm (ugly  (-> (= (cv y) (cv (ugh))) (A. (ugh) (= (cv y) (cv (ugh)))))       ((= (cv y) (cv (ugh))) (ugh) ax-17))

thm (lem1 ((x y)) (-> (A. x (= (cv y) (cv x))) (A. z (= (cv y) (cv z))))   ( x y dtru (cv x) (cv y) eqcom x albii biimpr mto (A. x (= (cv y) (cv x))) (A. z (= (cv y) (cv z))) pm2.21 ax-mp ))
 * 1) Well, it seems like a cheat to use dtru to establish this alpha-conversion
 * 2) lemma, but I'll use dtru later to get a contradiction, so why not:

thm (lem2  (-> (= (cv y) (cv (ugh))) (A. z (= (cv y) (cv z))))   ( y ugly (ugh) y z lem1 syl ))

thm (19.40i ((1 (E. x (/\ ph ps)))) (/\ (E. x ph) (E. x ps))   ( 1 x ph ps 19.40 ax-mp ))

thm (lem3  (E. y (A. z (= (cv y) (cv z))))   ( y (ugh) a9e y z lem2 y ax-gen y (= (cv y) (cv (ugh))) (A. z (= (cv y) (cv z))) exintr ax-mp ax-mp 19.40i pm3.27i ))

thm (lem4 ((y z)) (/\ (E. y (A. z (= (cv y) (cv z)))) (-. (E. y (A. z (= (cv y) (cv z))))))   ( y z lem3 z y dtru (cv z) (cv y) eqcom z albii biimpr mto y ax-gen y (A. z (= (cv y) (cv z))) alnex mpbi pm3.2i ))

thm (uglycontra  (/\ ph (-. ph))   ( y z lem4 pm3.26i y z lem4 pm3.27i (/\ ph (-. ph)) pm2.21i ax-mp ))




 * 1) The problem, of course, is not with set_mm, but with Ghilbert's
 * 2) definition system.  For this particular case, one could fix
 * 3) things by requiring that the RHS of a definition be a term
 * 4) proper, not just a variable; this would outlaw definitions
 * 5) like
 * 6)  def ((ugh) x)
 * 7) or even
 * 8)  def ((ident x) x)
 * 9) That might be a good idea in any case, since it doesn't
 * 10) seem quite safe to allow definition expansion to change the
 * 11) syntactic class of a definition term; terms are, after all,
 * 12) treated differently than variables.
 * 13) However, I think that fundamentally, the issue here
 * 14) is more that with the current rules, Ghilbert allows the
 * 15) use of definition terms for which the definition expansion
 * 16) contains dummy variables, where the meaning of the expansion
 * 17) is not independent of the choice of the dummy variable.
 * 18) That is, it allows immediate use of definition terms which
 * 19) have not been proven 'well defined'.  This allows the
 * 20) unexpanded definition term to circumvent distinct variables
 * 21) conditions which would otherwise apply to the not-really-dummy
 * 22) variables in the expansion.
 * 23) I think we may have to consider allowing interface files
 * 24) to provide some way of indicating how to show definition
 * 25) terms of a particular kind are 'well defined' within the
 * 26) theory, and requiring proof of well-definedness as determined
 * 27) by the interface file before allowing unrestricted use of
 * 28) a definition term introduced in a proof file.
 * 29) One other thing; I would like to consider disallowing
 * 30) definitions like
 * 31) def ((dropit ph ps) (-> ps ps))
 * 32) where the RHS does not contain all the definition argument
 * 33) variables.  I don't think this is theoretically essential,
 * 34) but allowing such definitions introduces conceptual complexity,
 * 35) and such definitions are probably not very useful.
 * 36) - Dan
 * 1) definitions like
 * 2) def ((dropit ph ps) (-> ps ps))
 * 3) where the RHS does not contain all the definition argument
 * 4) variables.  I don't think this is theoretically essential,
 * 5) but allowing such definitions introduces conceptual complexity,
 * 6) and such definitions are probably not very useful.
 * 7) - Dan
 * 1) and such definitions are probably not very useful.
 * 2) - Dan
 * 1) - Dan