\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Thu, 2 Feb 2017 18:06:12 +0100
From: Blatrix <blatrix@laposte.net>
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] axiom don't compile under slackware

Hello,

Excuse me for my language but I'm french.

I tried to compile axiom under slackware 14.2, slackware64 14.2 and
slackware64 14.1.
The compilation stops with this error : 

makefile:159: recipe for target 'raw_pre_gcl_map' failed
make[4]: *** [raw_pre_gcl_map] Error 1
make[4]: Leaving directory '/root/axiom/lsp/gcl-2.6.8pre7/unixport'
makefile:67: recipe for target 'unixport/saved_pre_gcl' failed
make[3]: *** [unixport/saved_pre_gcl] Error 2
make[3]: Leaving directory '/root/axiom/lsp/gcl-2.6.8pre7'
/bin/sh: line 5: unixport/saved_gcl: No such file or directory
Makefile:8: recipe for target 'gcldir' failed
make[2]: *** [gcldir] Error 127
make[2]: Leaving directory '/root/axiom/lsp'
Makefile.linux:163: recipe for target 'lspdir' failed
make[1]: *** [lspdir] Error 2
make[1]: Leaving directory '/root/axiom'
Makefile:128: recipe for target 'all' failed
make: *** [all] Error 2


What's wrong?

With docker, I don't have graphics.

Thank you for your help,

Yann

\start
Date: Fri, 3 Feb 2017 17:15:10 -0500
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] Why focus on education?

Keith Devlin writes: All the mathematical methods I learned in my
university math degree
becamse obsolete in my lifetime.

Dr Keith Devlin is a mathematician at Stanford University in Palo Alto,
California.

When I graduated with a bachelors degree in mathematics from one of the
most prestigious university mathematics programs in the world (Kings
College London) in 1968, I had acquired a set of skills that guaranteed
full employment, wherever I chose to go, for the then-foreseeable future=E2=
=80=94a
state of affairs that had been in existence ever since modern mathematics
began some three thousand years earlier. By the turn of the new Millennium,
however, just over thirty years later, those skills were essentially
worthless, having been very effectively outsourced to machines that did it
faster and more reliably, and were made widely available with the onset of
first desktop- and then cloud-computing. In a single lifetime, I
experienced first-hand a dramatic change in the nature of mathematics and
how it played a role in society.

The shift began with the introduction of the electronic calculator in the
1960s, which rendered obsolete the need for humans to master the ancient
art of mental arithmetical calculation. Over the succeeding decades, the
scope of algorithms developed to perform mathematical procedures steadily
expanded, culminating in the creation of desktop packages such as
*Mathematica* and cloud-based systems such as *Wolfram Alpha* that can
execute pretty well any mathematical procedure, solving=E2=80=94accurately =
and in a
fraction of a second=E2=80=94any mathematical problem formulated with suffi=
cient
precision (a bar that allows in all the exam questions I and any other math
student faced throughout our entire school and university careers).

So what, then, remains in mathematics that people need to master? The
answer is, the set of skills required to make effective use of those
powerful new (procedural) mathematical tools we can access from our
smartphone. Whereas it used to be the case that humans had to master the
computational skills required to *carry out* various mathematical
procedures (adding and multiplying numbers, inverting matrices, solving
polynomial equations, differentiating analytic functions, solving
differential equations, etc.), what is required today is a sufficiently
deep *understanding* of all those procedures, and the underlying concepts
they are built on, in order to know when, and how, to use those
digitally-implemented tools effectively, productively, and safely.

\start
Date: Sun, 5 Feb 2017 18:51:57 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Blatrix <blatrix@laposte.net>, axiom-dev <axiom-developer@nongnu.org>, 
	Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] Axiom on Slackware

It looks like the problem is related to GCL, not Axiom.
GCC changed behavior causing the GCL build to fail.
It might be fixed in GCL 13pre but I have not completed the port
from GCL 12 yet.

Axiom is available in the Debian repository. On most systems
you can install it with something like
    apt-get install axiom

On Slackware you might be able to use
https://sourceforge.net/projects/swaret/

As an alternaive you might consider using VirtualBox running Ubuntu.

Tim

\start
Date: Wed, 8 Feb 2017 09:29:30 -0500
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>,
	Renaud Rioboo <renaud.rioboo@ensiie.fr>, Jeremy Avigad <avigad@cmu.edu>
Subject: [Axiom-developer] [Proving Axiom Correct] Bootstrapping a library

The game is to prove GCD in NonNegativeInteger (NNI).

We would like to use the 'nat' theorems from the existing library
but extract those theorems automatically from Axiom sources
at build time.

Axiom's NNI inherits from a dozen Category objects, one of which
is BasicType which contains two signatures:

 ?=?: (%,%) -> Boolean       ?~=?: (%,%) -> Boolean

In the ideal case we would decorate BasicType with the existing
definitions of = and ~= so we could create a new library structure
for the logic system. So BasicType would contain

theorem = (a, b : Type) : Boolean := .....
theorem ~= (a, b : Type) : Boolean := ....

These theorems would be imported into NNI when it inherits the
signatures from the BasicType Category. The collection of all of
the theorems in NNI's Category structure would be used (hopefully
exclusively) to prove GCD. In this way, all of the theorems used to
prove Axiom source code would be inheritied from the Category
structure.

Unfortunately it appears the Coq and Lean will not take kindly to
removing the existing libraries and replacing them with a new version
that only contains a limited number of theorems. I'm not yet sure about
FoCaL but I suspect it has the same bootstrap problem.

Jeremy Avigad (Lean) made the suggestion to rename these theorems.
Thus, instead of =, the supporting theorem would be 'spad=' (spad is
the name of Axiom's algebra language).

Initially this would make Axiom depend on the external library structure.
Eventually there should be enough embedded logic to start coding Axiom
theorems by changing external references from = to spad= everywhere.

Axiom proofs would still depend on the external proof system but only
for the correctness engine, not the library structure. This will minimize
the struggle about Axiom's world view (e.g. handling excluded middle).
It will also organize the logic library to more closely mirror abstract
algebra.

Comments, suggestions?

Tim

\start
Date: Wed, 8 Feb 2017 17:52:48 -0500
From: Jeremy Avigad <avigad@cmu.edu>
To: Tim Daly <axiomcas@gmail.com>
Cc: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>,
	Renaud Rioboo <renaud.rioboo@ensiie.fr>
Subject: Re: [Axiom-developer] [Proving Axiom Correct] Bootstrapping a
 library

Dear Tim,

I don't understand what you mean. For one thing, theorems in both Lean and
Coq are marked as opaque, since you generally don't care about the
contents. But even if we replace "theorem" by "definition," I don't know
what you imagine going into the "...".

I think what you want to do is represent Axiom categories as structures.
For example, the declarations below declare a BasicType structure and
notation for elements of that structure. You can then prove theorems about
arbitrary types =CE=B1 that have a BasicType structure. You can also extend=
 the
structure as needed.

(Presumably you will eventually want to add axioms to the structures that
say things about what eq and neq do. Otherwise, you are just reasoning
about a type with two relations.)

Best wishes,

Jeremy

class BasicType (=CE=B1 : Type) : Type :=3D
(eq : =CE=B1 =E2=86=92 =CE=B1 =E2=86=92 bool) (neq : =CE=B1 =E2=86=92 =CE=
=B1 =E2=86=92 bool)

infix `?=3D?`:50  :=3D BasicType.eq
infix `?~=3D?`:50 :=3D BasicType.neq

section
  variables (=CE=B1 : Type) [BasicType =CE=B1]
  variables a b : =CE=B1

  check a ?=3D? b
  check a ?~=3D? b
end




On Wed, Feb 8, 2017 at 9:29 AM, Tim Daly <axiomcas@gmail.com> wrote:

> The game is to prove GCD in NonNegativeInteger (NNI).
>
> We would like to use the 'nat' theorems from the existing library
> but extract those theorems automatically from Axiom sources
> at build time.
>
> Axiom's NNI inherits from a dozen Category objects, one of which
> is BasicType which contains two signatures:
>
>  ?=3D?: (%,%) -> Boolean       ?~=3D?: (%,%) -> Boolean
>
> In the ideal case we would decorate BasicType with the existing
> definitions of =3D and ~=3D so we could create a new library structure
> for the logic system. So BasicType would contain
>
> theorem =3D (a, b : Type) : Boolean :=3D .....
> theorem ~=3D (a, b : Type) : Boolean :=3D ....
>
> These theorems would be imported into NNI when it inherits the
> signatures from the BasicType Category. The collection of all of
> the theorems in NNI's Category structure would be used (hopefully
> exclusively) to prove GCD. In this way, all of the theorems used to
> prove Axiom source code would be inheritied from the Category
> structure.
>
> Unfortunately it appears the Coq and Lean will not take kindly to
> removing the existing libraries and replacing them with a new version
> that only contains a limited number of theorems. I'm not yet sure about
> FoCaL but I suspect it has the same bootstrap problem.
>
> Jeremy Avigad (Lean) made the suggestion to rename these theorems.
> Thus, instead of =3D, the supporting theorem would be 'spad=3D' (spad is
> the name of Axiom's algebra language).
>
> Initially this would make Axiom depend on the external library structure.
> Eventually there should be enough embedded logic to start coding Axiom
> theorems by changing external references from =3D to spad=3D everywhere.
>
> Axiom proofs would still depend on the external proof system but only
> for the correctness engine, not the library structure. This will minimize
> the struggle about Axiom's world view (e.g. handling excluded middle).
> It will also organize the logic library to more closely mirror abstract
> algebra.
>
> Comments, suggestions?
>
> Tim

\start
Date: Wed, 8 Feb 2017 21:23:43 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Jeremy Avigad <avigad@cmu.edu>
Cc: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>,
	Renaud Rioboo <renaud.rioboo@ensiie.fr>
Subject: Re: [Axiom-developer] [Proving Axiom Correct] Bootstrapping a
 library

Part of your struggle of understanding what I wrote is that I'm not yet
fluent in the
logic language and syntax. I'm learning as fast as I can so please be
patient.

CATEGORY SIGNATURE vs DOMAIN SEMANTICS

> Presumably you will eventually want to add axioms to the structures that
say
> things about what eq and neq do

The semantics of =3D is given in the Domain (the current one being defined =
is
called % in Spad)
not in the Category (well...you can... sigh)

Each domain that inherits '=3D' from the Category BasicType needs to specif=
y
the meaning
of that function for the Domain you're implementing.. For a Polynomial
domain with some
structural data representation you have to define what it means for two
polynomial objects
to be =3D. such as a function to compare coefficients. Part of the game wou=
ld
be to prove
that the coefficient-compare function is correct, always returns a Boolean,
and terminates.

All a Category like BasicType does is specify that the Domain Polynomial
should
implement an =3D operation with the given signature.  That is, you have to
implement

     poly =3D poly

which returns a boolean. (Note that there are other =3D functions in
Polynomial such as one
that returns an equation object but that signature is inherited from a
different Category).

It looks like your 'class' syntax implements what I need. I will try this
for the other
Categories used in NNI.




PROVING TERMINATION

As I understood from class, for an algorithm like gcd it should be
sufficient to construct
a function that fulfills the signature of

   gcd(a:NNI,b:NNI):NNI

Coq provides gcd as

  Fixpoint gcd a b :=3D
    match a with
      | 0 =3D> b
      | S a' =3D> gcd (b mod (S a')) (S a')
    end.

and Axiom's definition is

  gcd(x:NNI,y:NNI):NNI =3D=3D
    zero? x =3D> y
    gcd(y rem x, x)

Everything in Spad is strongly typed and function definitions are chosen
not only
by the arguments but also by the return type (so there can be multiple
functions
with the same name and same arguments but different return types, for
example).
Every statement in the function is strongly type-checked.

Thus we are guaranteed that the Spad version of gcd above (in the Domain
NNI)
can only be called with NNI arguments and is guaranteed to only return NNI
results.

The languages are very close in spirit if not in syntax.

What Axiom does not do, for example, is prove termination.

Coq, in its version, will figure out that the recursion is on 'a' and that
it will terminate.

Part of the game is to provide the same termination analysis on Spad code.

ADDITIONAL CONSTRAINTS

It would be ideal to reject code that did not fulfill all of the
requirements
such as specifying at the Category level definition of gcd that it not only
has to have the correct signature, it also has to return the 'positive'
divisor. For NNI this is trivially fulfilled.

The Category definition should say something like

   gcd(%,%) -> %  and gcd >=3D 1$%

where 1$% says to use the unit from the implementing Domain.

So for some domains we have:

  gcd(x,y) =3D=3D
    x :=3D unitCanonical x
    y :=3D unitCanonical y
    while not zero? y repeat
      (x,y) :=3D (y, x rem y)
      y :=3D unitCanonical y
    x

using unitCanonical to deal with things like signs. (This also adds the
complication
of loops which I mentioned in a previous email.)

Not only the signature but the side-conditions would have to be checked.





ALTERNATE APPROACHES

Instead of a new library organization it might be possible to have a
generator function
in Coq that translates Coq code to Spad code. Or a translator from Spad
code to
Coq code.

Unfortunately Coq and Lean do not seem to use function name overloading
or inheritance (or do they?) which confuses the problem of name
translation.

Axiom has 42 functions named 'gcd', each living in a different Domain.





There is no such thing as a simple job. But this one promises to be
interesting.

In any case I'll push the implementation forward. Thanks for your help.

Tim






On Wed, Feb 8, 2017 at 5:52 PM, Jeremy Avigad <avigad@cmu.edu> wrote:

> Dear Tim,
>
> I don't understand what you mean. For one thing, theorems in both Lean an=
d
> Coq are marked as opaque, since you generally don't care about the
> contents. But even if we replace "theorem" by "definition," I don't know
> what you imagine going into the "...".
>
> I think what you want to do is represent Axiom categories as structures.
> For example, the declarations below declare a BasicType structure and
> notation for elements of that structure. You can then prove theorems abou=
t
> arbitrary types =CE=B1 that have a BasicType structure. You can also exte=
nd the
> structure as needed.
>
> (Presumably you will eventually want to add axioms to the structures that
> say things about what eq and neq do. Otherwise, you are just reasoning
> about a type with two relations.)
>
> Best wishes,
>
> Jeremy
>
> class BasicType (=CE=B1 : Type) : Type :=3D
> (eq : =CE=B1 =E2=86=92 =CE=B1 =E2=86=92 bool) (neq : =CE=B1 =E2=86=92 =CE=
=B1 =E2=86=92 bool)
>
> infix `?=3D?`:50  :=3D BasicType.eq
> infix `?~=3D?`:50 :=3D BasicType.neq
>
> section
>   variables (=CE=B1 : Type) [BasicType =CE=B1]
>   variables a b : =CE=B1
>
>   check a ?=3D? b
>   check a ?~=3D? b
> end
>
>
>
>
> On Wed, Feb 8, 2017 at 9:29 AM, Tim Daly <axiomcas@gmail.com> wrote:
>
>> The game is to prove GCD in NonNegativeInteger (NNI).
>>
>> We would like to use the 'nat' theorems from the existing library
>> but extract those theorems automatically from Axiom sources
>> at build time.
>>
>> Axiom's NNI inherits from a dozen Category objects, one of which
>> is BasicType which contains two signatures:
>>
>>  ?=3D?: (%,%) -> Boolean       ?~=3D?: (%,%) -> Boolean
>>
>> In the ideal case we would decorate BasicType with the existing
>> definitions of =3D and ~=3D so we could create a new library structure
>> for the logic system. So BasicType would contain
>>
>> theorem =3D (a, b : Type) : Boolean :=3D .....
>> theorem ~=3D (a, b : Type) : Boolean :=3D ....
>>
>> These theorems would be imported into NNI when it inherits the
>> signatures from the BasicType Category. The collection of all of
>> the theorems in NNI's Category structure would be used (hopefully
>> exclusively) to prove GCD. In this way, all of the theorems used to
>> prove Axiom source code would be inheritied from the Category
>> structure.
>>
>> Unfortunately it appears the Coq and Lean will not take kindly to
>> removing the existing libraries and replacing them with a new version
>> that only contains a limited number of theorems. I'm not yet sure about
>> FoCaL but I suspect it has the same bootstrap problem.
>>
>> Jeremy Avigad (Lean) made the suggestion to rename these theorems.
>> Thus, instead of =3D, the supporting theorem would be 'spad=3D' (spad is
>> the name of Axiom's algebra language).
>>
>> Initially this would make Axiom depend on the external library structure=
.
>> Eventually there should be enough embedded logic to start coding Axiom
>> theorems by changing external references from =3D to spad=3D everywhere.
>>
>> Axiom proofs would still depend on the external proof system but only
>> for the correctness engine, not the library structure. This will minimiz=
e
>> the struggle about Axiom's world view (e.g. handling excluded middle).
>> It will also organize the logic library to more closely mirror abstract
>> algebra.
>>
>> Comments, suggestions?
>>
>> Tim
>>
>>
>>
>

\start
Date: Thu, 9 Feb 2017 03:23:48 +0100
From: Kurt Pagani <nilqed@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] [Proving Axiom Correct] Bootstrapping a
 library

Am 08.02.2017 um 15:29 schrieb Tim Daly:
> The game is to prove GCD in NonNegativeInteger (NNI).

We encounter numerous problems when trying to prove gcd from EuclideanDomain:

---
gcd(x, y) ==   --Euclidean Algorithm
  x := unitCanonical x
  y := unitCanonical y
  while not zero? y repeat
    (x, y) := (y, x rem y)
    y := unitCanonical y     -- this doesn't affect the
                             -- correctness of Euclid's algorithm,
                             -- but
                             -- a) may improve performance
                             -- b) ensures gcd(x, y)=gcd(y, x)
                             --    if canonicalUnitNormal
  x

---

1. Define type EuclideanDomain (tower of hierarchies)
2. Define unitCanonical (depends on canonicalUnitNormal etc.)
3. Imperative elements in spad
4. Trust interpreter/compiler and lisp

While (1,2) seems not so difficult, (3) might be delicate and (4) seems to be
out of scope for the moment (that is let's trust it, as an axiom so to speak ).

Basically, I see two methods:

a) Implement spad language, e.g. like the "Imp" example:
https://www.seas.upenn.edu/~cis500/current/sf/Imp.html
and prove the statements.

b) Prove the math (by reusing existing [abundant] math libraries) and extract
the functions (Definitions in Coq) as spad code.
This would actually mean to replace parts of current code by new one (purely
functional).

Clearly, both methods will require a definition of spad's key
functions/operators. I believe that (a) is more laborious than (b). Moreover,
Coq's notation mechanism (Notation) has it's limits (e.g. conflicts with
built-in keywords)(**). Moreover, method (b) is admittedly not what we really
want: namely proving existing Axiom code correct.

(**) a parser might be a better solution
https://www.seas.upenn.edu/~cis500/current/sf/ImpParser.html

> 
> We would like to use the 'nat' theorems from the existing library
> but extract those theorems automatically from Axiom sources
> at build time.
> 
> Axiom's NNI inherits from a dozen Category objects, one of which
> is BasicType which contains two signatures:
> 
>  ?=?: (%,%) -> Boolean       ?~=?: (%,%) -> Boolean
> 
> In the ideal case we would decorate BasicType with the existing
> definitions of = and ~= so we could create a new library structure
> for the logic system. So BasicType would contain
> 
> theorem = (a, b : Type) : Boolean := .....
> theorem ~= (a, b : Type) : Boolean := ....
> 
> These theorems would be imported into NNI when it inherits the
> signatures from the BasicType Category. The collection of all of
> the theorems in NNI's Category structure would be used (hopefully
> exclusively) to prove GCD. In this way, all of the theorems used to
> prove Axiom source code would be inheritied from the Category
> structure.


Parameter BasicType:Type.
Parameter eq: BasicType -> BasicType -> bool.
Parameter neq: BasicType -> BasicType -> bool.
Infix "=" := eq.

Parameter x y z:BasicType.
Check (x=y).

There are several better choices of course: Module Type or type classes,
whereas I'm not very used to the latter.

> 
> Unfortunately it appears the Coq and Lean will not take kindly to
> removing the existing libraries and replacing them with a new version
> that only contains a limited number of theorems. I'm not yet sure about
> FoCaL but I suspect it has the same bootstrap problem.

I think you can overwrite anything and even do a

$ coqtop -noinit

so that even "nat" is unknown.

Coq < Check nat.
Toplevel input, characters 6-9:
> Check nat.
>       ^^^
Error: The reference nat was not found in the current environment.

> 
> Jeremy Avigad (Lean) made the suggestion to rename these theorems.
> Thus, instead of =, the supporting theorem would be 'spad=' (spad is
> the name of Axiom's algebra language).
> 
> Initially this would make Axiom depend on the external library structure.
> Eventually there should be enough embedded logic to start coding Axiom
> theorems by changing external references from = to spad= everywhere.
> 
> Axiom proofs would still depend on the external proof system but only
> for the correctness engine, not the library structure. This will minimize
> the struggle about Axiom's world view (e.g. handling excluded middle).
> It will also organize the logic library to more closely mirror abstract algebra.

Indeed, this is an important point when dealing with dependent types. Type
classes
(http://www.labri.fr/perso/casteran/CoqArt/TypeClassesTut/typeclassestut.pdf)
presumably could serve best to map the spad categories while reasoning in CoC
(whilst "exlcuded middle" may be introduced as needed).

> 
> Comments, suggestions?

I believe that some more research will be necessary to find the most suitable
approach before building a prototype. I should dig into the "type classes"
subject before making any suggestions.

BTW I have recently written "field_mpl.v" (attached) for a talk about MPL where
you can see how tedious it can be to prove simple facts from scratch, whereas
the last prop (P1) goes with ease owing to solid preparations (it's educational
only of course).
> 
> Tim
> 
> 
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> Axiom-developer@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/axiom-developer
> 

--------------242E01CAAAC57564FEDE2669
Content-Type: text/plain; charset=UTF-8;
 name="field_mpl.v"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="field_mpl.v"

Module Field.

Parameter F : Set.
Parameter plus : F->F->F.
Parameter times : F->F->F.
Parameter null : F.
Parameter one : F.
Parameter neg : F->F.
Parameter inv : F->F.

Infix "+" := plus.
Infix "*" := times.
Notation "0" := null.
Notation "1" := one.
Notation "- 1":=(neg one).
Notation "- u" := (neg u).
Notation "1 / u" := (inv u) 
 (at level 75, right associativity).

Axiom F1: forall u v:F, exists w:F, w=u+v.
Axiom F2: forall u v:F, exists w:F, w=u*v.
Axiom F3: forall u v:F, u+v = v+u.
Axiom F4: forall u v:F, u*v = v*u.
Axiom F5: forall u v w:F, u+(v+w) = (u+v)+w.
Axiom F6: forall u v w:F, u*(v*w) = (u*v)*w.
Axiom F7: forall u v w:F, u*(v+w) = (u*v)+(u*w).
Axiom F8: forall u v w:F, (u+v)*w = (u*w)+(v*w).
Axiom F9: forall u:F, u+0 = u.
Axiom F10: forall u:F, u*1 = u.
Axiom F11: forall u:F, u+(-u) = 0.
Axiom F12: forall u:F, ~(u=0) -> u * (1/u) = 1.
Axiom F13: 1 <> 0.


Proposition null_unique: forall n:F, (forall u:F, u+n=u) -> n=0.
proof.
let n:F.
assume(forall u : F, u+n = u).
then (0 + n = 0).
then f1:(n+0 = 0) by F3.
then f2:(n+0 = n) by F9.
thus thesis by f1,f2.
end proof.
Qed.

Proposition one_unique: forall e:F, (forall u:F, u*e=u) -> e=1.
proof.
let e:F.
assume(forall u : F, u*e = u).
then (1*e = 1).
then f1:(e*1 = 1) by F4.
then f2:(e*1 = e) by F10.
thus thesis by f1,f2.
end proof.
Qed.

(*
Lemma neg_null: forall u:F, (u=neg u) -> u=null.
proof.
let u:F.
assume(u=neg u).
then (plus u u=plus u (neg u)).
then (plus u u=null) by F11.
end proof.
Qed.
*)

Proposition neg_unique: forall u:F, forall v:F, (u+v=0) -> v=-u.
proof.
let u:F, v:F.
assume(u+v = 0).
then ((-u)+(u+v)=(-u)+0).
then f1:((-u) + (u+v)=-u) by F9.
then ((-u) + (u+v)=((-u)+u)+v) by F5.
then ((-u) + (u+v)=(u + (-u)) + v) by F3.
then ((-u) + (u+v)=0+v) by F11.
then  f2:((-u)+(u+v)=v) by F3,F9.
thus thesis by f1,f2.
end proof.
Qed.


Proposition inv_unique: forall u:F, forall v:F, (~(u=0)/\(u*v=1)) -> v=(1/u).
proof.
let u:F, v:F.
assume a:(u<>0 /\ u * v = 1).
then ((1/u)*(u*v)=((1/u)*1)).
then f1:((1/u)*(u*v)=(1/u)) by F10.
then ((1/u)*(u*v)=((1/u)*u)*v) by F6.
then ((1/u)*(u*v)=(u*(1/u))*v) by F4.
then ((1/u)*(u*v)=1*v) by a,F12.
then f2:((1/u)*(u*v)=v) by F4,F10.
thus thesis by f1,f2.
end proof.
Qed.

Proposition times_null: forall u:F, u*0 = 0.
proof.
let u:F.
then(u * (0+0) = (u*0) + (u*0)) by F7.
then(u*0 = (u*0) + (u*0)) by F9.
then(0 = ((u*0) + (u*0)) + (- (u*0))) by F11.
then(0 = (u*0) + ((u*0) + (- (u*0)))) by F5.
then(0 = (u*0) + 0) by F11.
then(0 = u * 0) by F9.
then f1:(u * 0 = 0)  by F4.
take f1.
end proof.
Qed.

Proposition neg_is_neg_one_times: forall u:F, -u =  (- 1) * u.
proof.
let u:F.
then(u + ( - 1 * u) = (u * 1) + (u * - 1)) by F4,F10.
then(u + ( - 1 * u)= u * (1 + - 1)) by F7.
then(u + ( - 1 * u)= u * 0) by F11.
then f1:(u + ( - 1 * u)= 0) by times_null.
thus thesis by f1,neg_unique.
end proof.
Qed.

Proposition neg_null_is_null: - 0 = 0.
proof.
have f1:(0+0 = 0) by F9.
thus thesis by f1, neg_unique.
end proof.
Qed.

Proposition inv_one_is_one: (1/1) = 1.
proof.
have f1:(1 * 1 = 1) by F10.
thus thesis by f1,F13,inv_unique.
end proof.
Qed.

Lemma neg_one_neq_null: not (- (1) = 0).
proof.
assume(- (1)= 0).
then f1:(1 +  -1 = 1+0) by F11.
then f2:(1 + - 1 = 1) by F9.
then f3:(0 = 1) by f2,F11.
thus thesis by f3,F13.
end proof.
Qed.


Proposition inv_neg_one_is_neg_one : (1/ - 1 ) = - 1.
proof.
have (- 1 * (1/- 1 )= 1)  by neg_one_neq_null,F12.
then f1:((1 + - 1) * (1/ - 1)= 0) by F11,F4,times_null.
then f2:( (1 + - 1) * (1/ - 1)= (1* (1/ - 1)) + (- 1 * (1/ - 1))) by F8.
then f3:((1+ - 1) * (1/- 1)= (1/ - 1) + 1)  by F4,F10,F12, neg_one_neq_null.
then f4:(0 =  (1/- 1) +1) by f1,f3.
then f5: (1+ (1/ - 1) = 0) by f4,F3.
thus thesis by neg_unique, f5.
end proof.
Qed.
  

Lemma neg_one_times_neg_one_is_one: -1 * -1 =1.
proof.
have f1:(-1*(1+ -1)=0) by F11, times_null.
then f2:(-1*(1+ -1)=-1*1 + -1*-1) by F7.
then f3:(-1*(1+ -1)=-1 + -1*-1) by f2,F10.
then f4:( 0=-1+ -1*-1) by f3,f1.
then (1+0 = 1 + (-1+ -1*-1) ) by f4.
then (1=(1+-1)+ (-1*-1)) by F5,F9.
then (1=0+(-1*-1)) by F11.
then f8:(1=(-1*-1)+0) by F3.
thus thesis by f8,F3,F9.
end proof.
Qed.


Proposition neg_times_neg_is_plus: forall u v:F, (-u)*(-v)=u*v.
proof.
let u:F, v:F.
have f1: ( -u = -1*u) by neg_is_neg_one_times.
have f2: ( -v = -1*v) by neg_is_neg_one_times.
then (-u * -v = (-1*u)*(-1*v)) by f1,f2.
then (-u * -v = ((-1*u)*-1)*v) by F6.
then (-u * -v = (-1*(-1*u))*v) by F4.
then  (-u * -v = ((-1*-1)*u)*v) by F6.
then  (-u * -v = (1*u)*v) by neg_one_times_neg_one_is_one.
then f3:(-u * -v = u*v) by F4,F10.
thus thesis by f3.
end proof.
Qed.

Lemma not_null_then_inv_not_null: forall u:F, u<>0 -> (1/u)<>0.
proof.
let u:F.
assume f1:(u<>0).
assume f2:( (1/u)=0).
then f3:(u*(1/u)=1) by f1,F12.
then (u*(1/u)=u*0) by f1,f2.
then f4:(1=u*0) by f3.
thus thesis by f4,times_null, F13.
end proof.
Qed.

Proposition inv_inv_is_id: forall u:F, ~(u=0) -> (1 / (1 / u)) = u.
proof.
let u:F.
assume h1:(u<>0).
have(u* (1/u)=1) by h1,F12.
then f1:( (1/u)*u=1) by F4.
then f2:((1/u)*(1 / (1/u))=1) by h1,not_null_then_inv_not_null, F12.
then ( (1/u)*(1 / (1/u)) = (1/u)*u ) by f1,f2.
then (  (1 / 1/u)*( (1/u)*(1 / (1/u))) = (1 / 1/u) * ( (1/u)*u )).
then (  ((1 / 1/u)* (1/u)) * (1 / (1/u)) =  ((1 / 1/u) *  (1/u))*u ) by F6.
then (  ( (1/u)*(1 / 1/u)) * (1 / (1/u)) =  ( (1/u)*(1 / 1/u))*u ) by F4.
then f3:( 1* (1 / (1/u)) = 1*u) by f2.
thus thesis by f3,F4, F10.
end proof.
Qed.

Lemma prod_not_null: forall u v:F, ((u<>0)/\ (v<>0)) -> (u*v<>0).
proof.
let u:F, v:F.
assume h1:(u <> 0 /\ v <> 0).
then f1:(u<>0) by h1.
then f2:(v<>0) by h1.
assume h2:(u*v=0).
then (u*v=u*0) by times_null.
then ( (1/u)*(u*v) = (1/u)*(u*0)) by f1,F12.
then ( (u*(1/u))*v=(u*(1/u))*0) by F6,F4.
then f3:(v=0) by f1,F4,F12,F10.
thus thesis by f2,f3.
end proof.
Qed.


Proposition inv_prod_is_prod_inv: forall u v:F, ((u<>0)/\ (v<>0)) -> 
  ((1/(u*v)) = (1/u)*(1/v)).
proof.
let u :F, v:F.
assume h1:(u <> 0 /\ v <> 0).
then f1:(u<>0) by h1.
then f2:(v<>0) by h1.
then f3:((u*v)<>0) by f1,f2,prod_not_null.
then ( (u*v)* ((1/u)*(1/v)) = (u*v)* ((1/v)*(1/u))) by F4.
then ( (u*v)* ((1/u)*(1/v)) = ((u*v)* (1/v))*(1/u)) by F6.
then ( (u*v)* ((1/u)*(1/v)) = (u*(v* (1/v))*(1/u))) by F6.
then ( (u*v)* ((1/u)*(1/v)) = (u*1)*(1/u)) by f2,F12.
then ( (u*v)* ((1/u)*(1/v)) = (u*(1/u))) by F10.
then ((u*v)* ((1/u)*(1/v)) = 1) by f1,F12.
then f4:((1/u)*(1/v)=(1 / u * v) ) by f3,inv_unique.
thus thesis by f4.
end proof.
Qed.


End Field.


Let S:=Field.F.
Notation "x + y":=(Field.plus x y).
Notation "x * y":=(Field.times x y).
Lemma comm: forall x y:S,x+y=y+x. 
proof.
intros.
thus thesis by Field.F3.
end proof.
Qed.

Definition addAndSquare(a b:S):S:=(a+b)*(a+b).
Definition sq(a:S):S:=a*a.

Check addAndSquare Field.one Field.one.
Compute addAndSquare Field.one Field.null.

Proposition P1:forall a b:S, addAndSquare a b =
  (sq a) + (sq b)+a*b+b*a.
proof.
let u:S.
let v:S.
compute.
thus thesis by Field.F7,Field.F8,Field.F3,Field.F5.
end proof.
Qed.

(*
have f1:((u+v)*(u+v) =u*(u+v)+v*(u+v)) by Field.F8.
then f2:((u+v)*(u+v) = u*u+u*v+v*(u+v)) by f1,Field.F7.
then f3:((u+v)*(u+v)= u*u+u*v+v*u+v*v) by f2, Field.F7,Field.F3,Field.F5.
thus thesis by f3, Field.F3,Field.F5.
end proof.
Qed.
*)
 


--------------242E01CAAAC57564FEDE2669--

\start
Date: Wed, 8 Feb 2017 21:44:28 -0500
From: Jeremy Avigad <avigad@cmu.edu>
To: Tim Daly <axiomcas@gmail.com>
Cc: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>,
	Renaud Rioboo <renaud.rioboo@ensiie.fr>
Subject: Re: [Axiom-developer] [Proving Axiom Correct] Bootstrapping a
 library

On Wed, Feb 8, 2017 at 9:23 PM, Tim Daly <axiomcas@gmail.com> wrote:

> Part of your struggle of understanding what I wrote is that I'm not yet
> fluent in the
> logic language and syntax. I'm learning as fast as I can so please be
> patient.
>
> CATEGORY SIGNATURE vs DOMAIN SEMANTICS
>
> > Presumably you will eventually want to add axioms to the structures tha=
t
> say
> > things about what eq and neq do
>
> The semantics of =3D is given in the Domain (the current one being define=
d
> is called % in Spad)
> not in the Category (well...you can... sigh)
>
> Each domain that inherits '=3D' from the Category BasicType needs to spec=
ify
> the meaning
> of that function for the Domain you're implementing..
>

In our language, we would say that every instance of the structure has all
the necessary data. For example, every group (=3Dinstance of the group
structure, or element of the type group =CE=B1) has a unit, a binary operat=
ion,
and inverse operation, etc.


> For a Polynomial domain with some
> structural data representation you have to define what it means for two
> polynomial objects
> to be =3D. such as a function to compare coefficients. Part of the game
> would be to prove
> that the coefficient-compare function is correct, always returns a
> Boolean, and terminates.
>
> All a Category like BasicType does is specify that the Domain Polynomial
> should
> implement an =3D operation with the given signature.  That is, you have t=
o
> implement
>
>      poly =3D poly
>
> which returns a boolean. (Note that there are other =3D functions in
> Polynomial such as one
> that returns an equation object but that signature is inherited from a
> different Category).
>

Is there anything that requires that the operation you implement is
reflexive, symmetric, and transitive?  Putting axioms on the structure
specifies that that has to be the case. Without such axioms, you cannot
prove anything about implementations in general. You can only prove things
about individual implementations.


> It looks like your 'class' syntax implements what I need. I will try this
> for the other
> Categories used in NNI.
>
>
>
>
> PROVING TERMINATION
>
> As I understood from class, for an algorithm like gcd it should be
> sufficient to construct
> a function that fulfills the signature of
>
>    gcd(a:NNI,b:NNI):NNI
>
> Coq provides gcd as
>
>   Fixpoint gcd a b :=3D
>     match a with
>       | 0 =3D> b
>       | S a' =3D> gcd (b mod (S a')) (S a')
>     end.
>
> and Axiom's definition is
>
>   gcd(x:NNI,y:NNI):NNI =3D=3D
>     zero? x =3D> y
>     gcd(y rem x, x)
>
> Everything in Spad is strongly typed and function definitions are chosen
> not only
> by the arguments but also by the return type (so there can be multiple
> functions
> with the same name and same arguments but different return types, for
> example).
> Every statement in the function is strongly type-checked.
>

That is what I referred to as a shallow embedding -- you are associating to
every axiom definition a Coq or Lean definition which has the same behavior=
.

If you do that, you cannot model arbitrary while loops. You have to write
functions in Coq or Lean in a way that, from the start, they are guaranteed
to terminate. You can do this, for example, by showing the recursive calls
are decreasing along a suitable measure, or giving a priori bounds on a
while loop. If you want to translate spad functions automatically, you'll
have to write the former in such a way that the translations have this
property. You can't translate an arbitrary, a priori partial, function and
then show after the fact that it terminates for every input.

Other approaches are possible. You can, for example, translate spad
functions to relations in Coq or Lean, and then prove that the relations
give rise to total functions.

Best wishes,

Jeremy



>
> Thus we are guaranteed that the Spad version of gcd above (in the Domain
> NNI)
> can only be called with NNI arguments and is guaranteed to only return NN=
I
> results.
>
> The languages are very close in spirit if not in syntax.
>
> What Axiom does not do, for example, is prove termination.
>
> Coq, in its version, will figure out that the recursion is on 'a' and tha=
t
> it will terminate.
>
> Part of the game is to provide the same termination analysis on Spad code=
.
>
>
>
>
> ADDITIONAL CONSTRAINTS
>
> It would be ideal to reject code that did not fulfill all of the
> requirements
> such as specifying at the Category level definition of gcd that it not on=
ly
> has to have the correct signature, it also has to return the 'positive'
> divisor. For NNI this is trivially fulfilled.
>
> The Category definition should say something like
>
>    gcd(%,%) -> %  and gcd >=3D 1$%
>
> where 1$% says to use the unit from the implementing Domain.
>
> So for some domains we have:
>
>   gcd(x,y) =3D=3D
>     x :=3D unitCanonical x
>     y :=3D unitCanonical y
>     while not zero? y repeat
>       (x,y) :=3D (y, x rem y)
>       y :=3D unitCanonical y
>     x
>
> using unitCanonical to deal with things like signs. (This also adds the
> complication
> of loops which I mentioned in a previous email.)
>
> Not only the signature but the side-conditions would have to be checked.
>
>
>
>
>
>
> ALTERNATE APPROACHES
>
> Instead of a new library organization it might be possible to have a
> generator function
> in Coq that translates Coq code to Spad code. Or a translator from Spad
> code to
> Coq code.
>
> Unfortunately Coq and Lean do not seem to use function name overloading
> or inheritance (or do they?) which confuses the problem of name
> translation.
>
> Axiom has 42 functions named 'gcd', each living in a different Domain.
>
>
>
>
>
> There is no such thing as a simple job. But this one promises to be
> interesting.
>
> In any case I'll push the implementation forward. Thanks for your help.
>
> Tim
>
>
>
>
>
>
> On Wed, Feb 8, 2017 at 5:52 PM, Jeremy Avigad <avigad@cmu.edu> wrote:
>
>> Dear Tim,
>>
>> I don't understand what you mean. For one thing, theorems in both Lean
>> and Coq are marked as opaque, since you generally don't care about the
>> contents. But even if we replace "theorem" by "definition," I don't know
>> what you imagine going into the "...".
>>
>> I think what you want to do is represent Axiom categories as structures.
>> For example, the declarations below declare a BasicType structure and
>> notation for elements of that structure. You can then prove theorems abo=
ut
>> arbitrary types =CE=B1 that have a BasicType structure. You can also ext=
end the
>> structure as needed.
>>
>> (Presumably you will eventually want to add axioms to the structures tha=
t
>> say things about what eq and neq do. Otherwise, you are just reasoning
>> about a type with two relations.)
>>
>> Best wishes,
>>
>> Jeremy
>>
>> class BasicType (=CE=B1 : Type) : Type :=3D
>> (eq : =CE=B1 =E2=86=92 =CE=B1 =E2=86=92 bool) (neq : =CE=B1 =E2=86=92 =
=CE=B1 =E2=86=92 bool)
>>
>> infix `?=3D?`:50  :=3D BasicType.eq
>> infix `?~=3D?`:50 :=3D BasicType.neq
>>
>> section
>>   variables (=CE=B1 : Type) [BasicType =CE=B1]
>>   variables a b : =CE=B1
>>
>>   check a ?=3D? b
>>   check a ?~=3D? b
>> end
>>
>>
>>
>>
>> On Wed, Feb 8, 2017 at 9:29 AM, Tim Daly <axiomcas@gmail.com> wrote:
>>
>>> The game is to prove GCD in NonNegativeInteger (NNI).
>>>
>>> We would like to use the 'nat' theorems from the existing library
>>> but extract those theorems automatically from Axiom sources
>>> at build time.
>>>
>>> Axiom's NNI inherits from a dozen Category objects, one of which
>>> is BasicType which contains two signatures:
>>>
>>>  ?=3D?: (%,%) -> Boolean       ?~=3D?: (%,%) -> Boolean
>>>
>>> In the ideal case we would decorate BasicType with the existing
>>> definitions of =3D and ~=3D so we could create a new library structure
>>> for the logic system. So BasicType would contain
>>>
>>> theorem =3D (a, b : Type) : Boolean :=3D .....
>>> theorem ~=3D (a, b : Type) : Boolean :=3D ....
>>>
>>> These theorems would be imported into NNI when it inherits the
>>> signatures from the BasicType Category. The collection of all of
>>> the theorems in NNI's Category structure would be used (hopefully
>>> exclusively) to prove GCD. In this way, all of the theorems used to
>>> prove Axiom source code would be inheritied from the Category
>>> structure.
>>>
>>> Unfortunately it appears the Coq and Lean will not take kindly to
>>> removing the existing libraries and replacing them with a new version
>>> that only contains a limited number of theorems. I'm not yet sure about
>>> FoCaL but I suspect it has the same bootstrap problem.
>>>
>>> Jeremy Avigad (Lean) made the suggestion to rename these theorems.
>>> Thus, instead of =3D, the supporting theorem would be 'spad=3D' (spad i=
s
>>> the name of Axiom's algebra language).
>>>
>>> Initially this would make Axiom depend on the external library structur=
e.
>>> Eventually there should be enough embedded logic to start coding Axiom
>>> theorems by changing external references from =3D to spad=3D everywhere=
.
>>>
>>> Axiom proofs would still depend on the external proof system but only
>>> for the correctness engine, not the library structure. This will minimi=
ze
>>> the struggle about Axiom's world view (e.g. handling excluded middle).
>>> It will also organize the logic library to more closely mirror abstract
>>> algebra.
>>>
>>> Comments, suggestions?
>>>
>>> Tim

\start
Date: Wed, 8 Feb 2017 22:27:54 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Kurt Pagani <nilqed@gmail.com>, axiom-dev <axiom-developer@nongnu.org>
Subject: [Axiom-developer] [Proving Axiom Correct] Kurt's comments and reply
Cc: Tim Daly <daly@axiom-developer.org>, Jeremy Avigad <avigad@cmu.edu>, 
	Laurent Thery <Laurent.Thery@inria.fr>,
	Renaud Rioboo <renaud.rioboo@ensiie.fr>

To: axiom-developer@nongnu.org
From: Kurt Pagani <nilqed@gmail.com>
Date: Thu, 9 Feb 2017 03:23:48 +0100

>> The game is to prove GCD in NonNegativeInteger (NNI).
>
>We encounter numerous problems when trying to prove gcd from
EuclideanDomain:
>
>---
>gcd(x, y) ==   --Euclidean Algorithm
>  x := unitCanonical x
>  y := unitCanonical y
>  while not zero? y repeat
>    (x, y) := (y, x rem y)
>    y := unitCanonical y     -- this doesn't affect the
>                             -- correctness of Euclid's algorithm,
>                             -- but
>                             -- a) may improve performance
>                             -- b) ensures gcd(x, y)=gcd(y, x)
>                             --    if canonicalUnitNormal
>  x
>
>---
>
>1. Define type EuclideanDomain (tower of hierarchies)
>2. Define unitCanonical (depends on canonicalUnitNormal etc.)
>3. Imperative elements in spad
>4. Trust interpreter/compiler and lisp
>


>While (1,2) seems not so difficult,

Indeed, I'm trying to construct the Category tower for NNI. Jeremy
suggested using the 'class' mechanism (which I'm currently reading).
Instantiating the Domain NNI should cause all of the classes from all
of the referenced Categories to become available.

I've also looked a bit at the unitCanonical/unitNormal question. See
http://axiom-developer.org/axiom-website/bookvol13.pdf
where I'm taking notes on proving Axiom correct.




>(3) might be delicate

Jeremy recommended the book 'Concrete Semantics (free PDF at
http://www.concrete-semantics.org/) that looks like it addresses
Hoare triples for loop pre-/post-conditions. I had a discussion about
potentially creating a 'while' tactic that might help loop proofs.

Axiom tends to use variables as 'named constants' in that, except for
loops, they tend to have a single assignment. Where that isn't true it
(should?) be easy to introduce a new constant instead of a reassignment.
Single assignment of local variables does not affect the purity of a
function.





>(4) seems to be
>out of scope for the moment (that is let's trust it, as an axiom so to
speak ).

Actually, this is 'in scope' also. I have automated the use of ACL2 for
proving the lisp code in the compiler and interpreter. I have proven one
lisp function so far (just to 'turn the crank') and more are in plan. The
first
real step is developing signatures for all of the functions. In Volume 5,
the interpreter, you'll find a new appendix listing the signatures of
functions.
http://axiom-developer.org/axiom-website/bookvol5,pdf

I didn't mention it here because this group of people are working much
closer to the Spad level, not the Lisp level. I've had Lisp-level
discussions
(offline so far) but I certainly plan to provide proofs of the
interpreter/compiler
code base. Spad is, after all, just a domain specific language in lisp.





>
>Basically, I see two methods:
>
>a) Implement spad language, e.g. like the "Imp" example:
>https://www.seas.upenn.edu/~cis500/current/sf/Imp.html
>and prove the statements.

Implementing another, compatible Spad compiler would be much too
difficult. The compiler has to know about subtle things like 'the add chain'
and name overloading and many other issues. Besides, that would have
to be proven anyway. So instead of making progress on proofs we'd be
back to pre-compiler problems.




>
>b) Prove the math (by reusing existing [abundant] math libraries) and
extract
>the functions (Definitions in Coq) as spad code.
>This would actually mean to replace parts of current code by new one
(purely
>functional).

I'm perfectly willing to replace existing code with code that can be proven
correct that implements the same functionality. The need to do that is
almost
a certainty. I expect that this effort will push the bounds of Axiom as
well as
Coq/Lean/FoCaL and ACL2. But the time has come to require proofs of
computational mathematics.




>
>Clearly, both methods will require a definition of spad's key
>functions/operators. I believe that (a) is more laborious than (b).
Moreover,
>Coq's notation mechanism (Notation) has it's limits (e.g. conflicts with
>built-in keywords)(**). Moreover, method (b) is admittedly not what we
really
>want: namely proving existing Axiom code correct.

Why do you say that (b) is not what we really want? I expect that the
proof effort will uncover a lot of problems in Spad code. The hope is
that it improves Axiom.


...clipped...


>
>
>Parameter BasicType:Type.
>Parameter eq: BasicType -> BasicType -> bool.
>Parameter neq: BasicType -> BasicType -> bool.
>Infix "=" := eq.
>
>Parameter x y z:BasicType.
>Check (x=y).
>
>There are several better choices of course: Module Type or type classes,
>whereas I'm not very used to the latter.

Indeed, neither am I but Jeremy's example is a starting point.





>
>>
>> Unfortunately it appears the Coq and Lean will not take kindly to
>> removing the existing libraries and replacing them with a new version
>> that only contains a limited number of theorems. I'm not yet sure about
>> FoCaL but I suspect it has the same bootstrap problem.
>
>I think you can overwrite anything and even do a
>
>$ coqtop -noinit
>
>so that even "nat" is unknown.
>
>Coq < Check nat.
>Toplevel input, characters 6-9:
>> Check nat.
>>       ^^^
>Error: The reference nat was not found in the current environment.

SWEET! (Does it sing Daisy? :-) (https://en.wikipedia.org/wiki/Daisy_Bell)

This might allow us to restructure the Coq libraries to match the Axiom
Category type tower. If so, I can automate extracting the 'class'
information directly from the Category structure when proving a Domain
function.




>
>>
>> Jeremy Avigad (Lean) made the suggestion to rename these theorems.
>> Thus, instead of =, the supporting theorem would be 'spad=' (spad is
>> the name of Axiom's algebra language).
>>
>> Initially this would make Axiom depend on the external library structure.
>> Eventually there should be enough embedded logic to start coding Axiom
>> theorems by changing external references from = to spad= everywhere.
>>
>> Axiom proofs would still depend on the external proof system but only
>> for the correctness engine, not the library structure. This will minimize
>> the struggle about Axiom's world view (e.g. handling excluded middle).
>> It will also organize the logic library to more closely mirror abstract
algebra.
>
>Indeed, this is an important point when dealing with dependent types. Type
>classes
>(
http://www.labri.fr/perso/casteran/CoqArt/TypeClassesTut/typeclassestut.pdf)
>presumably could serve best to map the spad categories while reasoning in
CoC
>(whilst "exlcuded middle" may be introduced as needed).

Thanks for the link... more to know.






>> Comments, suggestions?
>
>I believe that some more research will be necessary to find the most
suitable
>approach before building a prototype. I should dig into the "type classes"
>subject before making any suggestions.

I'm going to try to build the 'class' definitions for the Category
hierarchy used
by NNI and automate their extraction, followed by proving gcd automatically.
Hopefully. Maybe. The idea is to 'turn the crank' for the first time and
create
a prototype proof environment that runs during system builds.




>
>BTW I have recently written "field_mpl.v" (attached) for a talk about MPL
where
>you can see how tedious it can be to prove simple facts from scratch,
whereas
>the last prop (P1) goes with ease owing to solid preparations (it's
educational
>only of course).

Thanks. I'll look at it in detail.




Tim




>
>--------------242E01CAAAC57564FEDE2669
>Content-Type: text/plain; charset=UTF-8;
> name="field_mpl.v"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment;
> filename="field_mpl.v"
>
>Module Field.
>
>Parameter F : Set.
>Parameter plus : F->F->F.
>Parameter times : F->F->F.
>Parameter null : F.
>Parameter one : F.
>Parameter neg : F->F.
>Parameter inv : F->F.
>
>Infix "+" := plus.
>Infix "*" := times.
>Notation "0" := null.
>Notation "1" := one.
>Notation "- 1":=(neg one).
>Notation "- u" := (neg u).
>Notation "1 / u" := (inv u)
> (at level 75, right associativity).
>
>Axiom F1: forall u v:F, exists w:F, w=u+v.
>Axiom F2: forall u v:F, exists w:F, w=u*v.
>Axiom F3: forall u v:F, u+v = v+u.
>Axiom F4: forall u v:F, u*v = v*u.
>Axiom F5: forall u v w:F, u+(v+w) = (u+v)+w.
>Axiom F6: forall u v w:F, u*(v*w) = (u*v)*w.
>Axiom F7: forall u v w:F, u*(v+w) = (u*v)+(u*w).
>Axiom F8: forall u v w:F, (u+v)*w = (u*w)+(v*w).
>Axiom F9: forall u:F, u+0 = u.
>Axiom F10: forall u:F, u*1 = u.
>Axiom F11: forall u:F, u+(-u) = 0.
>Axiom F12: forall u:F, ~(u=0) -> u * (1/u) = 1.
>Axiom F13: 1 <> 0.
>
>
>Proposition null_unique: forall n:F, (forall u:F, u+n=u) -> n=0.
>proof.
>let n:F.
>assume(forall u : F, u+n = u).
>then (0 + n = 0).
>then f1:(n+0 = 0) by F3.
>then f2:(n+0 = n) by F9.
>thus thesis by f1,f2.
>end proof.
>Qed.
>
>Proposition one_unique: forall e:F, (forall u:F, u*e=u) -> e=1.
>proof.
>let e:F.
>assume(forall u : F, u*e = u).
>then (1*e = 1).
>then f1:(e*1 = 1) by F4.
>then f2:(e*1 = e) by F10.
>thus thesis by f1,f2.
>end proof.
>Qed.
>
>(*
>Lemma neg_null: forall u:F, (u=neg u) -> u=null.
>proof.
>let u:F.
>assume(u=neg u).
>then (plus u u=plus u (neg u)).
>then (plus u u=null) by F11.
>end proof.
>Qed.
>*)
>
>Proposition neg_unique: forall u:F, forall v:F, (u+v=0) -> v=-u.
>proof.
>let u:F, v:F.
>assume(u+v = 0).
>then ((-u)+(u+v)=(-u)+0).
>then f1:((-u) + (u+v)=-u) by F9.
>then ((-u) + (u+v)=((-u)+u)+v) by F5.
>then ((-u) + (u+v)=(u + (-u)) + v) by F3.
>then ((-u) + (u+v)=0+v) by F11.
>then  f2:((-u)+(u+v)=v) by F3,F9.
>thus thesis by f1,f2.
>end proof.
>Qed.
>
>
>Proposition inv_unique: forall u:F, forall v:F, (~(u=0)/\(u*v=1)) ->
v=(1/u).
>proof.
>let u:F, v:F.
>assume a:(u<>0 /\ u * v = 1).
>then ((1/u)*(u*v)=((1/u)*1)).
>then f1:((1/u)*(u*v)=(1/u)) by F10.
>then ((1/u)*(u*v)=((1/u)*u)*v) by F6.
>then ((1/u)*(u*v)=(u*(1/u))*v) by F4.
>then ((1/u)*(u*v)=1*v) by a,F12.
>then f2:((1/u)*(u*v)=v) by F4,F10.
>thus thesis by f1,f2.
>end proof.
>Qed.
>
>Proposition times_null: forall u:F, u*0 = 0.
>proof.
>let u:F.
>then(u * (0+0) = (u*0) + (u*0)) by F7.
>then(u*0 = (u*0) + (u*0)) by F9.
>then(0 = ((u*0) + (u*0)) + (- (u*0))) by F11.
>then(0 = (u*0) + ((u*0) + (- (u*0)))) by F5.
>then(0 = (u*0) + 0) by F11.
>then(0 = u * 0) by F9.
>then f1:(u * 0 = 0)  by F4.
>take f1.
>end proof.
>Qed.
>
>Proposition neg_is_neg_one_times: forall u:F, -u =  (- 1) * u.
>proof.
>let u:F.
>then(u + ( - 1 * u) = (u * 1) + (u * - 1)) by F4,F10.
>then(u + ( - 1 * u)= u * (1 + - 1)) by F7.
>then(u + ( - 1 * u)= u * 0) by F11.
>then f1:(u + ( - 1 * u)= 0) by times_null.
>thus thesis by f1,neg_unique.
>end proof.
>Qed.
>
>Proposition neg_null_is_null: - 0 = 0.
>proof.
>have f1:(0+0 = 0) by F9.
>thus thesis by f1, neg_unique.
>end proof.
>Qed.
>
>Proposition inv_one_is_one: (1/1) = 1.
>proof.
>have f1:(1 * 1 = 1) by F10.
>thus thesis by f1,F13,inv_unique.
>end proof.
>Qed.
>
>Lemma neg_one_neq_null: not (- (1) = 0).
>proof.
>assume(- (1)= 0).
>then f1:(1 +  -1 = 1+0) by F11.
>then f2:(1 + - 1 = 1) by F9.
>then f3:(0 = 1) by f2,F11.
>thus thesis by f3,F13.
>end proof.
>Qed.
>
>
>Proposition inv_neg_one_is_neg_one : (1/ - 1 ) = - 1.
>proof.
>have (- 1 * (1/- 1 )= 1)  by neg_one_neq_null,F12.
>then f1:((1 + - 1) * (1/ - 1)= 0) by F11,F4,times_null.
>then f2:( (1 + - 1) * (1/ - 1)= (1* (1/ - 1)) + (- 1 * (1/ - 1))) by F8.
>then f3:((1+ - 1) * (1/- 1)= (1/ - 1) + 1)  by F4,F10,F12,
neg_one_neq_null.
>then f4:(0 =  (1/- 1) +1) by f1,f3.
>then f5: (1+ (1/ - 1) = 0) by f4,F3.
>thus thesis by neg_unique, f5.
>end proof.
>Qed.
>
>
>Lemma neg_one_times_neg_one_is_one: -1 * -1 =1.
>proof.
>have f1:(-1*(1+ -1)=0) by F11, times_null.
>then f2:(-1*(1+ -1)=-1*1 + -1*-1) by F7.
>then f3:(-1*(1+ -1)=-1 + -1*-1) by f2,F10.
>then f4:( 0=-1+ -1*-1) by f3,f1.
>then (1+0 = 1 + (-1+ -1*-1) ) by f4.
>then (1=(1+-1)+ (-1*-1)) by F5,F9.
>then (1=0+(-1*-1)) by F11.
>then f8:(1=(-1*-1)+0) by F3.
>thus thesis by f8,F3,F9.
>end proof.
>Qed.
>
>
>Proposition neg_times_neg_is_plus: forall u v:F, (-u)*(-v)=u*v.
>proof.
>let u:F, v:F.
>have f1: ( -u = -1*u) by neg_is_neg_one_times.
>have f2: ( -v = -1*v) by neg_is_neg_one_times.
>then (-u * -v = (-1*u)*(-1*v)) by f1,f2.
>then (-u * -v = ((-1*u)*-1)*v) by F6.
>then (-u * -v = (-1*(-1*u))*v) by F4.
>then  (-u * -v = ((-1*-1)*u)*v) by F6.
>then  (-u * -v = (1*u)*v) by neg_one_times_neg_one_is_one.
>then f3:(-u * -v = u*v) by F4,F10.
>thus thesis by f3.
>end proof.
>Qed.
>
>Lemma not_null_then_inv_not_null: forall u:F, u<>0 -> (1/u)<>0.
>proof.
>let u:F.
>assume f1:(u<>0).
>assume f2:( (1/u)=0).
>then f3:(u*(1/u)=1) by f1,F12.
>then (u*(1/u)=u*0) by f1,f2.
>then f4:(1=u*0) by f3.
>thus thesis by f4,times_null, F13.
>end proof.
>Qed.
>
>Proposition inv_inv_is_id: forall u:F, ~(u=0) -> (1 / (1 / u)) = u.
>proof.
>let u:F.
>assume h1:(u<>0).
>have(u* (1/u)=1) by h1,F12.
>then f1:( (1/u)*u=1) by F4.
>then f2:((1/u)*(1 / (1/u))=1) by h1,not_null_then_inv_not_null, F12.
>then ( (1/u)*(1 / (1/u)) = (1/u)*u ) by f1,f2.
>then (  (1 / 1/u)*( (1/u)*(1 / (1/u))) = (1 / 1/u) * ( (1/u)*u )).
>then (  ((1 / 1/u)* (1/u)) * (1 / (1/u)) =  ((1 / 1/u) *  (1/u))*u ) by F6.
>then (  ( (1/u)*(1 / 1/u)) * (1 / (1/u)) =  ( (1/u)*(1 / 1/u))*u ) by F4.
>then f3:( 1* (1 / (1/u)) = 1*u) by f2.
>thus thesis by f3,F4, F10.
>end proof.
>Qed.
>
>Lemma prod_not_null: forall u v:F, ((u<>0)/\ (v<>0)) -> (u*v<>0).
>proof.
>let u:F, v:F.
>assume h1:(u <> 0 /\ v <> 0).
>then f1:(u<>0) by h1.
>then f2:(v<>0) by h1.
>assume h2:(u*v=0).
>then (u*v=u*0) by times_null.
>then ( (1/u)*(u*v) = (1/u)*(u*0)) by f1,F12.
>then ( (u*(1/u))*v=(u*(1/u))*0) by F6,F4.
>then f3:(v=0) by f1,F4,F12,F10.
>thus thesis by f2,f3.
>end proof.
>Qed.
>
>
>Proposition inv_prod_is_prod_inv: forall u v:F, ((u<>0)/\ (v<>0)) ->
>  ((1/(u*v)) = (1/u)*(1/v)).
>proof.
>let u :F, v:F.
>assume h1:(u <> 0 /\ v <> 0).
>then f1:(u<>0) by h1.
>then f2:(v<>0) by h1.
>then f3:((u*v)<>0) by f1,f2,prod_not_null.
>then ( (u*v)* ((1/u)*(1/v)) = (u*v)* ((1/v)*(1/u))) by F4.
>then ( (u*v)* ((1/u)*(1/v)) = ((u*v)* (1/v))*(1/u)) by F6.
>then ( (u*v)* ((1/u)*(1/v)) = (u*(v* (1/v))*(1/u))) by F6.
>then ( (u*v)* ((1/u)*(1/v)) = (u*1)*(1/u)) by f2,F12.
>then ( (u*v)* ((1/u)*(1/v)) = (u*(1/u))) by F10.
>then ((u*v)* ((1/u)*(1/v)) = 1) by f1,F12.
>then f4:((1/u)*(1/v)=(1 / u * v) ) by f3,inv_unique.
>thus thesis by f4.
>end proof.
>Qed.
>
>
>End Field.
>
>
>Let S:=Field.F.
>Notation "x + y":=(Field.plus x y).
>Notation "x * y":=(Field.times x y).
>Lemma comm: forall x y:S,x+y=y+x.
>proof.
>intros.
>thus thesis by Field.F3.
>end proof.
>Qed.
>
>Definition addAndSquare(a b:S):S:=(a+b)*(a+b).
>Definition sq(a:S):S:=a*a.
>
>Check addAndSquare Field.one Field.one.
>Compute addAndSquare Field.one Field.null.
>
>Proposition P1:forall a b:S, addAndSquare a b =
>  (sq a) + (sq b)+a*b+b*a.
>proof.
>let u:S.
>let v:S.
>compute.
>thus thesis by Field.F7,Field.F8,Field.F3,Field.F5.
>end proof.
>Qed.
>
>(*
>have f1:((u+v)*(u+v) =u*(u+v)+v*(u+v)) by Field.F8.
>then f2:((u+v)*(u+v) = u*u+u*v+v*(u+v)) by f1,Field.F7.
>then f3:((u+v)*(u+v)= u*u+u*v+v*u+v*v) by f2, Field.F7,Field.F3,Field.F5.
>thus thesis by f3, Field.F3,Field.F5.
>end proof.
>Qed.
>*)

\start
Date: Wed, 8 Feb 2017 22:33:33 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Jeremy Avigad <avigad@cmu.edu>
Subject: Re: [Axiom-developer] [Proving Axiom Correct] Bootstrapping a
 library
Cc: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>,
	Renaud Rioboo <renaud.rioboo@ensiie.fr>

>Is there anything that requires that the operation you implement is
>reflexive, symmetric, and transitive?  Putting axioms on the structure
>specifies that that has to be the case. Without such axioms, you
>cannot prove anything about implementations in general. You can
>only prove things about individual implementations.

Yes. Such properties are required by the Category hierarchy. There is,
for example, Group and AbelianGroup and there are Categories
constraints on properties like reflexive, etc. which can affect the
signatures that get inherited.


On Wed, Feb 8, 2017 at 9:44 PM, Jeremy Avigad <avigad@cmu.edu> wrote:

>
>
> On Wed, Feb 8, 2017 at 9:23 PM, Tim Daly <axiomcas@gmail.com> wrote:
>
>> Part of your struggle of understanding what I wrote is that I'm not yet
>> fluent in the
>> logic language and syntax. I'm learning as fast as I can so please be
>> patient.
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
>> CATEGORY SIGNATURE vs DOMAIN SEMANTICS
>>
>> > Presumably you will eventually want to add axioms to the structures
>> that say
>> > things about what eq and neq do
>>
>> The semantics of =3D is given in the Domain (the current one being defin=
ed
>> is called % in Spad)
>> not in the Category (well...you can... sigh)
>>
>> Each domain that inherits '=3D' from the Category BasicType needs to
>> specify the meaning
>> of that function for the Domain you're implementing..
>>
>
> In our language, we would say that every instance of the structure has al=
l
> the necessary data. For example, every group (=3Dinstance of the group
> structure, or element of the type group =CE=B1) has a unit, a binary oper=
ation,
> and inverse operation, etc.
>
>
>> For a Polynomial domain with some
>> structural data representation you have to define what it means for two
>> polynomial objects
>> to be =3D. such as a function to compare coefficients. Part of the game
>> would be to prove
>> that the coefficient-compare function is correct, always returns a
>> Boolean, and terminates.
>>
>> All a Category like BasicType does is specify that the Domain Polynomial
>> should
>> implement an =3D operation with the given signature.  That is, you have =
to
>> implement
>>
>>      poly =3D poly
>>
>> which returns a boolean. (Note that there are other =3D functions in
>> Polynomial such as one
>> that returns an equation object but that signature is inherited from a
>> different Category).
>>
>
> Is there anything that requires that the operation you implement is
> reflexive, symmetric, and transitive?  Putting axioms on the structure
> specifies that that has to be the case. Without such axioms, you cannot
> prove anything about implementations in general. You can only prove thing=
s
> about individual implementations.
>
>
>> It looks like your 'class' syntax implements what I need. I will try thi=
s
>> for the other
>> Categories used in NNI.
>>
>>
>>
>>
>> PROVING TERMINATION
>>
>> As I understood from class, for an algorithm like gcd it should be
>> sufficient to construct
>> a function that fulfills the signature of
>>
>>    gcd(a:NNI,b:NNI):NNI
>>
>> Coq provides gcd as
>>
>>   Fixpoint gcd a b :=3D
>>     match a with
>>       | 0 =3D> b
>>       | S a' =3D> gcd (b mod (S a')) (S a')
>>     end.
>>
>> and Axiom's definition is
>>
>>   gcd(x:NNI,y:NNI):NNI =3D=3D
>>     zero? x =3D> y
>>     gcd(y rem x, x)
>>
>> Everything in Spad is strongly typed and function definitions are chosen
>> not only
>> by the arguments but also by the return type (so there can be multiple
>> functions
>> with the same name and same arguments but different return types, for
>> example).
>> Every statement in the function is strongly type-checked.
>>
>
> That is what I referred to as a shallow embedding -- you are associating
> to every axiom definition a Coq or Lean definition which has the same
> behavior.
>
> If you do that, you cannot model arbitrary while loops. You have to write
> functions in Coq or Lean in a way that, from the start, they are guarante=
ed
> to terminate. You can do this, for example, by showing the recursive call=
s
> are decreasing along a suitable measure, or giving a priori bounds on a
> while loop. If you want to translate spad functions automatically, you'll
> have to write the former in such a way that the translations have this
> property. You can't translate an arbitrary, a priori partial, function an=
d
> then show after the fact that it terminates for every input.
>
> Other approaches are possible. You can, for example, translate spad
> functions to relations in Coq or Lean, and then prove that the relations
> give rise to total functions.
>
> Best wishes,
>
> Jeremy
>
>
>
>>
>> Thus we are guaranteed that the Spad version of gcd above (in the Domain
>> NNI)
>> can only be called with NNI arguments and is guaranteed to only return
>> NNI results.
>>
>> The languages are very close in spirit if not in syntax.
>>
>> What Axiom does not do, for example, is prove termination.
>>
>> Coq, in its version, will figure out that the recursion is on 'a' and
>> that it will terminate.
>>
>> Part of the game is to provide the same termination analysis on Spad cod=
e.
>>
>>
>>
>>
>> ADDITIONAL CONSTRAINTS
>>
>> It would be ideal to reject code that did not fulfill all of the
>> requirements
>> such as specifying at the Category level definition of gcd that it not
>> only
>> has to have the correct signature, it also has to return the 'positive'
>> divisor. For NNI this is trivially fulfilled.
>>
>> The Category definition should say something like
>>
>>    gcd(%,%) -> %  and gcd >=3D 1$%
>>
>> where 1$% says to use the unit from the implementing Domain.
>>
>> So for some domains we have:
>>
>>   gcd(x,y) =3D=3D
>>     x :=3D unitCanonical x
>>     y :=3D unitCanonical y
>>     while not zero? y repeat
>>       (x,y) :=3D (y, x rem y)
>>       y :=3D unitCanonical y
>>     x
>>
>> using unitCanonical to deal with things like signs. (This also adds the
>> complication
>> of loops which I mentioned in a previous email.)
>>
>> Not only the signature but the side-conditions would have to be checked.
>>
>>
>>
>>
>>
>>
>> ALTERNATE APPROACHES
>>
>> Instead of a new library organization it might be possible to have a
>> generator function
>> in Coq that translates Coq code to Spad code. Or a translator from Spad
>> code to
>> Coq code.
>>
>> Unfortunately Coq and Lean do not seem to use function name overloading
>> or inheritance (or do they?) which confuses the problem of name
>> translation.
>>
>> Axiom has 42 functions named 'gcd', each living in a different Domain.
>>
>>
>>
>>
>>
>> There is no such thing as a simple job. But this one promises to be
>> interesting.
>>
>> In any case I'll push the implementation forward. Thanks for your help.
>>
>> Tim
>>
>>
>>
>>
>>
>>
>> On Wed, Feb 8, 2017 at 5:52 PM, Jeremy Avigad <avigad@cmu.edu> wrote:
>>
>>> Dear Tim,
>>>
>>> I don't understand what you mean. For one thing, theorems in both Lean
>>> and Coq are marked as opaque, since you generally don't care about the
>>> contents. But even if we replace "theorem" by "definition," I don't kno=
w
>>> what you imagine going into the "...".
>>>
>>> I think what you want to do is represent Axiom categories as structures=
.
>>> For example, the declarations below declare a BasicType structure and
>>> notation for elements of that structure. You can then prove theorems ab=
out
>>> arbitrary types =CE=B1 that have a BasicType structure. You can also ex=
tend the
>>> structure as needed.
>>>
>>> (Presumably you will eventually want to add axioms to the structures
>>> that say things about what eq and neq do. Otherwise, you are just reaso=
ning
>>> about a type with two relations.)
>>>
>>> Best wishes,
>>>
>>> Jeremy
>>>
>>> class BasicType (=CE=B1 : Type) : Type :=3D
>>> (eq : =CE=B1 =E2=86=92 =CE=B1 =E2=86=92 bool) (neq : =CE=B1 =E2=86=92 =
=CE=B1 =E2=86=92 bool)
>>>
>>> infix `?=3D?`:50  :=3D BasicType.eq
>>> infix `?~=3D?`:50 :=3D BasicType.neq
>>>
>>> section
>>>   variables (=CE=B1 : Type) [BasicType =CE=B1]
>>>   variables a b : =CE=B1
>>>
>>>   check a ?=3D? b
>>>   check a ?~=3D? b
>>> end
>>>
>>>
>>>
>>>
>>> On Wed, Feb 8, 2017 at 9:29 AM, Tim Daly <axiomcas@gmail.com> wrote:
>>>
>>>> The game is to prove GCD in NonNegativeInteger (NNI).
>>>>
>>>> We would like to use the 'nat' theorems from the existing library
>>>> but extract those theorems automatically from Axiom sources
>>>> at build time.
>>>>
>>>> Axiom's NNI inherits from a dozen Category objects, one of which
>>>> is BasicType which contains two signatures:
>>>>
>>>>  ?=3D?: (%,%) -> Boolean       ?~=3D?: (%,%) -> Boolean
>>>>
>>>> In the ideal case we would decorate BasicType with the existing
>>>> definitions of =3D and ~=3D so we could create a new library structure
>>>> for the logic system. So BasicType would contain
>>>>
>>>> theorem =3D (a, b : Type) : Boolean :=3D .....
>>>> theorem ~=3D (a, b : Type) : Boolean :=3D ....
>>>>
>>>> These theorems would be imported into NNI when it inherits the
>>>> signatures from the BasicType Category. The collection of all of
>>>> the theorems in NNI's Category structure would be used (hopefully
>>>> exclusively) to prove GCD. In this way, all of the theorems used to
>>>> prove Axiom source code would be inheritied from the Category
>>>> structure.
>>>>
>>>> Unfortunately it appears the Coq and Lean will not take kindly to
>>>> removing the existing libraries and replacing them with a new version
>>>> that only contains a limited number of theorems. I'm not yet sure abou=
t
>>>> FoCaL but I suspect it has the same bootstrap problem.
>>>>
>>>> Jeremy Avigad (Lean) made the suggestion to rename these theorems.
>>>> Thus, instead of =3D, the supporting theorem would be 'spad=3D' (spad =
is
>>>> the name of Axiom's algebra language).
>>>>
>>>> Initially this would make Axiom depend on the external library
>>>> structure.
>>>> Eventually there should be enough embedded logic to start coding Axiom
>>>> theorems by changing external references from =3D to spad=3D everywher=
e.
>>>>
>>>> Axiom proofs would still depend on the external proof system but only
>>>> for the correctness engine, not the library structure. This will
>>>> minimize
>>>> the struggle about Axiom's world view (e.g. handling excluded middle).
>>>> It will also organize the logic library to more closely mirror abstrac=
t
>>>> algebra.
>>>>
>>>> Comments, suggestions?
>>>>
>>>> Tim

\start
Date: Wed, 8 Feb 2017 22:54:34 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Jeremy Avigad <avigad@cmu.edu>
Subject: Re: [Axiom-developer] [Proving Axiom Correct] Bootstrapping a
 library
Cc: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>,
	Renaud Rioboo <renaud.rioboo@ensiie.fr>

>
> > Coq provides gcd as
> >
> >  Fixpoint gcd a b :=3D
> >    match a with
> >      | 0 =3D> b
> >      | S a' =3D> gcd (b mod (S a')) (S a')
> >    end.
>
> > and Axiom's definition is
>
> >  gcd(x:NNI,y:NNI):NNI =3D=3D
> >    zero? x =3D> y
> >    gcd(y rem x, x)
>
> > Everything in Spad is strongly typed and function definitions are chose=
n
> not only
> > by the arguments but also by the return type (so there can be multiple
> functions
> > with the same name and same arguments but different return types, for
> example).
> > Every statement in the function is strongly type-checked.
>

> That is what I referred to as a shallow embedding -- you are associating
to every
> axiom definition a Coq or Lean >definition which has the same behavior.

> If you do that, you cannot model arbitrary while loops. You have to write
> functions in Coq or Lean in a way that, from the start, they are
> guaranteed to terminate. You can do this, for example, by showing
> the recursive calls are decreasing along a suitable measure, or giving a
> priori bounds on a while loop. If you want to translate spad functions
> automatically, you'll have to write the former in such a way that the
> translations have this property. You can't translate an arbitrary, a
priori
> partial, function and then show after the fact that it terminates for
every input.

This is not intended to be a shallow embedding. In order to prove Spad's gc=
d
we have to prove zero? and rem and have those available. The idea is to
initially create the definitions so that Spad code is reducible to code
that the
proof engine can process directly. This involves defining the Spad 'words'
like
'zero?' so they properly type check.

What can't be directly proven will have to be restructured/rewritten.

As we discussed on Tuesday, a lot of Spad code uses loops. I'm looking at
the Isabelle/HOL book you recommended for some advice on Hoare triples.

That's queued behind getting up to speed on FoCaL, as mentioned by Renaud.

Eventually I'd like to see the proof engine embedded directly into Axiom
rather than called at compile time so that it is also available in the
interpreter.

Where are grad students when you need them? :-)

Tim


On Wed, Feb 8, 2017 at 9:44 PM, Jeremy Avigad <avigad@cmu.edu> wrote:

>
>
> On Wed, Feb 8, 2017 at 9:23 PM, Tim Daly <axiomcas@gmail.com> wrote:
>
>> Part of your struggle of understanding what I wrote is that I'm not yet
>> fluent in the
>> logic language and syntax. I'm learning as fast as I can so please be
>> patient.
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
>> CATEGORY SIGNATURE vs DOMAIN SEMANTICS
>>
>> > Presumably you will eventually want to add axioms to the structures
>> that say
>> > things about what eq and neq do
>>
>> The semantics of =3D is given in the Domain (the current one being defin=
ed
>> is called % in Spad)
>> not in the Category (well...you can... sigh)
>>
>> Each domain that inherits '=3D' from the Category BasicType needs to
>> specify the meaning
>> of that function for the Domain you're implementing..
>>
>
> In our language, we would say that every instance of the structure has al=
l
> the necessary data. For example, every group (=3Dinstance of the group
> structure, or element of the type group =CE=B1) has a unit, a binary oper=
ation,
> and inverse operation, etc.
>
>
>> For a Polynomial domain with some
>> structural data representation you have to define what it means for two
>> polynomial objects
>> to be =3D. such as a function to compare coefficients. Part of the game
>> would be to prove
>> that the coefficient-compare function is correct, always returns a
>> Boolean, and terminates.
>>
>> All a Category like BasicType does is specify that the Domain Polynomial
>> should
>> implement an =3D operation with the given signature.  That is, you have =
to
>> implement
>>
>>      poly =3D poly
>>
>> which returns a boolean. (Note that there are other =3D functions in
>> Polynomial such as one
>> that returns an equation object but that signature is inherited from a
>> different Category).
>>
>
> Is there anything that requires that the operation you implement is
> reflexive, symmetric, and transitive?  Putting axioms on the structure
> specifies that that has to be the case. Without such axioms, you cannot
> prove anything about implementations in general. You can only prove thing=
s
> about individual implementations.
>
>
>> It looks like your 'class' syntax implements what I need. I will try thi=
s
>> for the other
>> Categories used in NNI.
>>
>>
>>
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
>> PROVING TERMINATION
>>
>> As I understood from class, for an algorithm like gcd it should be
>> sufficient to construct
>> a function that fulfills the signature of
>>
>>    gcd(a:NNI,b:NNI):NNI
>>
>> Coq provides gcd as
>>
>>   Fixpoint gcd a b :=3D
>>     match a with
>>       | 0 =3D> b
>>       | S a' =3D> gcd (b mod (S a')) (S a')
>>     end.
>>
>> and Axiom's definition is
>>
>>   gcd(x:NNI,y:NNI):NNI =3D=3D
>>     zero? x =3D> y
>>     gcd(y rem x, x)
>>
>> Everything in Spad is strongly typed and function definitions are chosen
>> not only
>> by the arguments but also by the return type (so there can be multiple
>> functions
>> with the same name and same arguments but different return types, for
>> example).
>> Every statement in the function is strongly type-checked.
>>
>
> That is what I referred to as a shallow embedding -- you are associating
> to every axiom definition a Coq or Lean definition which has the same
> behavior.
>
> If you do that, you cannot model arbitrary while loops. You have to write
> functions in Coq or Lean in a way that, from the start, they are guarante=
ed
> to terminate. You can do this, for example, by showing the recursive call=
s
> are decreasing along a suitable measure, or giving a priori bounds on a
> while loop. If you want to translate spad functions automatically, you'll
> have to write the former in such a way that the translations have this
> property. You can't translate an arbitrary, a priori partial, function an=
d
> then show after the fact that it terminates for every input.
>
> Other approaches are possible. You can, for example, translate spad
> functions to relations in Coq or Lean, and then prove that the relations
> give rise to total functions.
>
> Best wishes,
>
> Jeremy
>
>
>
>>
>> Thus we are guaranteed that the Spad version of gcd above (in the Domain
>> NNI)
>> can only be called with NNI arguments and is guaranteed to only return
>> NNI results.
>>
>> The languages are very close in spirit if not in syntax.
>>
>> What Axiom does not do, for example, is prove termination.
>>
>> Coq, in its version, will figure out that the recursion is on 'a' and
>> that it will terminate.
>>
>> Part of the game is to provide the same termination analysis on Spad cod=
e.
>>
>>
>>
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>> ADDITIONAL CONSTRAINTS
>>
>> It would be ideal to reject code that did not fulfill all of the
>> requirements
>> such as specifying at the Category level definition of gcd that it not
>> only
>> has to have the correct signature, it also has to return the 'positive'
>> divisor. For NNI this is trivially fulfilled.
>>
>> The Category definition should say something like
>>
>>    gcd(%,%) -> %  and gcd >=3D 1$%
>>
>> where 1$% says to use the unit from the implementing Domain.
>>
>> So for some domains we have:
>>
>>   gcd(x,y) =3D=3D
>>     x :=3D unitCanonical x
>>     y :=3D unitCanonical y
>>     while not zero? y repeat
>>       (x,y) :=3D (y, x rem y)
>>       y :=3D unitCanonical y
>>     x
>>
>> using unitCanonical to deal with things like signs. (This also adds the
>> complication
>> of loops which I mentioned in a previous email.)
>>
>> Not only the signature but the side-conditions would have to be checked.
>>
>>
>>
>>
>>
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>> ALTERNATE APPROACHES
>>
>> Instead of a new library organization it might be possible to have a
>> generator function
>> in Coq that translates Coq code to Spad code. Or a translator from Spad
>> code to
>> Coq code.
>>
>> Unfortunately Coq and Lean do not seem to use function name overloading
>> or inheritance (or do they?) which confuses the problem of name
>> translation.
>>
>> Axiom has 42 functions named 'gcd', each living in a different Domain.
>>
>>
>>
>>
>>
>> There is no such thing as a simple job. But this one promises to be
>> interesting.
>>
>> In any case I'll push the implementation forward. Thanks for your help.
>>
>> Tim
>>
>>
>>
>>
>>
>>
>> On Wed, Feb 8, 2017 at 5:52 PM, Jeremy Avigad <avigad@cmu.edu> wrote:
>>
>>> Dear Tim,
>>>
>>> I don't understand what you mean. For one thing, theorems in both Lean
>>> and Coq are marked as opaque, since you generally don't care about the
>>> contents. But even if we replace "theorem" by "definition," I don't kno=
w
>>> what you imagine going into the "...".
>>>
>>> I think what you want to do is represent Axiom categories as structures=
.
>>> For example, the declarations below declare a BasicType structure and
>>> notation for elements of that structure. You can then prove theorems ab=
out
>>> arbitrary types =CE=B1 that have a BasicType structure. You can also ex=
tend the
>>> structure as needed.
>>>
>>> (Presumably you will eventually want to add axioms to the structures
>>> that say things about what eq and neq do. Otherwise, you are just reaso=
ning
>>> about a type with two relations.)
>>>
>>> Best wishes,
>>>
>>> Jeremy
>>>
>>> class BasicType (=CE=B1 : Type) : Type :=3D
>>> (eq : =CE=B1 =E2=86=92 =CE=B1 =E2=86=92 bool) (neq : =CE=B1 =E2=86=92 =
=CE=B1 =E2=86=92 bool)
>>>
>>> infix `?=3D?`:50  :=3D BasicType.eq
>>> infix `?~=3D?`:50 :=3D BasicType.neq
>>>
>>> section
>>>   variables (=CE=B1 : Type) [BasicType =CE=B1]
>>>   variables a b : =CE=B1
>>>
>>>   check a ?=3D? b
>>>   check a ?~=3D? b
>>> end
>>>
>>>
>>>
>>>
>>> On Wed, Feb 8, 2017 at 9:29 AM, Tim Daly <axiomcas@gmail.com> wrote:
>>>
>>>> The game is to prove GCD in NonNegativeInteger (NNI).
>>>>
>>>> We would like to use the 'nat' theorems from the existing library
>>>> but extract those theorems automatically from Axiom sources
>>>> at build time.
>>>>
>>>> Axiom's NNI inherits from a dozen Category objects, one of which
>>>> is BasicType which contains two signatures:
>>>>
>>>>  ?=3D?: (%,%) -> Boolean       ?~=3D?: (%,%) -> Boolean
>>>>
>>>> In the ideal case we would decorate BasicType with the existing
>>>> definitions of =3D and ~=3D so we could create a new library structure
>>>> for the logic system. So BasicType would contain
>>>>
>>>> theorem =3D (a, b : Type) : Boolean :=3D .....
>>>> theorem ~=3D (a, b : Type) : Boolean :=3D ....
>>>>
>>>> These theorems would be imported into NNI when it inherits the
>>>> signatures from the BasicType Category. The collection of all of
>>>> the theorems in NNI's Category structure would be used (hopefully
>>>> exclusively) to prove GCD. In this way, all of the theorems used to
>>>> prove Axiom source code would be inheritied from the Category
>>>> structure.
>>>>
>>>> Unfortunately it appears the Coq and Lean will not take kindly to
>>>> removing the existing libraries and replacing them with a new version
>>>> that only contains a limited number of theorems. I'm not yet sure abou=
t
>>>> FoCaL but I suspect it has the same bootstrap problem.
>>>>
>>>> Jeremy Avigad (Lean) made the suggestion to rename these theorems.
>>>> Thus, instead of =3D, the supporting theorem would be 'spad=3D' (spad =
is
>>>> the name of Axiom's algebra language).
>>>>
>>>> Initially this would make Axiom depend on the external library
>>>> structure.
>>>> Eventually there should be enough embedded logic to start coding Axiom
>>>> theorems by changing external references from =3D to spad=3D everywher=
e.
>>>>
>>>> Axiom proofs would still depend on the external proof system but only
>>>> for the correctness engine, not the library structure. This will
>>>> minimize
>>>> the struggle about Axiom's world view (e.g. handling excluded middle).
>>>> It will also organize the logic library to more closely mirror abstrac=
t
>>>> algebra.
>>>>
>>>> Comments, suggestions?
>>>>
>>>> Tim

\start
Date: Thu, 9 Feb 2017 08:30:01 +0100
From: Laurent Thery <Laurent.Thery@inria.fr>
To: Tim Daly <axiomcas@gmail.com>, Jeremy Avigad <avigad@cmu.edu>
Subject: Re: [Axiom-developer] [Proving Axiom Correct] Bootstrapping a
 library
Cc: axiom-dev <axiom-developer@nongnu.org>,
	Tim Daly <daly@axiom-developer.org>,
	Renaud Rioboo <renaud.rioboo@ensiie.fr>

Termination is clearly an issue for provers like Coq. There are 
solutions to define function partially but they have some cost in term 
of proof effo.  Maybe we could benefit how the people of Focal deals 
with loops.

--
Laurent



On 02/09/2017 04:54 AM, Tim Daly wrote:
>     > Coq provides gcd as
>     >
>     >  Fixpoint gcd a b :=
>     >    match a with
>     >      | 0 => b
>     >      | S a' => gcd (b mod (S a')) (S a')
>     >    end.
>
>     > and Axiom's definition is
>
>     >  gcd(x:NNI,y:NNI):NNI ==
>     >    zero? x => y
>     >    gcd(y rem x, x)
>
>     > Everything in Spad is strongly typed and function definitions are chosen not only
>     > by the arguments but also by the return type (so there can be multiple functions
>     > with the same name and same arguments but different return types, for example).
>     > Every statement in the function is strongly type-checked.
>
>
>> That is what I referred to as a shallow embedding -- you are
> associating to every
>> axiom definition a Coq or Lean >definition which has the same behavior.
>
>> If you do that, you cannot model arbitrary while loops. You have to write
>> functions in Coq or Lean in a way that, from the start, they are
>> guaranteed to terminate. You can do this, for example, by showing
>> the recursive calls are decreasing along a suitable measure, or giving a
>> priori bounds on a while loop. If you want to translate spad functions
>> automatically, you'll have to write the former in such a way that the
>> translations have this property. You can't translate an arbitrary, a
> priori
>> partial, function and then show after the fact that it terminates for
> every input.
>
> This is not intended to be a shallow embedding. In order to prove Spad's gcd
> we have to prove zero? and rem and have those available. The idea is to
> initially create the definitions so that Spad code is reducible to code
> that the
> proof engine can process directly. This involves defining the Spad
> 'words' like
> 'zero?' so they properly type check.
>
> What can't be directly proven will have to be restructured/rewritten.
>
> As we discussed on Tuesday, a lot of Spad code uses loops. I'm looking at
> the Isabelle/HOL book you recommended for some advice on Hoare triples.
>
> That's queued behind getting up to speed on FoCaL, as mentioned by Renaud.
>
> Eventually I'd like to see the proof engine embedded directly into Axiom
> rather than called at compile time so that it is also available in the
> interpreter.
>
> Where are grad students when you need them? :-)
>
> Tim
>
>
> On Wed, Feb 8, 2017 at 9:44 PM, Jeremy Avigad <avigad@cmu.edu
> <mailto:avigad@cmu.edu>> wrote:
>
>
>
>     On Wed, Feb 8, 2017 at 9:23 PM, Tim Daly <axiomcas@gmail.com
>     <mailto:axiomcas@gmail.com>> wrote:
>
>         Part of your struggle of understanding what I wrote is that I'm
>         not yet fluent in the
>         logic language and syntax. I'm learning as fast as I can so
>         please be patient.
>
>         ======================================================
>         CATEGORY SIGNATURE vs DOMAIN SEMANTICS
>
>         > Presumably you will eventually want to add axioms to the structures that say
>         > things about what eq and neq do
>
>         The semantics of = is given in the Domain (the current one being
>         defined is called % in Spad)
>         not in the Category (well...you can... sigh)
>
>         Each domain that inherits '=' from the Category BasicType needs
>         to specify the meaning
>         of that function for the Domain you're implementing..
>
>
>     In our language, we would say that every instance of the structure
>     has all the necessary data. For example, every group (=instance of
>     the group structure, or element of the type group α) has a unit, a
>     binary operation, and inverse operation, etc.
>
>
>         For a Polynomial domain with some
>         structural data representation you have to define what it means
>         for two polynomial objects
>         to be =. such as a function to compare coefficients. Part of the
>         game would be to prove
>         that the coefficient-compare function is correct, always returns
>         a Boolean, and terminates.
>
>         All a Category like BasicType does is specify that the Domain
>         Polynomial should
>         implement an = operation with the given signature.  That is, you
>         have to implement
>
>              poly = poly
>
>         which returns a boolean. (Note that there are other = functions
>         in Polynomial such as one
>         that returns an equation object but that signature is inherited
>         from a different Category).
>
>
>     Is there anything that requires that the operation you implement is
>     reflexive, symmetric, and transitive?  Putting axioms on the
>     structure specifies that that has to be the case. Without such
>     axioms, you cannot prove anything about implementations in general.
>     You can only prove things about individual implementations.
>
>
>         It looks like your 'class' syntax implements what I need. I will
>         try this for the other
>         Categories used in NNI.
>
>
>
>
>         =======================================================
>         PROVING TERMINATION
>
>         As I understood from class, for an algorithm like gcd it should
>         be sufficient to construct
>         a function that fulfills the signature of
>
>            gcd(a:NNI,b:NNI):NNI
>
>         Coq provides gcd as
>
>           Fixpoint gcd a b :=
>             match a with
>               | 0 => b
>               | S a' => gcd (b mod (S a')) (S a')
>             end.
>
>         and Axiom's definition is
>
>           gcd(x:NNI,y:NNI):NNI ==
>             zero? x => y
>             gcd(y rem x, x)
>
>         Everything in Spad is strongly typed and function definitions
>         are chosen not only
>         by the arguments but also by the return type (so there can be
>         multiple functions
>         with the same name and same arguments but different return
>         types, for example).
>         Every statement in the function is strongly type-checked.
>
>
>     That is what I referred to as a shallow embedding -- you are
>     associating to every axiom definition a Coq or Lean definition which
>     has the same behavior.
>
>     If you do that, you cannot model arbitrary while loops. You have to
>     write functions in Coq or Lean in a way that, from the start, they
>     are guaranteed to terminate. You can do this, for example, by
>     showing the recursive calls are decreasing along a suitable measure,
>     or giving a priori bounds on a while loop. If you want to translate
>     spad functions automatically, you'll have to write the former in
>     such a way that the translations have this property. You can't
>     translate an arbitrary, a priori partial, function and then show
>     after the fact that it terminates for every input.
>
>     Other approaches are possible. You can, for example, translate spad
>     functions to relations in Coq or Lean, and then prove that the
>     relations give rise to total functions.
>
>     Best wishes,
>
>     Jeremy
>
>
>
>
>         Thus we are guaranteed that the Spad version of gcd above (in
>         the Domain NNI)
>         can only be called with NNI arguments and is guaranteed to only
>         return NNI results.
>
>         The languages are very close in spirit if not in syntax.
>
>         What Axiom does not do, for example, is prove termination.
>
>         Coq, in its version, will figure out that the recursion is on
>         'a' and that it will terminate.
>
>         Part of the game is to provide the same termination analysis on
>         Spad code.
>
>
>
>
>         ====================================================
>         ADDITIONAL CONSTRAINTS
>
>         It would be ideal to reject code that did not fulfill all of the
>         requirements
>         such as specifying at the Category level definition of gcd that
>         it not only
>         has to have the correct signature, it also has to return the
>         'positive'
>         divisor. For NNI this is trivially fulfilled.
>
>         The Category definition should say something like
>
>            gcd(%,%) -> %  and gcd >= 1$%
>
>         where 1$% says to use the unit from the implementing Domain.
>
>         So for some domains we have:
>
>           gcd(x,y) ==
>             x := unitCanonical x
>             y := unitCanonical y
>             while not zero? y repeat
>               (x,y) := (y, x rem y)
>               y := unitCanonical y
>             x
>
>         using unitCanonical to deal with things like signs. (This also
>         adds the complication
>         of loops which I mentioned in a previous email.)
>
>         Not only the signature but the side-conditions would have to be
>         checked.
>
>
>
>
>
>
>         ====================================================
>         ALTERNATE APPROACHES
>
>         Instead of a new library organization it might be possible to
>         have a generator function
>         in Coq that translates Coq code to Spad code. Or a translator
>         from Spad code to
>         Coq code.
>
>         Unfortunately Coq and Lean do not seem to use function name
>         overloading
>         or inheritance (or do they?) which confuses the problem of name
>         translation.
>
>         Axiom has 42 functions named 'gcd', each living in a different
>         Domain.
>
>
>
>
>
>         There is no such thing as a simple job. But this one promises to
>         be interesting.
>
>         In any case I'll push the implementation forward. Thanks for
>         your help.
>
>         Tim
>
>
>
>
>
>
>         On Wed, Feb 8, 2017 at 5:52 PM, Jeremy Avigad <avigad@cmu.edu
>         <mailto:avigad@cmu.edu>> wrote:
>
>             Dear Tim,
>
>             I don't understand what you mean. For one thing, theorems in
>             both Lean and Coq are marked as opaque, since you generally
>             don't care about the contents. But even if we replace
>             "theorem" by "definition," I don't know what you imagine
>             going into the "...".
>
>             I think what you want to do is represent Axiom categories as
>             structures. For example, the declarations below declare a
>             BasicType structure and notation for elements of that
>             structure. You can then prove theorems about arbitrary
>             types α that have a BasicType structure. You can also extend
>             the structure as needed.
>
>             (Presumably you will eventually want to add axioms to the
>             structures that say things about what eq and neq do.
>             Otherwise, you are just reasoning about a type with two
>             relations.)
>
>             Best wishes,
>
>             Jeremy
>
>             class BasicType (α : Type) : Type :=
>             (eq : α → α → bool) (neq : α → α → bool)
>
>             infix `?=?`:50  := BasicType.eq
>             infix `?~=?`:50 := BasicType.neq
>
>             section
>               variables (α : Type) [BasicType α]
>               variables a b : α
>
>               check a ?=? b
>               check a ?~=? b
>             end
>
>
>
>
>             On Wed, Feb 8, 2017 at 9:29 AM, Tim Daly <axiomcas@gmail.com
>             <mailto:axiomcas@gmail.com>> wrote:
>
>                 The game is to prove GCD in NonNegativeInteger (NNI).
>
>                 We would like to use the 'nat' theorems from the
>                 existing library
>                 but extract those theorems automatically from Axiom sources
>                 at build time.
>
>                 Axiom's NNI inherits from a dozen Category objects, one
>                 of which
>                 is BasicType which contains two signatures:
>
>                  ?=?: (%,%) -> Boolean       ?~=?: (%,%) -> Boolean
>
>                 In the ideal case we would decorate BasicType with the
>                 existing
>                 definitions of = and ~= so we could create a new library
>                 structure
>                 for the logic system. So BasicType would contain
>
>                 theorem = (a, b : Type) : Boolean := .....
>                 theorem ~= (a, b : Type) : Boolean := ....
>
>                 These theorems would be imported into NNI when it
>                 inherits the
>                 signatures from the BasicType Category. The collection
>                 of all of
>                 the theorems in NNI's Category structure would be used
>                 (hopefully
>                 exclusively) to prove GCD. In this way, all of the
>                 theorems used to
>                 prove Axiom source code would be inheritied from the
>                 Category
>                 structure.
>
>                 Unfortunately it appears the Coq and Lean will not take
>                 kindly to
>                 removing the existing libraries and replacing them with
>                 a new version
>                 that only contains a limited number of theorems. I'm not
>                 yet sure about
>                 FoCaL but I suspect it has the same bootstrap problem.
>
>                 Jeremy Avigad (Lean) made the suggestion to rename these
>                 theorems.
>                 Thus, instead of =, the supporting theorem would be
>                 'spad=' (spad is
>                 the name of Axiom's algebra language).
>
>                 Initially this would make Axiom depend on the external
>                 library structure.
>                 Eventually there should be enough embedded logic to
>                 start coding Axiom
>                 theorems by changing external references from = to spad=
>                 everywhere.
>
>                 Axiom proofs would still depend on the external proof
>                 system but only
>                 for the correctness engine, not the library structure.
>                 This will minimize
>                 the struggle about Axiom's world view (e.g. handling
>                 excluded middle).
>                 It will also organize the logic library to more closely
>                 mirror abstract algebra.
>
>                 Comments, suggestions?
>
>                 Tim


\start
Date: Fri, 10 Feb 2017 11:13:31 +0100
From: Renaud Rioboo <Renaud.Rioboo@ensiie.fr>
To: Tim Daly <axiomcas@gmail.com>, axiom-dev <axiom-developer@nongnu.org>,
	Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>, Jeremy Avigad <avigad@cmu.edu>
Subject: Re: [Axiom-developer] [Proving Axiom Correct] Bootstrapping a
 library

Dear Axiom gurus,

> Axiom's NNI inherits from a dozen Category objects, one of which
> is BasicType which contains two signatures:
>
>  ?=?: (%,%) -> Boolean       ?~=?: (%,%) -> Boolean
>
> In the ideal case we would decorate BasicType with the existing
> definitions of = and ~= so we could create a new library structure
> for the logic system. So BasicType would contain
>
> theorem = (a, b : Type) : Boolean := .....
> theorem ~= (a, b : Type) : Boolean := ....

Since BasicType is not an implementation you need to write a 
specification for equal and different. These specifictions should be 
inherited and proved at the domain level. You can see the standard 
library of FoCaLiZe for details.

In practice you need a language for writing logical statements and a 
language to prove these statements. Again see the FoCaLiZe library (for 
instance lattices) to see how a statement can be used in a proof.

> Unfortunately it appears the Coq and Lean will not take kindly to
> removing the existing libraries and replacing them with a new version
> that only contains a limited number of theorems. I'm not yet sure about
> FoCaL but I suspect it has the same bootstrap problem.

Inheritance is managed by the FoCaLiZe compiler together with 
dependencies which enables to have statements and proofs in a coherent way.


-- 
Renaud Rioboo

\start
Date: Fri, 10 Feb 2017 08:39:59 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Renaud Rioboo <Renaud.Rioboo@ensiie.fr>
Subject: Re: [Axiom-developer] [Proving Axiom Correct] Bootstrapping a
 library
Cc: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>, Jeremy Avigad <avigad@cmu.edu>

Renaud,

I'm just getting around to the FoCal information. Obviously you've done a
lot of
work on this subject already. I have the papers and the reference manual
near
the top of the reading stack. I'm certain to have questions.

Yes, BasicType requires properties for = such as symmetry which would have
to be proven at the Domain level for each implementation. Of course, = is
not
actually implemented directly in NNI but somewhere up the inheritance chain.
For example, the domain ANY has

  x = y ==
    (x.dm = y.dm) and EQUAL(x.ob, y.ob)$Lisp

where dm is a field in the Record implementation of ANY

   Rep := Record(dm: SExpression, ob: None)

which depends on the Lisp definition of EQUAL and SExpression
is one of String, Symbol, Integer, DoubleFloat, OutputForm

Whereas the domain IndexedList implements

  x = y ==
    Qeq(x,y) => true
    while not Qnull x and not Qnull y repeat
      Qfirst x ^=$S Qfirst y => return fase
      x := Qrest x
      y := Qrest y
    Qnull x and Qnull y

where
  Qeq   ==> EQ$Lisp
  Qnull ==> NULL$Lisp
  Qfirst ==> QCAR$Lisp
  Qrest ==> QCDR$Lisp
and
  S : Type
is a dependent argument type. Sigh.

The proofs of = in each domain will involve an appeal to the Lisp
definition of a small number of functions. I'm using ACL2 for Lisp.

This is where the ACL2 and Coq proofs meet.

There is no such thing as a simple job.

Tim



On Fri, Feb 10, 2017 at 5:13 AM, Renaud Rioboo <Renaud.Rioboo@ensiie.fr>
wrote:

> Dear Axiom gurus,
>
> Axiom's NNI inherits from a dozen Category objects, one of which
>> is BasicType which contains two signatures:
>>
>>  ?=?: (%,%) -> Boolean       ?~=?: (%,%) -> Boolean
>>
>> In the ideal case we would decorate BasicType with the existing
>> definitions of = and ~= so we could create a new library structure
>> for the logic system. So BasicType would contain
>>
>> theorem = (a, b : Type) : Boolean := .....
>> theorem ~= (a, b : Type) : Boolean := ....
>>
>
> Since BasicType is not an implementation you need to write a specification
> for equal and different. These specifictions should be inherited and proved
> at the domain level. You can see the standard library of FoCaLiZe for
> details.
>
> In practice you need a language for writing logical statements and a
> language to prove these statements. Again see the FoCaLiZe library (for
> instance lattices) to see how a statement can be used in a proof.
>
> Unfortunately it appears the Coq and Lean will not take kindly to
>> removing the existing libraries and replacing them with a new version
>> that only contains a limited number of theorems. I'm not yet sure about
>> FoCaL but I suspect it has the same bootstrap problem.
>>
>
> Inheritance is managed by the FoCaLiZe compiler together with dependencies
> which enables to have statements and proofs in a coherent way.
>
>
> --
> Renaud Rioboo
>

\start
Date: Tue, 14 Feb 2017 23:24:18 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Renaud Rioboo <Renaud.Rioboo@ensiie.fr>
Subject: Re: [Axiom-developer] [Proving Axiom Correct] Bootstrapping a
 library
Cc: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>, Jeremy Avigad <avigad@cmu.edu>

Renaud,

I've been looking at FoCal and, in particular, the Zenon program
http://zenon.inria.fr/zenlpar07.pdf

Zenon appears to be able to output OCAML code from proofs.
In your opinion is it reasonable to consider modifying the back end
to output Spad code?

Tim


On Fri, Feb 10, 2017 at 8:39 AM, Tim Daly <axiomcas@gmail.com> wrote:

> Renaud,
>
> I'm just getting around to the FoCal information. Obviously you've done a
> lot of
> work on this subject already. I have the papers and the reference manual
> near
> the top of the reading stack. I'm certain to have questions.
>
> Yes, BasicType requires properties for = such as symmetry which would have
> to be proven at the Domain level for each implementation. Of course, = is
> not
> actually implemented directly in NNI but somewhere up the inheritance
> chain.
> For example, the domain ANY has
>
>   x = y ==
>     (x.dm = y.dm) and EQUAL(x.ob, y.ob)$Lisp
>
> where dm is a field in the Record implementation of ANY
>
>    Rep := Record(dm: SExpression, ob: None)
>
> which depends on the Lisp definition of EQUAL and SExpression
> is one of String, Symbol, Integer, DoubleFloat, OutputForm
>
> Whereas the domain IndexedList implements
>
>   x = y ==
>     Qeq(x,y) => true
>     while not Qnull x and not Qnull y repeat
>       Qfirst x ^=$S Qfirst y => return fase
>       x := Qrest x
>       y := Qrest y
>     Qnull x and Qnull y
>
> where
>   Qeq   ==> EQ$Lisp
>   Qnull ==> NULL$Lisp
>   Qfirst ==> QCAR$Lisp
>   Qrest ==> QCDR$Lisp
> and
>   S : Type
> is a dependent argument type. Sigh.
>
> The proofs of = in each domain will involve an appeal to the Lisp
> definition of a small number of functions. I'm using ACL2 for Lisp.
>
> This is where the ACL2 and Coq proofs meet.
>
> There is no such thing as a simple job.
>
> Tim
>
>
>
> On Fri, Feb 10, 2017 at 5:13 AM, Renaud Rioboo <Renaud.Rioboo@ensiie.fr>
> wrote:
>
>> Dear Axiom gurus,
>>
>> Axiom's NNI inherits from a dozen Category objects, one of which
>>> is BasicType which contains two signatures:
>>>
>>>  ?=?: (%,%) -> Boolean       ?~=?: (%,%) -> Boolean
>>>
>>> In the ideal case we would decorate BasicType with the existing
>>> definitions of = and ~= so we could create a new library structure
>>> for the logic system. So BasicType would contain
>>>
>>> theorem = (a, b : Type) : Boolean := .....
>>> theorem ~= (a, b : Type) : Boolean := ....
>>>
>>
>> Since BasicType is not an implementation you need to write a
>> specification for equal and different. These specifictions should be
>> inherited and proved at the domain level. You can see the standard library
>> of FoCaLiZe for details.
>>
>> In practice you need a language for writing logical statements and a
>> language to prove these statements. Again see the FoCaLiZe library (for
>> instance lattices) to see how a statement can be used in a proof.
>>
>> Unfortunately it appears the Coq and Lean will not take kindly to
>>> removing the existing libraries and replacing them with a new version
>>> that only contains a limited number of theorems. I'm not yet sure about
>>> FoCaL but I suspect it has the same bootstrap problem.
>>>
>>
>> Inheritance is managed by the FoCaLiZe compiler together with
>> dependencies which enables to have statements and proofs in a coherent way.
>>
>>
>> --
>> Renaud Rioboo
>>
>
>

\start
Date: Wed, 22 Feb 2017 02:21:55 -0500
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] Proving Axiom Correct ... midnight musings

"The time has come," the Walrus said,
"To talk of many things:
Of shoes--and ships--and sealing-wax--
Of cabbages--and kings--
And why the sea is boiling hot--
And whether pigs have wings."
  -- Lewis Carroll (Through the Looking Glass)

Back when I was a lad Jon White taught a grad course that consisted
of a stack of papers which covered emerging areas of computer
science (e.g recursion, argued as relevant by Barron), structured
programming (Dijkstra), modular programming (Liskov), etc. It turned
out to be one of the most valuable courses I ever took.

At the time we still insisted on the need for computed GOTOs.
After all, with 4 kilobytes of memory, recursion seemed way too
theoretical to ever be practical.

Eventually I worked on implementing tail recursion in GCL and lusting
after SmallTalk. Structured programming became so obviously
good that programming using GOTOs required justification. The
new style reduced "spaghetti code" to a rare event. It greatly
decreased the error rate. Strong typing (ala PASCAL) reduced the
error rate even further, despite the side-effect of making programs
much harder to write.

These "advances" took time to develop, partly because the hardware
was not up to the task but mostly because we, as programmers,
resisted the ideas as too restrictive, too expensive, and a waste of
time. Even the notation (classes, inheritance, methods, etc) was painful.

The idea of writing provable programs has been around for a while
(Hoare, Dijkstra, etc.). It used to be that they were too hard to write
and not well-founded. But the last few years have seen the development
of systems that make writing provable programs a reasonable goal.

Writing such programs imposes yet more burdens on the programmer.
Loops should be written in a decreasing direction, functions should be
pure. They should be total in their domain. All kinds of pain points for
programmers that seem like a waste of time. Who needs Category
Theory and Inductive Construction? Even the notation is painful.

Eventually, and I believe it will be quite soon given the pace of the
internet, writing a proven program will be normal and so obviously
good that our current "just-make-it-work" style will need to be justified,
like using GOTOs. Theorem-Driven Development (TDD) will be all
the rage.

In an age when a car's brakes are computer controlled, we really do
need to prove they will be applied within 1ms under all conditions.

Computer algebra, given its strong basis in mathematics, is the ideal
setting, using the latest technology, to write proven programs. There
are a series of lectures from a summer school course at
https://www.cs.uoregon.edu/research/summerschool/summer13/curriculum.html
that are worth the time. Harper's Type Theory Foundations lectures are
excellent.

"The time has come"...
...to im-prove your programming...

Tim, the Walrus.



\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
