Re: [Hol-info] Learning HOL Light

[Mark]

Hi Bill,

It can get quite confusing sometimes, especially when "," is involved.  I
think people (or those that are not already super-familiar with the syntax)
intuitively expect mandatory surrounding parentheses around pairs/tuples.

But anyway, this should help you.  In the following list for HOL Light,
higher items bind more tightly (i.e. have higher "precedence") than lower
items:
- function application
- type annotation
- all prefixes
- "," separators in set enumeration (i.e. { a, b, c })
- all infixes, including "," for pairs
- all binders, including "\" and "let", and "if"
- ";" separators in list enumeration (i.e. [ a; b; c ])

Note that this is just my own informal list, derived from observed
behaviour, and there might be errors in it.  Please someone say if they find
an error!

Mark.


on 6/12/12 5:14 AM, Bill Richter  wrote:

> I'm trying to learn HOL Light by reading the tutorial, and I keep running
> into things I don't understand.  Maybe it's a good idea to have a thread
for
> the experts to straighten out beginners like me.  Here's my latest
problem,
> about parenthesis and maybe precedence.  I have an improved proof of the
> universal property of the Cartesian product below (John's code, with my
> modified definition of composition), but I don't understand why it works.
I
> knew this worked:
>
> parse_as_infix("timesp",(20, "right"));;
>
> let CartesianProductp = new_definition
> `! X Y. X timesp Y = {pair:A#B | ? x y. pair = x,y /\ x IN X /\ y IN
> Y}`;;
>
> let IN_CartesianProduct = thm `;
> ! X Y x:A y:B.
> x,y IN X timesp Y  <=>  x IN X /\ y IN Y
> by CartesianProductp, SET_RULE, PAIR_EQ`;;
>
> But why do I need the variable pair? I wanted
>
> parse_as_infix("timeb",(20, "right"));;
>
> let CartesianProductb = new_definition
> `! X Y. X timeb Y = {x,y:A#B | x IN X /\ y IN Y}`;;
>
> let IN_CartesianProductb = thm `;
> ! X Y x:A y:B.
> x,y IN X timeb Y  <=>  x IN X /\ y IN Y
> by CartesianProductb, SET_RULE, PAIR_EQ`;;
>
> But this theorem earns a #8 syntax or type error hol.  So let's try
> parentheses, as John does in the tutorial (the bug problem, p 64 ff):
>
> parse_as_infix("timec",(20, "right"));;
> let CartesianProductc = new_definition
> `! X Y. X timec Y = {(x,y):A#B | x IN X /\ y IN Y}`;;
>
> let IN_CartesianProductc = thm `;
> ! X Y x:A y:B.
> x,y IN X timec Y  <=>  x IN X /\ y IN Y
> by CartesianProductc, SET_RULE, PAIR_EQ`;;
>
> Now this works!  In spite of the fact that the def is printed without
> parentheses:
> #   val CartesianProductc : thm = |- !X Y. X timec Y = {x,y | x IN X /\ y
IN
> Y}
> What's going on?  Is this related to the parentheses here, which are
> printed:
>
> FST;;
> val it : thm = |- !x y. FST (x,y) = x
>
> The comma infix "," has precedence 14.  Is that lower than the precedence
of
> function application?  There's a lot written in the tutorial about
> precedence, but I found nothing about the precedence of function
> application, forall, exists or lambda.  Here's my improved code, which is
> due to John except my definition of composition, first with the statements
> using math characters:
>
> (*
> parse_as_infix("∉",(11, "right"));;
> parse_as_infix("∏",(20, "right"));;
> parse_as_infix("∘",(20, "right"));;
> parse_as_infix("→",(13,"right"));;
>
> ∉ |- ∀a l. a ∉ l ⇔ ¬(a ∈ l)
>
> CartesianProduct
> |- ∀ X Y. X ∏ Y = {x,y | x ∈ X ∧ y ∈ Y}
>
> IN_CartesianProduct
> |- ∀ X Y x y. x,y ∈ X ∏ Y ⇔ x ∈ X ∧ y ∈ Y
>
> FunctionSpace
> |- ∀ s t. s → t =
> {f | (∀ x. x ∈ s ⇒ f x ∈ t) ∧ ∀x. x ∉ s ⇒ f x = @y. T}
>
> IN_FunctionSpace
> |- ∀ s t f. f ∈ s → t ⇔
> (∀ x. x ∈ s ⇒ f x ∈ t) ∧ ∀ x. x ∉ s ⇒ f x = @y. T
>
> FunctionComposition
> |- ∀ x f s g. (g ∘ (f,s)) x = (if x ∈ s then g (f x) else @y. T)
>
> UniversalPropertyProduct
> |- ∀ M A B f g.
> f ∈ M → A ∧ g ∈ M → B
> ⇒ (∃! h. h ∈ M → A ∏ B  ∧  FST ∘ (h,M) = f  ∧  SND ∘ (h,M) = g)
> *)
>
> horizon := 0;;
> timeout := 50;;
>
> parse_as_infix("NOTIN",(11, "right"));;
> parse_as_infix("times",(20, "right"));;
> parse_as_infix("composition",(20, "right"));;
> parse_as_infix("--->",(13,"right"));;
>
> let NOTIN = new_definition
> `! a:A l:A->bool. a NOTIN l <=> ~(a IN l)`;;
>
> let CartesianProduct = new_definition
> `! X Y. X times Y = {(x,y):A#B | x IN X /\ y IN Y}`;;
>
> let IN_CartesianProduct = thm `;
> ! X Y x:A y:B.
> x,y IN X times Y  <=>  x IN X /\ y IN Y
> by CartesianProduct, SET_RULE, PAIR_EQ`;;
>
> let FunctionSpace = new_definition
> `! s t. s ---> t = {f: A->B | (! x. x IN s ==> f x  IN t) /\
> ! x. x NOTIN s ==> f x  = @y. T}`;;
>
> let IN_FunctionSpace = thm `;
> ! s: A->bool t: B->bool f: A->B. f IN s ---> t
> <=>  (! x. x IN s ==> f x IN t)  /\  ! x. x NOTIN s ==> f x  = @y. T
> by FunctionSpace, SET_RULE`;;
>
> let FunctionComposition = new_definition
> `! f:A->B s:A->bool g:B->C x.
> (g composition (f,s)) x = if x IN s then g (f x) else @y:C. T`;;
>
> let UniversalPropertyProduct = thm `;
> let M be mu->bool;
> let A be alpha->bool;
> let B be beta->bool;
> let f be mu->alpha;
> let g be m

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Mark!  Your precedence list explains my code.  Why don't we try to 
prove your precedence order is correct for HOL Light.  Don't we just have to 
understand parser.ml?  I just realized I don't need type annotations if use 
tactics:

let CartesianProduct = new_definition
   `! X Y. X times Y = {x,y | x IN X /\ y IN Y}`;;

let IN_CartesianProduct = prove
 (`! X Y x y. x,y IN X times Y  <=>  x IN X /\ y IN Y`,
  REWRITE_TAC[IN_ELIM_THM; CartesianProduct] THEN MESON_TAC[PAIR_EQ]);;

However, that doesn't work in miz3!!!  I get the error #6 underspecified types 
hol with

let IN_CartesianProduct = thm `;
   ! X Y x y. 
   x,y IN X times Y  <=>  x IN X /\ y IN Y
   by CartesianProduct, SET_RULE, PAIR_EQ`;;

So miz3 is doing something funny.  Milner type inference surely tells us that 
no type annotations were needed above.  Well, that's fine, I don't mind feeding 
miz3 extra type annotations.  I suppose it helps readability.  Here's a place 
where my type inference intuition doesn't work, and I get the error 
Exception: Failure "typechecking error (initial type assignment)":

parse_as_infix("-bb-->",(13,"right"));;

let FunctionbbSpace = new_definition
   `! s t. s -bb--> t = {f | (! x. x IN s ==> f x  IN t) /\
  ! x. x NOTIN s ==> f x  = @y. T}`;;

HOL Light seems to insist on the type annotation f: A->B.  But I can't see why. 
 A and B just mean arbitrary types.  The sub-term x IN s shows that s has type 
A->bool and x has type A, for some type A.  and the sub-term f x  IN t shows 
that t has type B->bool and f x has type B, for some type B.  Thus f has type 
A->B.  What am I missing?  

-- 
Best,
Bill 

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Mark]

Hi Bill,

> Why don't we try to prove your precedence order is correct for HOL Light.
>  Don't we just have to understand parser.ml?

Yes, but that's easier said than done!  Parsers can be subtle things.

>  I just realized I don't need type annotations if use tactics:
>
> let CartesianProduct = new_definition
> `! X Y. X times Y = {x,y | x IN X /\ y IN Y}`;;
>
> let IN_CartesianProduct = prove
> (`! X Y x y. x,y IN X times Y  <=>  x IN X /\ y IN Y`,
> REWRITE_TAC[IN_ELIM_THM; CartesianProduct] THEN MESON_TAC[PAIR_EQ]);;

The term defining CartesianProduct has a type variable (automatically
generated).  It's good practice to explicitly type-annotate your terms with
any type varaibles, rather than to get HOL Light to generate type variables
for you.  As you say, it helps readability.

Your proof above works because you don't need to supply term quotations that
involve the generated type variable.  If such term quotations were needed,
then you would have to annotate them with the nasty generated type variable
name.

> However, that doesn't work in miz3!!!  I get the error #6 underspecified
> types hol with
> 
> So miz3 is doing something funny.

I don't know about miz3, but I'm guessing it doesn't allow type variables to
be generated.

> Milner type inference surely tells us that no type annotations were needed
above.

Milner type inference tells us that type annotations are never needed!  It
always either fails (because the term is ill-typed) or succeeds with the
most general types possible (generating type variables that are not
explicitly supplied in type annotations).

> Here's a place where my type inference intuition doesn't work, and I get
the
> error
> Exception: Failure "typechecking error (initial type assignment)":
>
> parse_as_infix("-bb-->",(13,"right"));;
>
> let FunctionbbSpace = new_definition
> `! s t. s -bb--> t = {f | (! x. x IN s ==> f x  IN t) /\
> ! x. x NOTIN s ==> f x  = @y. T}`;;
>
> HOL Light seems to insist on the type annotation f: A->B.  But I can't see
> why.  A and B just mean arbitrary types.  The sub-term x IN s shows that s
> has type A->bool and x has type A, for some type A.  and the sub-term f x
> IN t shows that t has type B->bool and f x has type B, for some type B.
> Thus f has type A->B.  What am I missing?

Your reasoning is correct, but I don't know the full theory context in which
this exists.  Crucially, has 'NOTIN' been declared as an infix?  (whether it
is has been declared/defined as a constant is actually not important for the
purposes of type inference)

Mark.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Mark!  This is very cool, and I did not know it:

   Milner type inference tells us that type annotations are never needed!  

And I don't need type annotations for FunctionSpace!  These two results are 
fine: 

let FunctionSpace = new_definition
   `! s t. s ---> t = {f | (! x. x IN s ==> f x  IN t) /\
  ! x. x NOTIN s ==> f x  = @y. T}`;;

let IN_FunctionSpace = prove
  (`! s t f. f IN s ---> t  
  <=>  (! x. x IN s ==> f x IN t)  /\  ! x. x NOTIN s ==> f x  = @y. T`,
  REWRITE_TAC[IN_ELIM_THM; FunctionSpace]);;

I'm still getting the error message I got yesterday: 

parse_as_infix("-bb-->",(13,"right"));;

let FunctionbbSpace = new_definition
   `! s t. s -bb--> t = {f | (! x. x IN s ==> f x  IN t) /\
  ! x. x NOTIN s ==> f x  = @y. T}`;;

Your NOTIN suggestion made great sense, but that's not the problem, it seems, 
because FunctionSpace/---> worked.  I think HOL Light doesn't like my weird 
infix -bb-->.  HOL Light won't even take this as a function:

let FunctionddSpace = new_definition
   `! s t. -dd--> s t = {f | (! x. x IN s ==> f x  IN t) /\
  ! x. x NOTIN s ==> f x  = @y. T}`;;

I get the error Exception: Noparse.  

   It's good practice to explicitly type-annotate your terms with any
   type variables, rather than to get HOL Light to generate type
   variables for you.

Perhaps I don't agree with you.  Michael Norrish argued eloquently that type 
inference makes HOL more expressive, more abole to formalize pure math.  But 
it's a good point you're making.  

   I don't know about miz3, but I'm guessing it doesn't allow type
   variables to be generated.

Interesting suggestion!  Perhaps Freek will tell us.  

   that's easier said than done!  Parsers can be subtle things.

Yes, but it's something we're supposed to understand, nicht wahr?  How do you 
handle precedence in your HOL Zero?  I'd guess it's similar to the way HOL 
Light does precedence.

-- 
Best,
Bill 


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Mark]

Hi Bill,

> Your NOTIN suggestion made great sense, but that's not the problem, it
> seems, because FunctionSpace/---> worked.  I think HOL Light doesn't like
my
> weird infix -bb-->.  HOL Light won't even take this as a function:
>
> let FunctionddSpace = new_definition
> `! s t. -dd--> s t = {f | (! x. x IN s ==> f x  IN t) /\
> ! x. x NOTIN s ==> f x  = @y. T}`;;

Yes, I missed that.  The name "-dd-->" is irregular (it mixes symbolic and
alpha-numeric characters), and won't get parsed correctly in term quotations
in HOL Light.  You have to construct terms involving "-dd-->" using the
syntax constructor functions (mk_comb, mk_eq, etc).

> How do you handle precedence in your HOL Zero?  I'd guess it's similar
> to the way HOL Light does precedence.

I did a major review of HOL concrete syntax when designing HOL Zero, and
numerous details are handled differently from the other HOL systems.
Precedence is similar to HOL Light's, but type annotation generally requires
parentheses (although there are a few exceptions) - so `f a : A` in HOL
Light is `f (a:A)` in HOL Zero.  Pairs are a special syntactic category,
where "," is a separator instead of being an infix operator, and outer
parentheses are mandatory - so `a,b,c` in HOL Light is `(a,b,c)` in HOL
Zero.

Mark.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Mark, thanks for explaining my irregular syntax (how do I learn I can't mix 
symbolic and alpha-numeric characters?), and that HOL Zero precedence is 
similar to HOL Light's.  I have a SWAP_FORALL_THM question an a vote for miz3.  
I got this tactics proof to work, but I don't know why it does:

let ReachableInvariant = prove
 (`!p p'. reachable p p'  ==>  oriented_area p = oriented_area p'`,
  ASM_SIMP_TAC[ReachLemma] THEN SIMP_TAC[LEFT_IMP_EXISTS_THM] THEN 
  SIMP_TAC[SWAP_FORALL_THM] THEN INDUCT_TAC THEN 
ASM_MESON_TAC[reachableN_CLAUSES; MOVE_INVARIANT]);;

This tactics script requires other things to run, but my problem doesn't 
involve them, I think.  Writing this interactively I see that 
SIMP_TAC[SWAP_FORALL_THM] performed the goal reduction  

`!p p' n. reachableN p p' n ==> oriented_area p = oriented_area p'`

`!n p p'. reachableN p p' n ==> oriented_area p = oriented_area p'`

That's what I wanted, because now INDUCT_TAC gives me induction on the variable 
n.   But I don't know why that happened.  I would have thought that 
SWAP_FORALL_THM would take switch the variables p and p' instead:
SWAP_FORALL_THM;;
val it : thm = |- !P. (!x y. P x y) <=> (!y x. P x y)

This tactics script I think shows the value of miz3.  I was only able to write 
this, I think, after having already written the following miz3 proof, which is 
much longer but was much easier to write.  I've only read up to page 68 of the 
HOL Light tutorial, and I don't quite understand what these tactics do, or how 
to set up a tactics proof.  But I knew it could be done, and "in spirit" how 
the proof would go, so I was able to hunt through theorems.ml to find what I 
needed.  

-- 
Best,
Bill 

let ReachableInvariant = thm `;
  let p p' be (real#real)#(real#real)#(real#real);
  assume reachable p p' [H1];
  thus oriented_area p = oriented_area p'

  proof
consider P such that 
P = \n. ! p p'. reachableN p p' n  ==>  oriented_area p = oriented_area p'  
   [Pdef];
P 0 [P0] by Pdef, reachableN_CLAUSES; 
! n. P n ==> P (SUC n)
proof
  let n be num;
  assume P n;
  ! p p'. reachableN p p' n  ==>  oriented_area p = oriented_area p' 
[nStep] by -, Pdef;
  ! r r'. reachableN r r' (SUC n)  ==>  oriented_area r = oriented_area r'
  proof
let r r' be (real#real)#(real#real)#(real#real);
assume reachableN r r' (SUC n);
consider q such that 
reachableN r q n /\ move q r' [qExists] by -, reachableN_CLAUSES;
oriented_area r = oriented_area q   /\  oriented_area q = oriented_area 
r' by -, nStep, MOVE_INVARIANT;
  qed by -;
qed by -, Pdef;
! n. P n [allPn] by -, P0, Pdef, num_INDUCTION;
consider n such that 
reachableN p p' n by H1, ReachLemma;
  qed by -, Pdef, allPn;
`;;

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

I have a question about X_CHOOSE_TAC and another vote for miz3.

In miz3 you can easily define variables with `consider'.  The HOL Light 
tutorial only explains two ways to define variables, both in proofs (p 73--81) 
of the irrationality of sqrt{2}.  John's p 78 Mizar-like `consider' is close to 
miz3's, but I do not understand the code and I've found no HOL Light source 
code that seems to be using the idea.  I believe the only other variable 
definition in the tutorial is on p 74:
e(DISCH_THEN(X_CHOOSE_THEN 'm:num' SUBST_ALL_TAC));;
In the HOL Light source code I see variants of this, but always with DISCH.  I 
use DISCH_THEN(CHOOSE_TAC) below.  How can I use X_CHOOSE_TAC without DISCH?

John has a nice Mizar-like proof of the irrationality of sqrt{2} using his 
consider on p 81. I turned it into a normal tactics proof, but my code below 
looks clumsy.  It looks odd the way I add assumptions by SUBGOAL_THEN and then 
in one line prove the sub-goal.  I bet this can be done in one line.  I think 
my use of X_CHOOSE_TAC and DISCH is odd.  It's fine to only define variables 
through a "existentially quantified conclusion" like ?x.alpha, because when we 
define x, it no doubt satisfies some property alpha, thus ?x.alpha must be 
true.  So I made my ?x.alpha a sub-goal, proved it, and then used 
MP_TAC(ASSUME `?x.alpha`) 
to make ?x.alpha the antecedent of the goal, and then used 
DISCH_THEN(CHOOSE_TAC)
to define the variable x and make alpha an assumption.  Then we go back to the 
original goal.  Can someone tell me a better way?

-- 
Best,
Bill 

g `!p q. p * p = 2 * q * q ==> q = 0`;;
e(MATCH_MP_TAC num_WF);;
e(REPEAT STRIP_TAC);;
e(SUBGOAL_THEN `EVEN p` ASSUME_TAC);;
e(ASM_MESON_TAC[EVEN_EXISTS; EVEN_MULT]);;
e(SUBGOAL_THEN `?m. p = 2 * m` ASSUME_TAC);;
e(ASM_MESON_TAC[EVEN_EXISTS]);;
e(MP_TAC(ASSUME `?m. p = 2 * m`));;
e(DISCH_THEN(CHOOSE_TAC));;
e(DISJ_CASES_TAC(ARITH_RULE `q < p \/ p <= q`));;
e(SUBGOAL_THEN `q * q = 2 * m * m ==> m = 0` ASSUME_TAC);;
e(ASM_MESON_TAC[]);;
e(SUBGOAL_THEN `q * q = 2 * m * m` ASSUME_TAC);;
e(SUBGOAL_THEN `p = 2 * m /\ p * p = 2 * q * q ==> q * q = 2 * m * m` 
ASSUME_TAC);;
e(CONV_TAC NUM_RING);;
e(ASM_MESON_TAC[]);;
e(SUBGOAL_THEN `m = 0` ASSUME_TAC);;
e(ASM_MESON_TAC[]);;
e(ASM_MESON_TAC[MULT_EQ_0]);;
e(SUBGOAL_THEN `p * p <= q * q` ASSUME_TAC);;
e(ASM_MESON_TAC[LE_MULT2]);;
e(SUBGOAL_THEN `p * p = 2 * q * q /\ p * p <= q * q ==> q * q = 0` ASSUME_TAC);;
e(ARITH_TAC);;
e(SUBGOAL_THEN `q * q = 0` ASSUME_TAC);;
e(ASM_MESON_TAC[MULT_EQ_0]);;
e(ASM_MESON_TAC[MULT_EQ_0]);;

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Ramana Kumar]

Forgive me for not reading in full detail, but I think I can answer your
question:
To use X_CHOOSE_TAC without using DISCH_THEN, you can simply pass it a
theorem.
So, rather than MP_TAC(ASSUME t) followed by DISCH_THEN(CHOOSE_TAC), you
could simply do CHOOSE_TAC(ASSUME t).


On Wed, Dec 12, 2012 at 6:22 PM, Bill Richter  wrote:

> I have a question about X_CHOOSE_TAC and another vote for miz3.
>
> In miz3 you can easily define variables with `consider'.  The HOL Light
> tutorial only explains two ways to define variables, both in proofs (p
> 73--81) of the irrationality of sqrt{2}.  John's p 78 Mizar-like `consider'
> is close to miz3's, but I do not understand the code and I've found no HOL
> Light source code that seems to be using the idea.  I believe the only
> other variable definition in the tutorial is on p 74:
> e(DISCH_THEN(X_CHOOSE_THEN 'm:num' SUBST_ALL_TAC));;
> In the HOL Light source code I see variants of this, but always with
> DISCH.  I use DISCH_THEN(CHOOSE_TAC) below.  How can I use X_CHOOSE_TAC
> without DISCH?
>
> John has a nice Mizar-like proof of the irrationality of sqrt{2} using his
> consider on p 81. I turned it into a normal tactics proof, but my code
> below looks clumsy.  It looks odd the way I add assumptions by SUBGOAL_THEN
> and then in one line prove the sub-goal.  I bet this can be done in one
> line.  I think my use of X_CHOOSE_TAC and DISCH is odd.  It's fine to only
> define variables through a "existentially quantified conclusion" like
> ?x.alpha, because when we define x, it no doubt satisfies some property
> alpha, thus ?x.alpha must be true.  So I made my ?x.alpha a sub-goal,
> proved it, and then used
> MP_TAC(ASSUME `?x.alpha`)
> to make ?x.alpha the antecedent of the goal, and then used
> DISCH_THEN(CHOOSE_TAC)
> to define the variable x and make alpha an assumption.  Then we go back to
> the original goal.  Can someone tell me a better way?
>
> --
> Best,
> Bill
>
> g `!p q. p * p = 2 * q * q ==> q = 0`;;
> e(MATCH_MP_TAC num_WF);;
> e(REPEAT STRIP_TAC);;
> e(SUBGOAL_THEN `EVEN p` ASSUME_TAC);;
> e(ASM_MESON_TAC[EVEN_EXISTS; EVEN_MULT]);;
> e(SUBGOAL_THEN `?m. p = 2 * m` ASSUME_TAC);;
> e(ASM_MESON_TAC[EVEN_EXISTS]);;
> e(MP_TAC(ASSUME `?m. p = 2 * m`));;
> e(DISCH_THEN(CHOOSE_TAC));;
> e(DISJ_CASES_TAC(ARITH_RULE `q < p \/ p <= q`));;
> e(SUBGOAL_THEN `q * q = 2 * m * m ==> m = 0` ASSUME_TAC);;
> e(ASM_MESON_TAC[]);;
> e(SUBGOAL_THEN `q * q = 2 * m * m` ASSUME_TAC);;
> e(SUBGOAL_THEN `p = 2 * m /\ p * p = 2 * q * q ==> q * q = 2 * m * m`
> ASSUME_TAC);;
> e(CONV_TAC NUM_RING);;
> e(ASM_MESON_TAC[]);;
> e(SUBGOAL_THEN `m = 0` ASSUME_TAC);;
> e(ASM_MESON_TAC[]);;
> e(ASM_MESON_TAC[MULT_EQ_0]);;
> e(SUBGOAL_THEN `p * p <= q * q` ASSUME_TAC);;
> e(ASM_MESON_TAC[LE_MULT2]);;
> e(SUBGOAL_THEN `p * p = 2 * q * q /\ p * p <= q * q ==> q * q = 0`
> ASSUME_TAC);;
> e(ARITH_TAC);;
> e(SUBGOAL_THEN `q * q = 0` ASSUME_TAC);;
> e(ASM_MESON_TAC[MULT_EQ_0]);;
> e(ASM_MESON_TAC[MULT_EQ_0]);;
>
>
> --
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> ___
> hol-info mailing list
> hol-info@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hol-info
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

Hello Bill,

Without being as much of an expert as other people on this list, it is 
my understanding that traditionally HOL systems are rather inflexible 
when it comes to manipulating assumptions.

If you need to apply further rules/tactics, it is preferable to deal 
with antecedents rather than assumptions.

For example, instead of this:
e(SUBGOAL_THEN `EVEN p` ASSUME_TAC);;

it would be easier to do this:
e(SUBGOAL_THEN `EVEN p` MP_TAC);;

and then manipulate the antecedent further using DISCH_THEN (ie. without 
the need for your extra MP_TAC (ASSUME t) step).

In the spirit of Ramana's reply, you can avoid using DISCH_THEN as follows:
e(SUBGOAL_THEN `EVEN p` (CHOOSE_TAC o REWRITE_RULE[EVEN_EXISTS]));;

(You are actually using ASM_MESON_TAC to prove `?m. p = 2 * m` from 
`EVEN p` but rewriting is sufficient.)

This, of course, requires some planning ahead of what you need to do 
with `EVEN p`, but I am just demonstrating how one would manage not to 
use DISCH_THEN with CHOOSE_TAC.

Note that this would actually be less complicated if you didn't use 
`EVEN p` as an intermediate subgoal but went straight for `?m. p = 2 * 
m` (realising this would mean skipping a step from the original proof). 
You are using EVEN_EXISTS to prove your subgoal anyway!

You can simply:
e(SUBGOAL_THEN `?m. p = 2 * m` CHOOSE_TAC);;

To sum up, the first part of your proof:
g `!p q. p * p = 2 * q * q ==> q = 0`;;
e(MATCH_MP_TAC num_WF);;
e(REPEAT STRIP_TAC);;
e(SUBGOAL_THEN `EVEN p` ASSUME_TAC);;
e(ASM_MESON_TAC[EVEN_EXISTS; EVEN_MULT]);;
e(SUBGOAL_THEN `?m. p = 2 * m` ASSUME_TAC);;
e(ASM_MESON_TAC[EVEN_EXISTS]);;
e(MP_TAC(ASSUME `?m. p = 2 * m`));;
e(DISCH_THEN(CHOOSE_TAC));;

can be "simplified" as follows:
g `!p q. p * p = 2 * q * q ==> q = 0`;;
e(MATCH_MP_TAC num_WF);;
e(REPEAT STRIP_TAC);;
e(SUBGOAL_THEN `?m. p = 2 * m` CHOOSE_TAC);;
e(ASM_MESON_TAC[EVEN_EXISTS;EVEN_MULT]);;

Hope this helps.

Regards,

Petros


On 12/12/2012 07:22, Bill Richter wrote:
> It looks odd the way I add assumptions by SUBGOAL_THEN and then in one line 
> prove the sub-goal.
 > I bet this can be done in one line.  I think my use of X_CHOOSE_TAC 
and DISCH is odd.  It's fine to only define variables through a 
"existentially quantified conclusion" like ?x.alpha, because when we 
define x, it no doubt satisfies some property alpha, thus ?x.alpha must 
be true.  So I made my ?x.alpha a sub-goal, proved it, and then used
> MP_TAC(ASSUME `?x.alpha`)
> to make ?x.alpha the antecedent of the goal, and then used
> DISCH_THEN(CHOOSE_TAC)
> to define the variable x and make alpha an assumption.  Then we go back to 
> the original goal.  Can someone tell me a better way?
>

-- 
Petros Papapanagiotou
CISA, School of Informatics
The University of Edinburgh

Email: p.papapanagio...@sms.ed.ac.uk

---
  The University of Edinburgh is a charitable body, registered in
  Scotland, with registration number SC005336.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thank, Ramana and Petros!  Your code looks very helpful, and I'll study it, but 
first I want to explain something I did with miz3's `consider' but could not 
port to HOL Light, even using the tutorial p 78 Mizar-like `consider'.   Here's 
a simpler version of the tutorial p 65 `reachable'

let addN = new_definition
  `!p p' n.
  addN p p' n <=> ?s. 
  s 0 = p /\ s n = p' /\
  (!m. m < n ==> s (SUC m) = SUC (s m))`;;

Here's a very simple result I proved with mi3z, related to the tutorial p 67 
REACHABLE_INVARIANT:

addfour_THM : thm =
  |- !p p'. addN p p' 4 ==> (?q. addN p q 3 /\ p' = SUC q)

#load "unix.cma";;
loadt "miz3/miz3.ml";;
horizon := 0;;

let addfour_THM = thm `;
  thus !p p'. addN p p' 4 ==> ?q. addN p q 3 /\ p' = SUC q

  proof
let p p' be num;
assume addN p p' 4;
consider s such that 
s 0 = p /\ s 4 = p' /\ (!m. m < 4 ==> s (SUC m) = SUC (s m)) [sDef] by 
-, addN;
consider q such that 
q = s 3 [qDef];
SUC 3 = 4;
s 0 = p /\ s 3 = q /\ (!m. m < 3 ==> s (SUC m) = SUC (s m)) /\ p' = SUC q   
  by -, qDef, LT, sDef;
  qed by -, addN;
`;;

Let's try to port this proof to HOL Light up to qDef:

g `addN p p' 4 ==> ?q. addN p q 3 /\ p' = SUC q`;;
e(SIMP_TAC[addN]);;
e(DISCH_THEN(X_CHOOSE_TAC `s: num->num`));;
e(SUBGOAL_THEN `s 0 = p` ASSUME_TAC);;
e(ASM_MESON_TAC[]);;

It's OK to the last line, but MESON times out with Exception: Failure 
"solve_goal: Too deep".  I get the same problem using John's Mizar-like 
`consider': 

g `addN p p' 4 ==> ?q. addN p q 3 /\ p' = SUC q`;;
e(SIMP_TAC[addN]);;
e(assume("A") `?s. s 0 = p /\ s 4 = p' /\ (!m. m < 4 ==> s (SUC m) = SUC (s 
m))`);;
e(so consider (`s:num->num`,"B", 
`s 0 = p /\ s 4 = p' /\ (!m. m < 4 ==> s (SUC m) = SUC (s m))`) (using [] 
trivial));;
e(so have `s 0 = p` (by ["B"] trivial));;
 
To run this, you need the tutorial Mizar-like code included below.  I think I'm 
using John's code correctly, because it's similar to his p 81 Mizar-like proof 
of NSQRT_2.  The moral of the story must be that HOL uses different idioms 
(e.g. Petros's) to accomplish the same things I know how to do easily in miz3.  
This example of course is quite simple, but it illustrates a problem: how to do 
we bind a variable to a function with a label so that we can use it repeatedly? 
 With John's Mizar-like consider we can bind variables to numbers, e.g. 
so consider (‘m:num‘,"C",‘p = 2 * m‘) (using [EVEN_EXISTS] trivial) THEN
I studied the HOL Light sources and a number of places that X_CHOOSE_TAC was 
applied to a function.  But it seemed to me that EXISTS_TAC was usually applied 
right afterward, and that's not saving the function for later use.  

-- 
Best,
Bill 

let fix ts = MAP_EVERY X_GEN_TAC ts;;

let assume lab t =
  DISCH_THEN(fun th -> if concl th = t then LABEL_TAC lab th
   else failwith "assume");;
  
let we’re finished tac = tac;;

let suffices_to_prove q tac = SUBGOAL_THEN q (fun th -> MP_TAC th THEN tac);;

  let note(lab,t) tac =
SUBGOAL_THEN t MP_TAC THENL [tac; ALL_TAC] THEN
DISCH_THEN(fun th -> LABEL_TAC lab th);;

let have t = note("",t);;

  let cases (lab,t) tac =
SUBGOAL_THEN t MP_TAC THENL [tac; ALL_TAC] THEN
DISCH_THEN(REPEAT_TCL DISJ_CASES_THEN (LABEL_TAC lab));;
  
let consider (x,lab,t) tac =
let tm = mk_exists(x,t) in
SUBGOAL_THEN tm (X_CHOOSE_THEN x (LABEL_TAC lab)) THENL [tac; ALL_TAC];;


let trivial = MESON_TAC[];;
let algebra = CONV_TAC NUM_RING;;
let arithmetic = ARITH_TAC;;

let by labs tac = MAP_EVERY (fun l -> USE_THEN l MP_TAC) labs THEN tac;;

let using ths tac = MAP_EVERY MP_TAC ths THEN tac;;

let so constr arg tac = constr arg (FIRST_ASSUM MP_TAC THEN tac);;

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Petros, I really like your fix of my code, and it's even nicer than Ramana's, 
although I need to understand why his CHOOSE_TAC(ASSUME t) works.  Your fix 
SUBGOAL_THEN `?m. p = 2 * m` CHOOSE_TAC
is especially appealing to me, because you're usage just substitutes CHOOSE_TAC 
for ASSUME_TAC, as e.g. in
SUBGOAL_THEN `EVEN p` ASSUME_TAC
I don't understand that usage yet, but I'm used it by now.
I have a new HOL Light proof runs faster because I added an extra step, and I 
eliminated an embarrassment (see below) by using John's trick !x. 2 * x <= x  
==> x = 0 from his earlier proof: 

g `!p q. p * p = 2 * q * q ==> q = 0`;;
e(MATCH_MP_TAC num_WF);;
e(REPEAT STRIP_TAC);;
e(SUBGOAL_THEN `?m. p = 2 * m` CHOOSE_TAC);;
e(ASM_MESON_TAC[EVEN_EXISTS;EVEN_MULT]);;
e(DISJ_CASES_TAC(ARITH_RULE `q < p \/ p <= q`));;
e(SUBGOAL_THEN `q * q = 2 * m * m ==> m = 0` ASSUME_TAC);;
e(ASM_MESON_TAC[]);;
e(SUBGOAL_THEN `q * q = 2 * m * m` ASSUME_TAC);;
e(SUBGOAL_THEN `p = 2 * m /\ p * p = 2 * q * q ==> q * q = 2 * m * m` 
ASSUME_TAC);;
e(CONV_TAC NUM_RING);;
e(ASM_MESON_TAC[]);;
e(SUBGOAL_THEN `m = 0` ASSUME_TAC);;
e(ASM_MESON_TAC[]);;
e(SUBGOAL_THEN `q * q = 0` ASSUME_TAC);;
e(ASM_MESON_TAC[MULT_CLAUSES]);;
e(ASM_MESON_TAC[MULT_EQ_0]);;
e(SUBGOAL_THEN `p * p <= q * q` ASSUME_TAC);;
e(ASM_MESON_TAC[LE_MULT2]);;
e(SUBGOAL_THEN `!x. 2 * x <= x  ==> x = 0` ASSUME_TAC);;
e(ARITH_TAC);;
e(ASM_MESON_TAC[LTE_CASES; LE_MULT2; MULT_EQ_0]);;

I think you're saying that I can't avoid using two lines per statement: first 
state the statement as a subgoal, and then prove it on the next line.  So 
that's fine.  But I find these 3 lines embarrassing:

e(SUBGOAL_THEN `p = 2 * m /\ p * p = 2 * q * q ==> q * q = 2 * m * m` 
ASSUME_TAC);;
e(CONV_TAC NUM_RING);;
e(ASM_MESON_TAC[]);;

At this point my assumption-list and goal is 

  0 [`!m. m < p ==> (!q. m * m = 2 * q * q ==> q = 0)`]
  1 [`p * p = 2 * q * q`]
  2 [`p = 2 * m`]
  3 [`q < p`]
  4 [`q * q = 2 * m * m ==> m = 0`]

`q * q = 2 * m * m`

It's obvious that assumptions 1 & 2 imply the goal, and NUM_RING can prove it.  
So intead of these 3 lines, I wanted to write 
e(ASM_MESON_TAC[NUM_RING]);;
But I can't do that, because NUM_RING isn't a theorem.  I had a similar 
embarrassing problem with ARITH_TAC, but John's trick got rid of it.  

BTW I don't actually need ARITH_TAC for John's trick, as this miz3 proof shows: 

let _THM = thm `;
  thus !x. 2 * x <= x  ==> x = 0
  proof
let x be num;
assume 2 * x <= x;
2 <= 1 \/ x = 0 by -, MULT_CLAUSES, LE_MULT_RCANCEL;
  qed by -, LT, TWO, LET_ANTISYM;
`;;

BTW I realized that 
e(DISCH_THEN(CHOOSE_TAC));;
has the same effect as something that seems a lot simpler to me:
e(SIMP_TAC[LEFT_IMP_EXISTS_THM]);;
e(STRIP_TAC THEN DISCH_TAC);;

This is quite simple: 
 LEFT_IMP_EXISTS_THM;;
val it : thm = |- !P Q. (?x. P x) ==> Q <=> (!x. P x ==> Q)

And it makes me wonder if the way HOL tactics evolved had to do with what was 
simple and appealing in the Lambda Calculus...

-- 
Best,
Bill 

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

Hello Ramana,

On 13/12/2012 12:53, Bill Richter wrote:
> Petros, I really like your fix of my code,

Glad I could help.


> and it's even nicer than Ramana's, although I need to understand why his 
> CHOOSE_TAC(ASSUME t) works.  Your fix
> SUBGOAL_THEN `?m. p = 2 * m` CHOOSE_TAC
> is especially appealing to me, because you're usage just substitutes 
> CHOOSE_TAC for ASSUME_TAC, as e.g. in
> SUBGOAL_THEN `EVEN p` ASSUME_TAC
> I don't understand that usage yet, but I'm used it by now.

I am not sure which part confuses you in order to help out.

You can read "SUBGOAL_THEN t X" as "create a new subgoal t, then do X 
with it". If X is ASSUME_TAC then it is added as an assumption as-is.

You can read "CHOOSE_TAC" as "take an existentially quantified theorem 
and add its body as an assumption".


Actually things like "CHOOSE_TAC(ASSUME t)" and "MP_TAC(ASSUME t)" only 
work in this example because "t" is already an assumption.



> I think you're saying that I can't avoid using two lines per statement: first 
> state the statement as a subgoal, and then prove it on the next line.  So 
> that's fine.

You can sometimes. If your subgoal is general, you can prove it (either 
as an external lemma or inline using "prove") and use it in one line.
eg:
You can convert this:
e(SUBGOAL_THEN `q * q = 0` ASSUME_TAC);;
[...]
e(ASM_MESON_TAC[MULT_EQ_0]);; (* used to prove q = 0 *)

to this:
e(MATCH_MP_TAC (prove(`q * q = 0 ==> q = 0`,REWRITE_TAC[MULT_EQ_0]));;
[...]

It depends on your style and what you find better/cleaner.

I think a lot of these things actually boil down to personal style.


> But I find these 3 lines embarrassing:
>
> e(SUBGOAL_THEN `p = 2 * m /\ p * p = 2 * q * q ==> q * q = 2 * m * m` 
> ASSUME_TAC);;
> e(CONV_TAC NUM_RING);;
> e(ASM_MESON_TAC[]);;
>
> At this point my assumption-list and goal is
>
>0 [`!m. m < p ==> (!q. m * m = 2 * q * q ==> q = 0)`]
>1 [`p * p = 2 * q * q`]
>2 [`p = 2 * m`]
>3 [`q < p`]
>4 [`q * q = 2 * m * m ==> m = 0`]
>
> `q * q = 2 * m * m`
>
> It's obvious that assumptions 1 & 2 imply the goal, and NUM_RING can prove 
> it.  So intead of these 3 lines, I wanted to write
> e(ASM_MESON_TAC[NUM_RING]);;
> But I can't do that, because NUM_RING isn't a theorem.  I had a similar 
> embarrassing problem with ARITH_TAC, but John's trick got rid of it.

I am not exactly sure what your best option is here.
I would go for:
e (UNDISCH_TAC `p * p = 2 * q * q`);;
e (UNDISCH_TAC `p = 2 * m`);;
e (CONV_TAC NUM_RING);;

but I don't think this is much less "embarrassing" than yours.

I am as curious as you if someone could come up with a more elegant way 
of dealing with this.

Having a more computer science/engineering point of view, little 
problems like this often lead me to write my own tactics to do things 
"my way" (and sometimes later discover there was a HOL way all along).


On a different note,
e(SUBGOAL_THEN `q * q = 2 * m * m ==> m = 0` ASSUME_TAC);;
is not really necessary.


Regards,

Petros



-- 
Petros Papapanagiotou
CISA, School of Informatics
The University of Edinburgh

Email: p.papapanagio...@sms.ed.ac.uk

---
  The University of Edinburgh is a charitable body, registered in
  Scotland, with registration number SC005336.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

Hello Bill,

On 13/12/2012 10:32, Bill Richter wrote:
> Let's try to port this proof to HOL Light up to qDef:
>
> g `addN p p' 4 ==> ?q. addN p q 3 /\ p' = SUC q`;;
> e(SIMP_TAC[addN]);;
> e(DISCH_THEN(X_CHOOSE_TAC `s: num->num`));;
> e(SUBGOAL_THEN `s 0 = p` ASSUME_TAC);;
> e(ASM_MESON_TAC[]);;
>
> It's OK to the last line, but MESON times out with Exception: Failure 
> "solve_goal: Too deep".  I get the same problem using John's Mizar-like 
> `consider':

That is because the `s` and `p` in your subgoal do not match the `s` and 
`p` in your assumptions.

If you replace:
e(SUBGOAL_THEN `s 0 = p` ASSUME_TAC);;
with:
e(SUBGOAL_THEN `(s:num->num) 0 = p` ASSUME_TAC);;
it will work.

However, using SUBGOAL_THEN to obtain the conjuncts of your assumption 
is not very "elegant".

You can do something like:
e (FIRST_ASSUM (CONJUNCTS_THEN ASSUME_TAC));;

or if you do not need the original assumption:
e (POP_ASSUM (CONJUNCTS_THEN ASSUME_TAC));;

or if you want to break all conjuncts in one go:
e (REPEAT (POP_ASSUM (CONJUNCTS_THEN ASSUME_TAC)));;

or the equivalent:
e (POP_ASSUM (REPEAT_TCL CONJUNCTS_THEN ASSUME_TAC));;

I should note that for this proof you don't actually need to break down 
the assumption at all. MESON_TAC is powerful enough to handle it as-is 
(in fact using ASM_MESON_TAC puts the conjuncts back together in the 
background).

Here is my take on the proof you are attempting:

g `!p p'. addN p p' 4 ==> (?q. addN p q 3 /\ p' = SUC q)`;;
e (REPEAT GEN_TAC);;
e (SIMP_TAC[addN]);;
e (DISCH_THEN (X_CHOOSE_THEN `s: num->num` (REPEAT_TCL CONJUNCTS_THEN 
ASSUME_TAC)));;
(* Or simply: *)
(* e (DISCH_THEN (X_CHOOSE_TAC `s: num->num`));; *)
e (EXISTS_TAC `(s:num->num) 3`);;
e (ASM_MESON_TAC[LT;ARITH_RULE `SUC 3 = 4`]);;


Regards,

Petros



-- 
Petros Papapanagiotou
CISA, School of Informatics
The University of Edinburgh

Email: p.papapanagio...@sms.ed.ac.uk

---
  The University of Edinburgh is a charitable body, registered in
  Scotland, with registration number SC005336.

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Michael Norrish]

On 17/12/12 03:19, Petros Papapanagiotou wrote:
> Hello Bill,

> On 13/12/2012 10:32, Bill Richter wrote:
>> Let's try to port this proof to HOL Light up to qDef:

>> g `addN p p' 4 ==> ?q. addN p q 3 /\ p' = SUC q`;;
>> e(SIMP_TAC[addN]);;
>> e(DISCH_THEN(X_CHOOSE_TAC `s: num->num`));;
>> e(SUBGOAL_THEN `s 0 = p` ASSUME_TAC);;
>> e(ASM_MESON_TAC[]);;

>> It's OK to the last line, but MESON times out with Exception:
>> Failure "solve_goal: Too deep". I get the same problem using John's
>> Mizar-like `consider':

> That is because the `s` and `p` in your subgoal do not match the `s`
> and `p` in your assumptions.

> If you replace:
> e(SUBGOAL_THEN `s 0 = p` ASSUME_TAC);;
> with:
> e(SUBGOAL_THEN `(s:num->num) 0 = p` ASSUME_TAC);;
> it will work.

You could also use the Pa module that Vincent Aravantinos recently posted
(http://users.encs.concordia.ca/~vincent/Software_files/q.ml):

   e (Pa.SUBGOAL_THEN "s 0 = p" ASSUME_TAC)

so that the new ‘s’ mentioned here picks up the right type from the goal.

> You can do something like:
> e (FIRST_ASSUM (CONJUNCTS_THEN ASSUME_TAC));;

> or if you do not need the original assumption:
> e (POP_ASSUM (CONJUNCTS_THEN ASSUME_TAC));;

> or if you want to break all conjuncts in one go:
> e (REPEAT (POP_ASSUM (CONJUNCTS_THEN ASSUME_TAC)));;

> or the equivalent:
> e (POP_ASSUM (REPEAT_TCL CONJUNCTS_THEN ASSUME_TAC));;

Or even use STRIP_ASSUME_TAC.  And though using

  DISCH_THEN (X_CHOOSE_TAC `s:num->num`)

is probably good practice in general (fixing the names that will appear in the
goal is better than relying on the names that the system chooses for you), you
could just use

  STRIP_TAC

and save yourself the hassle.

Indeed, none of the manipulations after the call to SIMP_TAC are going to make
any difference to ASM_MESON_TAC.  You could just try (taking from Petros’ 
script)

  SIMP_TAC[addN] THEN ASM_MESON_TAC[LT;ARITH_RULE `SUC 3 = 4`]

Michael



signature.asc
Description: OpenPGP digital signature
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Petros & Michael!  I didn't completely understand what you wrote, but I 
see how Michael simplified Petros's proof.  This is really nice, and I can 
probably just modify your code to finish the exercise in footnote 23, p 67 of 
the HOL Light tutorial:

let addN = new_definition
  `!p p' n.
  addN p p' n <=> ?s. 
  s 0 = p /\ s n = p' /\
  (!m. m < n ==> s (SUC m) = SUC (s m))`;;

g `!p p'. addN p p' 4 ==> (?q. addN p q 3 /\ p' = SUC q)`;;
e (REPEAT GEN_TAC);;
e (SIMP_TAC[addN]);;
e(STRIP_TAC);;
e (EXISTS_TAC `(s:num->num) 3`);;
e (ASM_MESON_TAC[LT;ARITH_RULE `SUC 3 = 4`]);;
let addfour_THM = top_thm();;

I don't mind using EXISTS_TAC, and this code seems to answer my original 
question: how can I define a function (s in this case)and call it whenever I 
want.  I don't understand why we needed the typing (s:num->num), or why we need 
parenthesis.  That is, 
EXISTS_TAC `s:num->num 3` gets Exception: Failure "Unparsed input following 
term".  

But I really don't understand why Michael's STRIP_TAC works.  P 48 of the 
tutorial says 
STRIP_TAC has the effect of DISCH_TAC, GEN_TAC or CONJ_TAC.
At the time we use it, we have only the goal

`(?s. s 0 = p /\ s 4 = p' /\ (!m. m < 4 ==> s (SUC m) = SUC (s m)))
 ==> (?q. (?s. s 0 = p /\ s 3 = q /\ (!m. m < 3 ==> s (SUC m) = SUC (s m))) /\
  p' = SUC q)`

So I thought that STRIP_TAC here meant DISCH_TAC, which of course has the 
effect:
  0 [`?s. s 0 = p /\ s 4 = p' /\ (!m. m < 4 ==> s (SUC m) = SUC (s m))`]
which isn't helpful, as opposed to Michael's extremely helpful 
  0 [`s 0 = p`]
  1 [`s 4 = p'`]
  2 [`!m. m < 4 ==> s (SUC m) = SUC (s m)`]
where s is "defined" at it would be with miz3's consider.  What am I missing?  
BTW here's my miz3 proof:

horizon := 0;;
timeout := 1;;
let AddFour = thm `;
  thus !p p'. addN p p' 4 ==> ?q. addN p q 3 /\ p' = SUC q
  proof
let p p' be num;
assume addN p p' 4;
consider s such that 
s 0 = p /\ s 4 = p' /\ (!m. m < 4 ==> s (SUC m) = SUC (s m)) [sDef] by 
-, addN;
consider q such that 
q = s 3 [qDef];
SUC 3 = 4;
s 0 = p /\ s 3 = q /\ (!m. m < 3 ==> s (SUC m) = SUC (s m)) /\ p' = SUC q   
  by -, qDef, LT, sDef;
  qed by -, addN;
`;;

And here's a synthesis of my miz3 proof and your ideas above, which works with 
a MESON "solved at" number of 433,447: 

g `addN p p' 4 ==> ?q. addN p q 3 /\ p' = SUC q`;;
e(SIMP_TAC[addN]);;
e(STRIP_TAC);;
e(SUBGOAL_THEN `?q. q = s 3` CHOOSE_TAC);;
e(ASM_MESON_TAC[]);;
e(SUBGOAL_THEN `SUC 3 = 4 /\ 3 < 4` ASSUME_TAC);;
e (ASM_MESON_TAC[LT; ARITH_RULE `SUC 3 = 4 /\ 3 < 4`]);;
e (ASM_MESON_TAC[LT]);;
let addfour_THM = top_thm();;

So I "succeeded" in defining q and not using EXISTS_TAC, as we see from my 
assumption, 
  3 [`q = s 3`]
but I ran up a half-million in MESON units for something your proof did in 652, 
which is nothing.  What is MESON doing?  I'm so spoiled from miz3, where MESON 
does everything a first order prover should do, except it's weak on equational 
reasoning, and by setting the timeout to 50 I get just about everything I 
actually want by waiting for it.  I'm very curious about how Freek and John got 
miz3 to work so well.  

-- 
Best,
Bill 

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Michael Norrish]

On 18/12/12 6:04 PM, Bill Richter wrote:
> But I really don't understand why Michael's STRIP_TAC works.  P 48 of the 
> tutorial says 
> STRIP_TAC has the effect of DISCH_TAC, GEN_TAC or CONJ_TAC.
> At the time we use it, we have only the goal

> `(?s. s 0 = p /\ s 4 = p' /\ (!m. m < 4 ==> s (SUC m) = SUC (s m)))
>  ==> (?q. (?s. s 0 = p /\ s 3 = q /\ (!m. m < 3 ==> s (SUC m) = SUC (s m))) /\
>   p' = SUC q)`

> So I thought that STRIP_TAC here meant DISCH_TAC, which of course has the 
> effect:

I guess you've found a bug in the documentation.  The implementation of
STRIP_TAC will actually be calling

   DISCH_THEN STRIP_ASSUME_TAC

in the situation above, not

   DISCH_TAC

which, by way of contrast, is more or less equivalent to

   DISCH_THEN ASSUME_TAC

Michael



signature.asc
Description: OpenPGP digital signature
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

   I guess you've found a bug in the documentation.  

Thanks, Michael!  I think you're right, because the ref manual makes the same 
apparent error: 

http://www.cl.cam.ac.uk/~jrh13/hol-light/reference.html
Given a goal (A,t), STRIP_TAC removes one outermost occurrence of one of the 
connectives !, ==>, ~ or /\ from the conclusion of the goal t.

But the important point is that you taught me about about STRIP_ASSUME_TAC, 
about which the ref manual  says

   Given a theorem th and a goal (A,t), STRIP_ASSUME_TAC th splits th
   into a list of theorems. This is done by recursively breaking
   conjunctions into separate conjuncts, cases-splitting disjunctions,
   and eliminating existential quantifiers by choosing arbitrary
   variables.

That looks extremely useful.  You're also explaining DISCH_THEN.  The ref 
manual  says

   DISCH_THEN removes the antecedent and then creates a theorem by
   ASSUMEing it. This new theorem is passed to the theorem-tactic
   given as DISCH_THEN's argument. The consequent tactic is then
   applied.

I can't figure out what ASSUMEing means, I think I can skip that and say 

DISCH_THEN removes the antecedent and [passes it] to the
theorem-tactic given as DISCH_THEN's argument.

   DISCH_TAC [...] is more or less equivalent to DISCH_THEN ASSUME_TAC

The tutorial say that's exactly true on page 50!  I should have realized that.  

My minimal objective here is to understand miz3 well enough in terms of HOL 
Light tactics to be able to explain miz3.  Freek's explanation of miz3 only 
uses the obscure Mizar concept of the thesis, and it seems clear to me that we 
need the HOL concepts of goalstack and assumption list.  My maximal objective 
is to understand tactics well enough to get these fast Intel chips to prove 
theorems for me that I don't already know how to prove.  In my simple AddFour 
miz3 proof I posted, I did something that you & Petros didn't explain to me how 
to do, as my miz3 

consider q such that q = s 3 [qDef];

isn't quite replaced by your 

e (EXISTS_TAC `(s:num->num) 3`);;

which plugs s 3 in for q in the existential statement ?q. . Also the miz3 
behavior of MESON looks the same as the tactic ASM_MESON_TAC.  It looks like in 
miz3, my qDef was EXISTS_TAC-ed, but that doesn't easily happen in tactics.  In 
fact, I thought that in my tactics proof that ASM_MESON_TAC ignored my 
assumption value of q
  3 [`q = s 3`]
so I tried running your proof without EXISTS_TAC, and it worked, although I got 
a MESON solved at number of 17,212,792: 

let addN = new_definition
  `!p p' n.
  addN p p' n <=> ?s. 
  s 0 = p /\ s n = p' /\
  (!m. m < n ==> s (SUC m) = SUC (s m))`;;

g `!p p'. addN p p' 4 ==> (?q. addN p q 3 /\ p' = SUC q)`;;
e (REPEAT GEN_TAC);;
e (SIMP_TAC[addN]);;
e(STRIP_TAC);;
e (ASM_MESON_TAC[LT;ARITH_RULE `SUC 3 = 4`]);;
let addfour_THM = top_thm();;

-- 
Best,
Bill 

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Michael and Petros, thanks to your help, I wrote a tactics script for 
REACHABLE_INVARIANT from p 67 of the HOL tutorial using the explicitly 
sequential definition reachable of 65.  Here's a simpler version of it, using 
STRIP_TAC, EXISTS_TAC, and extra type annotations as you taught me to: 

let addN = new_definition
  `!p p' n.
  addN p p' n <=> ?s. 
  s 0 = p /\ s n = p' /\ 
  (!m. m < n ==> s (SUC m) = SUC (s m))`;;

let addN_CLAUSES = prove
 (`! p p'. (addN p p' 0 <=>  p = p') /\
  !n. addN p p' (SUC n) <=> ?q. addN p q n /\ (SUC q) = p'`,
  REPEAT STRIP_TAC THEN EQ_TAC THEN ASM_SIMP_TAC[addN; LT] 
  THENL [MESON_TAC[]; DISCH_TAC; STRIP_TAC; STRIP_TAC] THENL
  [EXISTS_TAC `\m:num. p':num` THEN SIMP_TAC[];
  EXISTS_TAC `(s:num->num) n`;
  EXISTS_TAC `\m:num. if m < SUC n then s m else p':num`] THEN 
  REPEAT STRIP_TAC THEN ASM_MESON_TAC[LT_0; LT_REFL; LT; LT_SUC]);;

I like my tactics script (maybe someone can suggest a better), but I wish I had 
been able to define variables and give them labels, as I did in the miz3 proof 
below with "consider".  EXISTS_TAC worked fine, but if you need to use a 
defined variable more than once, it would look awkward to EXISTS_TAC it every 
time you used it.  One could argue that this is ugly and hard to read
`(\m. if m < SUC n then s m else p') (SUC m) =
 SUC ((\m. if m < SUC n then s m else p') m)`
and that it would be nicer to call this function "t" and write instead 
t (SUC m) = SUC (t m),
as I essentially do in my miz3 proof.  I'm sure this can be done in HOL 
tactics, I just haven't figured it out yet.  

I did answer two beginner questions I posted earlier: how can you see the 
entire goalstack, and how you debug a tactics script?  More precisely, how can 
you produce a tactics script when THEN works differently than it does in a 
interactive proof and you have to use THENLs?  The answer is that you can 
gradually turn an interactive proof g & e proof into a tactics script, because 
a tactics script is "really" just an interactive proof with one e-command.  
I'll use my tactics script above as an example.  It's basically this 
"interactive" proof:

g `! p p'. (addN p p' 0 <=>  p = p') /\
  !n. addN p p' (SUC n) <=> ?q. addN p q n /\ (SUC q) = p'`;;
e(REPEAT STRIP_TAC THEN EQ_TAC THEN ASM_SIMP_TAC[addN; LT] 
  THENL [MESON_TAC[]; DISCH_TAC; STRIP_TAC; STRIP_TAC] THENL
  [EXISTS_TAC `\m:num. p':num` THEN SIMP_TAC[];
  EXISTS_TAC `(s:num->num) n`;
  EXISTS_TAC `\m:num. if m < SUC n then s m else p':num`] THEN 
  REPEAT STRIP_TAC THEN ASM_MESON_TAC[LT_0; LT_REFL; LT; LT_SUC]);;
let addN_CLAUSES = top_thm();;

I took a interactive proof with lots of e-commands and gradually built an 
interactive proof with only one e-command.  You can see how I built it by 
evaluating a top chunk, e.g. 

g `! p p'. (addN p p' 0 <=>  p = p') /\
  !n. addN p p' (SUC n) <=> ?q. addN p q n /\ (SUC q) = p'`;;
e(REPEAT STRIP_TAC THEN EQ_TAC THEN ASM_SIMP_TAC[addN; LT] 
  THENL [MESON_TAC[]; DISCH_TAC; STRIP_TAC; STRIP_TAC]);;

val it : goalstack = 3 subgoals (3 total)

  0 [`s 0 = p`]
  1 [`s n = q`]
  2 [`!m. m < n ==> s (SUC m) = SUC (s m)`]
  3 [`SUC q = p'`]

`?s. s 0 = p /\
 s (SUC n) = p' /\
 (!m. m = n \/ m < n ==> s (SUC m) = SUC (s m))`

  0 [`s 0 = p`]
  1 [`s (SUC n) = p'`]
  2 [`!m. m = n \/ m < n ==> s (SUC m) = SUC (s m)`]

`?q. (?s. s 0 = p /\ s n = q /\ (!m. m < n ==> s (SUC m) = SUC (s m))) /\
 SUC q = p'`

  0 [`p = p'`]

`?s. s 0 = p'`

So there exactly 3 goals, and each of them requires plugging in a variable, so 
that requires 3 EXISTS_TAC.  We can easily write all 3 EXISTS_TACs at once and 
put them into the tactics script with THENL:

THENL
  [EXISTS_TAC `\m:num. p':num` THEN SIMP_TAC[];
  EXISTS_TAC `(s:num->num) n`;
  EXISTS_TAC `\m:num. if m < SUC n then s m else p':num`] 

Paste that into the big e-command and evaluate it, and you'll we see there are 
2 goals, as the SIMP_TAC[] finished the first goal.  As both goals need 
STRIP_TAC-ing, I just use 
THEN REPEAT STRIP_TAC  
and now I have 6 goals, all of which are solved by ASM_MESON_TAC[] and some of 
the arith.ml LT theorems.  So I can finish the proof interactively (and it is 
sure cool to know the whole goalstack!):

e(ASM_MESON_TAC[]);;
e(ASM_MESON_TAC[]);;
e(ASM_MESON_TAC[LT_0]);;
e(ASM_MESON_TAC[LT_REFL]);;
e(ASM_MESON_TAC[LT_REFL; LT]);;
e(ASM_MESON_TAC[LT_SUC; LT]);;

val it : goalstack = No subgoals
Yay!  And then I can tactify this with last step with 

THENL
[ASM_MESON_TAC[]; ASM_MESON_TAC[]; ASM_MESON_TAC[LT_0]; ASM_MESON_TAC[LT_REFL]; 
ASM_MESON_TAC[LT_REFL; LT]; ASM_MESON_TAC[LT_SUC; LT]]

but as John explains, why not just use all the LT theorems for all 6 cases, and 
then we have my 
THEN ASM_MESON_TAC[LT_0; LT_REFL; LT; LT_SUC].  Now John explains a lot about 
interactive proof vs tactics scripts, but somehow I missed the point that with 
a "one e-command" version of tactics script you can see whole goalstack, and if 
you would just solve all the goals simultaneously, instead of wor

Re: [Hol-info] Learning HOL Light

[Bill Richter]

I finally understand how to translate between miz3 and straight HOL Light.  I 
profited from the Mizar-like code in the HOL Light tutorial p 76--78, which I 
modified to 

let consider th pf = SUBGOAL_THEN th CHOOSE_TAC THENL [pf; ALL_TAC];;
let state th pf = SUBGOAL_THEN th ASSUME_TAC THENL [pf; ALL_TAC];;
let statelab th lab pf = SUBGOAL_THEN th (LABEL_TAC lab) THENL [pf; ALL_TAC];;
let toprove th = SUBGOAL_THEN th ASSUME_TAC;;
let mby labs MesonList = MAP_EVERY (fun l -> USE_THEN l MP_TAC) labs THEN 
(MESON_TAC MesonList);;
let soby labs MesonList = FIRST_ASSUM MP_TAC THEN MAP_EVERY 
   (fun l -> USE_THEN l MP_TAC) labs THEN (MESON_TAC MesonList);;

Using this code I mechanically turned a 35-line miz3 proof of 

UniversalPropertyProduct
  |- ∀ M A B f g.
 f ∈ M → A ∧ g ∈ M → B
 ⇒ (∃! h. h ∈ M → A ∏ B  ∧  FST ∘ (h,M) = f  ∧  SND ∘ (h,M) = g)

into a 28-line tactics script with almost identical MESON solved at numbers: 
42063, 42992, 2590, 2687, 4515, 70020
42063, 42992, 1757 1854 4173, 70020

The only purpose of my Mizar-like code is to replace long lines with much 
shorter ones, as in

e(FIRST_ASSUM MP_TAC THEN USE_THEN "hDef" MP_TAC  THEN USE_THEN "kOffM" MP_TAC 
THEN 
   MESON_TAC[FUN_EQ_THM; ∉]);;
soby ["hDef"; "kOffM"] [FUN_EQ_THM; ∉]

As Rob explained, STRIP_ASSUME_TAC handles the miz3 cases, so there's no need 
for special coding.  My `toprove' could easily be removed, and `state th pf' 
could be replaced by `statelab th "" pf'.  

Here's my tactics script for UniversalPropertyProduct, together with the 
definitions and lemmas needed and my modification of John's Mizar-like code, 
first with more readable math characters, with working HOL Light code below.  
I'm including the miz3 proof, and you can see it's practically the same as my 
tactics script except the miz3 proof is prettier, far fewer backquotes, 
double-quotes, square braces, parentheses and type annotations.  I impressed 
that Freek made the miz3 code so pretty, and got Ocaml to cache results, but 
it's basically what I'm doing in my tactics script.

parse_as_infix("∉",(11, "right"));;
parse_as_infix("∏",(20, "right"));;
parse_as_infix("∘",(20, "right"));;
parse_as_infix("→",(13,"right"));;

let ∉ = new_definition
  `∀ a:A l:A->bool. a ∉ l ⇔ ¬(a ∈ l)`;;

let CartesianProduct = new_definition
   `∀ X Y. X ∏ Y = {x,y | x ∈ X ∧ y ∈ Y}`;;

let IN_CartesianProduct = prove
 (`∀ X Y x y. x,y ∈ X ∏ Y  ⇔  x ∈ X ∧ y ∈ Y`,
  REWRITE_TAC[IN_ELIM_THM; CartesianProduct] THEN MESON_TAC[PAIR_EQ]);;

let FunctionSpace = new_definition
   `∀ s t. s → t = {f | (∀ x. x ∈ s ⇒ f x  ∈ t) ∧
  ∀ x. x ∉ s ⇒ f x  = @y. T}`;;

let IN_FunctionSpace = prove
  (`∀ s t f. f ∈ s → t  
  ⇔  (∀ x. x ∈ s ⇒ f x ∈ t)  ∧  ∀ x. x ∉ s ⇒ f x  = @y. T`,
  REWRITE_TAC[IN_ELIM_THM; FunctionSpace]);;

let FunctionComposition = new_definition
  `∀ f:A->B s:A->bool g:B->C x.
  (g ∘ (f,s)) x = if x ∈ s then g (f x) else @y:C. T`;;

let UniversalPropertyProduct = prove
  (`∀ M:μ->bool A:α->bool B:β->bool f:μ->α g:μ->β .
 f ∈ M → A ∧ g ∈ M → B
 ⇒ (∃! h. h ∈ M → A ∏ B  ∧  FST ∘ (h,M) = f  ∧  SND ∘ (h,M) = g)`,
   REPEAT GEN_TAC THEN DISCH_THEN(LABEL_TAC "H1") THEN
   consider `?h:μ->α#β.  h = λx:μ. if x ∈ M then f x,g x else @y. T` (mby [] 
[]) THEN
   statelab `∀ x:μ. (x ∈ M  ⇒  (h:μ->α#β) x = f x,g x) ∧ (x ∉ M  ⇒  h x = @y. 
T)` "hDef"
   (soby [] [∉]) THEN
   statelab `∀ x:μ. x ∈ M  ⇒  (h:μ->α#β) x ∈ A ∏ B` "hProd" (soby ["H1"] 
[IN_FunctionSpace; IN_CartesianProduct]) THEN
   state `∀ x:μ. x ∈ M  ⇒  FST ((h:μ->α#β) x) = f x  ∧  SND (h x) = g x` 
   (mby ["hDef"] [FST_DEF; SND_DEF; PAIR_EQ]) THEN
   state `∀ x:μ. (x ∈ M  ⇒  (FST ∘ ((h:μ->α#β),M)) x = f x) ∧ (x ∉ M  ⇒  (FST ∘ 
(h,M)) x = f x)  ∧ 
(x ∈ M  ⇒  (SND ∘ (h,M)) x = g x) ∧ (x ∉ M  ⇒  (SND ∘ (h,M)) x = g x)`
   (soby ["H1"] [FunctionComposition; ∉; IN_FunctionSpace]) THEN
   statelab `(h:μ->α#β) ∈ M → A ∏ B  ∧  FST ∘ (h,M) = f  ∧  SND ∘ (h,M) = g` 
"hWorks"
   (soby ["hDef"; "hProd"] [IN_FunctionSpace; ∉; FUN_EQ_THM]) THEN
   toprove `∀ (k:μ->α#β). (k ∈ M → A ∏ B  ∧  FST ∘ (k,M) = f  ∧  SND ∘ (k,M) = 
g)  ⇒ h = k`
THENL[GEN_TAC THEN DISCH_THEN(LABEL_TAC "kWorks");
soby ["hWorks"] [EXISTS_UNIQUE_THM]] THEN
statelab `∀ x:μ. x ∉ M  ⇒  (k:μ->α#β) x = @y. T` "kOffM" (soby [] 
[IN_FunctionSpace]) THEN
toprove `∀ x:μ. x ∈ M ⇒ (k:μ->α#β) x = f x,g x ` THENL[
GEN_TAC THEN DISCH_THEN(LABEL_TAC "xM");
soby ["hDef"; "kOffM"] [FUN_EQ_THM; ∉]] THEN
state `FST ((k:μ->α#β) x) = f x  ∧  SND (k x) = g x` (soby ["kWorks"] 
[FunctionComposition]) THEN
state `(k:μ->α#β) x = FST (k x), SND (k x)  ∧ FST (k x) = f x  ∧ SND (k x) 
= g x` 
   (soby ["kWorks"] [PAIR]) THEN
   soby [] [PAIR_EQ]);;


Here's my original miz3 proof, which I mechanically turned into the above 
tactics script.  I think they look very similar, and I think this shows that I 
understand miz3 in terms of HOL LIGHT. 


let UniversalPropertyProduct = thm `;
  ∀ M:μ->bool A:α->bool B:β->bool 

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Is there any easy HOL 1-line way to state a result t, prove it, then use for 
some purpose?  
Below I'll give my best shot, and use it to improve the LABEL_TAC entry to the 
HOL Light reference manual.  

I finally understood, and modified, the HOL Light tutorial (p 78) Mizar-like 

  let cases (lab,t) tac =
SUBGOAL_THEN t MP_TAC THENL [tac; ALL_TAC] THEN
DISCH_THEN(REPEAT_TCL DISJ_CASES_THEN (LABEL_TAC lab));;

Tell me if this is right:  SUBGOAL_THEN is normally used with ASSUME_TAC, but 
not always, and here if the first goal is g, then 
SUBGOAL_THEN t MP_TAC
makes the first and second goals 
t and t ==> g
THENL applies tac to prove t, and does nothing to t ==> g.
Then DISCH_THEN pulls off the antecedent t, and DISJ_CASES_THEN breaks the 
disjunction t, and then LABEL_TAC gives each disjunct the same label lab, which 
is fine, because the different disjuncts have different goals and so there's no 
conflict between the the different copies of the label lab.

That's nice code, but I wondered if we could avoid the MP_TAC/DISCH_THEN 
routine, as Ramana, Petros and Michael taught me was sometimes possible.  
Here's a substitute bcases, mostly due to my son, which uses my modifications 
of the tutorial Mizar-like code 

let soby labs MesonList = FIRST_ASSUM MP_TAC THEN MAP_EVERY 
   (fun l -> USE_THEN l MP_TAC) labs THEN (MESON_TAC MesonList);;
let consider t lab pf = SUBGOAL_THEN t (CHOOSE_THEN (LABEL_TAC lab)) THENL [pf; 
ALL_TAC];;
let state t lab pf = SUBGOAL_THEN t (LABEL_TAC lab) THENL [pf; ALL_TAC];;
let bcases t pf lab =
  state t  "" pf THEN FIRST_X_ASSUM 
  (REPEAT_TCL DISJ_CASES_THEN (LABEL_TAC lab));;

But in a sense, bcases has the same problem as John's code, as it takes a 
statement t, pushes it onto the assumption stack via state, proves it with pf, 
then pops it off the assumption stack and uses DISJ_CASES_THEN and LABEL_TAC as 
John's cases does.  Is there a way to avoid one-step-forward-one-step-back 
routines like MP_TAC/DISCH_THEN and ASSUME_TAC/FIRST_X_ASSUM here?  Anyway, I'm 
really happy to understand this, because now I know how to port all my miz3 
Hilbert axiomatic geometry results to straight HOL Light tactics.  I'll apply 
this to the LABEL_TAC entry to the HOL Light reference manual, which has some 
typos and a proof that doesn't work.  

We'll prove that a binary relation <<= that is antisymmetric and has a strong 
wellfoundedness property is a wellorder.  The reference manual proves half of 
this in one line (if you put the {}s in) with SET_TAC[], but the transitive 
part seems harder.  My proof below uses the definitions above, and follows my 
Hilbert geometry by not using SET_TAC[], but only MESON_TAC and results from 
sets.ml. 

-- 
Happy New Year!
Bill 


g `(!x y. x <<= y /\ y <<= x ==> x = y) /\
  (!s. ~(s = {}) ==> ?a:A. a IN s /\ !x. x IN s ==> a <<= x)
  ==> (!x y. x <<= y \/ y <<= x) /\
  !x y z. x <<= y /\ y <<= z ==> x <<= z`;; 
e(DISCH_THEN(CONJUNCTS_THEN2 (LABEL_TAC "antisym") (LABEL_TAC "swf")));;
e(STRIP_TAC THEN STRIP_TAC THEN STRIP_TAC);;
e(consider `?s:A->bool. s = {x:A,y:A}` "" (soby [] []));;
e(state `!p:A. p IN s <=> p = x \/ p = y` "sxy" (soby [] [IN_INSERT; 
MEMBER_NOT_EMPTY]));;
e(state `~(s:A->bool = {})` "" (soby [] [MEMBER_NOT_EMPTY]));;
e(consider `?a:A. a IN (s:A->bool) /\ !p:A. p IN s ==> a <<= p` "aExists" (soby 
["swf"] []));;
e(bcases `a:A = x:A \/ a = y:A` (soby ["sxy"] []) "xxx");;
e(soby ["aExists"; "sxy"] []);;
e(soby ["aExists"; "sxy"] []);;
e(STRIP_TAC THEN DISCH_THEN(CONJUNCTS_THEN2 
(LABEL_TAC "xLESSy") (LABEL_TAC "yLESSz")));;
e(consider `?s:A->bool. s = {x:A,y:A,z:A}` "C" (soby [] []));;
e(state `!p:A. p IN s <=> p = x \/ p = y \/ p = z` "sxyz" (soby [] [IN_INSERT; 
MEMBER_NOT_EMPTY]));;
e(state `~(s:A->bool = {})` "" (soby [] [MEMBER_NOT_EMPTY]));;
e(consider `?a:A. a IN (s:A->bool) /\ !p:A. p IN s ==> a <<= p` "aExists" (soby 
["swf"] []));;
e(bcases `a:A = x:A \/ a = y:A \/ a = z:A` (soby ["sxyz"] []) "bbb");;
e(soby ["sxyz"] []);;
e(soby ["aExists"; "sxyz"] []);;
e(soby ["aExists"; "sxyz"; "xLESSy"; "antisym"; "yLESSz"] []);;
e(soby ["aExists"; "sxyz"; "yLESSz"; "antisym"; "xLESSy"] []);;
let WfAndAntisymImpliesWo = top_thm();;


--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

Hello Bill,

On 01/01/2013 08:08, Bill Richter wrote:
> Is there any easy HOL 1-line way to state a result t, prove it, then use for 
> some purpose?

Apart from SUBGOAL_THEN you can also:
1) Use SUBGOAL_TAC.
2) Use a 'prove' command inline, then use the resulting theorem for any 
purpose.

These two alternatives allow you to prove your subgoal immediately and 
then use it whichever way you want.

(Very) trivial example:
g `a:num = a`;;
e (SUBGOAL_THEN `!x:num. x = x` MATCH_ACCEPT_TAC);;
e (GEN_TAC THEN REFL_TAC);;

You can also:
g `a:num = a`;;
e (SUBGOAL_TAC "label" `!x:num. x = x` [GEN_TAC THEN REFL_TAC]);;
e (USE_THEN "label" MATCH_ACCEPT_TAC);;

Or:
g `a:num = a`;;
e (MATCH_ACCEPT_TAC (prove (`!x:num. x = x`, GEN_TAC THEN REFL_TAC)));;





>let cases (lab,t) tac =
>  SUBGOAL_THEN t MP_TAC THENL [tac; ALL_TAC] THEN
>  DISCH_THEN(REPEAT_TCL DISJ_CASES_THEN (LABEL_TAC lab));;
>
> Tell me if this is right:  SUBGOAL_THEN is normally used with ASSUME_TAC, but 
> not always, and here if the first goal is g, then
> SUBGOAL_THEN t MP_TAC
> makes the first and second goals
> t and t ==> g
> THENL applies tac to prove t, and does nothing to t ==> g.
> Then DISCH_THEN pulls off the antecedent t, and DISJ_CASES_THEN breaks the 
> disjunction t, and then LABEL_TAC gives each disjunct the same label lab, 
> which is fine, because the different disjuncts have different goals and so 
> there's no conflict between the the different copies of the label lab.

You have got this right.

>
> That's nice code, but I wondered if we could avoid the MP_TAC/DISCH_THEN 
> routine, as Ramana, Petros and Michael taught me was sometimes possible.

In theory, you could use replace MP_TAC with (REPEAT_TCL DISJ_CASES_THEN 
(LABEL_TAC lab)) - or whichever tactic you wish to apply to your new 
assumpion.

The problem if you do this is that DISJ_CASES_THEN will create two new 
subgoals (for a total of three).

eg.:
g `P:bool`;;
Warning: Free variables in goal: P
val it : goalstack = 1 subgoal (1 total)

`P`

#  e (SUBGOAL_THEN `p:bool = T \/ p:bool = F` (DISJ_CASES_THEN 
(LABEL_TAC "case")));;
val it : goalstack = 3 subgoals (3 total)

   0 [`p <=> F`] (case)

`P`

   0 [`p <=> T`] (case)

`P`

`(p <=> T) \/ (p <=> F)`


Since t can have multiple disjuncts, the number of generated subgoals is 
arbitrary. This makes things complicated for THENL because the list of 
tactics in its argument must be the same size as the number of subgoals 
(so as to provide one tactic for each subgoal).

Using MP_TAC/DISCH_THEN solves this problem and makes the "cases" work 
for any t.

As far as I can think right now, the best alternatives if you want to 
avoid the MP_TAC/DISCH_THEN combination are the ones I gave in the 
beginning.

(Note that, as far as I can tell, "cases" assumes tac will prove t.)

Regards,

Petros




-- 
Petros Papapanagiotou
CISA, School of Informatics
The University of Edinburgh

Email: p.papapanagio...@sms.ed.ac.uk

---
  The University of Edinburgh is a charitable body, registered in
  Scotland, with registration number SC005336.

--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Petros, but I don't see how SUBGOAL_TAC is any better than SUBGOAL_THEN 
at avoiding the one-step-forward-one-step-back awkwardness of MP_TAC/DISCH_THEN 
ASSUME_TAC/FIRST_X_ASSUM that John's cases and the modification bcases have.  
Below is a tactics script for my proof of the LABEL_TAC exercise in the HOL 
Light reference manual, which I should have posted yesterday.  BTW how does HOL 
and Informatics fit together?  Thanks for the feedback on my explanation of 
John's cases, which as you say assumes tac will prove t, as does bcases.  I 
thought of this 

   you could use replace MP_TAC with (REPEAT_TCL DISJ_CASES_THEN
   (LABEL_TAC lab)) [but] DISJ_CASES_THEN will create two new subgoals
   (for a total of three).

but as you say that won't work unless I can calculate how my disjuncts I'll 
get.  There must be a function that calculates that.  In the first bcases 
below, it's 2, and it's 3 for the second.  I need to know because of the THENL 
[tac; ALL_TAC], which would be changed to THENL [tac; ALL_TAC; ALL_TAC; 
ALL_TAC] for 3 disjuncts.  I also don't know how to print a variable number of 
ALL_TACs.  I thought maybe I could try 
SUBGOAL_THEN t ALL_TAC THENL [SUBGOAL_THEN t ALL_TAC; ALL_TAC]
so the top 3 goals in the goalstack would be (for g the original top goal) 
t, t, and g 
But  that won't fly, because 
MP_TAC is a thm_tactic, and ALL_TAC is just a tactic.  I that the correct 
usage?  And that's the difference between SUBGOAL_THEN and SUBGOAL_TAC, whether 
you use a thm_tactic or a tactic?  BTW how do I learn the typed LC or whatever 
that explains how tactics and thm_tactics actually work?  The HOL Light 
tutorial I think is actually a pretty good way to learn how to write tactics 
proofs, if you read the whole tutorial from beginning to end, dipping into the 
reference manual (and posting here!) when you get stuck, but I don't think it 
explains the theory of tactics proofs.  Maybe I missed it.  

-- 
Best,
Bill 

let soby labs MesonList = FIRST_ASSUM MP_TAC THEN MAP_EVERY 
   (fun l -> USE_THEN l MP_TAC) labs THEN (MESON_TAC MesonList);;
let consider t lab pf = SUBGOAL_THEN t (CHOOSE_THEN (LABEL_TAC lab)) THENL [pf; 
ALL_TAC];;
let state t lab pf = SUBGOAL_THEN t (LABEL_TAC lab) THENL [pf; ALL_TAC];;
let bcases t lab pf =
  state t  "" pf THEN FIRST_X_ASSUM 
  (REPEAT_TCL DISJ_CASES_THEN (LABEL_TAC lab));;

let WfAndAntisymImpliesWo = prove
  (`(!x y. x <<= y /\ y <<= x ==> x = y) /\
  (!s. ~(s = {}) ==> ?a:A. a IN s /\ !x. x IN s ==> a <<= x)
  ==> (!x y. x <<= y \/ y <<= x) /\
  !x y z. x <<= y /\ y <<= z ==> x <<= z`, 
  DISCH_THEN(CONJUNCTS_THEN2 (LABEL_TAC "antisym") (LABEL_TAC "swf")) 
  THEN STRIP_TAC THEN REPEAT GEN_TAC THENL [ALL_TAC;
  DISCH_THEN(CONJUNCTS_THEN2 (LABEL_TAC "xLESSy") (LABEL_TAC "yLESSz"))] THENL 
  [consider `?s:A->bool. s = {x:A,y:A}` "" (soby [] []);
  consider `?s:A->bool. s = {x:A,y:A,z:A}` "C" (soby [] [])] THENL
  [state `!p:A. p IN s <=> p = x \/ p = y` "sxy" (soby [] [IN_INSERT; 
MEMBER_NOT_EMPTY]);
  state `!p:A. p IN s <=> p = x \/ p = y \/ p = z` "sxyz" 
  (soby [] [IN_INSERT; MEMBER_NOT_EMPTY])] THEN
  state `~(s:A->bool = {})` "" (soby [] [MEMBER_NOT_EMPTY]) THEN
  consider `?a:A. a IN (s:A->bool) /\ !p:A. p IN s ==> a <<= p` "aExists" (soby 
["swf"] []) THENL
  [bcases `a:A = x:A \/ a = y:A` "" (soby ["sxy"] []);
  bcases `a:A = x:A \/ a = y:A \/ a = z:A` "" (soby ["sxyz"] [])] THENL
  [soby ["aExists"; "sxy"] []; 
  soby ["aExists"; "sxy"] [];
  soby ["aExists"; "sxyz"] [];
  soby ["aExists"; "sxyz"; "xLESSy"; "antisym"; "yLESSz"] [];
  soby ["aExists"; "sxyz"; "yLESSz"; "antisym"; "xLESSy"] []]);;

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

Hello Bill,

On 02/01/2013 06:22, Bill Richter wrote:
> Thanks, Petros, but I don't see how SUBGOAL_TAC is any better than 
> SUBGOAL_THEN at avoiding the one-step-forward-one-step-back awkwardness of 
> MP_TAC/DISCH_THEN ASSUME_TAC/FIRST_X_ASSUM that John's cases and the 
> modification bcases have.


Only indirectly, I guess, since the ASSUME_TAC or MP_TAC step is 
implicit in SUBGOAL_TAC.


> BTW how does HOL and Informatics fit together?

How do they not? :)
They are connected in so many ways...


>
> but as you say that won't work unless I can calculate how my disjuncts I'll 
> get.  There must be a function that calculates that. In the first bcases 
> below, it's 2, and it's 3 for the second.  I also don't know how to print a 
> variable number of ALL_TACs.  I thought maybe I could try
> SUBGOAL_THEN t ALL_TAC THENL [SUBGOAL_THEN t ALL_TAC; ALL_TAC]
> so the top 3 goals in the goalstack would be (for g the original top goal)
> t, t, and g
> But  that won't fly, because
> MP_TAC is a thm_tactic, and ALL_TAC is just a tactic.  I that the correct 
> usage?  And that's the difference between SUBGOAL_THEN and SUBGOAL_TAC, 
> whether you use a thm_tactic or a tactic?  BTW how do I learn the typed LC or 
> whatever that explains how tactics and thm_tactics actually work?  The HOL 
> Light tutorial I think is actually a pretty good way to learn how to write 
> tactics proofs, if you read the whole tutorial from beginning to end, dipping 
> into the reference manual (and posting here!) when you get stuck, but I don't 
> think it explains the theory of tactics proofs.  Maybe I missed it.
>


I am not exactly sure what you are trying to accomplish here.


I'll try to explain a few things as simply and as best I can:

A thm_tactic roughly corresponds to a forward reasoning step, whereas a 
tactic roughly corresponds to a backwards step.

A thm_tactic expects a theorem (often one of the assumptions) as an 
argument, and does something with it (its conclusion to be more precise).

That's why SUBGOAL_THEN requires a thm_tactic. You provide a SUBGOAL and 
THEN the thm_tactic does something to/with it.
Same goes for DISCH_THEN. It DISCHarges an antecedent (which is now an 
assumption/theorem) and THEN uses a thm_tactic on it.

eg. MP_TAC adds it as an antecedent to the goal, while ASSUME_TAC adds 
it as an assumption.
(Note how DISCH_TAC is *roughly* equivalent to DISCH_THEN ASSUME_TAC.)

Examples:
e (MP_TAC LT_0);; (* adds `!n. 0 < SUC n` as an antecedent to the goal *)
e (ASSUME_TAC LT_0);; (* adds `!n. 0 < SUC n` as an assumption *)
e (FIRST_ASSUM MP_TAC);; (* adds the first assumption as an antecedent - 
the opposite of DISCH_TAC *)

Tactics (traditionally and usually) apply their effects to the goal.



The difference between SUBGOAL_THEN and SUBGOAL_TAC is deeper than this.
Both of them introduce two new subgoals:

Subgoal (A) is your original subgoal, where your newly introduced t is 
also available.
Subgoal (B) is a new subgoal where you need to prove t with your 
original assumptions.


** The thm_tactic given to SUBGOAL_THEN is applied to t in subgoal (A).

ie. it allows you to take an extra step in your original subgoal using 
t. This step can be as simple as introducing t as an assumption 
(ASSUME_TAC) or an antecedent (MP_TAC), or more complicated:

eg. from a previous email:
eliminatean existential quantifier from t and then add the result as an 
assumption:

   SUBGOAL_THEN t (X_CHOOSE_THEN `foo:bar` ASSUME_TAC)


** The tactic given to SUBGOAL_TAC is applied to subgoal (B).

ie. the tactic given to SUBGOAL_TAC works towards (and possibly proves) 
t. If the tactic can completely prove t, subgoal (B) will be eliminated 
in the same step and not appear to the user at all. The difference here 
is that you do not (immediately) control what happens to t in (A), 
except only through its new label in subsequent steps. (Depending on 
your style and what you want to do this may be a good or a bad thing.)


Note that "SUBGOAL_TAC tm s [p]" is defined as:

   SUBGOAL_THEN tm (LABEL_TAC s) THENL [p; ALL_TAC]


What you are trying to do:

   SUBGOAL_THEN t ALL_TAC ...

is like saying: "introduce subgoal t then do nothing (ALL_TAC)".
You need to provide a thm_tactic so that you do "something" with t (as 
trivial or as complicated this "something" is).

That being said (and in hope that this will not confuse you further), 
you can use a tactic as a thm_tactic if that is what you *really* need. 
For example if you want to use t once to simplify your goal (and then 
throw t away) you can do this:

   SUBGOAL_THEN t (fun t -> SIMP_TAC[t])

Note that t will *not* appear in the new subgoal (as you have not added 
it as an assumption or as an antecedent). Of course you can do both if 
you so desire:

   SUBGOAL_THEN t (fun t -> SIMP_TAC[t] THEN ASSUME_TAC t)


Now, just to give you a more concrete idea of what I meant in the 
previous email in the context of the "cases" tactic from p.78 of the 
tutorial you've been looking

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Petros!  It will take me a while to digest your post.  BTW I was wrong 
about the HOL Light reference manual treatment of STRIP_TAC, which is fine.   

   > BTW how does HOL and Informatics fit together?

   How do they not? :) They are connected in so many ways...

I think hol-info ought to have much more info about how HOL is used in the real 
world.  Why not more details! 

   (Note how DISCH_TAC is *roughly* equivalent to DISCH_THEN ASSUME_TAC.)

Michael posted that too, and I'm confused.  I think DISCH_TAC is exactly 
DISCH_THEN ASSUME_TAC.  

   A thm_tactic roughly corresponds to a forward reasoning step,
   whereas a tactic roughly corresponds to a backwards step.

I'm missing the boat about forward & backwards.  I don't know how to prove 
anything except as one does in miz3, and as John (and maybe I) showed, it only 
takes a few lines of code to write up the miz3 reasoning cleanly in HOL 
tactics.  

   A thm_tactic expects a theorem (often one of the assumptions) as an
   argument, and does something with it (its conclusion to be more
   precise).

I would say that's true for ASSUME_TAC, MP_TAC and DISCH_TAC, but they're 
described differently in manual:

FIRST_ASSUM : thm_tactic -> tactic
DISCH_THEN : thm_tactic -> tactic
SUBGOAL_THEN : term -> thm_tactic -> tactic
ASSUME_TAC : thm_tactic
MP_TAC : thm_tactic
DISCH_TAC : tactic

Seems to me that thm_tactic means something that can't begin a command, but can 
be the argument of something like 
FIRST_ASSUM, DISCH_THEN or SUBGOAL_THEN `t`, while a tactic can begin a 
command.  I'll go read your post more carefully!

-- 
Best,
Bill 

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Ramana Kumar]

On Thu, Jan 3, 2013 at 6:06 PM, Bill Richter
wrote:

> Thanks, Petros!  It will take me a while to digest your post.  BTW I was
> wrong about the HOL Light reference manual treatment of STRIP_TAC, which is
> fine.
>
>> BTW how does HOL and Informatics fit together?
>
>How do they not? :) They are connected in so many ways...
>
> I think hol-info ought to have much more info about how HOL is used in the
> real world.  Why not more details!
>

I agree. Perhaps you can write some of your notes on the HOL4 wiki?
https://github.com/mn200/HOL/wiki


>
>(Note how DISCH_TAC is *roughly* equivalent to DISCH_THEN ASSUME_TAC.)
>
> Michael posted that too, and I'm confused.  I think DISCH_TAC is exactly
> DISCH_THEN ASSUME_TAC.
>

In HOL4, you are right: they are exactly the same.
(The only difference I see is that DISCH_TAC will re-raise any exceptions
as having originated with DISCH_TAC rather than with DISCH_THEN).


>
>A thm_tactic roughly corresponds to a forward reasoning step,
>whereas a tactic roughly corresponds to a backwards step.
>
> I'm missing the boat about forward & backwards.  I don't know how to prove
> anything except as one does in miz3, and as John (and maybe I) showed, it
> only takes a few lines of code to write up the miz3 reasoning cleanly in
> HOL tactics.
>
>A thm_tactic expects a theorem (often one of the assumptions) as an
>argument, and does something with it (its conclusion to be more
>precise).
>
> I would say that's true for ASSUME_TAC, MP_TAC and DISCH_TAC, but they're
> described differently in manual:
>
> FIRST_ASSUM : thm_tactic -> tactic
> DISCH_THEN : thm_tactic -> tactic
> SUBGOAL_THEN : term -> thm_tactic -> tactic
> ASSUME_TAC : thm_tactic
> MP_TAC : thm_tactic
> DISCH_TAC : tactic
>
> Seems to me that thm_tactic means something that can't begin a command,
> but can be the argument of something like
> FIRST_ASSUM, DISCH_THEN or SUBGOAL_THEN `t`, while a tactic can begin a
> command.  I'll go read your post more carefully!
>

To keep things really simple: thm_tactic is just an abbreviation for (thm
-> tactic). That is, a thm_tactic is any function that takes a theorem and
returns a tactic. They happen to be used in certain idiomatic ways like as
arguments to FIRST_ASSUM, or DISCH_THEN, but they can be used anywhere a
"theorem-parameterised tactic" is required.

E.g. with FIRST_ASSUM ttac, you can think of ttac as being a
theorem-parameterised tactic; then FIRST_ASSUM says to provide the first
assumption in the current goal as the theorem that makes ttac into a tactic.

--
> Best,
> Bill
>
>
> --
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> ___
> hol-info mailing list
> hol-info@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hol-info
>
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Ramana Kumar]

Sorry, I got the semantics of FIRST_ASSUM wrong: it's more subtle (but
irrelevant to the point I was making); it says to provide the first
assumption that makes the resulting tactic succeed (i.e. it will backtrack
and try each assumption in turn until the constructed tactic doesn't fail).


On Thu, Jan 3, 2013 at 7:07 PM, Ramana Kumar wrote:

> On Thu, Jan 3, 2013 at 6:06 PM, Bill Richter <
> rich...@math.northwestern.edu> wrote:
>
>> Thanks, Petros!  It will take me a while to digest your post.  BTW I was
>> wrong about the HOL Light reference manual treatment of STRIP_TAC, which is
>> fine.
>>
>>> BTW how does HOL and Informatics fit together?
>>
>>How do they not? :) They are connected in so many ways...
>>
>> I think hol-info ought to have much more info about how HOL is used in
>> the real world.  Why not more details!
>>
>
> I agree. Perhaps you can write some of your notes on the HOL4 wiki?
> https://github.com/mn200/HOL/wiki
>
>
>>
>>(Note how DISCH_TAC is *roughly* equivalent to DISCH_THEN ASSUME_TAC.)
>>
>> Michael posted that too, and I'm confused.  I think DISCH_TAC is exactly
>> DISCH_THEN ASSUME_TAC.
>>
>
> In HOL4, you are right: they are exactly the same.
> (The only difference I see is that DISCH_TAC will re-raise any exceptions
> as having originated with DISCH_TAC rather than with DISCH_THEN).
>
>
>>
>>A thm_tactic roughly corresponds to a forward reasoning step,
>>whereas a tactic roughly corresponds to a backwards step.
>>
>> I'm missing the boat about forward & backwards.  I don't know how to
>> prove anything except as one does in miz3, and as John (and maybe I)
>> showed, it only takes a few lines of code to write up the miz3 reasoning
>> cleanly in HOL tactics.
>>
>>A thm_tactic expects a theorem (often one of the assumptions) as an
>>argument, and does something with it (its conclusion to be more
>>precise).
>>
>> I would say that's true for ASSUME_TAC, MP_TAC and DISCH_TAC, but they're
>> described differently in manual:
>>
>> FIRST_ASSUM : thm_tactic -> tactic
>> DISCH_THEN : thm_tactic -> tactic
>> SUBGOAL_THEN : term -> thm_tactic -> tactic
>> ASSUME_TAC : thm_tactic
>> MP_TAC : thm_tactic
>> DISCH_TAC : tactic
>>
>> Seems to me that thm_tactic means something that can't begin a command,
>> but can be the argument of something like
>> FIRST_ASSUM, DISCH_THEN or SUBGOAL_THEN `t`, while a tactic can begin a
>> command.  I'll go read your post more carefully!
>>
>
> To keep things really simple: thm_tactic is just an abbreviation for (thm
> -> tactic). That is, a thm_tactic is any function that takes a theorem and
> returns a tactic. They happen to be used in certain idiomatic ways like as
> arguments to FIRST_ASSUM, or DISCH_THEN, but they can be used anywhere a
> "theorem-parameterised tactic" is required.
>
> E.g. with FIRST_ASSUM ttac, you can think of ttac as being a
> theorem-parameterised tactic; then FIRST_ASSUM says to provide the first
> assumption in the current goal as the theorem that makes ttac into a tactic.
>
> --
>> Best,
>> Bill
>>
>>
>> --
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. ON SALE this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122712
>> ___
>> hol-info mailing list
>> hol-info@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/hol-info
>>
>
>
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

On 03/01/2013 10:07, Ramana Kumar wrote:
> On Thu, Jan 3, 2013 at 6:06 PM, Bill Richter
> mailto:rich...@math.northwestern.edu>>
> wrote:
>
> Β  Β > BTW how does HOL and Informatics fit together?
>
> Β  Β How do they not? :) They are connected in so many ways...
>
> I think hol-info ought to have much more info about how HOL is used
> in the real world. Β Why not more details!
>

I agree gathering this kind of information (not only for informatics but 
also for any applicable field) would be beneficial especially for 
newcomers in the community.

HOL systems are commonly used in informatics for software and hardware 
verification. For example, (as far as I can tell) this is the kind of 
thing John is working on at Intel.

For my research, as another example, I am using an embedding of Linear 
Logic to specify and reason about services/processes and their 
compositions/workflows in HOL Light.




> Β
>
>
> Β  Β (Note how DISCH_TAC is *roughly* equivalent to DISCH_THEN
> ASSUME_TAC.)
>
> Michael posted that too, and I'm confused. Β I think DISCH_TAC is
> exactly DISCH_THEN ASSUME_TAC.
>
>
> In HOL4, you are right: they are exactly the same.
> (The only difference I see is that DISCH_TAC will re-raise any
> exceptions as having originated with DISCH_TAC rather than with DISCH_THEN).

My apologies for confusing you Bill. My memory betrayed me. They are in 
fact the same (apart from what Ramana pointed out), as shown by the 
definition of DISCH_THEN:

   let (DISCH_THEN: thm_tactic -> tactic) =
 fun ttac -> DISCH_TAC THEN POP_ASSUM ttac;;

Regards,

Petros



-- 
Petros Papapanagiotou
CISA, School of Informatics
The University of Edinburgh

Email: p.papapanagio...@sms.ed.ac.uk

---
  The University of Edinburgh is a charitable body, registered in
  Scotland, with registration number SC005336.

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Ramana!  That's very helpful, clarifying DISCH_TAC and explaining 

   To keep things really simple: thm_tactic is just an abbreviation
   for (thm -> tactic). That is, a thm_tactic is any function that
   takes a theorem and returns a tactic.

Great, I didn't know how to parse the phrase thm_tactic!

   E.g. with FIRST_ASSUM ttac, you can think of ttac as being a
   theorem-parameterised tactic; then FIRST_ASSUM says to provide the
   first assumption in the current goal as the theorem that makes ttac
   into a tactic.

OK, I was using it that way in monkey-see-monkey-do fashion, but I didn't see 
that with ttac having an actual meaning.  I didn't realize this was incorrect, 
as you next explain: 

   Sorry, I got the semantics of FIRST_ASSUM wrong: it's more subtle
   (but irrelevant to the point I was making); it says to provide the
   first assumption that makes the resulting tactic succeed (i.e. it
   will backtrack and try each assumption in turn until the
   constructed tactic doesn't fail).

Thanks!  I did wonder why the term FIRST was used: I would have said 
LAST_ASSUM, as the assumption number I always use is the highest number, not 
the lowest.   Let's go through an example I just wrote, a proof of the 
LABEL_TAC manual exercise that doesn't use LABEL_TAC: 

g `(!x y. x <<= y /\ y <<= x ==> x = y) /\
   (!s. ~(s = {}) ==> ?a:A. a IN s /\ !x. x IN s ==> a <<= x)
   ==> (!x y. x <<= y \/ y <<= x) /\
   (!x y z. x <<= y /\ y <<= z ==> x <<= z)`;;
e(REPEAT STRIP_TAC);;
e(FIRST_ASSUM (MP_TAC o SPEC `{x:A,y:A}`) THEN ASM SET_TAC[]);;
e(FIRST_ASSUM (MP_TAC o SPEC `{x:A,y:A,z:A}`) THEN ASM SET_TAC[]);;

Please check if I got this right.  I still have trouble with SPEC and 
composition.  I see the "types" are 
FIRST_ASSUM : thm_tactic -> tactic
SPEC : term -> thm -> thm
MP_TAC : thm_tactic

Thus SPEC `{x:A,y:A}` is a function of "type" :thm -> thm, and MP_TAC is a 
thm_tactic, meaning it's a function of "type" 
:thm -> tactic, 
so composing them we see that (MP_TAC o SPEC `{x:A,y:A}`) is a function of 
"type" 
:thm -> tactic, i.e. it's a thm_tactic, and so the right "type" argument for 
FIRST_ASSUM, which hands over the first assumption (that works!) to our 
thm_tactic, and that means we're evaluating 
 
(MP_TAC o SPEC `{x:A,y:A}`) `!s. ~(s = {}) ==> (?a. a IN s /\ (!x. x IN s ==> a 
<<= x))`
=
MP_TAC `({x:A,y:A} = {}) ==> (?a. a IN {x:A,y:A} /\ (!x. x IN {x:A,y:A} ==> a 
<<= x))`
=
`({x:A,y:A} = {}) ==> (?a. a IN {x:A,y:A} /\ (!x. x IN {x:A,y:A} ==> a <<= x)) 
==> x <<= y \/ y <<= x`

So MP_TAC applied to its thm argument `t` is a tactic, meaning it did 
something: it changed the goal `g` to 
`t ==> g`.  

So i.e. something that does something with a thm.  Now I see the "type"
SET_TAC : thm list -> tactic
which I think means that SET_TAC[] is a tactic, but the ASM means to use the 
list of theorems in the assumption list, which is 
0 [`!x y. x <<= y /\ y <<= x ==> x = y`]
1 [`!s. ~(s = {}) ==> (?a. a IN s /\ (!x. x IN s ==> a <<= x))`]
to get a tactic, and this tactic uses SET_RULE to prove the new goal `t ==> g`, 
and it does!

Wow, this is great, Ramana, I never had any idea what was actually going on.  
How do I learn more about this? 

Petros, this sounds really cool, but I have only the vaguest idea what you 
mean: 

   HOL systems are commonly used in informatics for software and hardware 
   verification. For example, (as far as I can tell) this is the kind of 
   thing John is working on at Intel.

   For my research, as another example, I am using an embedding of Linear 
   Logic to specify and reason about services/processes and their 
   compositions/workflows in HOL Light.

Please say more.  I'm no expert, but I think one of the things John does at 
Intel is formalize theorems for them, floating point theorems about the 
algorithms the chips use that are very difficult for humans to check, perhaps 
using clever stunts with fast fourier transforms?  So that would be actual math 
that John's doing.  I'm having a hard time understanding what else we can use 
HOL for besides mathematical proofs. 

-- 
Best,
Bill 

--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Ramana Kumar]

Dear Bill,

The "types" that you're talking about in quotation marks are ML types. I
guess you quote them to distinguish them from HOL types. Indeed, they are
meta-language types (guess what ML stands for).

Your example with MP_TAC o SPEC etc. looks good.

To learn more about this stuff I tentatively suggest Larry Paulson's "ML
for the Working Programmer". Others may have better suggestions.

Ramana


On Fri, Jan 4, 2013 at 6:47 PM, Bill Richter
wrote:

> Thanks, Ramana!  That's very helpful, clarifying DISCH_TAC and explaining
>
>To keep things really simple: thm_tactic is just an abbreviation
>for (thm -> tactic). That is, a thm_tactic is any function that
>takes a theorem and returns a tactic.
>
> Great, I didn't know how to parse the phrase thm_tactic!
>
>E.g. with FIRST_ASSUM ttac, you can think of ttac as being a
>theorem-parameterised tactic; then FIRST_ASSUM says to provide the
>first assumption in the current goal as the theorem that makes ttac
>into a tactic.
>
> OK, I was using it that way in monkey-see-monkey-do fashion, but I didn't
> see that with ttac having an actual meaning.  I didn't realize this was
> incorrect, as you next explain:
>
>Sorry, I got the semantics of FIRST_ASSUM wrong: it's more subtle
>(but irrelevant to the point I was making); it says to provide the
>first assumption that makes the resulting tactic succeed (i.e. it
>will backtrack and try each assumption in turn until the
>constructed tactic doesn't fail).
>
> Thanks!  I did wonder why the term FIRST was used: I would have said
> LAST_ASSUM, as the assumption number I always use is the highest number,
> not the lowest.   Let's go through an example I just wrote, a proof of the
> LABEL_TAC manual exercise that doesn't use LABEL_TAC:
>
> g `(!x y. x <<= y /\ y <<= x ==> x = y) /\
>(!s. ~(s = {}) ==> ?a:A. a IN s /\ !x. x IN s ==> a <<= x)
>==> (!x y. x <<= y \/ y <<= x) /\
>(!x y z. x <<= y /\ y <<= z ==> x <<= z)`;;
> e(REPEAT STRIP_TAC);;
> e(FIRST_ASSUM (MP_TAC o SPEC `{x:A,y:A}`) THEN ASM SET_TAC[]);;
> e(FIRST_ASSUM (MP_TAC o SPEC `{x:A,y:A,z:A}`) THEN ASM SET_TAC[]);;
>
> Please check if I got this right.  I still have trouble with SPEC and
> composition.  I see the "types" are
> FIRST_ASSUM : thm_tactic -> tactic
> SPEC : term -> thm -> thm
> MP_TAC : thm_tactic
>
> Thus SPEC `{x:A,y:A}` is a function of "type" :thm -> thm, and MP_TAC is a
> thm_tactic, meaning it's a function of "type"
> :thm -> tactic,
> so composing them we see that (MP_TAC o SPEC `{x:A,y:A}`) is a function of
> "type"
> :thm -> tactic, i.e. it's a thm_tactic, and so the right "type" argument
> for FIRST_ASSUM, which hands over the first assumption (that works!) to our
> thm_tactic, and that means we're evaluating
>
> (MP_TAC o SPEC `{x:A,y:A}`) `!s. ~(s = {}) ==> (?a. a IN s /\ (!x. x IN s
> ==> a <<= x))`
> =
> MP_TAC `({x:A,y:A} = {}) ==> (?a. a IN {x:A,y:A} /\ (!x. x IN {x:A,y:A}
> ==> a <<= x))`
> =
> `({x:A,y:A} = {}) ==> (?a. a IN {x:A,y:A} /\ (!x. x IN {x:A,y:A} ==> a <<=
> x))
> ==> x <<= y \/ y <<= x`
>
> So MP_TAC applied to its thm argument `t` is a tactic, meaning it did
> something: it changed the goal `g` to
> `t ==> g`.
>
> So i.e. something that does something with a thm.  Now I see the "type"
> SET_TAC : thm list -> tactic
> which I think means that SET_TAC[] is a tactic, but the ASM means to use
> the list of theorems in the assumption list, which is
> 0 [`!x y. x <<= y /\ y <<= x ==> x = y`]
> 1 [`!s. ~(s = {}) ==> (?a. a IN s /\ (!x. x IN s ==> a <<= x))`]
> to get a tactic, and this tactic uses SET_RULE to prove the new goal `t
> ==> g`, and it does!
>
> Wow, this is great, Ramana, I never had any idea what was actually going
> on.  How do I learn more about this?
>
> Petros, this sounds really cool, but I have only the vaguest idea what you
> mean:
>
>HOL systems are commonly used in informatics for software and hardware
>verification. For example, (as far as I can tell) this is the kind of
>thing John is working on at Intel.
>
>For my research, as another example, I am using an embedding of Linear
>Logic to specify and reason about services/processes and their
>compositions/workflows in HOL Light.
>
> Please say more.  I'm no expert, but I think one of the things John does
> at Intel is formalize theorems for them, floating point theorems about the
> algorithms the chips use that are very difficult for humans to check,
> perhaps using clever stunts with fast fourier transforms?  So that would be
> actual math that John's doing.  I'm having a hard time understanding what
> else we can use HOL for besides mathematical proofs.
>
> --
> Best,
> Bill
>
>
> --
> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> much more. Get web development skills now with LearnDevNow -
> 350+ hours of step-by-step video tutorials by Microsoft MVPs and 

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Ramana!  I'll try to find Larry's book ($66.30 on Amazon).  But since 
it's ML code, uh, can't we read the sources and get a pretty good idea?   Is 
there an Isabelle doc version of this?  Thanks for the feedback on my MP_TAC o 
SPEC code, which I forgot to say is John's code 
http://www.cl.cam.ac.uk/~jrh13/hol-light/HTML/LABEL_TAC.html
with FIRST_ASSUM replacing the label stuff.  I'm really happy you taught me 
some of the ML meaning of what had formerly been HOL black box magic.  I 
guessed later that my "types" were actually ML types, as you said, but I didn't 
guess that when I posted.

BTW you were going to write some HOL documentation for mathematicians who sorta 
understand ZFC...

Here's a nice example of how I taught myself a tactics proof via miz3.  Here's 
a very short proof of a vector version of John's 1-line tutorial theorem on p 67

let MOVE_INVARIANT = prove
  (`!p p'. move p p' ==> oriented_area p = oriented_area p'`,
  REWRITE_TAC[FORALL_PAIR_THM; move; oriented_area; COLLINEAR_LEMMA;  
vector_mul] THEN VEC2_TAC);;

using his new vector versions of the tutorial defs

let oriented_area = new_definition
  `oriented_area (a:real^2,b:real^2,c:real^2) =
  ((b$1 - a$1) * (c$2 - a$2) - (c$1 - a$1) * (b$2 - a$2)) / &2`;;

let move = new_definition
  `!A B C A' B' C':real^2. move (A,B,C) (A',B',C') <=>
  ~collinear {A,B,C} /\ ~collinear {A',B',C'} /\ 
  (B = B' /\ C = C' /\ collinear {vec 0,C - B,A' - A} \/
  C = C' /\ A = A' /\ collinear {vec 0,A - C,B' - B} \/
  A = A' /\ B = B' /\ collinear {vec 0,B - A,C' - C})`;;

and a version of VEC2_TAC of the p 183 tutorial cross product result VEC3_TAC.  
But I couldn't do it until I'd written a 45-line miz3 proof which takes much 
longer to run (and I'd sure like to know why!!!). 

-- 
Best,
Bill 

#load "unix.cma";;
loadt "miz3/miz3.ml";;
horizon := 0;;
timeout := 50;;

needs "Multivariate/vectors.ml";;

let VEC2_TAC =
  SIMP_TAC[CART_EQ; LAMBDA_BETA; FORALL_2; SUM_2; DIMINDEX_2; VECTOR_2;
   vector_add; vec; dot; orthogonal; basis; 
   vector_neg; vector_sub; vector_mul; ARITH] THEN
  CONV_TAC REAL_RING;;

let oriented_area = new_definition
  `oriented_area (a:real^2,b:real^2,c:real^2) =
  ((b$1 - a$1) * (c$2 - a$2) - (c$1 - a$1) * (b$2 - a$2)) / &2`;;

let move = new_definition
  `!A B C A' B' C':real^2. move (A,B,C) (A',B',C') <=>
  ~collinear {A,B,C} /\ ~collinear {A',B',C'} /\ 
  (B = B' /\ C = C' /\ collinear {vec 0,C - B,A' - A} \/
  C = C' /\ A = A' /\ collinear {vec 0,A - C,B' - B} \/
  A = A' /\ B = B' /\ collinear {vec 0,B - A,C' - C})`;;

let Noncollinear_3ImpliesDistinct = prove
  (`~collinear {a,b,c}  ==>  ~(a = b) /\ ~(a = c) /\ ~(b = c)`,
  MESON_TAC[COLLINEAR_BETWEEN_CASES; BETWEEN_REFL]);;

let MOVE_INVARIANT_THM = thm `;
  !p p'. move p p' ==> 
  oriented_area p = oriented_area p'

  proof
let p p' be real^2#real^2#real^2;
assume move p p' [H1];
consider A B C A' B' C' such that
p = (A,B,C) /\ p' = (A',B',C') [DefABC] by PAIR_SURJECTIVE;
~collinear {A,B,C} /\ ~collinear {A',B',C'} [ABCncol] by -, H1, move;
~(A = B) /\ ~(A = C) /\ ~(B = C) /\ ~(A' = B') /\ ~(A' = C') /\ ~(B' = C')  
   [Distinct] by -, Noncollinear_3ImpliesDistinct;
~(C - B = vec 0) /\ ~(A - C = vec 0) /\ ~(B - A = vec 0) [vecDistinct] 
by -, VEC2_TAC;
cases by DefABC, H1, move;
suppose B = B' /\ C = C' /\ collinear {vec 0,C - B,A' - A} [Case];
  cases by -, vecDistinct, COLLINEAR_LEMMA;
  suppose A' - A = vec 0;
A' = A by -, VECTOR_ARITH_TAC;
  qed by -, Case, DefABC, oriented_area;
  suppose ?c. A' - A = c % (C - B);
((B$1 - A$1) * (C$2 - A$2) - (C$1 - A$1) * (B$2 - A$2)) / &2 =
((B$1 - A'$1) * (C$2 - A'$2) - (C$1 - A'$1) * (B$2 - A'$2)) / &2 by 
-, H1,  VEC2_TAC;   
  qed by -, Case, DefABC, oriented_area;
end;
suppose C = C' /\ A = A' /\ collinear {vec 0,A - C,B' - B} [Case];
  cases by -, vecDistinct, COLLINEAR_LEMMA;
  suppose B' - B = vec 0;
B' = B by -, VECTOR_ARITH_TAC;
  qed by -, Case, DefABC, oriented_area;
  suppose ?c. B' - B = c % (A - C);
((B$1 - A$1) * (C$2 - A$2) - (C$1 - A$1) * (B$2 - A$2)) / &2 =
((B'$1 - A$1) * (C$2 - A$2) - (C$1 - A$1) * (B'$2 - A$2)) / &2 by 
-, H1,  VEC2_TAC;  
  qed by -, Case, DefABC, oriented_area;
end;
suppose A = A' /\ B = B' /\ collinear {vec 0,B - A,C' - C} [Case];
  cases by -, vecDistinct, COLLINEAR_LEMMA;
  suppose C' - C = vec 0;
C' = C by -, VECTOR_ARITH_TAC; 
  qed by -, Case, DefABC, oriented_area;
  suppose ?c. C' - C = c % (B - A);
((B$1 - A$1) * (C$2 - A$2) - (C$1 - A$1) * (B$2 - A$2)) / &2 =
((B$1 - A$1) * (C'$2 - A$2) - (C'$1 - A$1) * (B$2 - A$2)) / &2 by 
-, H1,  VEC2_TAC;  
  qed by -, Case, DefABC, oriented_area;
end;
  end;
`;;

let MOVE_INVARIANT = prove
  (`!p p'. move p p' ==> oriented_area p = oriented_area p'`,
  REWRITE_

Re: [Hol-info] Learning HOL Light

[Rob Arthan]

Bill,

On Jan 6, 2013, at 6:18 AM, Bill Richter  wrote:

> Thanks, Ramana!  I'll try to find Larry's book ($66.30 on Amazon). 

One caution: Larry's (excellent) book is about Standard ML, which is the 
metalanguage used in HOL IV and ProofPower. HOL Light is implemented in OCaml. 
With a few notable exception HOL Light generally uses language features that 
have semantic equivalents in Standard ML, but the syntax is different. If you 
go to caml.org you will find lots of information and references specific to 
OCaml.

Regards,

Rob.


--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

In HOL Light vectors, there's something like type quantification, and I thought 
that wasn't possible in HOL.

First, I could not find an HOL4 analogue of HOL Light vectors.  The basic idea 
seems to be that to define the type operator ^ which yields the type real^3 
which denotes vectors in R^3, 3 must be a type, and somehow it must be a type 
with exactly 3 elements, as on p 182 of the HOL Light tutorial we see 
# DIMINDEX_3;
val it : thm = |- dimindex (:3) = 3
This type issue means we need the function $ of type A^B->num->A which involves 
a bijection from the set of numbers from 1 to n (written 1...n in HOL Light) 
and the type B if dimindex (:B) = n.  Here's where I'm seeing something like 
type quantification, in cart.ml: 

let lambda = new_definition
  `(lambda) g =
 @f:A^B. !i. 1 <= i /\ i <= dimindex(:B) ==> (f$i = g i)`;;

let vector = new_definition
  `(vector l):A^N = lambda i. EL (i - 1) l`;;

So the functions (lambda) and vector have types 
(num->A)->A^B and
(A)list->A^B resp.  Notice that type B is only on the right-hand side?  Doesn't 
that mean B is brought in by type quantification?  I would think that meant 
that vector was really defined by 
`!l: (A)list. !B. (vector l):A^B = lambda i. EL (i - 1) l`
Do we get away with this "type quantification" because N is so close to a 
finite set of natural numbers, which has type num->bool? 

In practice this "type quantification" seems to amount to including type 
annotations that I'd think weren't needed, as in the same page of the tutorial. 
 So type_of tells us that 
vector[&1;&2;&3]: real^3 
has type real^3, but 
vector[&1;&2;&3] 
has type real^?185046. 
Surely the type should be real^3, even if we don't  specifically annotate, 
right?  Because the list has length 3?  But that's not what the definition 
vector above says!  It says to feed in a list l and apparently a type 
annotation as well.  I think that's pretty interesting, and I'd like to know 
more. 

-- 
Best,
Bill 

--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Michael Norrish]

On 15/01/13 20:13, Bill Richter wrote:

> In HOL Light vectors, there's something like type quantification,
> and I thought that wasn't possible in HOL.

> First, I could not find an HOL4 analogue of HOL Light vectors. The
> basic idea seems to be that to define the type operator ^ which
> yields the type real^3 which denotes vectors in R^3, 3 must be a
> type, and somehow it must be a type with exactly 3 elements, ...

This is possible in HOL4, using the same “finite cartesian products” approach as
in HOL Light.  See p84 of the HOL4 Description manual (available at
http://sourceforge.net/projects/hol/files/hol/kananaskis-8/kananaskis-8-description.pdf/download);
our approach is ported from HOL Light’s.  There was a paper by John Harrison at
TPHOLs 2005 describing how it all works.

> In practice this "type quantification" seems to amount to including
> type annotations that I'd think weren't needed, as in the same page
> of the tutorial. So type_of tells us that vector[&1;&2;&3]: real^3
> has type real^3, but vector[&1;&2;&3] has type real^?185046.

> Surely the type should be real^3, even if we don't specifically
> annotate, right? Because the list has length 3? But that's not what
> the definition vector above says! It says to feed in a list l and
> apparently a type annotation as well. I think that's pretty
> interesting, and I'd like to know more.

Type inference can’t tell that the argument [1;2;3] has length 3; all it can
deduce is that this is indeed a list of numbers.

Michael



signature.asc
Description: OpenPGP digital signature
--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Michael!  As you see, I haven't read the HOL4 Description manual 
carefully yet.  I should, because I think it's quite possible you might have 
some good explanations not in the HOL Light dox.  Since HOL4 ports HOL Light's 
finite cartesian products, maybe you can explain it!  As you write on p 84 of 
Description: 

dimindex(’b) is the cardinality of univ(:’b) 

That's easier to read that the HOL Light cart.ml code 

let dimindex = new_definition
  `dimindex(s:A->bool) = if FINITE(:A) then CARD(:A) else 1`;;

But it doesn't explain to me how to prove these theorems so necessary for the 
vector types real^2 and real^3: 

# DIMINDEX_2;;
val it : thm = |- dimindex (:2) = 2
#  DIMINDEX_3;;
val it : thm = |- dimindex (:3) = 3

And as Rob says that eventually we should modify HOL to allow type 
quantification, maybe we should ask if we shouldn't allow terms to show up it 
types, so we could define real^3 where 3 has type num, as it normally does, 
rather than being a type that somehow satisfies dimindex (:3) = 3.  

-- 
Best,
Bill 

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Ramana Kumar]

On Wed, Jan 16, 2013 at 1:31 PM, Bill Richter  wrote:

> Thanks, Michael!  As you see, I haven't read the HOL4 Description manual
> carefully yet.  I should, because I think it's quite possible you might
> have some good explanations not in the HOL Light dox.  Since HOL4 ports HOL
> Light's finite cartesian products, maybe you can explain it!  As you write
> on p 84 of Description:
>
> dimindex(’b) is the cardinality of univ(:’b)
>
> That's easier to read that the HOL Light cart.ml code
>
> let dimindex = new_definition
>   `dimindex(s:A->bool) = if FINITE(:A) then CARD(:A) else 1`;;
>
> But it doesn't explain to me how to prove these theorems so necessary for
> the vector types real^2 and real^3:
>
> # DIMINDEX_2;;
> val it : thm = |- dimindex (:2) = 2
> #  DIMINDEX_3;;
> val it : thm = |- dimindex (:3) = 3
>
> And as Rob says that eventually we should modify HOL to allow type
> quantification,


I missed where Rob said this.
HOL-Omega has type quantification, and is backwards compatible with HOL4.
http://www.trustworthytools.com/id17.html.
I'm not sure if we mean the same thing by "type quantification" though.


> maybe we should ask if we shouldn't allow terms to show up it types, so we
> could define real^3 where 3 has type num, as it normally does, rather than
> being a type that somehow satisfies dimindex (:3) = 3.
>

Allowing terms to show up in types probably means moving to a dependently
typed logic. There are many theorem provers in that space: Coq, Agda,
Matita, Idris, Epigram.


>
> --
> Best,
> Bill
>
>
> --
> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> and much more. Keep your Java skills current with LearnJavaNow -
> 200+ hours of step-by-step video tutorials by Java experts.
> SALE $49.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122612
> ___
> hol-info mailing list
> hol-info@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hol-info
>
--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 ___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Rob Arthan]

Bill,

On Jan 16, 2013, at 1:31 PM, Bill Richter  wrote:

> 
> …
> And as Rob says that eventually we should modify HOL to allow type 
> quantification

You make me sound more definite about this than I actually feel. In fact it has 
already been done (for HOL4) in the shape of Peter Homeier's HOL-Omega. But 
Peter has gone quite a bit further than I expected.

> maybe we should ask if we shouldn't allow terms to show up it types, so we 
> could define real^3 where 3 has type num, as it normally does, rather than 
> being a type that somehow satisfies dimindex (:3) = 3.  

You are now entering the world of dependent types - where the extent of a type 
can depend on the value of a term.  This introduces a whole new set of 
complications. I don't recall how far down this path HOL-Omega goes.

Regards,

Rob.



--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Ramana and Rob, thanks for telling me about dependent types, which I'd heard 
Coq had.  I think John Harrison believes that Coq dependent types are really 
complicated, so I'm happy with HOL not allowing 3 to have type num in the 
vector type real^3,  , and instead requiring 3 to be a type.  If anyone wants 
to explain how this 
"n is a type with dimindex(:n) = n" 
actually works under the hood, I'd be grateful,  but I suppose I don't need to 
know.  I do notice that my miz3 vector code runs slower and times out sooner 
than I'd expect.  

Ramana, I was referring to something Rob explained to me off-line, and I think 
it's really cool.  You can't comfortably formalize Algebraic Topology, my 
subject and Rob's, without type quantification.   A continuous function p: E 
---> B between topological spaces is called a fibration if it has the homotopy 
extension property (HLP, and it doesn't matter right now what it means) for all 
spaces M.  We can define a predicate 
HLP p E B M
but defining the predicate fibration requires type quantification, because we 
want to define something like  
Fibration p E B <==> !A. !M: A->bool. HLP p E B M.
and we can't, because we can't quantify over all types A.  At this point, it 
just sounds like something we ought to have but don't, rather than a serious 
problem, because we can write in HOL 
!M: A->bool. HLP p E B M
and make it an assumption of a theorem e.g., we just can't write in inside a 
definition.  Am I getting this right?  It's merely an annoyance to have to drag 
the !M around, and we have more serious formalization problems we haven't 
solved.  

As Rob explained, this problem comes up in a much simpler context, defining a 
product of sets.  Algebraic topologists insist that the product A x B of two 
sets has the universal property that for any set M, a function 
M ---> A x B
is "the same thing" as two functions 
M ---> A and M ---> B. 
I defined a predicate like 
ProductForExample A B M,
by using some ideas of John and redefining composition, but then, as Rob 
explained, we can't define the predicate
Product A B
because that involves quantifying over all sets M, and that sounds like  !A. 
!M: A->bool.  

That's very nice work of Rob's, but he said something that confused me about 
free groups, which also involves type quantification problems, because we want 
to say that for any set S there exists a group F and a function of sets 
inj: S ---> F
such that if we have any group G and any function of sets 
f: S ---> G,
there is a unique homomorphism of groups 
f': F ---> G such that we have equality of functions of sets 
f = f' composed-with inj. 
Of course that requires defining composed-with to not just be o, but I don't 
see the problem.  Why can't we define 
FreeGroupForExample S inj F G 
and then just say that we want to 
FreeGroup S inj F 
but say it doesn't work because we have to quantify over all groups G?  So it's 
free groups are no worse than fibrations or products?  I don't myself know 
enough about free groups in HOL to define the predicate
FreeGroupForExample S inj F G
but I don't see any other problems than my ignorance.  

BTW did you know that Rob was an algebraic topologist?  Here's a paper he 
published long ago in a good journal, with a nice review by a top guy at the 
Univ Chicago:  

   Localization of stable homotopy rings.
   Math. Proc. Cambridge Philos. Soc. 93 (1983), no. 2, 295–302.

   [...] K(Z,2)[b−1]≃K, the spectrum of complex K-theory (the last is
   a classical result of V. P. Snaith, but the author presents an
   elementary proof).

That looks like a nice result to me.  I know something about Snaith's proof, 
and it's not easy. 

-- 
Best,
Bill 

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Ramana Kumar]

On Thu, Jan 17, 2013 at 6:05 AM, Bill Richter  wrote:

> Ramana, I was referring to something Rob explained to me off-line, and I
> think it's really cool.  You can't comfortably formalize Algebraic
> Topology, my subject and Rob's, without type quantification.   A continuous
> function p: E ---> B between topological spaces is called a fibration if it
> has the homotopy extension property (HLP, and it doesn't matter right now
> what it means) for all spaces M.  We can define a predicate
> HLP p E B M
> but defining the predicate fibration requires type quantification, because
> we want to define something like
> Fibration p E B <==> !A. !M: A->bool. HLP p E B M.
> and we can't, because we can't quantify over all types A.  At this point,
> it just sounds like something we ought to have but don't, rather than a
> serious problem, because we can write in HOL
> !M: A->bool. HLP p E B M
> and make it an assumption of a theorem e.g., we just can't write in inside
> a definition.  Am I getting this right?  It's merely an annoyance to have
> to drag the !M around, and we have more serious formalization problems we
> haven't solved.
>

It's not just an annoyance.
Suppose the assumption you have to drag around was instead the definition
of Fibration.
Then I could construct the following theorem:
Fibration p E B = Fibration p E B (by REFL)
(!M:A->bool. HLP p E B M) = Fibration p E B (by definition of Fibration)
(!M:unit->bool. HLP p E B M) = Fibration p E B (by type instantiation)
Now, suppose p does satisfy HLP p E B M for the two cases M = {} and M =
{()}. Then the left-hand-side is T, so we've proved that p is a fibration.
I hazard a guess that this is not supposed to be true (i.e. just because
HLP p E B {} and HLP p E B {()} does not mean p is a fibration).
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Ramana!  I think I wasn't clear.  As Rob explained, there's a type 
quantification problem: we can't define Fibration p E B.  Any time you wish to 
write Fibration p E B, you must write instead 
!M:A->bool. HLP p E B M.  With that in mind, I don't understand your objection 

   It's not just an annoyance.  Suppose the assumption you have to
   drag around was instead the definition of Fibration.

-- 
Best,
Bill 

--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Ramana Kumar]

On Fri, Jan 18, 2013 at 12:58 PM, Bill Richter <
rich...@math.northwestern.edu> wrote:

> Thanks, Ramana!  I think I wasn't clear.  As Rob explained, there's a type
> quantification problem: we can't define Fibration p E B.


I think I was just trying to explain why you can't define it (without type
quantification).


> Any time you wish to write Fibration p E B, you must write instead
> !M:A->bool. HLP p E B M.


Though you'll have to be careful when writing that if the type variable A
is already in your context.


>  With that in mind, I don't understand your objection
>
>It's not just an annoyance.  Suppose the assumption you have to
>drag around was instead the definition of Fibration.
>
> --
> Best,
> Bill
>
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

That's fine, Ramana, you're explanation was probably as good as mine: 

   I think I was just trying to explain why you can't define
   [Fibration p E B] (without type quantification).

   BR> Any time you wish to write Fibration p E B, you must write instead
   BR> !M:A->bool. HLP p E B M.

   Though you'll have to be careful when writing that if the type
   variable A is already in your context.

Good point.  However, I think Milner type inference means we don't need the A 
at all, that we can just write 
!M. HLP p E B M
The definition of HLP will require M to be not only a set (i.e. of type 
A->bool, for some type A) but a topological space, however that's define.  

Anyway, I think !M. HLP p E B M is an acceptable annoyance at this point, when 
we've formalized so little of algebraic topology.  Later maybe the HOL 
maintainers will think we've done such great work they will want to add in type 
quantification.  And maybe it will turn out that there are more serious 
problems to formalizing AT... I'm interested in Rob's challenge about free 
groups.  I don't know how to define a free group in HOL, and mostly because I 
don't think it's an easy matter mathematically.  Take a finite set 
S = {x1,...,xn}
The free group on S consists of all possible expressions like 
x3^6 * x1^{-1} * x4.
We just multiply these expression by concatenating them, but there may be 
cancellations, and we perform recursively as many of them as we can:

x3^6 * x4 TIMES x5^{-1} * x1^{-1} = x3^6 *x4 * x5^{-1} * x1^{-1}

x3^6 * x1^{-1} * x4 TIMES x4^{-2} * x3 = x3^6 * x1^{-1} * x4^{-1} * x3

To me, that's hard HOL to define the free group, but I'm guessing someone has 
already coded this up.  

-- 
Best,
Bill 

--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Ramana Kumar]

On Fri, Jan 18, 2013 at 1:51 PM, Bill Richter  wrote:

> That's fine, Ramana, you're explanation was probably as good as mine:
>
>I think I was just trying to explain why you can't define
>[Fibration p E B] (without type quantification).
>
>BR> Any time you wish to write Fibration p E B, you must write instead
>BR> !M:A->bool. HLP p E B M.
>
>Though you'll have to be careful when writing that if the type
>variable A is already in your context.
>
> Good point.  However, I think Milner type inference means we don't need
> the A at all, that we can just write
> !M. HLP p E B M
> The definition of HLP will require M to be not only a set (i.e. of type
> A->bool, for some type A) but a topological space, however that's define.
>

Just because you don't write the A doesn't mean it isn't there. And if
you'll still need to be careful if there's an A in context, whether you
write it explicitly or not, although hopefully type inference will pick
another type variable for you if there's already an A around (e.g. B).


>
> Anyway, I think !M. HLP p E B M is an acceptable annoyance at this point,
> when we've formalized so little of algebraic topology.  Later maybe the HOL
> maintainers will think we've done such great work they will want to add in
> type quantification.


You seem to have missed the point that HOL Omega already has type
quantification. If you want type quantification, you should definitely be
using it.


>  And maybe it will turn out that there are more serious problems to
> formalizing AT... I'm interested in Rob's challenge about free groups.  I
> don't know how to define a free group in HOL, and mostly because I don't
> think it's an easy matter mathematically.  Take a finite set
> S = {x1,...,xn}
> The free group on S consists of all possible expressions like
> x3^6 * x1^{-1} * x4.
> We just multiply these expression by concatenating them, but there may be
> cancellations, and we perform recursively as many of them as we can:
>
> x3^6 * x4 TIMES x5^{-1} * x1^{-1} = x3^6 *x4 * x5^{-1} * x1^{-1}
>
> x3^6 * x1^{-1} * x4 TIMES x4^{-2} * x3 = x3^6 * x1^{-1} * x4^{-1} * x3
>
> To me, that's hard HOL to define the free group, but I'm guessing someone
> has already coded this up.
>
> --
> Best,
> Bill
>
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

   Just because you don't write the A doesn't mean it isn't there. And
   if you'll still need to be careful if there's an A in context,
   whether you write it explicitly or not, although hopefully type
   inference will pick another type variable for you if there's
   already an A around (e.g. B).

Thanks, Ramana!  I think type inference always behaves that way. I mean, I've 
always assumed it did, and in my limited experience, it does. 

   You seem to have missed the point that HOL Omega already has type
   quantification. If you want type quantification, you should
   definitely be using it.

I'm sold on HOL Light, which Tom Hales particularly recommended in his Notices 
AMS article "Formal Proof", and largely because of John Harrison's interest in 
formalizing pure math.  

-- 
Best,
Bill 

--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[rda]

>Just because you don't write the A doesn't mean it isn't there. And
>if you'll still need to be careful if there's an A in context,
>whether you write it explicitly or not, although hopefully type
>inference will pick another type variable for you if there's
>already an A around (e.g. B).
>
> Thanks, Ramana!  I think type inference always behaves that way. I mean,
> I've always assumed it did, and in my limited experience, it does.
>
>

I believe the type checkers in all known HOL implementations are designed
to give you the most general possible typing subject to any explicit type
constraints. So where Ramana said "hopefully", I would say "unless there's
a bug".

Regards,

Rob.


--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

I think I just learned something about MP_TAC, that these are different:
MP_TAC t THEN MESON_TAC[]
MESON_TAC[t]
This is important to me because of the HOL Light tutorial's Mizar-like 
definitions
let by labs tac = MAP_EVERY (fun l -> USE_THEN l MP_TAC) labs THEN tac;;
let using ths tac = MAP_EVERY MP_TAC ths THEN tac;;
where the tutorial recommends MESON_TAC[] as a possible "tac".  In this case 
I've used instead something I imagined was the same:  with 
let mby labs ths = MAP_EVERY (fun l -> USE_THEN l MP_TAC) labs THEN 
  (MESON_TAC ths);;
But this example below indicates they're not the same.

needs "Multivariate/vectors.ml";; 

g `!u v w:real^2. 
~(v = w) /\ independent {v,w} ==> ?s t. s % v + t % w = u`;;
e(REPEAT STRIP_TAC);;
e(SUBGOAL_THEN `rank (transp (vector [v; w]):real^2^2) = dimindex (:2)
==> ?x:real^2. transp (vector [v; w]) ** x = u` ASSUME_TAC);;
e(MESON_TAC[MATRIX_FULL_LINEAR_EQUATIONS]);;

(* That worked!  But this times out: *)

g `!u v w:real^2. 
~(v = w) /\ independent {v,w} ==> ?s t. s % v + t % w = u`;;
e(REPEAT STRIP_TAC);;
e(SUBGOAL_THEN `rank (transp (vector [v; w]):real^2^2) = dimindex (:2)
==> ?x:real^2. transp (vector [v; w]) ** x = u` ASSUME_TAC);;
e(MP_TAC MATRIX_FULL_LINEAR_EQUATIONS THEN   MESON_TAC[]);;

(* -- 
Best,
Bill *)

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[John Harrison]

Ramana wrote:

| HOL-Omega has type quantification, and is backwards compatible with
| HOL4. http://www.trustworthytools.com/id17.html.

Norbert Voelker's HOL2P also offers type quantification, and is
essentially upward compatible with HOL Light:

  http://cswww.essex.ac.uk/staff/norbert/hol2p/

Indeed, as Peter Homeier has noted, HOL2P was a major inspiration for
his own further extension of the type theory in HOL-Omega.

John.

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Ramana Kumar]

Peter, I have a quick question about one part of your email:
Do you know whether you could add dependent types (the third sort of
abstraction, of a type by a term variable) while still retaining backwards
compatibility with ordinary HOL?


On Fri, Jan 25, 2013 at 4:48 PM, Peter Vincent Homeier <
palan...@trustworthytools.com> wrote:

> Thanks for mentioning HOL-Omega, Ramana and John.
>
> For those who don't know, HOL-Omega extends the existing higher order
> logic implemented in HOL4, HOL-Light, HOL-Zero, etc., with two new kinds of
> abstraction:
>
>1) abstraction of a type by a type variable, and
>2) abstraction of a term by a type variable.
>
> The first sort of abstraction gives you type operator variables and a
> version of the lambda calculus completely within the type language. The
> second sort of abstraction gives you type quantification over terms, as in
> System F, and gives one a more precise and general form of polymorphism
> than in classical higher order logic.
>
> This is essentially the system Fω, as described in Benjamin PIerce's book
> *Types and Programming Languages*, but with one huge change. In Fω, when
> you create a universal type by quantifying over all types, the range of
> that quantification includes the very type that you are constructing. This
> is circular, and this style of definition is called "impredicativity."
>
> It turns out that if you naively try to combine these language features as
> I have described, it doesn't work. The logic you get is inconsistent. This
> was proven by Girard and is known as Girard's Paradox.
>
> Coq and other similar systems avoid this inconsistency by restricting the
> power of the logic to intuitionistic logic, not full classical higher order
> logic. It turns out that this is enough to subdue the logic's power to be
> consistent, in that one cannot prove false.
>
> However, there is another possible design choice, which has not been
> previously explored to my knowledge (any info to the contrary would be
> appreciated!). That is the avoidance of impredicativity by classifying all
> types into collections ordered by ranks, numbered 0, 1, 2, etc. Then when
> one forms a universal type by quantifying over types, the quantification
> takes place over all types of one rank, but the type being formed is of at
> least the next higher rank. Thus the construction is not circular.
>
> With this design choice, I have constructed a version of higher order
> logic that does contain the two new forms of abstraction mentioned above,
> while still retaining all of the power and expressivity of classical higher
> order logic, with a semantics that is considerably simpler than that of
> Coq. HOL-Omega's semantics, as presented in this new upcoming paper, fits
> well within normal set theory, that is, Zermelo-Fraenkel set theory with
> choice. I understand that Coq's semantics requires additional assumptions
> beyond this, namely the existence of an infinite number of inaccessible
> cardinals.
>
> Currently, HOL-Omega does not support dependent types as Coq does; this
> would be a third fundamental sort of abstraction,
>
>3) abstraction of a type by a term variable.
>
> I do not see any fundamental difficulties with adding dependent types to
> HOL-Omega, and could probably do it if I get the opportunity. It should
> actually be easier than the abstraction of terms by type variables. But I
> don't want to speculate on what could be, but rather present to you what is
> actually working today, and that is HOL-Omega.
>
> If people are interested in learning more, there are some new developments
> soon appearing.
>
> First, I have submitted a new paper to the ITP 2013 conference, that
> substantially revises and improves the 2009 TPHOLs paper:
> The HOL-Omega Logic 
> (PDF)
>
> It explains how the logic has changed since 2009, most importantly by
> making ranks attributes of kinds, rather than of types. I'm happy to share
> a preprint with anyone interested, but I should warn you that it is dense,
> highly compressed to fit within 16 pages. The 2009 paper above is still
> useful to read first, as it provides motivation and several cool examples,
> all of which still run unchanged in the newest version of HOL-Omega.
>
> A more readable document is the HOL-Omega TUTORIAL, which I am happy to
> announce has been completed (as far as writing goes) and is now awaiting
> approval for distribution. I expect that this will be available sometime
> early this spring, say about April, but the timing is out of my hands.
>
> In the meantime, there is a nice and juicy TUTORIAL TEASER on the website,
> which gives one chapter from the upcoming tutorial, showing in a light and
> easy way how the new features of the logic can be used to good effect.
>
> Enjoy!
>
> Peter
>
> On Thu, Jan 24, 2013 at 8:48 PM, John Harrison  > wrote:
>
>>
>> Ramana wrote:
>>
>> | HOL-Omega has type quantification, and is backwards co

Re: [Hol-info] Learning HOL Light

[Peter Vincent Homeier]

Thanks for mentioning HOL-Omega, Ramana and John.

For those who don't know, HOL-Omega extends the existing higher order logic
implemented in HOL4, HOL-Light, HOL-Zero, etc., with two new kinds of
abstraction:

   1) abstraction of a type by a type variable, and
   2) abstraction of a term by a type variable.

The first sort of abstraction gives you type operator variables and a
version of the lambda calculus completely within the type language. The
second sort of abstraction gives you type quantification over terms, as in
System F, and gives one a more precise and general form of polymorphism
than in classical higher order logic.

This is essentially the system Fω, as described in Benjamin PIerce's
book *Types
and Programming Languages*, but with one huge change. In Fω, when you
create a universal type by quantifying over all types, the range of that
quantification includes the very type that you are constructing. This is
circular, and this style of definition is called "impredicativity."

It turns out that if you naively try to combine these language features as
I have described, it doesn't work. The logic you get is inconsistent. This
was proven by Girard and is known as Girard's Paradox.

Coq and other similar systems avoid this inconsistency by restricting the
power of the logic to intuitionistic logic, not full classical higher order
logic. It turns out that this is enough to subdue the logic's power to be
consistent, in that one cannot prove false.

However, there is another possible design choice, which has not been
previously explored to my knowledge (any info to the contrary would be
appreciated!). That is the avoidance of impredicativity by classifying all
types into collections ordered by ranks, numbered 0, 1, 2, etc. Then when
one forms a universal type by quantifying over types, the quantification
takes place over all types of one rank, but the type being formed is of at
least the next higher rank. Thus the construction is not circular.

With this design choice, I have constructed a version of higher order logic
that does contain the two new forms of abstraction mentioned above, while
still retaining all of the power and expressivity of classical higher order
logic, with a semantics that is considerably simpler than that of Coq.
HOL-Omega's semantics, as presented in this new upcoming paper, fits well
within normal set theory, that is, Zermelo-Fraenkel set theory with choice.
I understand that Coq's semantics requires additional assumptions beyond
this, namely the existence of an infinite number of inaccessible cardinals.

Currently, HOL-Omega does not support dependent types as Coq does; this
would be a third fundamental sort of abstraction,

   3) abstraction of a type by a term variable.

I do not see any fundamental difficulties with adding dependent types to
HOL-Omega, and could probably do it if I get the opportunity. It should
actually be easier than the abstraction of terms by type variables. But I
don't want to speculate on what could be, but rather present to you what is
actually working today, and that is HOL-Omega.

If people are interested in learning more, there are some new developments
soon appearing.

First, I have submitted a new paper to the ITP 2013 conference, that
substantially revises and improves the 2009 TPHOLs paper:
The HOL-Omega Logic
(PDF)

It explains how the logic has changed since 2009, most importantly by
making ranks attributes of kinds, rather than of types. I'm happy to share
a preprint with anyone interested, but I should warn you that it is dense,
highly compressed to fit within 16 pages. The 2009 paper above is still
useful to read first, as it provides motivation and several cool examples,
all of which still run unchanged in the newest version of HOL-Omega.

A more readable document is the HOL-Omega TUTORIAL, which I am happy to
announce has been completed (as far as writing goes) and is now awaiting
approval for distribution. I expect that this will be available sometime
early this spring, say about April, but the timing is out of my hands.

In the meantime, there is a nice and juicy TUTORIAL TEASER on the website,
which gives one chapter from the upcoming tutorial, showing in a light and
easy way how the new features of the logic can be used to good effect.

Enjoy!

Peter

On Thu, Jan 24, 2013 at 8:48 PM, John Harrison
wrote:

>
> Ramana wrote:
>
> | HOL-Omega has type quantification, and is backwards compatible with
> | HOL4. http://www.trustworthytools.com/id17.html.
>
> Norbert Voelker's HOL2P also offers type quantification, and is
> essentially upward compatible with HOL Light:
>
>   http://cswww.essex.ac.uk/staff/norbert/hol2p/
>
> Indeed, as Peter Homeier has noted, HOL2P was a major inspiration for
> his own further extension of the type theory in HOL-Omega.
>
> John.
>
>
> --
> Master Visual Studio, SharePoint, S

Re: [Hol-info] Learning HOL Light

[Peter Vincent Homeier]

Hi, Ramana.

I hate to speculate about experiments that have not been performed yet, but
my plan would be yes, to retain full backwards compatibility with HOL4, as
has been done so far with HOL-Omega. This does force certain design
choices, but I think it would still all work out all right.

For one thing, instead of having one fundamental ML type to represent both
Object Logic terms and types, I would retain the ML types term and hol_type,
and in the kernel write mutually recursive routines to work down through
both types and terms simultaneously. This would require a few coding tricks
but I think it would be fine.

Of course, you could simplify the logic by having certain restrictions
like, perhaps, no free term variables in a type? But I'm not sure whether
that would be needed or not. That's the sort of question that would be
answered by experimentation.

So yes, Ramana, backwards compatibility has always been a high priority for
me, and it has been almost completely achieved so far. I would not want to
give that up, since the value here is not just the new features of
HOL-Omega, but the joining of that power with the considerable wealth and
investment existing in the HOL4 libraries and examples. It would be madness
to throw that away. The backwards compatibility of HOL-Omega with HOL4 is
discussed more in the upcoming HOL-Omega TUTORIAL.

Peter

On Fri, Jan 25, 2013 at 11:55 AM, Ramana Kumar wrote:

> Peter, I have a quick question about one part of your email:
> Do you know whether you could add dependent types (the third sort of
> abstraction, of a type by a term variable) while still retaining backwards
> compatibility with ordinary HOL?
>
>
> On Fri, Jan 25, 2013 at 4:48 PM, Peter Vincent Homeier <
> palan...@trustworthytools.com> wrote:
>
>> Thanks for mentioning HOL-Omega, Ramana and John.
>>
>> For those who don't know, HOL-Omega extends the existing higher order
>> logic implemented in HOL4, HOL-Light, HOL-Zero, etc., with two new kinds of
>> abstraction:
>>
>>1) abstraction of a type by a type variable, and
>>2) abstraction of a term by a type variable.
>>
>> The first sort of abstraction gives you type operator variables and a
>> version of the lambda calculus completely within the type language. The
>> second sort of abstraction gives you type quantification over terms, as in
>> System F, and gives one a more precise and general form of polymorphism
>> than in classical higher order logic.
>>
>> This is essentially the system Fω, as described in Benjamin PIerce's
>> book *Types and Programming Languages*, but with one huge change. In Fω,
>> when you create a universal type by quantifying over all types, the range
>> of that quantification includes the very type that you are constructing.
>> This is circular, and this style of definition is called "impredicativity."
>>
>> It turns out that if you naively try to combine these language features
>> as I have described, it doesn't work. The logic you get is inconsistent.
>> This was proven by Girard and is known as Girard's Paradox.
>>
>> Coq and other similar systems avoid this inconsistency by restricting the
>> power of the logic to intuitionistic logic, not full classical higher order
>> logic. It turns out that this is enough to subdue the logic's power to be
>> consistent, in that one cannot prove false.
>>
>> However, there is another possible design choice, which has not been
>> previously explored to my knowledge (any info to the contrary would be
>> appreciated!). That is the avoidance of impredicativity by classifying all
>> types into collections ordered by ranks, numbered 0, 1, 2, etc. Then when
>> one forms a universal type by quantifying over types, the quantification
>> takes place over all types of one rank, but the type being formed is of at
>> least the next higher rank. Thus the construction is not circular.
>>
>> With this design choice, I have constructed a version of higher order
>> logic that does contain the two new forms of abstraction mentioned above,
>> while still retaining all of the power and expressivity of classical higher
>> order logic, with a semantics that is considerably simpler than that of
>> Coq. HOL-Omega's semantics, as presented in this new upcoming paper, fits
>> well within normal set theory, that is, Zermelo-Fraenkel set theory with
>> choice. I understand that Coq's semantics requires additional assumptions
>> beyond this, namely the existence of an infinite number of inaccessible
>> cardinals.
>>
>> Currently, HOL-Omega does not support dependent types as Coq does; this
>> would be a third fundamental sort of abstraction,
>>
>>3) abstraction of a type by a term variable.
>>
>> I do not see any fundamental difficulties with adding dependent types to
>> HOL-Omega, and could probably do it if I get the opportunity. It should
>> actually be easier than the abstraction of terms by type variables. But I
>> don't want to speculate on what could be, but rather present to you what is
>> actually

Re: [Hol-info] Learning HOL Light

[Peter Vincent Homeier]

Hi, Grant. That is a great question, and it has sparked my memory. In fact,
I'm going to copy this to the hol-info list since it is of general
interest, and because I made a mistake for which I must apologize.

First, I was wrong in saying that no one else had been doing this sort of
thing, stratifying types into ranks.  I had completely forgotten some
extremely important theorem provers. Examples of some systems that include
this to at least some degree are Coq, ECC by Luo, and MetaPRL from Cornell.
Of course there may be others as well.

Coq is an interesting combination of both predicative and impredicative
types. Originally, based on the Calculus of Constructions, Coq had a type
structure where both Set and Prop were impredicative. However, Zhaohua Luo
improved that logic when he created his Extended Calculus of Constructions
(ECC), which had a base of impredicative types, but allowed for normal
datatype like lists to be formed on top of that base as predicative types
in a rank structure.

Sometime in the mid-2000's the Coq team considered this, and decided to
revise the core logic, making Set predicative and having all the Type(0),
Type(1), etc. hierarchy. But they decided to keep Prop impredicative, and
in fact I think the system as constructed uses this in some subtle ways in
the core. It's not quite as elegant as Luo's ECC, but it's close to the
same logic, and there was only modest disruption to the Coq community from
this change.

MetaPRL is an intuitionistic type theory theorem prover which is strictly
impredicative, just as HOL-Omega is. Bob Constable has described energetic
discussions that he had with the Coq people when they were forming their
theorem prover, advocating for strictly predicative types, but the Coq team
decided they wanted to include impredicativity. By the way, the MetaPRL
team uses an intuitionistic logic on philosophical grounds, and would not
want to use a classical logic even if Girard's Paradox did not prevent it.

So if you have impredicativity at all within your logic, in light of the
dangers posed by Girard's Paradox, you must pay for the impredicativity in
some way, usually by restricting the power of the logic to be
intuitionistic. The impredicative type calculus does look very simple and
elegant, and this can catch your heart if you are not careful. However,
that apparent lovely simplicity hides a world of complex trouble
underneath, typically by allowing the existence of things that are build
out of themselves, circularly. Proofs regarding such logics cannot be done
by the normal means of structural induction, but must use sophisticated
techniques such as induction by logical relations, as I heard Bob Harper
describe a couple of summers ago.
https://sites.google.com/site/oplss10/robert-harper
So this can be done, and it is perfectly sound and respectable, but it is a
lot of work.

But for the predicative portions of the logic, other issues arise. Similar
to the strong typing introduced in Pascal in 1970, the ranks give needed
structure but can get in your way. Just as successor languages after Pascal
found ways to wisely weaken the strong typing, practicality demands some
additional flexibility in the rank system. A feature that I found necessary
from a practical perspective is *universe polymorphism*, which says that
any type constant, term constant, or theorem has rank instances of itself,
both at its current rank and at every higher rank. In each case, the
instance is the same as the original except that all ranks everywhere in
the construct are lifted the same number of levels, simultaneously.
Intuitively, this is saying that any mathematical development that we could
do at one rank, with definitions and theorems, etc., we could have done
just as well one level up. All the resulting theorems would also be true
and would look almost the same except that their ranks were lifted by one,
uniformly. I have found that this is an absolutely necessary feature to
keep the logic as a usable tool.

Coq I believe does not have universe polymorphism, and this has caused some
problems in practical use. such as wanting to have lists of elements which
each have rank 1. But the normal list *nil* and *cons* in Coq are of rank
0, and all of the existing Coq theorems about lists are theorems at rank 0.
So they can't be used to create or reason about such lists. You'd have to
make a copy of the list theory file, edit it throughout to make the ranks
one higher, renaming the type, say, list1, and then compile it before you
could use this in your work. And then you'd have to worry about not
confusing the LENGTH operator for rank 1 with the one for rank 0, etc.

I have not studied MetaPRL much at all, but I understand it has an even
more complex rank system than HOL-Omega. In MetaPRL there are an unlimited
number of separate rank variables. In HOL-Omega, following a suggestion by
John Matthews, there is only one rank variable, in the interests of keeping
the semantics of HOL-Omega a s

Re: [Hol-info] Learning HOL Light

[Grant Olney Passmore]

Hi, Peter --

Thank you very much for this wonderful explanation!

Grant

On 26 Jan 2013, at 01:42, Peter Vincent Homeier wrote:

> Hi, Grant. That is a great question, and it has sparked my memory. In fact, 
> I'm going to copy this to the hol-info list since it is of general interest, 
> and because I made a mistake for which I must apologize.
> 
> First, I was wrong in saying that no one else had been doing this sort of 
> thing, stratifying types into ranks.  I had completely forgotten some 
> extremely important theorem provers. Examples of some systems that include 
> this to at least some degree are Coq, ECC by Luo, and MetaPRL from Cornell. 
> Of course there may be others as well.
> 
> Coq is an interesting combination of both predicative and impredicative 
> types. Originally, based on the Calculus of Constructions, Coq had a type 
> structure where both Set and Prop were impredicative. However, Zhaohua Luo 
> improved that logic when he created his Extended Calculus of Constructions 
> (ECC), which had a base of impredicative types, but allowed for normal 
> datatype like lists to be formed on top of that base as predicative types in 
> a rank structure.
> 
> Sometime in the mid-2000's the Coq team considered this, and decided to 
> revise the core logic, making Set predicative and having all the Type(0), 
> Type(1), etc. hierarchy. But they decided to keep Prop impredicative, and in 
> fact I think the system as constructed uses this in some subtle ways in the 
> core. It's not quite as elegant as Luo's ECC, but it's close to the same 
> logic, and there was only modest disruption to the Coq community from this 
> change.
> 
> MetaPRL is an intuitionistic type theory theorem prover which is strictly 
> impredicative, just as HOL-Omega is. Bob Constable has described energetic 
> discussions that he had with the Coq people when they were forming their 
> theorem prover, advocating for strictly predicative types, but the Coq team 
> decided they wanted to include impredicativity. By the way, the MetaPRL team 
> uses an intuitionistic logic on philosophical grounds, and would not want to 
> use a classical logic even if Girard's Paradox did not prevent it.
> 
> So if you have impredicativity at all within your logic, in light of the 
> dangers posed by Girard's Paradox, you must pay for the impredicativity in 
> some way, usually by restricting the power of the logic to be intuitionistic. 
> The impredicative type calculus does look very simple and elegant, and this 
> can catch your heart if you are not careful. However, that apparent lovely 
> simplicity hides a world of complex trouble underneath, typically by allowing 
> the existence of things that are build out of themselves, circularly. Proofs 
> regarding such logics cannot be done by the normal means of structural 
> induction, but must use sophisticated techniques such as induction by logical 
> relations, as I heard Bob Harper describe a couple of summers ago.
> https://sites.google.com/site/oplss10/robert-harper
> So this can be done, and it is perfectly sound and respectable, but it is a 
> lot of work.
> 
> But for the predicative portions of the logic, other issues arise. Similar to 
> the strong typing introduced in Pascal in 1970, the ranks give needed 
> structure but can get in your way. Just as successor languages after Pascal 
> found ways to wisely weaken the strong typing, practicality demands some 
> additional flexibility in the rank system. A feature that I found necessary 
> from a practical perspective is universe polymorphism, which says that any 
> type constant, term constant, or theorem has rank instances of itself, both 
> at its current rank and at every higher rank. In each case, the instance is 
> the same as the original except that all ranks everywhere in the construct 
> are lifted the same number of levels, simultaneously. Intuitively, this is 
> saying that any mathematical development that we could do at one rank, with 
> definitions and theorems, etc., we could have done just as well one level up. 
> All the resulting theorems would also be true and would look almost the same 
> except that their ranks were lifted by one, uniformly. I have found that this 
> is an absolutely necessary feature to keep the logic as a usable tool.
> 
> Coq I believe does not have universe polymorphism, and this has caused some 
> problems in practical use. such as wanting to have lists of elements which 
> each have rank 1. But the normal list nil and cons in Coq are of rank 0, and 
> all of the existing Coq theorems about lists are theorems at rank 0. So they 
> can't be used to create or reason about such lists. You'd have to make a copy 
> of the list theory file, edit it throughout to make the ranks one higher, 
> renaming the type, say, list1, and then compile it before you could use this 
> in your work. And then you'd have to worry about not confusing the LENGTH 
> operator for rank 1 with the one for rank 0, etc.
> 

Re: [Hol-info] Learning HOL Light

[Bill Richter]

I'm trying to learn how to write an interface for HOL Light that's basically 
miz3 without the the "by" justification lists, so proofs of the statements 
would be normal HOL Light proofs.  I figure that's the easy part of miz3, the 
part that doesn't really have anything to do with Mizar, which is all about a 
nice FOL mathematical formula that limits the size of inference leaps.  Has 
anyone besides Freek every done such a thing?  More specifically, 

A standard Scheme exercise is to write a Scheme meta-interpreter, and that's 
pretty easy because of the quote function, which allows you to read a Scheme 
program as text, which you can then write simple parser for.  Does Ocaml have a 
feature similar to the Scheme quote?

What amazes me most about Freek's miz2 & miz3 is that his interface doesn't use 
backquotes, and miz3 doesn't require the extra type annotations of variables 
put in the backquotes that Petros taught me about.  How do you do something 
like that?  parse_context_term at the top of Mizarlight/miz2a.ml uses the 
functions 
parse_preterm, term_of_preterm, retypecheck and pretype_of_type
whose documentation say things like 

   These are parsing function are not normally of concern to users.
   User manipulation of pretypes is not usually necessary, unless you seek to 
radically change aspects of parsing and typechecking.

I think what Freek's doing runs something like this.  We have many functions 
that deal with strings, e.g. lex & explode. HOL Light deals with pretypes and 
preterms as intermediate representations.   We can use parse_term and  
parse_type to eventually get actual terms and types.

Here's something simple I haven't yet learned how to do: transform a term to a 
string and then back again, and vice versa.

-- 
Best,
Bill 

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Freek Wiedijk answered a question: "string_of_term" and then "parse_term" take 
terms to strings and strings to terms.   Using "parse_term", I made a start 
toward Freek's miz3 interface which doesn't use backquotes and require the 
extra type annotations.   It also uses Marco Maggesi's new DESTRUCT_TAC:

let CONSIDER_TAC vars_string lab t_string prfs =
  match prfs with
   p::ps -> (warn (ps <> []) "CONSIDER_TAC: additional subproofs ignored";
   let tm = parse_term ("?" ^ vars_string ^ "." ^ t_string) in
   SUBGOAL_THEN tm (DESTRUCT_TAC ("@" ^ vars_string ^ "." ^ lab)) 
   THENL [p; ALL_TAC])
   | [] -> failwith "CONSIDER_TAC: no subproof given";;

let CASES_TAC sDestruct sDisjlist tac = 
  let rec list_mk_string_disj sDisjlist = 
match sDisjlist with 
 [] -> "" |
 s::[] -> "(" ^ s ^ ")" | 
 s::ls -> "(" ^ s ^ ") \\/ " ^ list_mk_string_disj ls in 
  let disjthm =  parse_term (list_mk_string_disj sDisjlist) in 
  SUBGOAL_TAC "" disjthm tac THEN FIRST_X_ASSUM  
  (DESTRUCT_TAC sDestruct);;

By using strings assembled by ^ and then transformed to terms by parse_term, I 
can avoid the extra type annotations that arise from typing each of the terms 
that would be assembled by term functions, in this case mk_exists and 
list_mk_disj.  I'm not quite happy with CONSIDER_TAC.  I'd prefer the usage to 
be 
  consider "M such that 
  M = transp(vector[v:real^2;w:real^2]):real^2^2" " Mexists" [MESON_TAC[]]

and I bet this can be done with Ocaml string functions, which would remove the 
substring "such that" and then call the above version 
  CONSIDER_TAC "M" "Mexists" 
  "M = transp(vector[v:real^2;w:real^2]):real^2^2" [MESON_TAC[]]

but I haven't learned how yet.  Notice the improvement due to Freek's 
parse_term and Marco's DESTRUCT_TAC: the first M has no type annotation.  

-- 
Best,
Bill 

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

I fixed my Mizar-like function `consider' (see below) using strings, Marco's 
DESTRUCT_TAC ideas and Freek's  parse_term ideas, and used it to port the HOL 
Light tutorial (p 81) readable proof of the irrationality of sqrt 2.  I 
realized that John's function (p 78) `using' can be thought of mapping a tactic 
to a thm list -> tactic, which we can then apply HYP to!  Here's all my 
Mizar-like tactics code and my port of John's NSQRT_2.  It's readable if you 
evaluate the interactive proof, which I'll include because I'm puzzled by my 3 
message

"Translating certificate to HOL inferences"

which all come from NUM_RING_thmTAC, built with my new understanding of John's 
`using'.  Can anyone explain this?

-- 
Best,
Bill 

let TACtoThmTactic tac = fun  ths -> MAP_EVERY MP_TAC ths THEN tac;;

let NUM_RING_thmTAC = TACtoThmTactic (CONV_TAC NUM_RING);;

let ARITH_thmTAC = TACtoThmTactic ARITH_TAC;;

let so = fun tac -> FIRST_ASSUM MP_TAC THEN tac;;

let consider vars_t prfs lab =
  let len = String.length vars_t in 
  let rec findSuchThat = function
n -> if String.sub vars_t n 9 = "such that" then n
else findSuchThat (n + 1) in 
  let n = findSuchThat 1 in 
  let vars = String.sub vars_t 0 (n - 1) and 
  t = String.sub vars_t (n + 9) (len - n - 9) in 
  let tm = parse_term ("?" ^ vars ^ ". " ^ t) in 
  match prfs with
   p::ps -> (warn (ps <> []) "consider: additional subproofs ignored";
   SUBGOAL_THEN tm (DESTRUCT_TAC ("@" ^ vars ^ "." ^ lab)) 
   THENL [p; ALL_TAC])
   | [] -> failwith "consider: no subproof given";;

let cases sDestruct sDisjlist tac = 
  let rec list_mk_string_disj sDisjlist = 
match sDisjlist with 
 [] -> "" |
 s::[] -> "(" ^ s ^ ")" | 
 s::ls -> "(" ^ s ^ ") \\/ " ^ list_mk_string_disj ls in 
  let disjthm =  parse_term (list_mk_string_disj sDisjlist) in 
  SUBGOAL_TAC "" disjthm tac THEN FIRST_X_ASSUM  
  (DESTRUCT_TAC sDestruct);;

let NSQRT_2 = prove
 (`!p q. p * p = 2 * q * q ==> q = 0`,
  MATCH_MP_TAC num_WF THEN
  INTRO_TAC "!p; A; !q; B"  THEN
  SUBGOAL_TAC "" `EVEN(p * p) <=> EVEN(2 * q * q)` 
  [HYP MESON_TAC "B" []] THEN
  SUBGOAL_TAC "" `EVEN(p)` [so (MESON_TAC [ARITH; EVEN_MULT])] THEN
  consider "m such that p = 2 * m" 
  [so (MESON_TAC [EVEN_EXISTS])] "C" THEN
  cases "qp | pq" ["(q:num) < p"; "p <= q"] [ARITH_TAC] THENL
  [SUBGOAL_TAC "" `q * q = 2 * m * m ==> m = 0` [HYP MESON_TAC "qp A" []] THEN
  so (HYP NUM_RING_thmTAC "B C" []);
  SUBGOAL_TAC "" `p * p <= (q:num) * q` [so (MESON_TAC [LE_MULT2 ])] THEN
  SUBGOAL_TAC "" `q * q = 0` [so (HYP ARITH_thmTAC "B" [])] THEN
  so (NUM_RING_thmTAC [])]);;

g `!p q. p * p = 2 * q * q ==> q = 0`;;
e(MATCH_MP_TAC num_WF);;
e(INTRO_TAC "!p; A; !q; B" );;
e(SUBGOAL_TAC "" `EVEN(p * p) <=> EVEN(2 * q * q)` 
  [HYP MESON_TAC "B" []]);;
e(SUBGOAL_TAC "" `EVEN(p)` [so (MESON_TAC [ARITH; EVEN_MULT])]);;
e(consider "m such that p = 2 * m" 
  [so (MESON_TAC [EVEN_EXISTS])] "C");;
e(cases "qp | pq" ["(q:num) < p"; "p <= q"] [ARITH_TAC]);;
e(SUBGOAL_TAC "" `q * q = 2 * m * m ==> m = 0` [HYP MESON_TAC "qp A" []]);;
e(so (HYP NUM_RING_thmTAC "B C" []));;
e(SUBGOAL_TAC "" `p * p <= (q:num) * q` [so (MESON_TAC [LE_MULT2 ])]);;
e(SUBGOAL_TAC "" `q * q = 0` [so (HYP ARITH_thmTAC "B" [])]);;
e(so (NUM_RING_thmTAC []));;
let NSQRT_2 = top_thm();;

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

John Harrison pointed out that my Mizar-like function `consider' and `cases' I 
just posted won't work if a string contains /\ followed immediately by a 
newline.  We see the problem from 

#   "move (B,A,C) (B,A,X)  /\  move (B,A,X) (B',A,X) /\
move (B',A,X) (B',A,Y)  /\  move (B',A,Y) (B',A',Y)";;
 
val it : string =
  "move (B,A,C) (B,A,X)  /\\  move (B,A,X) (B',A,X) /move (B',A,X) (B',A,Y)  
/\\  move (B',A,Y) (B',A',Y)"

Moving the /\ to the next line solves the problem, but that's not a nice 
solution, and I thought I'd use backquotes instead of doublequotes.  So I need 
a function TermToString that just literally translates a backquoted expression 
to the correct doublequoted expression (of course fixing backslashes and 
newlines), without introducing any extra type inference, so 

TermToString `M such that M = transp(vector[v:real^2;w:real^2]):real^2^2` 

should evaluate to 

"M such that M = transp(vector[v:real^2;w:real^2]):real^2^2"

This is a small part of what Freek Wiedijk must have done in moving from miz2 
to miz3.  I've looked pretty carefully in both the HOL Light dox and the HOL4 
dox and can't find anything.  I'm wondering if there's not something about 
Ocaml that I'm missing.  

Page 159 of the HOL4 Description manual says, "The parser turns strings into 
terms."  Doesn't that mean that backquoted expressions get turned into strings? 
 Now HOL4 seems a bit different from HOL Light, as

   [P. 173] Thus the function Parse.Term function takes a (term) quotation and 
returns a term,
   and is thus of type
   term quotation -> term

Now the HOL Light parse_term has type string -> term.  I do think that HOL4 and 
HOL Light both mean the same thing by quotation, an expression delimited by 
single backquotes (called back-ticks by HOL4).  The HOL Light tutorial says on 
p 10 that "backquotes are used for quotations."

As par as I've gotten is to learn a bit about term_of_preterm and 
preterm_of_term, which I believe are inverse functions.  I can make little 
sense of the large output from 

preterm_of_term `M = transp(vector[v:real^2;w:real^2]):real^2^2`;;

but this evaluates to true

let foo = `M = transp(vector[v:real^2;w:real^2]):real^2^2` in 
term_of_preterm (preterm_of_term foo) = foo;;

and that indicates to me that preterm_of_term is not introducing too many extra 
type annotations.   This however evaluates to false: 

term_of_preterm (preterm_of_term `M = 
transp(vector[v:real^2;w:real^2]):real^2^2`) = 
`M = transp(vector[v:real^2;w:real^2]):real^2^2`;;

and I'm suspecting the reason is that some type annotation is taking place.  In 
fact:

# preterm_of_term `M`;;
Warning: inventing type variables
val it : preterm = Varp ("M", Utv "?84705")

# preterm_of_term `M`;;
Warning: inventing type variables
val it : preterm = Varp ("M", Utv "?84706")

Looks to me that 2 separate arbitrary types were assigned to M.  So I guess I 
don't know if preterm_of_term can be used to build my TermToString.  Maybe 
TermToListOfCharacters would be just as good, as long as there was an inverse 
function.  

BTW the problem I'm trying to solve is pretty simple.  I want cases to have 
multiple arguments which are terms, say `t1`, `t2` and `t3`, but I only want to 
make as many  give type annotations as I would need for 
`t1 \/ t2 \/ t3`.   I don't want to repeate type annotations in t1, t2 and t3.  

-- 
Best,
Bill 

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Ramana Kumar]

In HOL4, all code is passed through a "quotation filter" which does roughly
the following transformations:

`x y z ^(a b c) w` = [QUOTE "x y z ", ANTIQUOTE (a b c), QUOTE " w"]

``foo`` = Term`foo` = Term[...]

``:bar`` = Type`bar` = Type[...]

Term has type term frag list -> term.
Type has type hol_type frag list -> hol_type.
QUOTE has type string -> 'a frag.
ANTIQUOTE has type 'a -> 'a frag.

So much for the mechanincs of quotations in HOL4, which probably doesn't
help you much except for knowledge and peace of mind.

The real piece you need, however, is the fact that Term does
type-inference. I'm not sure if there is anything in HOL-Light already that
does type-inference (as opposed to type-checking).

For further information on how it's done, I would look at the HOL4 docfiles
for, for example Parse.Term, and possibly the sources under the src/parse
directory.


On Sat, Mar 30, 2013 at 3:53 AM, Bill Richter  wrote:

> John Harrison pointed out that my Mizar-like function `consider' and
> `cases' I just posted won't work if a string contains /\ followed
> immediately by a newline.  We see the problem from
>
> #   "move (B,A,C) (B,A,X)  /\  move (B,A,X) (B',A,X) /\
> move (B',A,X) (B',A,Y)  /\  move (B',A,Y) (B',A',Y)";;
>
> val it : string =
>   "move (B,A,C) (B,A,X)  /\\  move (B,A,X) (B',A,X) /move (B',A,X)
> (B',A,Y)  /\\  move (B',A,Y) (B',A',Y)"
>
> Moving the /\ to the next line solves the problem, but that's not a nice
> solution, and I thought I'd use backquotes instead of doublequotes.  So I
> need a function TermToString that just literally translates a backquoted
> expression to the correct doublequoted expression (of course fixing
> backslashes and newlines), without introducing any extra type inference, so
>
> TermToString `M such that M = transp(vector[v:real^2;w:real^2]):real^2^2`
>
> should evaluate to
>
> "M such that M = transp(vector[v:real^2;w:real^2]):real^2^2"
>
> This is a small part of what Freek Wiedijk must have done in moving from
> miz2 to miz3.  I've looked pretty carefully in both the HOL Light dox and
> the HOL4 dox and can't find anything.  I'm wondering if there's not
> something about Ocaml that I'm missing.
>
> Page 159 of the HOL4 Description manual says, "The parser turns strings
> into terms."  Doesn't that mean that backquoted expressions get turned into
> strings?  Now HOL4 seems a bit different from HOL Light, as
>
>[P. 173] Thus the function Parse.Term function takes a (term) quotation
> and returns a term,
>and is thus of type
>term quotation -> term
>
> Now the HOL Light parse_term has type string -> term.  I do think that
> HOL4 and HOL Light both mean the same thing by quotation, an expression
> delimited by single backquotes (called back-ticks by HOL4).  The HOL Light
> tutorial says on p 10 that "backquotes are used for quotations."
>
> As par as I've gotten is to learn a bit about term_of_preterm and
> preterm_of_term, which I believe are inverse functions.  I can make little
> sense of the large output from
>
> preterm_of_term `M = transp(vector[v:real^2;w:real^2]):real^2^2`;;
>
> but this evaluates to true
>
> let foo = `M = transp(vector[v:real^2;w:real^2]):real^2^2` in
> term_of_preterm (preterm_of_term foo) = foo;;
>
> and that indicates to me that preterm_of_term is not introducing too many
> extra type annotations.   This however evaluates to false:
>
> term_of_preterm (preterm_of_term `M =
> transp(vector[v:real^2;w:real^2]):real^2^2`) =
> `M = transp(vector[v:real^2;w:real^2]):real^2^2`;;
>
> and I'm suspecting the reason is that some type annotation is taking
> place.  In fact:
>
> # preterm_of_term `M`;;
> Warning: inventing type variables
> val it : preterm = Varp ("M", Utv "?84705")
>
> # preterm_of_term `M`;;
> Warning: inventing type variables
> val it : preterm = Varp ("M", Utv "?84706")
>
> Looks to me that 2 separate arbitrary types were assigned to M.  So I
> guess I don't know if preterm_of_term can be used to build my TermToString.
>  Maybe TermToListOfCharacters would be just as good, as long as there was
> an inverse function.
>
> BTW the problem I'm trying to solve is pretty simple.  I want cases to
> have multiple arguments which are terms, say `t1`, `t2` and `t3`, but I
> only want to make as many  give type annotations as I would need for
> `t1 \/ t2 \/ t3`.   I don't want to repeate type annotations in t1, t2 and
> t3.
>
> --
> Best,
> Bill
>
>
> --
> Own the Future-Intel(R) Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest. Compete
> for recognition, cash, and the chance to get your game on Steam.
> $5K grand prize plus 10 genre and skill prizes. Submit your demo
> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
> ___
> hol-info mailing list
> hol-info@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hol-info
>
--

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Ramana! You're the person I wanted to talk to.  I already had a vague 
understand of what you explained (thanks for explaning), but I have a different 
question about HOL4:

I'm convinced that the solution to my problem involves camlp (I use 
camlp5-6.05), as I can't find anything in the HOL Light or Ocaml dox.  So I 
think this is a parsing issue, and I'd like to understand what HOL4 that's 
analogous to the HOL Light camlp5 parsing that allows us to put terms in 
backquotes (or back-ticks as the HOL4 dox say).  So can you describe the what 
HOL4 does that's comparable to the HOL Light use of camlp?  I bet it will be 
easier for me to understand.  For starters, why does HOL4 use double backquotes 
instead of HOL Light's single backquotes?  

   The real piece you need, however, is the fact that Term does
   type-inference. I'm not sure if there is anything in HOL-Light
   already that does type-inference (as opposed to type-checking).

That's encouraging for my project!  I bet you're right. I bet preterm_of_term 
doesn't do type-inference and it's the later function term_of_preterm that does 
type-inference.  Certainly the first place in preterm.ml where the string 
"infer" occurs is as an error message in term_of_preterm.

Let me clarify what I want.  Take two blocks of text t1 and t2.  I want a 
functions like disj_term so that evaluating

disj_term `t1` `t2`;;

yields `t1 \/ t2`.  That's not going to be possible if HOL Light does type 
inference on `t1` and `t2 before disj_term goes to work.  And I'm sure from 
Freek's miz3 that HOL Light does not perform such type inference.  

-- 
Best,
Bill 

--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Hi Bill,

Short answer: string_of_term

Long answer:
let me try to make things clearer about what happens in HOL-Light 
(pretty similar, conceptually, to what happens in HOL4) when you type in 
something like `bla`:
1. the quotation `bla` is turned (by camlp5 indeed) into an expression 
of type preterm
   (this is done mainly by parse_preterm, preceded by "lex o explode")
2. the resulting preterm contains mostly no type information but the one 
which is given explicitly in the term
3. the resulting preterm then goes through the function retypecheck 
which checks that the preterm is well typed
4. then only it is turned into a value of type term by term_of_preterm 
(note thus that a value of type term is assumed to be well-typed, which 
is not the case for values of type preterm)

(  Maybe the following example might make things clearer:

   # parse_preterm (lex (explode "&1 + 1"));;
   val it : preterm * lexcode list =
 (Combp
   (Combp (Varp ("+", Ptycon ("", [])),
 Combp (Varp ("&", Ptycon ("", [])), Varp ("1", Ptycon ("", [],
   Varp ("1", Ptycon ("", []))),
  [])

   # retypecheck [] (fst it);;
   Exception: Failure "typechecking error (overload resolution)".

   -> You see that the type error appears only after the call to 
retypecheck, apart from that,
   parse_preterm yields a very valid value of type preterm out of the 
(badly-typed) expression "&1 + 1"
)

Consequence: each time you write `bla`, you automatically go through the 
whole process of type inference.
Therefore, about your main problem, `t1` will automatically be given an 
arbitrary type, as well as `t2` (and both type will be different, and 
different from bool).
So there is no (simple) way to get a function disj_term that behaves the 
way you want.
The alternative, that you seem to have considered already, is to use 
strings (i.e., double-quote instead of single quote) but this yields the 
problems you have already encountered (i.e., backslash preceding a new 
line messes up the parsing).
The other alternative, which is the one you required in your previous 
email, is to make use of the built-in term parser in order to avoid the 
parsing problems of the first alternative, then go back to strings by 
using a function that you called "TermToString", which exists in HOL 
Light, except that it's called "string_of_term".
This might yield to other problems but I guess it will depend on the use 
you make of it.

Cheers,
V.

Le 31.03.13 23:38, Bill Richter a écrit :
> Thanks, Ramana! You're the person I wanted to talk to.  I already had a vague 
> understand of what you explained (thanks for explaning), but I have a 
> different question about HOL4:
>
> I'm convinced that the solution to my problem involves camlp (I use 
> camlp5-6.05), as I can't find anything in the HOL Light or Ocaml dox.  So I 
> think this is a parsing issue, and I'd like to understand what HOL4 that's 
> analogous to the HOL Light camlp5 parsing that allows us to put terms in 
> backquotes (or back-ticks as the HOL4 dox say).  So can you describe the what 
> HOL4 does that's comparable to the HOL Light use of camlp?  I bet it will be 
> easier for me to understand.  For starters, why does HOL4 use double 
> backquotes instead of HOL Light's single backquotes?
>
> The real piece you need, however, is the fact that Term does
> type-inference. I'm not sure if there is anything in HOL-Light
> already that does type-inference (as opposed to type-checking).
>
> That's encouraging for my project!  I bet you're right. I bet preterm_of_term 
> doesn't do type-inference and it's the later function term_of_preterm that 
> does type-inference.  Certainly the first place in preterm.ml where the 
> string "infer" occurs is as an error message in term_of_preterm.
>
> Let me clarify what I want.  Take two blocks of text t1 and t2.  I want a 
> functions like disj_term so that evaluating
>
> disj_term `t1` `t2`;;
>
> yields `t1 \/ t2`.  That's not going to be possible if HOL Light does type 
> inference on `t1` and `t2 before disj_term goes to work.  And I'm sure from 
> Freek's miz3 that HOL Light does not perform such type inference.
>


-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

I do not know if this qualifies as "simple" or if it is what you are 
really looking for, but you can use the "trick" I have been using in my 
"Isabelle Light" library.

Basically, if you know (or if you can determine) what the well-behaved 
type of your term (string?) is, then you can (try to) force it into that 
type.

eg. (from 
http://code.google.com/p/hol-light/source/browse/trunk/IsabelleLight/new_tactics.ml
 
) :

let (X_MATCH_CHOOSE_TAC: term -> thm_tactic) =
   fun x' xth ->
 try let xtm = concl xth in
 let x,bod = dest_exists xtm in
 let x'type = type_of x' in
 let x'' = if (is_vartype x'type) then
   inst (type_match x'type (type_of x) []) x'
 else x' in
 let pat = vsubst[x'',x] bod in
 let xth' = ASSUME pat in
 fun (asl,w) ->
   let avoids = itlist (union o frees o concl o snd) asl
   (union (frees w) (thm_frees xth)) in
   if mem x' avoids then failwith "X_CHOOSE_TAC" else
   null_meta,[("",xth')::asl,w],
   fun i [th] -> CHOOSE(x'',INSTANTIATE_ALL i xth) th
 with Failure _ -> failwith "X_CHOOSE_TAC";;

(Compare this to X_CHOOSE_TAC in tactics.ml for contrast.)
This allows you to do:

prove (` (?x . x = 5) ==> ?y . y > 4`,
DISCH_THEN (X_MATCH_CHOOSE_TAC `x`) THEN
EXISTS_TAC `x:num` THEN
FIRST_ASSUM SUBST1_TAC THEN ARITH_TAC);;

instead of:
[...] DISCH_THEN (X_CHOOSE_TAC `x:num`) THEN [...]

(You can also replace "EXISTS_TAC `x:num`" with "rule_tac [`a`,`x`] exI" 
to avoid the other type annotation since rule_tac uses the same type 
instantiation mechanism.)


Similarly you could write your disj_term so that it forces t1 and t2 to 
be bool:

let (disj_term: term -> term -> term) =
   fun t1 t2 ->
 let mk_bool tm =
   let ty = type_of tm in
   if (is_vartype ty) then
   inst (type_match ty `:bool` []) tm
   else tm in
 mk_disj (mk_bool t1,mk_bool t2);;


# disj_term `x` `y`;;
Warning: inventing type variables
Warning: inventing type variables
val it : term = `x \/ y`
# disj_term `5` `6`;;
Exception: Failure "mk_binary".

Switching off the "inventing type variables" warning becomes standard 
practice when using this kind of "tricks":

# type_invention_warning := false;;
val it : unit = ()

You may also want to catch any exceptions and give more meaningful error 
messages, but it is up to you how you want to handle failures.


Hope this helps!


Regards,

Petros


On 01/04/2013 05:19, Vincent Aravantinos wrote:
 > So there is no (simple) way to get a function disj_term that behaves the
 > way you want.


On 31/03/13 23:38, Bill Richter wrote:
 >
 > Let me clarify what I want.  Take two blocks of text t1 and t2.  I 
want a functions like disj_term so that evaluating
 >
 > disj_term `t1` `t2`;;
 >
 > yields `t1 \/ t2`.  That's not going to be possible if HOL Light does 
type inference on `t1` and `t2 before disj_term goes to work.  And I'm 
sure from Freek's miz3 that HOL Light does not perform such type inference.
 >



-- 
Petros Papapanagiotou
CISA, School of Informatics
The University of Edinburgh

Email: p.papapanagio...@sms.ed.ac.uk

---
  The University of Edinburgh is a charitable body, registered in
  Scotland, with registration number SC005336.

--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

On 01/04/2013 10:40, Petros Papapanagiotou wrote:
>
> You may also want to catch any exceptions and give more meaningful error
> messages, but it is up to you how you want to handle failures.
>

Actually I just noticed John has updated the error messages of 
X_CHOOSE_TAC recently (in the spirit of Vincent's approach to providing 
better type checking feedback I am guessing). I should propagate these 
changes!

Also note that the "is_vartype" check in my code is actually restricting 
and can be omitted. Here is a new more generalised version:

let try_type tp tm =
   try inst (type_match (type_of tm) tp []) tm
   with Failure _ -> tm;;

let (disj_term: term -> term -> term) =
fun t1 t2 -> mk_disj (try_type `:bool` t1, try_type `:bool` t2);;


Regards,

Petros



-- 
Petros Papapanagiotou
CISA, School of Informatics
The University of Edinburgh

Email: p.papapanagio...@sms.ed.ac.uk

---
  The University of Edinburgh is a charitable body, registered in
  Scotland, with registration number SC005336.

--
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Vincent and Petros!  I'll have to study your interesting posts 
carefully.  A few quick comments:

Petros, it looks like you're doing something that's a whole lot more 
interesting than my project.  I'm not sure I have the terminology straight:

Suppose we bind a variable x, say with INTRO_TAC, DESTRUCT_TAC or 
X_CHOOSE_THEN, to a term t with type alpha.Then if the variable x occurs in 
a term (in doublequotes) that is in the scope of this variable binding, x ought 
to automatically be bound to t:alpha.  We should not have to repeat the type 
annotation of x.  

If that's what you did, Petros, that's fabulous, and will cut down on more type 
annotations than my consider/case would.  Freek's miz3 does something like this 
I think, and I haven't figured out how he does it.  Can you comment on your 
Isabelle Light code?  I'll go read your paper with Jacques Fleuriot 
link.springer.com/chapter/10.1007%2F978-3-642-16242-8_40

   The other alternative, which is the one you required in your
   previous email, is to make use of the built-in term parser in order
   to avoid the parsing problems of the first alternative, then go
   back to strings by using a function that you called "TermToString",
   which exists in HOL Light, except that it's called
   "string_of_term".

Thanks, Vincent, and I think I have to go this way, but string_of_term doesn't 
do what I want, because it loses my explicit type annotations.  How can I go 
about learning how to use the built-in term parser, and which parser do you 
mean?  I believe that pa_j.ml defines how backquotes work in HOL Light, and 
that pa_j.ml gets compiled by make.  Is that right?   Just to be a bit more 
precise, the ocaml function ^ that concatenates strings obviously has to know 
what strings look like internally.  Even beginners know how to write a 
recursive function that concatenates two lists, but of course you have to know 
about cons (::), car (sometimes hd), & cdr (sometimes tl) to do it.  Some 
similar knowlege is needed to write ^, and probably even more knowledge is 
needed to join two terms with an \/, but I don't see why it can't be done, 
given sufficient knowledge of camlp and pa_j.ml.   Now is that right? 

-- 
Best,
Bill 

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Hi Bill,

Le 01.04.13 22:08, Bill Richter a écrit :
> Thanks, Vincent, and I think I have to go this way, but string_of_term 
> doesn't do what I want, because it loses my explicit type annotations.  How 
> can I go about learning how to use the built-in term parser, and which parser 
> do you mean?  I believe that pa_j.ml defines how backquotes work in HOL 
> Light, and that pa_j.ml gets compiled by make.  Is that right?
Yes.
> Just to be a bit more precise, the ocaml function ^ that concatenates strings 
> obviously has to know what strings look like internally.  Even beginners know 
> how to write a recursive function that concatenates two lists, but of course 
> you have to know about cons (::), car (sometimes hd), & cdr (sometimes tl) to 
> do it.  Some similar knowlege is needed to write ^, and probably even more 
> knowledge is needed to join two terms with an \/, but I don't see why it 
> can't be done, given sufficient knowledge of camlp and pa_j.ml.   Now is that 
> right?
I'm not sure I see what you mean here, could you be more precise?

-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Vincent!  Let me be more precise.  I want functions that act on terms 
that are somewhat like the ocaml function ^ which concatenates strings.  I 
don't know how to define ^, but I know how to define similar functions on lists 
in ocaml.  There's a simple example in the official documentation 
ocaml-4.00-refman.pdf on page 12--13: 

let rec sort lst =
  match lst with
[] -> []
  | head :: tail -> insert head (sort tail)
and insert elt lst =
  match lst with
[] -> [elt]
  | head :: tail -> if elt <= head then elt :: lst else head :: insert elt 
tail;;

let l = ["is"; "a"; "tale"; "told"; "etc."];;

sort l;;

This is easy, but you have to know how lists work to do it, that every list is 
either [] or of the sort head :: tail where tail is a list.  You'd have to know 
more things of that sort to understand how to write ^.  I think what I want is 
similar, but it requires knowledge of the much harder camlp:

Given two blocks of text t1 and t2 (I don't want to call them strings), I want 
to define a function disj_term so that 

disj_term `t1` `t2`;;

evaluates to the term `t1 \/ t2`.  Now it's possible that this can't be done, 
and it's also possible that Petros just did it.  I think you can't do this if 
you first apply string_of_term to the terms `t1` and `t2`, because that will 
destroy explicit type annotations.  That's clear from the documentation: 

   The call string_of_term tm produces a textual representation of the
   term tm as a string, similar to what is printed automatically at
   the toplevel, though without the surrounding quotes.

That is, the toplevel textual representation has less information than type_of 
will give you, so you lose explicit type annotations.  But I don't want to lose 
them.  Let me give an example:  I want 

disj_term `~collinear {B,(A:real^2),A'} /\ ~collinear {A',B,B'}` `~collinear 
{A,B,B'} /\ ~collinear {B',A,A'}`;;

to evaluate to 

`~collinear {B,(A:real^2),A'} /\ ~collinear {A',B,B'} \/ ~collinear {A,B,B'} /\ 
~collinear {B',A,A'}`

It's important that I don't lose my type annotation A:real^2, because that 
annotation forces B, A' and B' to also have type real^2.  But string_of_term 
would remove that type annotation A:real^2.

So I figure that writing disj_term would require understanding how the parser 
works, but if you did, it should be straightforward.

-- 
Best,
Bill 

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Ok, got it. Indeed, I don't see any other options than the one already 
mentionned.
The parser one is indeed the most complex of them but it's of course 
doable.
I had the same problem when developping for HOL-Light a module similar 
to the Q module of HOL4 (see 
http://users.encs.concordia.ca/~vincent/Software.html).
My own conclusion was that using strings was offering the best 
compromise time/benefit (compared to developping my own parser).
The only drawback is that backslashes require a particular attention as 
you noticed already, but the implementation is much more straightforward 
than developping a new parser.

Le 01.04.13 22:46, Bill Richter a écrit :
> Thanks, Vincent!  Let me be more precise.  I want functions that act on terms 
> that are somewhat like the ocaml function ^ which concatenates strings.  I 
> don't know how to define ^, but I know how to define similar functions on 
> lists in ocaml.  There's a simple example in the official documentation 
> ocaml-4.00-refman.pdf on page 12--13:
>
> let rec sort lst =
>match lst with
>  [] -> []
>| head :: tail -> insert head (sort tail)
> and insert elt lst =
>match lst with
>  [] -> [elt]
>| head :: tail -> if elt <= head then elt :: lst else head :: insert elt 
> tail;;
>
> let l = ["is"; "a"; "tale"; "told"; "etc."];;
>
> sort l;;
>
> This is easy, but you have to know how lists work to do it, that every list 
> is either [] or of the sort head :: tail where tail is a list.  You'd have to 
> know more things of that sort to understand how to write ^.  I think what I 
> want is similar, but it requires knowledge of the much harder camlp:
>
> Given two blocks of text t1 and t2 (I don't want to call them strings), I 
> want to define a function disj_term so that
>
> disj_term `t1` `t2`;;
>
> evaluates to the term `t1 \/ t2`.  Now it's possible that this can't be done, 
> and it's also possible that Petros just did it.  I think you can't do this if 
> you first apply string_of_term to the terms `t1` and `t2`, because that will 
> destroy explicit type annotations.  That's clear from the documentation:
>
> The call string_of_term tm produces a textual representation of the
> term tm as a string, similar to what is printed automatically at
> the toplevel, though without the surrounding quotes.
>
> That is, the toplevel textual representation has less information than 
> type_of will give you, so you lose explicit type annotations.  But I don't 
> want to lose them.  Let me give an example:  I want
>
> disj_term `~collinear {B,(A:real^2),A'} /\ ~collinear {A',B,B'}` `~collinear 
> {A,B,B'} /\ ~collinear {B',A,A'}`;;
>
> to evaluate to
>
> `~collinear {B,(A:real^2),A'} /\ ~collinear {A',B,B'} \/ ~collinear {A,B,B'} 
> /\ ~collinear {B',A,A'}`
>
> It's important that I don't lose my type annotation A:real^2, because that 
> annotation forces B, A' and B' to also have type real^2.  But string_of_term 
> would remove that type annotation A:real^2.
>
> So I figure that writing disj_term would require understanding how the parser 
> works, but if you did, it should be straightforward.
>


-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Oh wait, I think I just found a quick (maybe dirty) hack: in the file 
system.ml, replace the lines:

let quotexpander s =
   if String.sub s 0 1 = ":" then
 "parse_type \""^
 (String.escaped (String.sub s 1 (String.length s - 1)))^"\""
   else "parse_term \""^(String.escaped s)^"\"";;

by:

let quotexpander s =
   if String.sub s 0 1 = ":" then
 "parse_type \""^
 (String.escaped (String.sub s 1 (String.length s - 1)))^"\""
   else if String.sub s 0 1 = ";" then
 "(fst o parse_preterm o lex o explode) \""^
 (String.escaped (String.sub s 1 (String.length s - 1)))^"\""
   else "parse_term \""^(String.escaped s)^"\"";;

Then each time you type something that starts with a semi-colon (e.g., 
`;blabla`), you obtain the intermediate preterm instead of the term.
If I'm right, this means that you don't have the backslash problem 
anymore (since we're going through the John's parser), but not all the 
types are infered since we didn't go through the type checking phasis 
yet. And you could define a function disj_preterm easily (once you built 
your preterm, it is easy to get the term by using term_of_preterm, 
generally composed with retypecheck in order to check that the final 
term is well typed).

I didn't go far in these thoughts though. So there might be other 
loopholes that I'm not aware of.

V.

PS: I have the feeling that I have seen some quotations starting with 
";" somewhere else, but I can't remember where, maybe there's a 
connection, maybe not...?

Le 01.04.13 23:31, Vincent Aravantinos a écrit :
> Ok, got it. Indeed, I don't see any other options than the one already 
> mentionned.
> The parser one is indeed the most complex of them but it's of course 
> doable.
> I had the same problem when developping for HOL-Light a module similar 
> to the Q module of HOL4 (see 
> http://users.encs.concordia.ca/~vincent/Software.html).
> My own conclusion was that using strings was offering the best 
> compromise time/benefit (compared to developping my own parser).
> The only drawback is that backslashes require a particular attention 
> as you noticed already, but the implementation is much more 
> straightforward than developping a new parser.
>
> Le 01.04.13 22:46, Bill Richter a écrit :
>> Thanks, Vincent!  Let me be more precise. I want functions that act 
>> on terms that are somewhat like the ocaml function ^ which 
>> concatenates strings.  I don't know how to define ^, but I know how 
>> to define similar functions on lists in ocaml.  There's a simple 
>> example in the official documentation ocaml-4.00-refman.pdf on page 
>> 12--13:
>>
>> let rec sort lst =
>>match lst with
>>  [] -> []
>>| head :: tail -> insert head (sort tail)
>> and insert elt lst =
>>match lst with
>>  [] -> [elt]
>>| head :: tail -> if elt <= head then elt :: lst else head :: 
>> insert elt tail;;
>>
>> let l = ["is"; "a"; "tale"; "told"; "etc."];;
>>
>> sort l;;
>>
>> This is easy, but you have to know how lists work to do it, that 
>> every list is either [] or of the sort head :: tail where tail is a 
>> list.  You'd have to know more things of that sort to understand how 
>> to write ^.  I think what I want is similar, but it requires 
>> knowledge of the much harder camlp:
>>
>> Given two blocks of text t1 and t2 (I don't want to call them 
>> strings), I want to define a function disj_term so that
>>
>> disj_term `t1` `t2`;;
>>
>> evaluates to the term `t1 \/ t2`.  Now it's possible that this can't 
>> be done, and it's also possible that Petros just did it. I think you 
>> can't do this if you first apply string_of_term to the terms `t1` and 
>> `t2`, because that will destroy explicit type annotations.  That's 
>> clear from the documentation:
>>
>> The call string_of_term tm produces a textual representation of the
>> term tm as a string, similar to what is printed automatically at
>> the toplevel, though without the surrounding quotes.
>>
>> That is, the toplevel textual representation has less information 
>> than type_of will give you, so you lose explicit type annotations.  
>> But I don't want to lose them.  Let me give an example:  I want
>>
>> disj_term `~collinear {B,(A:real^2),A'} /\ ~collinear {A',B,B'}` 
>> `~collinear {A,B,B'} /\ ~collinear {B',A,A'}`;;
>>
>> to evaluate to
>>
>> `~collinear {B,(A:real^2),A'} /\ ~collinear {A',B,B'} \/ ~collinear 
>> {A,B,B'} /\ ~collinear {B',A,A'}`
>>
>> It's important that I don't lose my type annotation A:real^2, because 
>> that annotation forces B, A' and B' to also have type real^2.  But 
>> string_of_term would remove that type annotation A:real^2.
>>
>> So I figure that writing disj_term would require understanding how 
>> the parser works, but if you did, it should be straightforward.
>>
>
>


-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


---

Re: [Hol-info] Learning HOL Light

[Freek Wiedijk]

Vincent:

>Then each time you type something that starts with a semi-colon (e.g., 
>`;blabla`), you obtain the intermediate preterm instead of the term.

Hey!  miz3 already uses `;...` for proofs.  So maybe it's
less confusing if you use another symbol to get preterms?

Freek

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Oh, so that answers my PS, haha: that's where I saw this symbol! Sorry, I just 
caught the conversation when it started to deal with types and I am not fully 
aware of miz3. Then, Bill, just change the corresponding character to whatever 
you want. A dot for instance.

--
Vincent Aravantinos
PostDoctoral Fellow, Concordia University, Hardware Verification Group
http://users.encs.concordia.ca/~vincent


Am 2013-04-02 um 03:55 schrieb Freek Wiedijk :

> Vincent:
> 
>> Then each time you type something that starts with a semi-colon (e.g., 
>> `;blabla`), you obtain the intermediate preterm instead of the term.
> 
> Hey!  miz3 already uses `;...` for proofs.  So maybe it's
> less confusing if you use another symbol to get preterms?
> 
> Freek

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

Hello Bill,


On 02/04/2013 03:08, Bill Richter wrote:
> Suppose we bind a variable x, say with INTRO_TAC, DESTRUCT_TAC or 
> X_CHOOSE_THEN, to a term t with type alpha.Then if the variable x occurs 
> in a term (in doublequotes) that is in the scope of this variable binding, x 
> ought to automatically be bound to t:alpha.  We should not have to repeat the 
> type annotation of x.
>
> If that's what you did, Petros, that's fabulous, and will cut down on more 
> type annotations than my consider/case would.  Freek's miz3 does something 
> like this I think, and I haven't figured out how he does it.  Can you comment 
> on your Isabelle Light code?  I'll go read your paper with Jacques Fleuriot
> link.springer.com/chapter/10.1007%2F978-3-642-16242-8_40

The paper gives a good overview of what this library was built for.
There is also a small README file in the library folder and the code is 
commented throughout.

The main effort was to emulate Isabelle's procedural natural deduction 
tactics rule, erule, drule, and frule. In this, similarly to you, I 
wanted to get rid of unnecessary type annotations in situations where 
the type of an expression that is being provided by the user can be 
determined by the context of the particular proof step.

I am not sure to what extent this is being done in INTRO_TAC and 
DESTRUCT_TAC as I haven't used or seen these tactics in detail (yet).

It is very easy to write versions of X_CHOOSE_TAC, X_CHOOSE_THEN, 
X_GEN_TAC, and EXISTS_TAC that do this kind of type instantiation using 
the try_type function from my previous email.


Regards,

Petros




-- 
Petros Papapanagiotou
CISA, School of Informatics
The University of Edinburgh

Email: p.papapanagio...@sms.ed.ac.uk

---
  The University of Edinburgh is a charitable body, registered in
  Scotland, with registration number SC005336.

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Freek, can you explain your code miz3.ml in really broad detail?  I think 
miz3.ml is an amazing accomplishment, but I don't understand it, and much of 
what I don't understand involves parsing.  

Petros, thanks for your new stuff, which I haven't understood yet.  I ran your 
code, which works: 

needs "IsabelleLight/make.ml";;

prove (` (?x . x = 5) ==> ?y . y > 4`,
DISCH_THEN (X_MATCH_CHOOSE_TAC `x`) THEN
EXISTS_TAC `x:num` THEN
FIRST_ASSUM SUBST1_TAC THEN ARITH_TAC);;

But I can't figure out from this example what X_MATCH_CHOOSE_TAC is supposed to 
be doing.  I can prove your result a different way: 

let TACtoThmTactic tac = fun  ths -> MAP_EVERY MP_TAC ths THEN tac;;
let ARITH_thmTAC = TACtoThmTactic ARITH_TAC;;

let PetrosExample = prove
 (`(?x . x = 5) ==> ?y . y > 4`,
  REWRITE_TAC[LEFT_IMP_EXISTS_THM] THEN
  INTRO_TAC "!x; x5" THEN
  EXISTS_TAC `x:num` THEN
  HYP ARITH_thmTAC "x5" []);;


Consequence: each time you write `bla`, you automatically go through the 
whole process of type inference.

Vincent, thanks for explaining this, and for your new stuff, which I haven't 
understood.  I had thought that preterm_of_term wouldn't go through type 
inference, but it does:

# preterm_of_term `&1 + 1`;;

  Exception: Failure "typechecking error (overload resolution)".

So I was wrong.  Thanks.  However, 

1) maybe we can use preterm_of_term if we don't have typechecking error, and 

2) I'm sure it's possible to avoid this problem, because miz3 does so.  I 
usually start an HOL session with 

ocaml
#use "hol.ml";;

#load "unix.cma";;
loadt "miz3/miz3.ml";;

and this allows me to evaluate miz3 code, and it doesn't (much) interfere with 
straight HOL Light code.  

Let me give you a dumb example of what I don't understand about miz3 parsing.  
Evaluating this code 

`;
  let P be point;
  let l be point_set;
  assume Line l /\ P IN l [H1];
  thus ? Q. Q IN l /\ ~(P = Q)

  proof
consider A B such that
A IN l /\ B IN l /\ ~(A = B)[l_line] by H1, I2;
cases;
suppose P = A;
qed by -, l_line;
suppose ~(P = A);
qed by -, l_line;
  end;
`;;

yields the error message 
Error: Unbound value parse_qproof

But first evaluate

#load "unix.cma";;
loadt "miz3/miz3.ml";;

and then evaluate the above, and you'll get sensible miz3 output, i.e. a lot of 
errors because none of the terms have been defined.  So I know that it's 
possible to get the parser to do interesting nonstandard things.  I just don't 
know how to do them myself.  

-- 
Best,
Bill 

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Le 02.04.13 21:19, Bill Richter a écrit :
> Vincent, thanks for explaining this, and for your new stuff, which I haven't 
> understood.  I had thought that preterm_of_term wouldn't go through type 
> inference, but it does:
>
> # preterm_of_term `&1 + 1`;;
>
>Exception: Failure "typechecking error (overload resolution)".
>
> So I was wrong.  Thanks.
No you were right, preterm_of_term indeed does no inference.
Here the exception does not occur in preterm_of_term but in the parsing 
of `&1 + 1`.
Actually, if you just type`&1 + 1`, you still get the exception:

# `&1 + 1`;;

Exception: Failure "typechecking error (overload resolution)".

To understand better let's say that you can turn any expression of the form:
`bla`
into:
parse_term "bla"

So your above example:
preterm_of_term `&1 + 1`;;
is turned into:

  preterm_of_term (parse_term "&1 + 1");;

In the above, the type checking occurs in the call to parse_term, not in 
preterm_of_term.


In addition, parse_term can be decomposed (roughly) as:
term_of_preterm o retypecheck [] o parse_preterm o lex o explode
where:
- explode simply turns a string into a list of characters
- lex turns this list of characters into a list of lexcodes (i.e., a 
list of atomic words w.r.t. HOL Light understanding of what is a word)
- parse_preterm turns this into a preterm (i.e., almost like a term but 
without any type checking)
- retypecheck checks the types
- term_of_preterm gets the term out the preterm
As you see, type checking only appears after parse_preterm.
That's why in my last email, the hack I suggested was to do the work 
only until this phase.

-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Vincent, but I really was wrong, I just made an error in describing my 
mistake.  You're right (and I knew it):

   if you just type `&1 + 1`, you still get the exception:

My error was thinking that the presence of preterm_of_term would keep `&1 + 1` 
from being evaluated, and that was wrong.  I learned about parse_term from 
Freek, as a way to emulate backquotes into miz3, which doesn't allow them.  But 
outside of miz3, doesn't parse_term mean the same as backquotes? 

-- 
Best,
Bill 

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Le 02.04.13 21:46, Bill Richter a écrit :
> Thanks, Vincent, but I really was wrong, I just made an error in describing 
> my mistake.  You're right (and I knew it):
>
> if you just type `&1 + 1`, you still get the exception:
>
> My error was thinking that the presence of preterm_of_term would keep `&1 + 
> 1` from being evaluated, and that was wrong.  I learned about parse_term from 
> Freek, as a way to emulate backquotes into miz3, which doesn't allow them.  
> But outside of miz3, doesn't parse_term mean the same as backquotes?
>
Yes.

(note: I know almost nothing about miz3)

-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Vince, this is great!  May I ask you to learn about miz3?  With a little work, 
I think miz3.ml can be turned into a general purpose interface for HOL Light, 
with much improved readability, with fewer type annotations in particular.  The 
part of miz3.ml we don't need is what I think is the hard part: the "by" 
justifications, dealing with a "by" list, which is order-independent and 
comma-separated.  We can just use normal HOL Light proofs.  The way to learn 
about miz3 is to look at Freek's hol_light/miz3/miz3.ml and my example code 
hol_light/Examples/inverse_bug_puzzle_miz3.ml and  
hol_light/RichterHilbertAxiomGeometry/HilbertAxiom.ml.  Anyway: 

   Then each time you type something that starts with a semi-colon
   (e.g., `;blabla`), you obtain the intermediate preterm instead of
   the term.  If I'm right, this means that you don't have the
   backslash problem anymore (since we're going through the John's
   parser), but not all the types are infered since we didn't go
   through the type checking phasis yet. And you could define a
   function disj_preterm easily (once you built your preterm, it is
   easy to get the term by using term_of_preterm, generally composed
   with retypecheck in order to check that the final term is well
   typed).

Thanks!  You're explaining something about miz3 I never understood.  Let's look 
at thm in inverse_bug_puzzle_miz3.ml, which has no unnecessary type 
annotations: 

let Noncollinear_2Span = thm `;
  let u v w be real^2;
  assume ~collinear  {vec 0,v,w}[H1];
  thus ? s t. s % v + t % w = u

  proof
!n r. ~(r < n)  /\  r <= MIN n n  ==>  r = n [easy_arith] by ARITH_RULE;
~(w$1 * v$2 = v$1 * w$2) [H1'] by H1, COLLINEAR_3_2Dzero;
consider M such that
M = transp(vector[v;w]):real^2^2 [Mexists];
det M = v$1 * w$2 - w$1 * v$2 by -, DIMINDEX_2, SUM_2, 
TRANSP_COMPONENT, VECTOR_2, LAMBDA_BETA, ARITH, CART_EQ, FORALL_2, DET_2;
~(det M = &0) by -, H1', REAL_ARITH;
consider x s t such that
M ** x = u /\ s = x$1 /\ t = x$2 by -, easy_arith, DET_EQ_0_RANK, 
RANK_BOUND, MATRIX_FULL_LINEAR_EQUATIONS;
 v$1 * s + w$1 * t = u$1  /\  v$2 * s + w$2 * t = u$2 by Mexists, -, 
SIMP_TAC[matrix_vector_mul; DIMINDEX_2; SUM_2; TRANSP_COMPONENT; VECTOR_2; 
LAMBDA_BETA; ARITH; CART_EQ; FORALL_2] THEN MESON_TAC[];
s % v + t % w = u by -, REAL_MUL_SYM, VECTOR_MUL_COMPONENT, 
VECTOR_ADD_COMPONENT, VEC2_TAC;
  qed by -;
`;;
 
The function thm is applied to a term that begins with a semicolon!  Just as 
you said!  And maybe as Freek said, we'd be better to use a different 
character, and I see where you use the semicolon, in the if String.sub s 0 1 = 
";":

   let quotexpander s =
  if String.sub s 0 1 = ":" then
"parse_type \""^
(String.escaped (String.sub s 1 (String.length s - 1)))^"\""
  else if String.sub s 0 1 = ";" then
"(fst o parse_preterm o lex o explode) \""^
(String.escaped (String.sub s 1 (String.length s - 1)))^"\""
  else "parse_term \""^(String.escaped s)^"\"";;

OK, I'll go play with that!  I hate to be picky, but 

1) Freek does not use quotexpander in miz3.ml, and 

2) Is there any way to get rid of the initial semicolon?

-- 
Best,
Bill 

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Le 02.04.13 22:33, Bill Richter a écrit :
> Vince, this is great!  May I ask you to learn about miz3?
Well, it's on my TODO list, but not in the short term...
>   With a little work, I think miz3.ml can be turned into a general purpose 
> interface for HOL Light, with much improved readability, with fewer type 
> annotations in particular.
I work on this too (see, e.g., the module I refered too previously, or 
the tactics that I regularly present on this mailing list), but I 
generally prefer the usual tactic style rather than the declarative style.
> Then each time you type something that starts with a semi-colon
> (e.g., `;blabla`), you obtain the intermediate preterm instead of
> the term.  If I'm right, this means that you don't have the
> backslash problem anymore (since we're going through the John's
> parser), but not all the types are infered since we didn't go
> through the type checking phasis yet. And you could define a
> function disj_preterm easily (once you built your preterm, it is
> easy to get the term by using term_of_preterm, generally composed
> with retypecheck in order to check that the final term is well
> typed).
>
> Thanks!  You're explaining something about miz3 I never understood. (...)
> The function thm is applied to a term that begins with a semicolon!
> Just as you said!
Wait, this is absolutely random: I don't know anything about miz3, so I 
don't know what the semicolon represents w.r.t miz3 internals.
I just happened to use a semicolon because I needed a way to distinguish 
from usual quotations and it was close to a colon (used for type 
quotations), but it has nothing to do (a priori) with miz3 semicolon.

> And maybe as Freek said, we'd be better to use a different character, and I 
> see where you use the semicolon, in the if String.sub s 0 1 = ";":
Exactly.
> OK, I'll go play with that!  I hate to be picky, but
>
> 1) Freek does not use quotexpander in miz3.ml
Again, I don't know anything about miz3 (and don't have any time to 
spend on it right now) so maybe he's using a trick that I didn't think of.

> 2) Is there any way to get rid of the initial semicolon?

Well you just need a way to make a distinction with usual term quotations 
(`bla`) and type quotations (`:bla`).
You can either find another prefix character (e.g., `'bla`) or a suffix one 
(e.g., `bla.`) (I find the ending dot cool too), or any exotic way if you like 
(e.g., a '$' sign in the 4th position, or a # sign at every prime number 
position, well whatever you like...).

Cheers,

-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Vince!  Can you remind me about your module & tactics that improve 
readability, with fewer type annotations?  

   I generally prefer the usual tactic style rather than the
   declarative style.

I don't tend to think these words are too helpful.  The important words are 
readable and powerful (rather than declarative and procedural), and we want 
both.  My code hol_light/Examples/inverse_bug_puzzle_tac.ml uses tactics, and I 
think the proofs are quite readable if you first turn it into an interactive 
proof, evaluate it, and look at the output.   It's very similar to 
hol_light/Examples/inverse_bug_puzzle_miz3.ml, which is however a lot more 
readable if you just read the code.  So what I want is to make 
inverse_bug_puzzle_tac.ml more readable without interactive/evaluation.  Isn't 
that the sort of thing you're doing? 

-- 
Best,
Bill 

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Le 02.04.13 23:10, Bill Richter a écrit :
> Thanks, Vince!  Can you remind me about your module & tactics that improve 
> readability, with fewer type annotations?
To remove type annotations, see the Q-like module at 
http://users.encs.concordia.ca/~vincent/Software.html
(note that this is present by default in HOL4).
For the tactics, see my messages on this mailing list.
But I'm preparing something more general and better that I'll release 
within 2 months, maybe it will be satisfying to you...

> I generally prefer the usual tactic style rather than the
> declarative style.
>
> I don't tend to think these words are too helpful.  The important words are 
> readable and powerful (rather than declarative and procedural), and we want 
> both.  My code hol_light/Examples/inverse_bug_puzzle_tac.ml uses tactics, and 
> I think the proofs are quite readable if you first turn it into an 
> interactive proof, evaluate it, and look at the output.   It's very similar 
> to hol_light/Examples/inverse_bug_puzzle_miz3.ml, which is however a lot more 
> readable if you just read the code.  So what I want is to make 
> inverse_bug_puzzle_tac.ml more readable without interactive/evaluation.  
> Isn't that the sort of thing you're doing?
Haha, no: my proofs are unreadable without the interactive/evaluation!
And this is where I say that I disagree with what is usually presented 
as the declarative style (I think miz3 is more than just a usual 
declarative style though):
I don't believe that scripts should look like mathematical proofs. I 
believe that there should be powerful tactics which would correspond to 
"big steps" in a proof.
But I want the outcome of these big steps to be obtained by interaction 
with the machine, instead of being given explicitly by the human.
I will hopefully write a paper on this and explain my views and the 
underlying reasons in more details.

Cheers,

-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Vincent, you gave me a nice exercise which I'll try to work, but it dawned on 
me that we can't use that unless we permanently change the parser.  E.g. every 
time I use miz3, I have to change the parser for that entire HOL Light session. 
 The same thing goes for your nice hack of quotexpander: it hold for the entire 
HOL Light session.  Is that right?  In that case, I think it would not be a 
good idea to install that in HOL Light, I think, as the benefit so far 
(improving case & consider a bit) is too low.  I think the benefit of changing 
the parser permanently would be high enough if we could always infer the type 
of a variable in the scope of a variable binding.  

Petros, I have some understanding now of your X_MATCH_CHOOSE_TAC: the variable 
x' doesn't need a type annotation that X_CHOOSE_TAC would need, because it 
infers the type from the existential statement xth by 
xtm = concl xth
x,bod = dest_exists xtm
(type_of x)
Is that more or less correct?  I know I'm missing a lot of details.  I couldn't 
understand how rule_tac worked.  I didn't understand much of your Isabelle 
Light paper, so I wonder if you can try to apply your skills to my problems.  
First, I'd like to be able to pluck the type of a variable out of the 
"environment".  I don't think you're doing that.  I think you can only infer 
the type of a variable in very specific circumstances.  Let's fix the manual 
example for X_CHOOSE_TAC:

g `(?y. x = y + 2) ==> x < x * x`;;
e(DISCH_THEN(X_CHOOSE_TAC `d:num`));;
e(ASM_REWRITE_TAC[] THEN ARITH_TAC);;

needs "IsabelleLight/make.ml";;
g `(?y. x = y + 2) ==> x < x * x`;;
e(DISCH_THEN(X_MATCH_CHOOSE_TAC `d`));;
e(ASM_REWRITE_TAC[] THEN ARITH_TAC);;

So we got rid of a type annotation :num, but we inferred it from something 
nearby, the (?y. x = y + 2) that we just discharged.  Is that right?  Well, how 
about something else nearby.  How about we try to define a function consider of 
type 
term -> string -> term -> term
so that 
consider `x` "such that" `t`;;
would evaluate to the term
`?x. t`
and x would not be typed, but would infer its type from the term `t`.  Can you 
do that?  If we know that a variable x occurs free in a term, can you access 
the type of x by IsabelleLight techniques?

-- 
Best,
Bill 

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

 Bill Richter :

> Vincent, you gave me a nice exercise which I'll try to work, but it dawned on 
> me that we can't use that unless we permanently change the parser.  E.g. 
> every time I use miz3, I have to change the parser for that entire HOL Light 
> session.  The same thing goes for your nice hack of quotexpander: it hold for 
> the entire HOL Light session.  Is that right?  In that case, I think it would 
> not be a good idea to install that in HOL Light, I think, as the benefit so 
> far (improving case & consider a bit) is too low.  I think the benefit of 
> changing the parser permanently would be high enough if we could always infer 
> the type of a variable in the scope of a variable binding.  

Hi Bill,

the change is very small actually. The only non backward compatible change is 
that every usual term starting with ";" (or whatever other symbol that you 
decide to use) will not be parsed as it would have been before the change. But 
the chances that a usual HOL term starts with ";" is extremely low (actually I 
would even not be surprised if it did not parse at all) so you are not losing a 
lot if any. Now we said that ";" is a bad choice because miz3 already uses it, 
but many other symbols would have this property, " ' " for instance or the 
ending " . ".

V.
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

On 04/04/2013 03:55, Bill Richter wrote:
> Petros, I have some understanding now of your X_MATCH_CHOOSE_TAC: the 
> variable x' doesn't need a type annotation that X_CHOOSE_TAC would need, 
> because it infers the type from the existential statement xth by
> xtm = concl xth
> x,bod = dest_exists xtm
> (type_of x)
> Is that more or less correct?  I know I'm missing a lot of details.  I 
> couldn't understand how rule_tac worked.  I didn't understand much of your 
> Isabelle Light paper, so I wonder if you can try to apply your skills to my 
> problems.  First, I'd like to be able to pluck the type of a variable out of 
> the "environment".  I don't think you're doing that.  I think you can only 
> infer the type of a variable in very specific circumstances.  Let's fix the 
> manual example for X_CHOOSE_TAC:
>
> g `(?y. x = y + 2) ==> x < x * x`;;
> e(DISCH_THEN(X_CHOOSE_TAC `d:num`));;
> e(ASM_REWRITE_TAC[] THEN ARITH_TAC);;
>
> needs "IsabelleLight/make.ml";;
> g `(?y. x = y + 2) ==> x < x * x`;;
> e(DISCH_THEN(X_MATCH_CHOOSE_TAC `d`));;
> e(ASM_REWRITE_TAC[] THEN ARITH_TAC);;
>
> So we got rid of a type annotation :num, but we inferred it from something 
> nearby, the (?y. x = y + 2) that we just discharged.  Is that right?  Well, 
> how about something else nearby.


Yes that's exactly right.


> How about we try to define a function consider of type
> term -> string -> term -> term
> so that
> consider `x` "such that" `t`;;
> would evaluate to the term
> `?x. t`
> and x would not be typed, but would infer its type from the term `t`.  Can 
> you do that?  If we know that a variable x occurs free in a term, can you 
> access the type of x by IsabelleLight techniques?
>

Yes you can, and I actually had to do that for the *rule_tac tactics.

Here you go:


let try_type tp tm =
try inst (type_match (type_of tm) tp []) tm
with Failure _ -> tm;;

(* Check if two variables match allowing only type instantiations: *)
let vars_match tm1 tm2 =
   let inst = try term_match [] tm1 tm2 with Failure _ -> [],[tm2,tm1],[] in
 match inst with
[],[],_ -> tm2
   | _  -> failwith "vars_match: no match";;

let consider:(term -> string -> term -> term) =
 fun x _ t ->
   (* Find the type of a matching variable in t. *)
   let tp = try type_of (tryfind (vars_match x) (frees t))
   with Failure _ ->
warn true ("consider: `" ^ string_of_term x ^ "` could not be found in 
`" ^ string_of_term t ^ "`") ;
type_of x in
(* Try to force x to type tp. *)
   let x' = try_type tp x in
mk_exists (x',t);;



Examples:

# consider `x` "such that" `x >0`;;
val it : term = `?x. x > 0`

# (type_of o fst o dest_exists) it;;
val it : hol_type = `:num`

# consider `y` "any string can go here!" `x >0`;;
Warning: consider: `y` could not be found in `x > 0`
val it : term = `?y. x > 0`


There are some (extreme) cases where you can run into "trouble" with 
this. In HOL Light it is possible to construct a term t that contains 
two variables `x` with different types. These are treated as two 
independent variables, and the code above will use the type of the first 
free one it encounters.

Regards,

Petros


-- 
Petros Papapanagiotou
CISA, School of Informatics
The University of Edinburgh

Email: p.papapanagio...@sms.ed.ac.uk

---
  The University of Edinburgh is a charitable body, registered in
  Scotland, with registration number SC005336.

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Vincent!  I definitely have to work your exercise now.  Two dumb 
questions:
1) how do I get quotexpander to turn off type inference by putting a period at 
the end of the terms?  Of all your possibilities, that's the one I like best.  
2)Doesn't Ocaml use the "applicative order application" so that if I type
cases "case_string" [`t1`; `t2`; `t3`];;
that I can not defined cases by 
let case str termlist = 
  let quotexpander = 
  [do the cases construction] 
  let quotexpander = original version of quotexpander;;
Because Ocaml will evaluate all the arguments independently?  

Petros, your consider and *rule_tac tactics code looks excellent!  I noticed 
one simple thing:  X_GEN_TAC in tactics.ml also uses type_of to infer types.  
It's a dumb of me, but I didn't think you could use type_of in Ocaml code.   

-- 
Best,
Bill 

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Petros, your consider code is a huge step toward what I need.  I'll try to 
finish modifying your code tonight.  Here's the string version I have now, and 
below that is an earlier term version: 

let consider vars_t prfs lab =
  let len = String.length vars_t in
  let rec findSuchThat = function
  n -> if String.sub vars_t n 9 = "such that" then n
  else findSuchThat (n + 1) in
  let n = findSuchThat 1 in
  let vars = String.sub vars_t 0 (n - 1) and
  t = String.sub vars_t (n + 9) (len - n - 9) in
  let tm = parse_term ("?" ^ vars ^ ". " ^ t) in
  match prfs with
   p::ps -> (warn (ps <> []) "consider: additional subproofs ignored";
   SUBGOAL_THEN tm (DESTRUCT_TAC ("@" ^ vars ^ "." ^ lab))
   THENL [p; ALL_TAC])
   | [] -> failwith "consider: no subproof given";;

let CONSIDER_TAC xl lab t prfs =
  match prfs with
   p::ps -> (warn (ps <> []) "CONSIDER_TAC: additional subproofs ignored";
   let tm = itlist (curry mk_exists) xl t in
   SUBGOAL_THEN tm ((EVERY_TCL (map X_CHOOSE_THEN xl)) (LABEL_TAC lab)) 
   THENL [p; ALL_TAC])
   | [] -> failwith "CONSIDER_TAC: no subproof given";;

It shouldn't be hard to fuse this this with your code:

let try_type tp tm =
try inst (type_match (type_of tm) tp []) tm
with Failure _ -> tm;;

(* Check if two variables match allowing only type instantiations: *)
let vars_match tm1 tm2 =
   let inst = try term_match [] tm1 tm2 with Failure _ -> [],[tm2,tm1],[] in
 match inst with
[],[],_ -> tm2
   | _  -> failwith "vars_match: no match";;

let consider:(term -> string -> term -> term) =
 fun x _ t ->
   (* Find the type of a matching variable in t. *)
   let tp = try type_of (tryfind (vars_match x) (frees t))
   with Failure _ ->
warn true ("consider: `" ^ string_of_term x ^ "` could not be found in 
`" ^ string_of_term t ^ "`") ;
type_of x in
(* Try to force x to type tp. *)
   let x' = try_type tp x in
mk_exists (x',t);;

If you can't bear not to work on it, you'll probably beat me to it.  

I really like your code, and I wonder if you can't do even better.  I feel that 
we should never have to make an explicit type annotation of a variable that is 
in the scope of a typed variable.  Assuming that's the right terminology.  So 
there ought to be an "environment" out of which variable typing can be pulled.  
Obviously the values of the variables, once they're typed correctly, can be 
pulled out of this "environment".  

BTW maybe you can post here the point of the IsabelleLight code you and Jacques 
wrote.  I think the MizarLight stuff doesn't require you to understand Mizar, 
it's all explained in the HOL Light tutorial in the section "Towards more 
readable proofs", but maybe IsabelleLight requires you to understand Isabelle, 
and I don't. 

-- 
Best,
Bill 

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Petros, your code worked great, and I now have consider working the way I 
wanted, included below.  I couldn't use it for cases, and that's a good place 
to try Vincent's quotexpander idea.  I put your code into BuildExist, and 
borrowed some of Marco Maggesi's HYP ideas to turn a string into a list of term 
variables.  Below I'll give an example, my version of the HOL Light tutorial 
readable proof that the square root of 2 is irrational.  Perhaps you'll have a 
suggestion.  I don't quite know what all your code means yet.  

-- 
Best,
Bill 

let TACtoThmTactic tac = fun  ths -> MAP_EVERY MP_TAC ths THEN tac;;

let NUM_RING_thmTAC = TACtoThmTactic (CONV_TAC NUM_RING);;

let ARITH_thmTAC = TACtoThmTactic ARITH_TAC;;

let so = fun tac -> FIRST_ASSUM MP_TAC THEN tac;;

let BuildExist x t =
  let try_type tp tm =
try inst (type_match (type_of tm) tp []) tm
with Failure _ -> tm in

  (* Check if two variables match allowing only type instantiations: *)
  let vars_match tm1 tm2 =
let inst = try term_match [] tm1 tm2 with Failure _ -> [],[tm2,tm1],[] in
  match inst with
[],[],_ -> tm2
  | _  -> failwith "vars_match: no match" in

  (* Find the type of a matching variable in t. *)
  let tp = try type_of (tryfind (vars_match x) (frees t))
  with Failure _ ->
  warn true ("BuildExist: `" ^ string_of_term x ^ "` not be found in
  `" ^ string_of_term t ^ "`") ;
  type_of x in
  (* Try to force x to type tp. *)
  let x' = try_type tp x in
  mk_exists (x',t);;

let consider vars_SuchThat t prfs lab =
  (* Functions ident and parse_using borrowed from HYP in tactics.ml *)
  let ident = function
  Ident s::rest when isalnum s -> s,rest
| _ -> raise Noparse in
  let parse_using = many ident in
  let rec findSuchThat = function
  n -> if String.sub vars_SuchThat n 9 = "such that" then n
  else findSuchThat (n + 1) in
  let n = findSuchThat 1 in
  let vars = String.sub vars_SuchThat 0 (n - 1) in
  let xl = map parse_term ((fst o parse_using o lex o explode) vars) in
  let tm = itlist BuildExist xl t in
  match prfs with
p::ps -> (warn (ps <> []) "consider: additional subproofs ignored";
SUBGOAL_THEN tm (DESTRUCT_TAC ("@" ^ vars ^ "." ^ lab))
THENL [p; ALL_TAC])
  | [] -> failwith "consider: no subproof given";;

let cases sDestruct disjthm tac =
  SUBGOAL_TAC "" disjthm tac THEN FIRST_X_ASSUM
  (DESTRUCT_TAC sDestruct);;

let NSQRT_2 = prove
 (`!p q. p * p = 2 * q * q ==> q = 0`,
  MATCH_MP_TAC num_WF THEN
  INTRO_TAC "!p; A; !q; B"  THEN
  SUBGOAL_TAC "" `EVEN(p * p) <=> EVEN(2 * q * q)` 
  [HYP MESON_TAC "B" []] THEN
  SUBGOAL_TAC "" `EVEN(p)` [so (MESON_TAC [ARITH; EVEN_MULT])] THEN
  consider "m such that" `p = 2 * m`
  [so (MESON_TAC [EVEN_EXISTS])] "C" THEN
  cases "qp | pq" `(q:num) < p  \/  p <= q` [ARITH_TAC] THENL
  [SUBGOAL_TAC "" `q * q = 2 * m * m ==> m = 0` [HYP MESON_TAC "qp A" []] THEN
  so (HYP NUM_RING_thmTAC "B C" []);
  SUBGOAL_TAC "" `p * p <= (q:num) * q` [so (MESON_TAC [LE_MULT2 ])] THEN
  SUBGOAL_TAC "" `q * q = 0` [so (HYP ARITH_thmTAC "B" [])] THEN
  so (NUM_RING_thmTAC [])]);;

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

On 05/04/2013 04:55, Bill Richter wrote:
> Petros, your consider code is a huge step toward what I need.  I'll try to 
> finish modifying your code tonight.

I am glad you found it helpful!


>
> I really like your code, and I wonder if you can't do even better.  I feel 
> that we should never have to make an explicit type annotation of a variable 
> that is in the scope of a typed variable.  Assuming that's the right 
> terminology.  So there ought to be an "environment" out of which variable 
> typing can be pulled.  Obviously the values of the variables, once they're 
> typed correctly, can be pulled out of this "environment".

Yes that would be something interesting to implement.
For example, when saying "consider x such that t", perhaps "t" contains 
other variables that are mentioned in the current proof context. It 
would be nice if you didn't have to annotate them with their types either.

In Isabelle Light, the proof context is merely the current goal, so I am 
using this function (from IsabelleLight/support.ml) to match and 
retrieve the types of the "environment":

let gl_frees : goal -> term list =
   fun (asl,w) -> itlist (union o thm_frees o snd) asl (frees w);;

I am not sure if this is as straightforward in a declarative style.


>
> BTW maybe you can post here the point of the IsabelleLight code you and 
> Jacques wrote.  I think the MizarLight stuff doesn't require you to 
> understand Mizar, it's all explained in the HOL Light tutorial in the section 
> "Towards more readable proofs", but maybe IsabelleLight requires you to 
> understand Isabelle, and I don't.
>

I will try and do this as concisely as possible.

There are two main reasons why we implemented Isabelle Light:

1) Manipulation of assumptions in traditional HOL proofs is fairly 
limited, especially for novice users. This is simply not the "HOL style" 
of proving things.

For example, assume a novice user does this:
g `P ==> (P==>Q) ==> Q`;;
e (REPEAT DISCH_TAC);;

Even though the proof is a straightforward application of modus ponens 
on the assumptions, it is not that straightforward how they (being a 
novice user) would do this in HOL Light:

e (FIRST_ASSUM (fun x -> FIRST_ASSUM (fun y -> ACCEPT_TAC (MP x y;;


2) There is *at least* one tactic (backwards) and one rule (forward) for 
each natural deduction inference step in HOL Light. These are too many! 
(I still keep a printed copy of VERYQUICK_REFERENCE.txt pinned on my 
office wall, and that is far from containing all the available and 
useful tactics.)


In Isabelle's procedural mode, you can express, prove, and use any 
custom made inference rule, both forwards and backwards, and manipulate 
the assumptions in a very precise manner using the 4 *rule tactics:

rule: for backward/introduction steps
drule, frule: for forward/destruction steps
erule: for elimination (simultaneous forward and backward) steps
(for more details see Section 3.2 of our paper [1]).

Each of those can be used with any custom rule described using 
Isabelle's meta-logic. Inspecting rules is more straightforward than 
remembering tactics. Even more so, proving new rules is *much* easier 
than creating new tactics.

You only need to remember the functionality of 4 tactics and the names 
of the rules.

Also, their *rule_tac counterparts allow you to partially instantiate a 
rule using expressions from the context in order to have a more precise 
application of the rule (for example in order to resolve ambiguity 
between two equally matching assumptions in a forward rule).


In Isabelle Light, we emulate Isabelle's meta-logic (with a few 
limitations of course), the four tactics, and a few other useful features.

The proof of the previous example can be completed as follows:
(* mp is the modus ponens rule: |- (p ==> q) ===> p ===> q *)
e (drule mp);;
e (assumption);;
e (assumption);;

Avoiding explicit type annotations in the *rule_tac instantiations is 
what lead to our current discussion!

As an example, in the proof above you could do:
e (drule_tac [`p`,`P`] mp);;
which means "instantiate variable p in the mp rule with expression P in 
the goal, then use it as a destruction/forward rule)".

Notice the lack of typing information (`:bool`) for `p` and `P`, which 
would otherwise make the script much more cumbersome. The type of `p` is 
determined by the rule, and the type of `P` by the goal/context.



Regards,

Petros



[1] Papapanagiotou, P. and Fleuriot, J.: An Isabelle-Like Procedural 
Mode for HOL Light. Logic for Programming, Artificial Intelligence, and 
Reasoning, pp 565-580, Springer (2010)


-- 
Petros Papapanagiotou
CISA, School of Informatics
The University of Edinburgh

Email: p.papapanagio...@sms.ed.ac.uk

---
  The University of Edinburgh is a charitable body, registered in
  Scotland, with registration number SC005336.

--
Minimize network downtime and maximize team effectiveness.
Reduce network managem

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Petros, I think this is a pretty good exercise for a novice (unless they use 
MESON_TAC[], which solves it instantly): 

   g `P ==> (P==>Q) ==> Q`;;
   e (REPEAT DISCH_TAC);;
   e (FIRST_ASSUM (fun x -> FIRST_ASSUM (fun y -> ACCEPT_TAC (MP x y;;

I'm still kind of a novice myself, so I tried to solve it using John and 
Marco's readable code ideas: 

let USE2THEN a b thm2tactic = 
  USE_THEN a (fun x -> (USE_THEN b (fun y -> thm2tactic x y)));;

g `P ==> (P==>Q) ==> Q`;;
e(INTRO_TAC "p; pq");;
e(USE2THEN "pq" "p" (fun x y -> ACCEPT_TAC (MP x y)));;

I'd say this is simpler because my
fun x y -> ACCEPT_TAC (MP x y)
is pretty simple, just a version of 
ACCEPT_TAC o MP, and we can write USE2THEN ourselves, and explain to the novice 
how to use USE2THEN and that USE_THEN is explained in the HOL Light reference 
manual.   Probably your fix is even simpler.

Thanks for your explanation of the 4 * rule tactics, but I'm sorry to say that 
I'm not really getting it.  I'll try to read your paper with Jacques
An Isabelle-Like Procedural Mode for HOL Light
more carefully, but it would really help if I had an example that I already 
understood.  I wonder if you could translate part of 
Examples/inverse_bug_puzzle_tac.ml
from the latest subversion (159) into you IsabelleLight framework.  

That is, I've been using the readable code framework of John, Freek and Marco, 
but I think you and Jacques are working in a very different framework.  I'm 
already sold on your code (that's great how you can remove type annotations), 
so I expect to benefit from understanding your framework as well. 

-- 
Best,
Bill 

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Vince, you recommended replacing the lines

   let quotexpander s =
  if String.sub s 0 1 = ":" then
"parse_type \""^
(String.escaped (String.sub s 1 (String.length s - 1)))^"\""
  else "parse_term \""^(String.escaped s)^"\"";;

   in system.ml by:

   let quotexpander s =
  if String.sub s 0 1 = ":" then
"parse_type \""^
(String.escaped (String.sub s 1 (String.length s - 1)))^"\""
  else if String.sub s 0 1 = ";" then
"(fst o parse_preterm o lex o explode) \""^
(String.escaped (String.sub s 1 (String.length s - 1)))^"\""
  else "parse_term \""^(String.escaped s)^"\"";;

I couldn't get this to work.  I think you have an old version of HOL Light.  In 
the current subversion (159), or I think any subversion since Wed 2nd Jan 2013, 
system.ml reads 

   let quotexpander s =
 if s = "" then failwith "Empty quotation" else
 let c = String.sub s 0 1 in
 if c = ":" then
   "parse_type \""^
   (String.escaped (String.sub s 1 (String.length s - 1)))^"\""
 else if c = ";" then "parse_qproof \""^(String.escaped s)^"\""
 else "parse_term \""^(String.escaped s)^"\"";;

And that means, I think, that as long as we're not using miz3, we can just 
redefine parse_qproof, which is defined in hol_light/miz3/miz3.ml.  So instead 
of modifying system.ml, let's define 

let parse_qproof string = (fst o parse_preterm o lex o explode) string;;

# parse_qproof "1 + 1";;

val it : preterm =
  Combp (Combp (Varp ("+", Ptycon ("", [])), Varp ("1", Ptycon ("", []))),
   Varp ("1", Ptycon ("", [])))

# parse_qproof "&1 + 1";;

val it : preterm =
  Combp
   (Combp (Varp ("+", Ptycon ("", [])),
 Combp (Varp ("&", Ptycon ("", [])), Varp ("1", Ptycon ("", [],
   Varp ("1", Ptycon ("", [])))

So according to my understanding of quotexpander, I should get the same answer 
like this, but I don't: 

# `;&1 + 1`;;
Exception: Noparse.

What am I missing?  The only 2 places where quotexpander is ever used are in 
system.ml: the definition of quotexpander and then the next standalone line 

Quotation.add "tot" (Quotation.ExStr (fun x -> quotexpander));;

I see these Quotation functions are discussed in the Camlp4 Tutorial, and I'll 
got read up on it.  I think I understand this now: 


   In addition, parse_term can be decomposed (roughly) as:
   term_of_preterm o retypecheck [] o parse_preterm o lex o explode
   where:
   - explode simply turns a string into a list of characters
   - lex turns this list of characters into a list of lexcodes (i.e., a 
   list of atomic words w.r.t. HOL Light understanding of what is a word)
   - parse_preterm turns this into a preterm (i.e., almost like a term but 
   without any type checking)
   - retypecheck checks the types
   - term_of_preterm gets the term out the preterm
   As you see, type checking only appears after parse_preterm.
   That's why in my last email, the hack I suggested was to do the work 
   only until this phase.

In parser.ml, we have the definition 

let parse_term s =
  let ptm,l = (parse_preterm o lex o explode) s in
  if l = [] then
   (term_of_preterm o (retypecheck [])) ptm
  else failwith "Unparsed input following term";;

That means that for a good string s, 

parse_term s = (term_of_preterm o (retypecheck []) o fst o parse_preterm o lex 
o explode) s

and I think that's what you wrote.  And parse_term occurs in exactly one other 
place, in the def of quotexpander above.  So doesn't that mean that the
(fun x -> quotexpander)
line above says that parse_term is called on the string created by 
Quotation.add and Quotation.ExStr 
from a backquoted quotation?  Now all I really want is to access the string 
created this way.  I'm happy to go through term_of_preterm, as a learning 
exercise, but it seems like it would be simpler to just use this string.  

Here's a question about retypecheck, about which the manual says 

   This is the main HOL Light typechecking function. Given an
   environment env of pretype assignments for variables, it assigns a
   pretype to all variables and constants, including performing
   resolution of overloaded constants based on what type information
   there is.  Normally, this happens implicitly when a term is entered
   in the quotation parser.

I believe that other than Freek's miz3.ml etc, retypecheck is only used once, 
in parse_term, and the environment is the empty list.   In miz3.ml, Freek is 
clearly using a nonempty environment, called env'.  Why don't we learn how to 
do that ourselves?

-- 
Best,
Bill 

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___

Re: [Hol-info] Learning HOL Light

[Petros Papapanagiotou]

Hello Bill,


On 07/04/2013 05:22, Bill Richter wrote:
> I wonder if you could translate part of
> Examples/inverse_bug_puzzle_tac.ml
> from the latest subversion (159) into you IsabelleLight framework.
>

I tried a couple of the proofs: reachableNSymmetry and 
FourStepMoveABBAreach.

I have included some extra code that needs to be included because I 
implemented it recently and haven't gotten around to sending it to John yet.

I tried as much as possible not to change the proofs (I haven't read 
what they mean anyway), and simply used Isabelle Light's tools to 
perform the same steps.

Isabelle Light tactics can be used at the same level as normal HOL Light 
tactics, so it is up to you to decide what you find more elegant in each 
case. For example, (rule impI) is equivalent to DISCH_TAC and (fun x -> 
rule_tac [`a`,x] exI) is equivalent to MATCH_EXISTS_TAC.

Also, you lose some of the labelling functionality that you have from 
the recently added tactics (HYP, INTRO_TAC etc). It would take a bit of 
work to build this into Isabelle Light which I'm hoping to find some 
time to do.

Hope this helps get a better idea about the library.

As a side note, I suggest you rename your "cases" tactic because you are 
overriding the "cases" function of HOL Light 
(http://www.cl.cam.ac.uk/~jrh13/hol-light/HTML/cases.html).


Regards,

Petros


needs "IsabelleLight/make.ml";;
needs "Examples/inverse_bug_puzzle_tac.ml";;

(* Some extra code that normally belongs to Isabelle Light: *)

let try_type tp tm =
   try inst (type_match (type_of tm) tp []) tm
   with Failure _ -> tm;;

let (X_MATCH_GEN_TAC: term -> tactic),
   (X_MATCH_CHOOSE_TAC: term -> thm_tactic),
   (MATCH_EXISTS_TAC: term -> tactic) =
   let tactic_type_compatibility_check pfx e g =
 let et = type_of e in
 let g' = try_type et g in
 let gt = type_of g' in
 if et = gt then g'
 else failwith(pfx ^ ": expected type :"^string_of_type et^" but got :"^
string_of_type gt) in
   let X_MATCH_GEN_TAC x' =
 if not(is_var x') then failwith "X_GEN_TAC: not a variable" else
   fun (asl,w) ->
 let x,bod = try dest_forall w
   with Failure _ -> failwith "X_GEN_TAC: Not universally 
quantified" in
 let x'' = tactic_type_compatibility_check "X_GEN_TAC" x x' in
 let avoids = itlist (union o thm_frees o snd) asl (frees w) in
 if mem x'' avoids then failwith "X_GEN_TAC: invalid variable" else
   let afn = CONV_RULE(GEN_ALPHA_CONV x) in
   null_meta,[asl,vsubst[x'',x] bod],
   fun i [th] -> afn (GEN x'' th)
   and X_MATCH_CHOOSE_TAC x' xth =
 let xtm = concl xth in
 let x,bod = try dest_exists xtm
   with Failure _ -> failwith "X_CHOOSE_TAC: not existential" in
 let x'' = tactic_type_compatibility_check "X_CHOOSE_TAC" x x' in
 let pat = vsubst[x'',x] bod in
 let xth' = ASSUME pat in
 fun (asl,w) ->
   let avoids = itlist (union o frees o concl o snd) asl
 (union (frees w) (thm_frees xth)) in
   if mem x'' avoids then failwith "X_CHOOSE_TAC: invalid variable" else
 null_meta,[("",xth')::asl,w],
 fun i [th] -> CHOOSE(x'',INSTANTIATE_ALL i xth) th
   and MATCH_EXISTS_TAC t (asl,w) =
 let v,bod = try dest_exists w with Failure _ ->
   failwith "EXISTS_TAC: Goal not existentially quantified" in
 let t' = tactic_type_compatibility_check "EXISTS_TAC" v t in
 null_meta,[asl,vsubst[t',v] bod],
 fun i [th] -> EXISTS (instantiate i w,instantiate i t') th in
   X_MATCH_GEN_TAC,X_MATCH_CHOOSE_TAC,MATCH_EXISTS_TAC;;


(* reachableNSymmetry using Isabelle Light tactics: *)

let reachableNSymmetry = prove
(`! n. ! A B C A' B' C'. reachableN (A,B,C) (A',B',C') n  ==>
reachableN (B,C,A) (B',C',A') n  /\  reachableN (C,A,B) (C',A',B') n /\
reachableN (A,C,B) (A',C',B') n  /\  reachableN (B,A,C) (B',A',C') n /\
reachableN (C,B,A) (C',B',A') n`,
MATCH_MP_TAC num_INDUCTION THEN
simp[reachableN_CLAUSES;PAIR_EQ] THEN
allI THEN rule impI THEN REPEAT allI THEN
simp[LEFT_IMP_EXISTS_THM; FORALL_PAIR_THM] THEN
MAP_EVERY X_MATCH_GEN_TAC [`X`; `Y`; `Z`] THEN
rule impI THEN
simp[RIGHT_AND_EXISTS_THM; LEFT_AND_EXISTS_THM] THEN
MAP_EVERY (fun x -> rule_tac [`a`,x] exI) [`(Y,Z,X)`; `(Z,X,Y)`;
 `(X,Z,Y)`; `(Y,X,Z)`; `(Z,Y,X)`] THEN
simp[moveSymmetry]);;

(* Broken down version: *)

g (`! n. ! A B C A' B' C'. reachableN (A,B,C) (A',B',C') n  ==>
reachableN (B,C,A) (B',C',A') n  /\  reachableN (C,A,B) (C',A',B') n /\
reachableN (A,C,B) (A',C',B') n  /\  reachableN (B,A,C) (B',A',C') n /\
reachableN (C,B,A) (C',B',A') n`);;
e (MATCH_MP_TAC num_INDUCTION THEN simp[reachableN_CLAUSES;PAIR_EQ]);;
e allI;;
e (rule impI);;
e (REPEAT allI);;
e (simp[LEFT_IMP_EXISTS_THM; FORALL_PAIR_THM]);;
e (MAP_EVERY X_MATCH_GEN_TAC [`X`; `Y`; `Z`]);;
e (rule impI);;
e (simp[RIGHT_AND_EXISTS_THM; LEFT_AND_EXISTS_THM]);;
e (MAP_EVERY (fun x -> 

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Petros!  I hate to be an ingrate, but could you port one of my longer 
proofs to IsabelleLight?  It might help if you read section 10.1, The bug 
puzzle, of the HOL Light tutorial, or 
hol_light/Examples/inverse_bug_puzzle_tac.ml.  Thanks for telling me about 
cases: I'll change the name.   What I mainly want is to replicate in tactics 
proofs an accomplishment of Freek's in miz3.ml: maintaining an environment so 
that variables don't have to be repeatedly typed.  Are you trying to do that in 
IsabelleLight?  Freek did this, by changing the parser, and Vince has been 
advising me on how to do this myself.  Are you planning to change the parser as 
well, or does IsabelleLight have a different idea for the environment? 

   Also, you lose some of the labelling functionality that you have
   from the recently added tactics (HYP, INTRO_TAC etc). It would take
   a bit of work to build this into Isabelle Light which I'm hoping to
   find some time to do.

Excellent!  I apologize for not having read your code yet.  I just learned 
about another formalization of Tarski's axiomatic geometry, one using the proof 
assistant otter, which I know little about:
http://www.michaelbeeson.com/research/FormalTarski/index.php
Michael Beeson and Julien Narboux both got quite a bit farther than I did:
http://www.math.northwestern.edu/~richter/TarskiAxiomGeometry.ml
Does anyone know about otter, or how far Julien is on his Tarski project? 

-- 
Best,
Bill 

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Hi Bill,

(sorry for the late answer)

Le 08.04.13 23:59, Bill Richter a écrit :
> Vince, you recommended replacing the lines
>
> (...)
> I couldn't get this to work.  I think you have an old version of HOL Light.  
> In the current subversion (159), or I think any subversion since Wed 2nd Jan 
> 2013, system.ml reads
>
> let quotexpander s =
>   if s = "" then failwith "Empty quotation" else
>   let c = String.sub s 0 1 in
>   if c = ":" then
> "parse_type \""^
> (String.escaped (String.sub s 1 (String.length s - 1)))^"\""
>   else if c = ";" then "parse_qproof \""^(String.escaped s)^"\""
>   else "parse_term \""^(String.escaped s)^"\"";;

Indeed, use instead:

let quotexpander s =
   if s = "" then failwith "Empty quotation" else
   let c = String.sub s 0 1 in
   if c = ":" then
 "parse_type \""^
 (String.escaped (String.sub s 1 (String.length s - 1)))^"\""
   else if c = ";" then "parse_qproof \""^(String.escaped s)^"\""
   else if c = "'" then "(fst o parse_preterm o lex o explode) \""
 ^ String.escaped (String.sub s 1 (String.length s - 1)) ^ "\""
   else "parse_term \""^(String.escaped s)^"\"";;

I changed again the trigger character for the quotation, it is now " ' 
". So for instance:

# `'&1+1`;;
val it : preterm =
   Combp
(Combp (Combp (Varp ("&", Ptycon ("", [])), Varp ("1", Ptycon ("", 
[]))),
  Varp ("+", Ptycon ("", []))),
Varp ("1", Ptycon ("", [])))

> And that means, I think, that as long as we're not using miz3, we can just 
> redefine parse_qproof, which is defined in hol_light/miz3/miz3.ml.

Indeed, however in my opinion, it is a better long-term solution to 
modify system.ml since others might benefit from having quotations 
dedicated to preterms (as it is the case for instance in HOL4).

> So according to my understanding of quotexpander, I should get the same 
> answer like this, but I don't:
>
> # `;&1 + 1`;;
> Exception: Noparse.
>
> What am I missing?

If you have a careful look at quotexpander, you will see that, contrary 
to both other parsers, the string is passed to parse_qproof without 
removing the ";".
The problem is solved if you thus define parse_qproof as follows:

# let parse_qproof s = (fst o parse_preterm o lex o explode) (String.sub 
s 1 (String.length s - 1));;

> In parser.ml, we have the definition
>
> let parse_term s =
>let ptm,l = (parse_preterm o lex o explode) s in
>if l = [] then
> (term_of_preterm o (retypecheck [])) ptm
>else failwith "Unparsed input following term";;
>
> That means that for a good string s,
>
> parse_term s = (term_of_preterm o (retypecheck []) o fst o parse_preterm o 
> lex o explode) s
>
> and I think that's what you wrote.

Indeed.

> Here's a question about retypecheck, about which the manual says
>
> This is the main HOL Light typechecking function. Given an
> environment env of pretype assignments for variables, it assigns a
> pretype to all variables and constants, including performing
> resolution of overloaded constants based on what type information
> there is.  Normally, this happens implicitly when a term is entered
> in the quotation parser.
>
> I believe that other than Freek's miz3.ml etc, retypecheck is only used once, 
> in parse_term, and the environment is the empty list.   In miz3.ml, Freek is 
> clearly using a nonempty environment, called env'.  Why don't we learn how to 
> do that ourselves?
>
I don't get what you mean, here...

-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Vince!  It worked, once I substituted your quotexpander into system.ml 
and restarted HOL Light with
ocaml
#use "hol.ml";;

Now I can get to work on your exercise.  A few questions:  

Why didn't my attempt work?  Why did I get the error message "Exception: 
Noparse." from

let parse_qproof string = (fst o parse_preterm o lex o explode) string;;
`;&1 + 1`;;

It doesn't look that different from your fix:

else if c = ";" then "parse_qproof \""^(String.escaped s)^"\""
   else if c = "'" then "(fst o parse_preterm o lex o explode) \""

I assume my problem involves the doublequotes, which I know I don't understand. 
 But your version is fine, and 

   Indeed, however in my opinion, it is a better long-term solution to
   modify system.ml 

Sure, I was just borrowing Freek's parse_qproof line for simplicity right now 
when I don't know much, and it turned out I knew even less than I thought.

   since others might benefit from having quotations dedicated to
   preterms (as it is the case for instance in HOL4).

That's very interesting.  Can you say more?  And what do you think of Petros's 
interesting IsabelleLight possibilities?  Would it be possible, do you think, 
to maintain an environment which would get rid of repeated type annotation 
without changing the parser?  That is, I was amazed by what Petros did for my 
consider function, but I don't know how far you can do in that direction.  

-- 
Best,
Bill 

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Le 16.04.13 00:30, Bill Richter a écrit :
> Thanks, Vince!  It worked, once I substituted your quotexpander into 
> system.ml and restarted HOL Light with
> ocaml
> #use "hol.ml";;
>
> Now I can get to work on your exercise.  A few questions:
>
> Why didn't my attempt work?  Why did I get the error message "Exception: 
> Noparse." from
>
> let parse_qproof string = (fst o parse_preterm o lex o explode) string;;
> `;&1 + 1`;;
>
> It doesn't look that different from your fix:
>
> else if c = ";" then "parse_qproof \""^(String.escaped s)^"\""
> else if c = "'" then "(fst o parse_preterm o lex o explode) \""
The answer actually comes from the next line, I let you check.
The problem was that the string was passed to parse_qproof without 
removing the ";".

>
> since others might benefit from having quotations dedicated to
> preterms (as it is the case for instance in HOL4).
>
> That's very interesting.  Can you say more?
For instance, my Q-like module would benefit from using this instead of 
strings as it is doing right now.

> And what do you think of Petros's interesting IsabelleLight possibilities?
No idea, unfortunately I have only a shalow knowledge of it...
>   Would it be possible, do you think, to maintain an environment which would 
> get rid of repeated type annotation without changing the parser?
Could you be more precise?


-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Vince, thanks for fixing my error!  This works now:
let parse_qproof s = (fst o parse_preterm o lex o explode) (String.sub s 1 
(String.length s - 1));;

Now I get the same output for both 
`;&1 + 1`;;
and, with your new quotexpander, 
`'&1 + 1`;;
val it : preterm =
  Combp
   (Combp (Varp ("+", Ptycon ("", [])),
 Combp (Varp ("&", Ptycon ("", [])), Varp ("1", Ptycon ("", [],
   Varp ("1", Ptycon ("", [])))

That's great you're changing your Q-like module right now to use the parser 
instead of strings.  Let me be more precise about environments, or as precise 
as I can be with my poor understanding of how words like scope and variable 
binding are used in HOL.  Let's say in HOL Light that a free variable 
occurrence is in the scope of a variable binding.  I think the variable is 
given the bound value, if we type it correctly, but its type is not inferred.  
I think the type ought to be inferred, and that's what Freek does in miz3.ml, 
by changing the parser, partly with his parse_qproof line in quotexpander.

-- 
Best,
Bill 

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Le 16.04.13 00:55, Bill Richter a écrit :
> Vince, thanks for fixing my error!  This works now:
> let parse_qproof s = (fst o parse_preterm o lex o explode) (String.sub s 1 
> (String.length s - 1));;
>
> Now I get the same output for both
> `;&1 + 1`;;
> and, with your new quotexpander,
> `'&1 + 1`;;
> val it : preterm =
>Combp
> (Combp (Varp ("+", Ptycon ("", [])),
>   Combp (Varp ("&", Ptycon ("", [])), Varp ("1", Ptycon ("", [],
> Varp ("1", Ptycon ("", [])))
>
> That's great you're changing your Q-like module right now to use the parser 
> instead of strings.
I'll do it if the new preterm parser gets integrated in HOL Light.
> Let me be more precise about environments, or as precise as I can be with my 
> poor understanding of how words like scope and variable binding are used in 
> HOL.  Let's say in HOL Light that a free variable occurrence is in the scope 
> of a variable binding.  I think the variable is given the bound value, if we 
> type it correctly, but its type is not inferred.
Could you give an example?
>


-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Vince!  Here's an example of a free variable occurrence in the scope of 
a variable binding whose type is not inferred, from 
hol_light/Examples/inverse_bug_puzzle_tac.ml.  I picked a long proof so you can 
clearly see.  I apologize is my ML-like terminology isn't correct in HOL: 

let reachableN_CLAUSES = prove
 (`! p p'. (reachableN p p' 0  <=>  p = p') /\
  ! n. reachableN p p' (SUC n)  <=>  ? q. reachableN p q n  /\ move q p'`,
  INTRO_TAC "!p p'" THEN
  consider "s0 such that" `s0 =  \m:num. p':triple` [MESON_TAC[]] "s0exists" 
THEN
  SUBGOAL_TAC "0CLAUSE" `reachableN p p' 0  <=>  p = p'`
  [HYP MESON_TAC "s0exists" [LE_0; reachableN; LT]] THEN SUBGOAL_TAC "Imp1"
  `! n. reachableN p p' (SUC n)  ==>  ? q. reachableN p q n  /\ move q p'`
  [INTRO_TAC "!n; H1" THEN
  consider "s such that"
  `s 0 = p /\ s (SUC n) = p' /\ !m. m < SUC n ==> move (s m) (s (SUC m))`
  [HYP MESON_TAC "H1" [LE_0; reachableN]] "sDef" THEN
  consider "q such that" `q:triple = s n` [MESON_TAC[]]  "qDef" THEN
  HYP MESON_TAC "sDef qDef" [LE_0; reachableN; LT]] THEN SUBGOAL_TAC "Imp2"
  `!n. (? q. reachableN p q n  /\ move q p')  ==>  reachableN p p' (SUC n)`
  [INTRO_TAC "!n" THEN REWRITE_TAC[IMP_CONJ; LEFT_IMP_EXISTS_THM] THEN
  INTRO_TAC "!q; nReach; move_qp'" THEN
  consider "s such that"
  `s 0 = p /\ s n = q /\ !m. m < n ==> move (s m) (s (SUC m))`
  [HYP MESON_TAC "nReach" [reachableN; LT; LE_0]] "sDef" THEN
  REWRITE_TAC[reachableN; LT; LE_0] THEN
  EXISTS_TAC `\m. if m < SUC n then s m else p':triple` THEN
  HYP MESON_TAC "sDef move_qp'" [LT_0; LT_REFL; LT; LT_SUC]] THEN
  HYP MESON_TAC "0CLAUSE Imp1 Imp2" []);;

Using Petros's and Marco's ideas, I defined consider so that the first s0 of 
consider "s0 such that" `s0 =  \m:num. p':triple` 
did not need a type annotation.  But the free variable p' should need a type 
annotation, as it is in the scope of the binding given by 
INTRO_TAC "!p p'"
so p and p' have type triple, because reachableN has type
triple -> triple -> num -> bool.
That's also true for the function 
`\m. if m < SUC n then s m else p':triple`
near the end.  

In 
consider "q such that" `q:triple = s n`
the free variable q should not need a type annotation, because the free 
variable s is in the scope of the variable binding given by 
  consider "s such that"
  `s 0 = p /\ s (SUC n) = p' /\ !m. m < SUC n ==> move (s m) (s (SUC m))`
where s is given the type 
num -> triple
because move has type
triple -> triple -> bool.

Now Petros taught me here long ago to put these type annotations, but it would 
be nice to not need them.   If you look at the analogous proof in 
Examples/inverse_bug_puzzle_miz3.ml, there's only one type annotation, in 
 consider s0 such that
s0 = \m:num. p';
That's a necessary type annotation for m, because it tells us that s0 has type
num -> triple
and we wouldn't know that otherwise.  

   > That's great you're changing your Q-like module right now to use
   > the parser instead of strings.

   I'll do it if the new preterm parser gets integrated in HOL Light.

Wow, I meant it was great you were using the parser in HOL4!  But that's even 
better, if you're porting your HOL4 Q-like module to HOL Light.  Am I getting 
something wrong?   Assuming I'm getting you right, why don't you help me with 
what I'm doing, see if I can sell your quotexpander modification to John, and 
then you can do a great deal more with Q-like modules.

-- 
Best,
Bill 

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Vincent Aravantinos]

Le 17.04.13 00:31, Bill Richter a écrit :
> > That's great you're changing your Q-like module right now to use
> > the parser instead of strings.
>
> I'll do it if the new preterm parser gets integrated in HOL Light.
>
> Wow, I meant it was great you were using the parser in HOL4!  But that's even 
> better, if you're porting your HOL4 Q-like module to HOL Light.  Am I getting 
> something wrong?

Let me clarify:
- HOL4 has a module called "Q" (not developped by me) which basically 
replaces some tactics taking a term as input by the same tactics taking 
a preterm as input:
   * taking preterms as input can be done easily because HOL4 contains a 
preterm parser by default
   * the benefit is that it allows to remove type annotations (for the 
same reasons you would like a preterm parser) in many contexts;
   for instance, consider a proof where you use EXISTS_TAC as follows:
   # EXISTS_TAC `f (x:A) (y:B) :C`
   If f already appears in the context of the goal (either the 
assumptions or the conclusion) then there is somehow a way to know that 
f has type `:A->B->C` and thus we would reasonably like HOL(4/Light) to 
find it itself rather than provide it explicitly. This precisely what 
the Q module does in HOL4, it allows you to do instead:
   # Q.EXISTS_TAC `'f x y`
   (note that I used my notation with a " ' " at the beginning to show 
that we are using the a preter parser here; the notation is actually 
different in HOL4, but it is not important for your understanding)
   And similarly for many other tactics which require a term as input

- I did recently a module which does the same job for HOL Light (this is 
why I always refer to it as the "Q-like module"). For reasons that do 
not need to be mentionned here, this module is called "Pa" (for 
*Pa*rse/er/ing/whatever), but, right now instead of working with 
preterms, it works with strings; precisely because there is no preterm 
dedicated parser in HOL Light. Therefore it has the same problems as 
what you mentionned in the post at the origin of this conversation: 
problems in case of new lines and backslashes must be doubled. If the 
preterm parser was present by default in HOL Light, I could update my Pa 
module to take preterms instead of strings as input, and these problems 
would be solved.

-- 
Vincent ARAVANTINOS - PostDoctoral Fellow - Concordia University, Hardware
Verification Group
http://users.encs.concordia.ca/~vincent/


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Mark]

Oops, my Low-tech solution B doesn't require an adapted HOL Light term
quotation parser.

Mark.

on 17/4/13 10:08 AM, Mark  wrote:

> Hi Bill,
>
> (I'm joining this conversation late, so apologies if I've got the wrong
end
> of the stick here, but ...)
> If you want to do the classic HOL Light proof script thing of creating
> "packaged up" proofs that prove your goal in one compound ML expression,
> involving various ML subexpressions for term quotations, then there is a
> fairly fundamental OCaml language mechanism that restricts with what can
> ultimately be achieved with contextual type inference.  This is related to
> the order in which OCaml evaluates subexpressions.
>
> Specifically, if OCaml has some curried expression:
> F X Y Z
> then it will evaluate Z, then Y, then X before it evaluates the overall
> expression.  So if there is more than one term quotation in your ML
> expression, the first term quotations to be evaluated will be ones
occurring
> later on in the expression.
>
> The impression I get is that this is the opposite of what you want to do,
> i.e. type annotate "early on" (i.e. towards the left of the ML expression)
> and expect ML subexpressions "later on" (i.e. towards the right) in the
same
> expression to inherit the HOL type context of this "early" type
annotation.
>
> The only obvious solutions to this that occur to me are:
>
> 1. Low-tech solution A: Breaking up your proof to a series of "g" and "e"
> steps, so that they get evaluated in the intended order, and then adapting
> the HOL Light term quotation parser to inherit a HOL type context for
> variables occurring early on in the proof (this is what ProofPower does).
> However, you still have same problem here at the individual proof step
> level, if a given "e" step involves more than one term quotation;
>
> 2. Low-tech solution B: Evaluating all of your term quotations up front,
as
> a series of term definitions, and then using an adapted HOL Light
contextual
> term parser as in Low-tech solution A.  However, your proof script is then
> less readable because all the term quotations are defined up front instead
> of being embedded in the proof steps;
>
> 3. High-tech solution: Expressing your proof script not in ML but in some
> special proof script language (like Isabelle's Isar), so that you are not
> tied to the order in which OCaml evaluates subexpressions, because it is
the
> parser for your proof script language, and not OCaml, that would decide
> evaluation order.  However, this involves designing a proof scripting
> language and writing a parser for it.
>
> Regards,
>
> Mark.
>
> on 17/4/13 5:32 AM, Bill Richter  wrote:
>
>> Thanks, Vince!  Here's an example of a free variable occurrence in the
> scope
>> of a variable binding whose type is not inferred, from
>> hol_light/Examples/inverse_bug_puzzle_tac.ml.  I picked a long proof so
> you
>> can clearly see.  I apologize is my ML-like terminology isn't correct in
>> HOL:
>>
>> let reachableN_CLAUSES = prove
>> (`! p p'. (reachableN p p' 0  <=>  p = p') /\
>> ! n. reachableN p p' (SUC n)  <=>  ? q. reachableN p q n  /\ move q p'`,
>> INTRO_TAC "!p p'" THEN
>> consider "s0 such that" `s0 =  \m:num. p':triple` [MESON_TAC[]]
"s0exists"
>> THEN
>> SUBGOAL_TAC "0CLAUSE" `reachableN p p' 0  <=>  p = p'`
>> [HYP MESON_TAC "s0exists" [LE_0; reachableN; LT]] THEN SUBGOAL_TAC "Imp1"
>> `! n. reachableN p p' (SUC n)  ==>  ? q. reachableN p q n  /\ move q p'`
>> [INTRO_TAC "!n; H1" THEN
>> consider "s such that"
>> `s 0 = p /\ s (SUC n) = p' /\ !m. m < SUC n ==> move (s m) (s (SUC m))`
>> [HYP MESON_TAC "H1" [LE_0; reachableN]] "sDef" THEN
>> consider "q such that" `q:triple = s n` [MESON_TAC[]]  "qDef" THEN
>> HYP MESON_TAC "sDef qDef" [LE_0; reachableN; LT]] THEN SUBGOAL_TAC "Imp2"
>> `!n. (? q. reachableN p q n  /\ move q p')  ==>  reachableN p p' (SUC n)`
>> [INTRO_TAC "!n" THEN REWRITE_TAC[IMP_CONJ; LEFT_IMP_EXISTS_THM] THEN
>> INTRO_TAC "!q; nReach; move_qp'" THEN
>> consider "s such that"
>> `s 0 = p /\ s n = q /\ !m. m < n ==> move (s m) (s (SUC m))`
>> [HYP MESON_TAC "nReach" [reachableN; LT; LE_0]] "sDef" THEN
>> REWRITE_TAC[reachableN; LT; LE_0] THEN
>> EXISTS_TAC `\m. if m < SUC n then s m else p':triple` THEN
>> HYP MESON_TAC "sDef move_qp'" [LT_0; LT_REFL; LT; LT_SUC]] THEN
>> HYP MESON_TAC "0CLAUSE Imp1 Imp2" []);;
>>
>> Using Petros's and Marco's ideas, I defined consider so that the first s0
> of
>>
>> consider "s0 such that" `s0 =  \m:num. p':triple`
>> did not need a type annotation.  But the free variable p' should need a
> type
>> annotation, as it is in the scope of the binding given by
>> INTRO_TAC "!p p'"
>> so p and p' have type triple, because reachableN has type
>> triple -> triple -> num -> bool.
>> That's also true for the function
>> `\m. if m < SUC n then s m else p':triple`
>> near the end.
>>
>> In
>> consider "q such that" `q:triple = s n`
>> the free variable q should not need a type annotation, because the free
>> variable s is in the scope of 

Re: [Hol-info] Learning HOL Light

[Mark]

Hi Bill,

(I'm joining this conversation late, so apologies if I've got the wrong end
of the stick here, but ...)
If you want to do the classic HOL Light proof script thing of creating
"packaged up" proofs that prove your goal in one compound ML expression,
involving various ML subexpressions for term quotations, then there is a
fairly fundamental OCaml language mechanism that restricts with what can
ultimately be achieved with contextual type inference.  This is related to
the order in which OCaml evaluates subexpressions.

Specifically, if OCaml has some curried expression:
F X Y Z
then it will evaluate Z, then Y, then X before it evaluates the overall
expression.  So if there is more than one term quotation in your ML
expression, the first term quotations to be evaluated will be ones occurring
later on in the expression.

The impression I get is that this is the opposite of what you want to do,
i.e. type annotate "early on" (i.e. towards the left of the ML expression)
and expect ML subexpressions "later on" (i.e. towards the right) in the same
expression to inherit the HOL type context of this "early" type annotation.

The only obvious solutions to this that occur to me are:

1. Low-tech solution A: Breaking up your proof to a series of "g" and "e"
steps, so that they get evaluated in the intended order, and then adapting
the HOL Light term quotation parser to inherit a HOL type context for
variables occurring early on in the proof (this is what ProofPower does).
However, you still have same problem here at the individual proof step
level, if a given "e" step involves more than one term quotation;

2. Low-tech solution B: Evaluating all of your term quotations up front, as
a series of term definitions, and then using an adapted HOL Light contextual
term parser as in Low-tech solution A.  However, your proof script is then
less readable because all the term quotations are defined up front instead
of being embedded in the proof steps;

3. High-tech solution: Expressing your proof script not in ML but in some
special proof script language (like Isabelle's Isar), so that you are not
tied to the order in which OCaml evaluates subexpressions, because it is the
parser for your proof script language, and not OCaml, that would decide
evaluation order.  However, this involves designing a proof scripting
language and writing a parser for it.

Regards,

Mark.

on 17/4/13 5:32 AM, Bill Richter  wrote:

> Thanks, Vince!  Here's an example of a free variable occurrence in the
scope
> of a variable binding whose type is not inferred, from
> hol_light/Examples/inverse_bug_puzzle_tac.ml.  I picked a long proof so
you
> can clearly see.  I apologize is my ML-like terminology isn't correct in
> HOL:
>
> let reachableN_CLAUSES = prove
> (`! p p'. (reachableN p p' 0  <=>  p = p') /\
> ! n. reachableN p p' (SUC n)  <=>  ? q. reachableN p q n  /\ move q p'`,
> INTRO_TAC "!p p'" THEN
> consider "s0 such that" `s0 =  \m:num. p':triple` [MESON_TAC[]] "s0exists"
> THEN
> SUBGOAL_TAC "0CLAUSE" `reachableN p p' 0  <=>  p = p'`
> [HYP MESON_TAC "s0exists" [LE_0; reachableN; LT]] THEN SUBGOAL_TAC "Imp1"
> `! n. reachableN p p' (SUC n)  ==>  ? q. reachableN p q n  /\ move q p'`
> [INTRO_TAC "!n; H1" THEN
> consider "s such that"
> `s 0 = p /\ s (SUC n) = p' /\ !m. m < SUC n ==> move (s m) (s (SUC m))`
> [HYP MESON_TAC "H1" [LE_0; reachableN]] "sDef" THEN
> consider "q such that" `q:triple = s n` [MESON_TAC[]]  "qDef" THEN
> HYP MESON_TAC "sDef qDef" [LE_0; reachableN; LT]] THEN SUBGOAL_TAC "Imp2"
> `!n. (? q. reachableN p q n  /\ move q p')  ==>  reachableN p p' (SUC n)`
> [INTRO_TAC "!n" THEN REWRITE_TAC[IMP_CONJ; LEFT_IMP_EXISTS_THM] THEN
> INTRO_TAC "!q; nReach; move_qp'" THEN
> consider "s such that"
> `s 0 = p /\ s n = q /\ !m. m < n ==> move (s m) (s (SUC m))`
> [HYP MESON_TAC "nReach" [reachableN; LT; LE_0]] "sDef" THEN
> REWRITE_TAC[reachableN; LT; LE_0] THEN
> EXISTS_TAC `\m. if m < SUC n then s m else p':triple` THEN
> HYP MESON_TAC "sDef move_qp'" [LT_0; LT_REFL; LT; LT_SUC]] THEN
> HYP MESON_TAC "0CLAUSE Imp1 Imp2" []);;
>
> Using Petros's and Marco's ideas, I defined consider so that the first s0
of
>
> consider "s0 such that" `s0 =  \m:num. p':triple`
> did not need a type annotation.  But the free variable p' should need a
type
> annotation, as it is in the scope of the binding given by
> INTRO_TAC "!p p'"
> so p and p' have type triple, because reachableN has type
> triple -> triple -> num -> bool.
> That's also true for the function
> `\m. if m < SUC n then s m else p':triple`
> near the end.
>
> In
> consider "q such that" `q:triple = s n`
> the free variable q should not need a type annotation, because the free
> variable s is in the scope of the variable binding given by
> consider "s such that"
> `s 0 = p /\ s (SUC n) = p' /\ !m. m < SUC n ==> move (s m) (s (SUC m))`
> where s is given the type
> num -> triple
> because move has type
> triple -> triple -> bool.
>
> Now Petros taught me here long ago to put thes

Re: [Hol-info] Learning HOL Light

[Mark]

Oops again, ignore my last email.  Momentarily forgot what I was talking
about there.

Mark.

on 17/4/13 1:30 PM, Mark  wrote:

> Hi Bill,
>
> (I'm joining this conversation late, so apologies if I've got the wrong
end
> of the stick here, but ...)
> If you want to do the classic HOL Light proof script thing of creating
> "packaged up" proofs that prove your goal in one compound ML expression,
> involving various ML subexpressions for term quotations, then there is a
> fairly fundamental OCaml language mechanism that restricts with what can
> ultimately be achieved with contextual type inference.  This is related to
> the order in which OCaml evaluates subexpressions.
>
> Specifically, if OCaml has some curried expression:
> F X Y Z
> then it will evaluate Z, then Y, then X before it evaluates the overall
> expression.  So if there is more than one term quotation in your ML
> expression, the first term quotations to be evaluated will be ones
occurring
> later on in the expression.
>
> The impression I get is that this is the opposite of what you want to do,
> i.e. type annotate "early on" (i.e. towards the left of the ML expression)
> and expect ML subexpressions "later on" (i.e. towards the right) in the
same
> expression to inherit the HOL type context of this "early" type
annotation.
>
> The only obvious solutions to this that occur to me are:
>
> 1. Low-tech solution A: Breaking up your proof to a series of "g" and "e"
> steps, so that they get evaluated in the intended order, and then adapting
> the HOL Light term quotation parser to inherit a HOL type context for
> variables occurring early on in the proof (this is what ProofPower does).
> However, you still have same problem here at the individual proof step
> level, if a given "e" step involves more than one term quotation;
>
> 2. Low-tech solution B: Evaluating all of your term quotations up front,
as
> a series of term definitions, and then using an adapted HOL Light
contextual
> term parser as in Low-tech solution A.  However, your proof script is then
> less readable because all the term quotations are defined up front instead
> of being embedded in the proof steps;
>
> 3. High-tech solution: Expressing your proof script not in ML but in some
> special proof script language (like Isabelle's Isar), so that you are not
> tied to the order in which OCaml evaluates subexpressions, because it is
the
> parser for your proof script language, and not OCaml, that would decide
> evaluation order.  However, this involves designing a proof scripting
> language and writing a parser for it.
>
> Regards,
>
> Mark.
>
> on 17/4/13 5:32 AM, Bill Richter  wrote:
>
>> Thanks, Vince!  Here's an example of a free variable occurrence in the
> scope
>> of a variable binding whose type is not inferred, from
>> hol_light/Examples/inverse_bug_puzzle_tac.ml.  I picked a long proof so
> you
>> can clearly see.  I apologize is my ML-like terminology isn't correct in
>> HOL:
>>
>> let reachableN_CLAUSES = prove
>> (`! p p'. (reachableN p p' 0  <=>  p = p') /\
>> ! n. reachableN p p' (SUC n)  <=>  ? q. reachableN p q n  /\ move q p'`,
>> INTRO_TAC "!p p'" THEN
>> consider "s0 such that" `s0 =  \m:num. p':triple` [MESON_TAC[]]
"s0exists"
>> THEN
>> SUBGOAL_TAC "0CLAUSE" `reachableN p p' 0  <=>  p = p'`
>> [HYP MESON_TAC "s0exists" [LE_0; reachableN; LT]] THEN SUBGOAL_TAC "Imp1"
>> `! n. reachableN p p' (SUC n)  ==>  ? q. reachableN p q n  /\ move q p'`
>> [INTRO_TAC "!n; H1" THEN
>> consider "s such that"
>> `s 0 = p /\ s (SUC n) = p' /\ !m. m < SUC n ==> move (s m) (s (SUC m))`
>> [HYP MESON_TAC "H1" [LE_0; reachableN]] "sDef" THEN
>> consider "q such that" `q:triple = s n` [MESON_TAC[]]  "qDef" THEN
>> HYP MESON_TAC "sDef qDef" [LE_0; reachableN; LT]] THEN SUBGOAL_TAC "Imp2"
>> `!n. (? q. reachableN p q n  /\ move q p')  ==>  reachableN p p' (SUC n)`
>> [INTRO_TAC "!n" THEN REWRITE_TAC[IMP_CONJ; LEFT_IMP_EXISTS_THM] THEN
>> INTRO_TAC "!q; nReach; move_qp'" THEN
>> consider "s such that"
>> `s 0 = p /\ s n = q /\ !m. m < n ==> move (s m) (s (SUC m))`
>> [HYP MESON_TAC "nReach" [reachableN; LT; LE_0]] "sDef" THEN
>> REWRITE_TAC[reachableN; LT; LE_0] THEN
>> EXISTS_TAC `\m. if m < SUC n then s m else p':triple` THEN
>> HYP MESON_TAC "sDef move_qp'" [LT_0; LT_REFL; LT; LT_SUC]] THEN
>> HYP MESON_TAC "0CLAUSE Imp1 Imp2" []);;
>>
>> Using Petros's and Marco's ideas, I defined consider so that the first s0
> of
>>
>> consider "s0 such that" `s0 =  \m:num. p':triple`
>> did not need a type annotation.  But the free variable p' should need a
> type
>> annotation, as it is in the scope of the binding given by
>> INTRO_TAC "!p p'"
>> so p and p' have type triple, because reachableN has type
>> triple -> triple -> num -> bool.
>> That's also true for the function
>> `\m. if m < SUC n then s m else p':triple`
>> near the end.
>>
>> In
>> consider "q such that" `q:triple = s n`
>> the free variable q should not need a type annotation, because the free
>> variable s is in the scope of the 

Re: [Hol-info] Learning HOL Light

[Mark]

Not sure what's going on there.  The 2nd message I sent to hol-info didn't
seem to get through, and so my 3rd message, saying ignore the previous
message, wrongly looks like it's saying ignore the 1st message.  Just having
one of those days...

Mark.

on 17/4/13 1:43 PM, Mark  wrote:

> Oops again, ignore my last email.  Momentarily forgot what I was talking
> about there.
>
> Mark.
>
> on 17/4/13 1:30 PM, Mark  wrote:
>
>> Hi Bill,
>>
>> (I'm joining this conversation late, so apologies if I've got the wrong
> end
>> of the stick here, but ...)
>> If you want to do the classic HOL Light proof script thing of creating
>> "packaged up" proofs that prove your goal in one compound ML expression,
>> involving various ML subexpressions for term quotations, then there is a
>> fairly fundamental OCaml language mechanism that restricts with what can
>> ultimately be achieved with contextual type inference.  This is related
to
>> the order in which OCaml evaluates subexpressions.
>>
>> Specifically, if OCaml has some curried expression:
>> F X Y Z
>> then it will evaluate Z, then Y, then X before it evaluates the overall
>> expression.  So if there is more than one term quotation in your ML
>> expression, the first term quotations to be evaluated will be ones
> occurring
>> later on in the expression.
>>
>> The impression I get is that this is the opposite of what you want to do,
>> i.e. type annotate "early on" (i.e. towards the left of the ML
expression)
>> and expect ML subexpressions "later on" (i.e. towards the right) in the
> same
>> expression to inherit the HOL type context of this "early" type
> annotation.
>>
>> The only obvious solutions to this that occur to me are:
>>
>> 1. Low-tech solution A: Breaking up your proof to a series of "g" and "e"
>> steps, so that they get evaluated in the intended order, and then
adapting
>> the HOL Light term quotation parser to inherit a HOL type context for
>> variables occurring early on in the proof (this is what ProofPower does).
>> However, you still have same problem here at the individual proof step
>> level, if a given "e" step involves more than one term quotation;
>>
>> 2. Low-tech solution B: Evaluating all of your term quotations up front,
> as
>> a series of term definitions, and then using an adapted HOL Light
> contextual
>> term parser as in Low-tech solution A.  However, your proof script is
then
>> less readable because all the term quotations are defined up front
instead
>> of being embedded in the proof steps;
>>
>> 3. High-tech solution: Expressing your proof script not in ML but in some
>> special proof script language (like Isabelle's Isar), so that you are not
>> tied to the order in which OCaml evaluates subexpressions, because it is
> the
>> parser for your proof script language, and not OCaml, that would decide
>> evaluation order.  However, this involves designing a proof scripting
>> language and writing a parser for it.
>>
>> Regards,
>>
>> Mark.
>>
>> on 17/4/13 5:32 AM, Bill Richter  wrote:
>>
>>> Thanks, Vince!  Here's an example of a free variable occurrence in the
>> scope
>>> of a variable binding whose type is not inferred, from
>>> hol_light/Examples/inverse_bug_puzzle_tac.ml.  I picked a long proof so
>> you
>>> can clearly see.  I apologize is my ML-like terminology isn't correct in
>>> HOL:
>>>
>>> let reachableN_CLAUSES = prove
>>> (`! p p'. (reachableN p p' 0  <=>  p = p') /\
>>> ! n. reachableN p p' (SUC n)  <=>  ? q. reachableN p q n  /\ move q p'`,
>>> INTRO_TAC "!p p'" THEN
>>> consider "s0 such that" `s0 =  \m:num. p':triple` [MESON_TAC[]]
> "s0exists"
>>> THEN
>>> SUBGOAL_TAC "0CLAUSE" `reachableN p p' 0  <=>  p = p'`
>>> [HYP MESON_TAC "s0exists" [LE_0; reachableN; LT]] THEN SUBGOAL_TAC
"Imp1"
>>> `! n. reachableN p p' (SUC n)  ==>  ? q. reachableN p q n  /\ move q p'`
>>> [INTRO_TAC "!n; H1" THEN
>>> consider "s such that"
>>> `s 0 = p /\ s (SUC n) = p' /\ !m. m < SUC n ==> move (s m) (s (SUC m))`
>>> [HYP MESON_TAC "H1" [LE_0; reachableN]] "sDef" THEN
>>> consider "q such that" `q:triple = s n` [MESON_TAC[]]  "qDef" THEN
>>> HYP MESON_TAC "sDef qDef" [LE_0; reachableN; LT]] THEN SUBGOAL_TAC
"Imp2"
>>> `!n. (? q. reachableN p q n  /\ move q p')  ==>  reachableN p p' (SUC
n)`
>>> [INTRO_TAC "!n" THEN REWRITE_TAC[IMP_CONJ; LEFT_IMP_EXISTS_THM] THEN
>>> INTRO_TAC "!q; nReach; move_qp'" THEN
>>> consider "s such that"
>>> `s 0 = p /\ s n = q /\ !m. m < n ==> move (s m) (s (SUC m))`
>>> [HYP MESON_TAC "nReach" [reachableN; LT; LE_0]] "sDef" THEN
>>> REWRITE_TAC[reachableN; LT; LE_0] THEN
>>> EXISTS_TAC `\m. if m < SUC n then s m else p':triple` THEN
>>> HYP MESON_TAC "sDef move_qp'" [LT_0; LT_REFL; LT; LT_SUC]] THEN
>>> HYP MESON_TAC "0CLAUSE Imp1 Imp2" []);;
>>>
>>> Using Petros's and Marco's ideas, I defined consider so that the first
s0
>> of
>>>
>>> consider "s0 such that" `s0 =  \m:num. p':triple`
>>> did not need a type annotation.  But the free variable p' should need a
>> type
>>> annotation, as it is in the scope o

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Thanks, Vince!  I think you're saying that the HOL4 Q-module can do type 
inference using the goal.  I would guess that Petros's IsabelleLight techniques 
(which I used for my consider) could also do this goal-powered type inference.  
Freek's miz3.ml does much more type inference.

   Specifically, if OCaml has some curried expression F X Y Z, then it
   will evaluate Z, then Y, then X before it evaluates the overall
   expression.

Thanks, Mark! I didn't know that, and I'd wondered about it.  But this is only 
barely relevant.  

   However, this involves designing a proof scripting language and
   writing a parser for it

That's kind of what Freek' miz3.ml does, and Vince has been instructing me on 
how to do similar things.  I didn't that like Isabelle's Isar was similar...

-- 
Best,
Bill 

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info

Re: [Hol-info] Learning HOL Light

[Bill Richter]

Here's a simpler version of the type-inference question I've been asking, and 
this I suspect does not involve the parser.  Suppose we have a free variable in 
a term that's in the scope of a variable binding.   As Petros explained to me 
here some time ago, this variable's type must be either annotated in the term, 
or else follow from type inference using only the term itself.  Vince explained 
to me why this extra typing is needed.  But having correctly typed the 
variable, I have a beginner's question: 

Why does the variable receive its correct value?  

Here's the first example of this in Examples/inverse_bug_puzzle_tac.ml:

let Noncollinear_2Span = prove
 (`!u v w:real^2. ~collinear  {vec 0,v,w} ==> ? s t. s % v + t % w = u`,
  INTRO_TAC "!u v w; H1" THEN
  SUBGOAL_TAC "H1'" `~(v$1 * w$2 - (w:real^2)$1 * (v:real^2)$2 = &0)`
  [HYP MESON_TAC "H1" [COLLINEAR_3_2Dzero; REAL_SUB_0]] THEN [...]);;

So in the SUBGOAL_TAC expression, v and w need type annotations.  But then they 
received the value given by INTRO_TAC.  That is, the statement of the theorem 
is "for all u, v, w...", and INTRO_TAC then fixes arbitrary real^2 vectors u, 
v, w, for which we're to prove 
~collinear  {vec 0,v,w} ==> ? s t. s % v + t % w = u.
How does HOL Light know that the v and w of the SUBGOAL_TAC command are the 
same v and w that were fixed by INTRO_TAC?  

-- 
Best,
Bill 

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
hol-info mailing list
hol-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hol-info