\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: Wed, 11 Jan 2017 23:17:20 -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

I'm making progress on proving Axiom correct both at the Spad level and
the Lisp level. One interesting talk by Phillip Wadler on "Propositions as
Types", a very entertaining talk, is here:
https://www.youtube.com/watch?v=IOiZatlZtGU

He makes the interesting point late in the talk that some languages are
"discovered" based on fundamental logic principles (e.g.Lisp) and others
are "invented" with no formal basis (e.g. C). As he says, "you can tell
whether your language is discovered or invented".

The point is that Lisp has a formal logic basis and, as Spad is really
just a domain specific language implemented in Lisp then Spad shares
the formal logic basis.

\start
Date: Thu, 12 Jan 2017 19:14:26 -0800
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Tim Daly <axiomcas@gmail.com>, 
	open-axiom-devel <open-axiom-devel@lists.sourceforge.net>
Subject: Re: [Axiom-developer] Proving Axiom Correct

There were implementations of C in Lisp. So C shares that formal logic
basis, or that it was discovered?

On Wed, Jan 11, 2017 at 8:17 PM, Tim Daly <axiomcas@gmail.com> wrote:

> I'm making progress on proving Axiom correct both at the Spad level and
> the Lisp level. One interesting talk by Phillip Wadler on "Propositions as
> Types", a very entertaining talk, is here:
> https://www.youtube.com/watch?v=IOiZatlZtGU
>
> He makes the interesting point late in the talk that some languages are
> "discovered" based on fundamental logic principles (e.g.Lisp) and others
> are "invented" with no formal basis (e.g. C). As he says, "you can tell
> whether your language is discovered or invented".
>
> The point is that Lisp has a formal logic basis and, as Spad is really
> just a domain specific language implemented in Lisp then Spad shares
> the formal logic basis.

\start
Date: Fri, 13 Jan 2017 01:35:45 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>,
	axiom-dev <axiom-developer@nongnu.org>, 
	Tim Daly <daly@axiom-developer.org>
Subject: Re: [Axiom-developer] Proving Axiom Correct

> There were implementations of C in Lisp. So C shares that formal logic
basis, or that it was discovered?

According to Wadler, C is an "invented" language, not a "discovered"
language.

Wadler (https://www.youtube.com/watch?v=aeRVdYN6fE8)  at around 40 minutes
shows the logician's view versus the computer science view of various
theories.
He makes a distinction betwen invented and discovered langauges.

(begin quote of Wadler)

Every interesting logic has a corresponding language feature:

Natural Deduction (Gentzen) <==> Typed Lambda Calculus (Church)
Type Schemes (Hindley) <==> ML Type System (Milner)
System F (Girard) <==> Polymorphic Lambda Calculus (Reynolds)
Modal Logic (Lewis) <==> Monads (state, exceptions) (Kleisli, Moggi)
Classical-Intuitionistic Embedding (Godel) <==> Continuation Passing
(Reynolds)
Linear Logic (Girard) <==> Session Types (Honda)

Languages which were "discovered" (based on theory):

Lisp (McCarthy)
Iswim (Landin)
Scheme (Steele and Sussman)
ML (Milner, Gordon, Wadsworth)
Haskell (Hudak, Hughes, Peyton Jones, Wadler)
O'Caml (Leroy)
Erlang (Armstrong, Virding, Williams)
Scala (Odersky)
F# (Syme)
Clojure (Hickey)
Elm (Czaplicki)

At about minute 43 we hear:

"Not all of these languages are based on lambda calculus ...
but there is a core that is "discovered". Now most of you work
in languages like Java, C++, or Python and those languages I will
claim are not discovered; they are "invented". Looking at them
you can tell they are invented. So this is my invitation to you
to work in languages that are "discovered".

Somebody asked before about "dependent types". It turns out that
when you extend into dependent types you now get languages that
have "for all" and "there exists" that corresponds to a feature
called "dependent types". So this means that you can encode very
sophisticated proofs, pretty much everything you can name as a
program. And so the standard way to get a computer to check a
proof for you and to help you with that proof is to represent that
as a program in typed lambda calculus.

All of these systems are based on a greater or lesser extent on
that idea:

Automath (de Bruijn)
Type Theory (Martin Lof)
Mizar (Trybulec)
ML/LCF (Milner, Gordon, Wadsworth)
NuPrl (COnstable)
HOL (Gordon, Melham)
Coq (Huet, Coquand)
Isabelle (Paulson)
Epigram (McBride, McKinna)
Agda (Norell)

(end quote)

Axiom is using Coq for its proof platform because Axiom needs
dependent types (e.g. specifying matrix sizes by parameters).

In addition, Coq is capable of generating a program from a
proof and the plan is to reshape the Spad solution to more
closely mirror the proof-generated code. Also, of course, we need
to remove any errors in the Spad code found during proofs.

It seems there must be an isomorphism between Coq and Spad.

At the moment it seems that Coq's 'nat' matches Axiom's
NonNegativeInteger. Coq also has a 'Group' type which needs
to be matched with the Axiom type. The idea is to find many
isomorphisms of primitive types which will generate lemmas
that can be used to prove more complex code.

Given that Axiom has an abstract algebra scaffold it seems likely
that a reasonable subset can be proven (modulo the fact that there
are arguable differences from the abstract algebra type hierarchy).

Currently Coq is run during the Axiom build to check any proofs
of Spad code that are included. ACL2 is also run during the build
to check any proofs of Lisp code that are included.

I'm taking a course at Carnegie-Mellon this semester using Lean
(a Coq offshoot) in order to try to make some working examples
of proving Spad code correct.


On Thu, Jan 12, 2017 at 10:14 PM, Gabriel Dos Reis <
gdr@integrable-solutions.net> wrote:

> There were implementations of C in Lisp. So C shares that formal logic
> basis, or that it was discovered?
>
> On Wed, Jan 11, 2017 at 8:17 PM, Tim Daly <axiomcas@gmail.com> wrote:
>
>> I'm making progress on proving Axiom correct both at the Spad level and
>> the Lisp level. One interesting talk by Phillip Wadler on "Propositions as
>> Types", a very entertaining talk, is here:
>> https://www.youtube.com/watch?v=IOiZatlZtGU
>>
>> He makes the interesting point late in the talk that some languages are
>> "discovered" based on fundamental logic principles (e.g.Lisp) and others
>> are "invented" with no formal basis (e.g. C). As he says, "you can tell
>> whether your language is discovered or invented".
>>
>> The point is that Lisp has a formal logic basis and, as Spad is really
>> just a domain specific language implemented in Lisp then Spad shares
>> the formal logic basis.

\start
Date: Fri, 13 Jan 2017 18:04:53 +0100
From: Kurt Pagani <nilqed@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Proving Axiom Correct

Am 13.01.2017 um 07:35 schrieb Tim Daly:

...

> 
> Axiom is using Coq for its proof platform because Axiom needs
> dependent types (e.g. specifying matrix sizes by parameters).
> 
> In addition, Coq is capable of generating a program from a
> proof and the plan is to reshape the Spad solution to more
> closely mirror the proof-generated code. Also, of course, we need
> to remove any errors in the Spad code found during proofs.

A SPAD extractor should be feasible but it may take some time to set up the
necessary infrastructure to compile a plugin. E.g. see

https://github.com/coq/coq/tree/trunk/plugins/extraction

There is a recent post @ https://news.ycombinator.com/item?id=12183095
about Coq2Rust where I saw some nice ideas:

-- https://github.com/pirapira/coq2rust

There's more about it if you use the search field (bottom) at
https://news.ycombinator.com/news.

> 
> It seems there must be an isomorphism between Coq and Spad.
> 
> At the moment it seems that Coq's 'nat' matches Axiom's
> NonNegativeInteger. Coq also has a 'Group' type which needs
> to be matched with the Axiom type. The idea is to find many
> isomorphisms of primitive types which will generate lemmas
> that can be used to prove more complex code.
> 

Still there are a lot of Lisp dependencies, e.g. integer.spad

zero? x == ZEROP(x)$Lisp
--      one? x == ONEP(x)$Lisp
        one? x == x = 1
        0 == 0$Lisp
        1 == 1$Lisp
        base() == 2$Lisp

which will it make necessary to start defining a bunch of axioms/parameters.
Coq certainly is the right tool for such a venture, however, I recently cloned
'pvslib' which uses SRI's PVS and I was surprised how close it is
(syntactically) to SPAD. i guess it would be my second choice.

http://pvs.csl.sri.com
https://github.com/nasa/pvslib/blob/master/interval_arith/interval.pvs

\start
Date: Fri, 13 Jan 2017 13:20:49 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Kurt Pagani <nilqed@gmail.com>, axiom-dev <axiom-developer@nongnu.org>, 
	Tim Daly <daly@axiom-developer.org>
Subject: Re: [Axiom-developer] Proving Axiom Correct

>From: Kurt Pagani <nilqed@gmail.com>
>
>>
>> Axiom is using Coq for its proof platform because Axiom needs
>> dependent types (e.g. specifying matrix sizes by parameters).
>>
>> In addition, Coq is capable of generating a program from a
>> proof and the plan is to reshape the Spad solution to more
>> closely mirror the proof-generated code. Also, of course, we need
>> to remove any errors in the Spad code found during proofs.
>
>A SPAD extractor should be feasible but it may take some time to set up the
>necessary infrastructure to compile a plugin. E.g. see
>
>https://github.com/coq/coq/tree/trunk/plugins/extraction

I had not actually thought of trying to extract Spad directly.
My plan was to extract the ML code and compare it to Spad.

It would be interesting to extract Spad directly.
Indeed it would probably uncover bugs in Axiom's compiler.

I think it would be really valuable to try to converge Spad and COQ.
It would force more functional programming discipline on Spad code.
COQ will probably benefit as Axiom's mathematics gets proven.



>There is a recent post @ https://news.ycombinator.com/item?id=12183095
>about Coq2Rust where I saw some nice ideas:
>
>-- https://github.com/pirapira/coq2rust
>
>There's more about it if you use the search field (bottom) at
>https://news.ycombinator.com/news.
>
>>
>> It seems there must be an isomorphism between Coq and Spad.
>>
>> At the moment it seems that Coq's 'nat' matches Axiom's
>> NonNegativeInteger. Coq also has a 'Group' type which needs
>> to be matched with the Axiom type. The idea is to find many
>> isomorphisms of primitive types which will generate lemmas
>> that can be used to prove more complex code.
>>
>
>Still there are a lot of Lisp dependencies, e.g. integer.spad
>
>zero? x == ZEROP(x)$Lisp
>--      one? x == ONEP(x)$Lisp
>        one? x == x = 1
>        0 == 0$Lisp
>        1 == 1$Lisp
>        base() == 2$Lisp

This proof effort uses COQ for the Spad code and ACL2 for the Lisp code.
We will probably need a COQ.Lisp interface package that provides proofs
of Axiom's $Lisp package calls. This needs to be formalized anyway. There
should be a complete list made.

At the moment (in book volume 5) there is a chapter that contains the Lisp
code that Axiom uses but it does not cover direct lisp package calls like
0$Lisp.
I''ll try to collect all instances and document the complete set.




>which will it make necessary to start defining a bunch of
axioms/parameters.
>Coq certainly is the right tool for such a venture, however, I recently
cloned
'>pvslib' which uses SRI's PVS and I was surprised how close it is
>(syntactically) to SPAD. i guess it would be my second choice.
>
>http://pvs.csl.sri.com
>https://github.com/nasa/pvslib/blob/master/interval_arith/interval.pvs

Thanks. I'll look into the PVS work. However, I've looked at a fair number
of
these proof systems and COQ seems to be well supported (an INRIA project),
well documented, and compatible with Axiom's needs.

ACL2 is also well supported, well documented, and compatible. I've used some
prior work years ago on a project at IBM Research. It was known as the
Boyer-Moore theorem prover.

\start
Date: Mon, 16 Jan 2017 09:09:58 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Kurt Pagani <nilqed@gmail.com>, Tim Daly <daly@axiom-developer.org>, 
	axiom-dev <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Axiom, COQ, and Proof General

Kurt,

I've been using Proof General for COQ proof development.
I've been thinking about your idea of directly proving Spad code.
There are several interesting points.

COQ has types as first-class objects. This allows types like
nat to be effectively renamed into NNI. More likely, a COQ-based
NNI would extend COQ's nat type. It appears I can also do some
Spad-Category-like inheritance hierarchy. The net result would be
that "nearly native" Spad code could be proven.

COQ also has a form of literate programming. COQ comments are
rendered as latex/pdf files. Latex commands can be embedded in the
comments. The net result is that a form of the final document is
directly executable.

Proof General runs the coqtop interpreter as a separate process under
Emacs, similar to the Slime interface used for lisp. This allows for the
forward and backward stepping in the file. Axiom has an undo command
so it seems possible to run the Axiom interpreter under Proof General.
That would allow interactive development of Spad code that could also
be proof-checked during development.

This combination of factors could really change the way that Axiom code
is developed, leading to much higher code quality.

If I get time this semester I may try to develop the geometric algebra code
this way. It depends on how the class goes.

All things considers, you made a brilliant suggestion.

Tim

\start
Date: Wed, 25 Jan 2017 00:18:02 -0800
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Tim Daly <axiomcas@gmail.com>, 
	open-axiom-devel <open-axiom-devel@lists.sourceforge.net>
Subject: Re: [Axiom-developer] Proving Axiom Correct

I was largely poking, tongue in cheek, at the earlier syllogism:

>> The point is that Lisp has a formal logic basis and, as Spad is really
>> just a domain specific language implemented in Lisp then Spad shares
>> the formal logic basis.

-- Gaby

On Thu, Jan 12, 2017 at 10:35 PM, Tim Daly <axiomcas@gmail.com> wrote:

> > There were implementations of C in Lisp. So C shares that formal logic
> basis, or that it was discovered?
>
> According to Wadler, C is an "invented" language, not a "discovered"
> language.
>
> Wadler (https://www.youtube.com/watch?v=aeRVdYN6fE8)  at around 40 minutes
> shows the logician's view versus the computer science view of various
> theories.
> He makes a distinction betwen invented and discovered langauges.
>
> (begin quote of Wadler)
>
> Every interesting logic has a corresponding language feature:
>
> Natural Deduction (Gentzen) <==> Typed Lambda Calculus (Church)
> Type Schemes (Hindley) <==> ML Type System (Milner)
> System F (Girard) <==> Polymorphic Lambda Calculus (Reynolds)
> Modal Logic (Lewis) <==> Monads (state, exceptions) (Kleisli, Moggi)
> Classical-Intuitionistic Embedding (Godel) <==> Continuation Passing
> (Reynolds)
> Linear Logic (Girard) <==> Session Types (Honda)
>
> Languages which were "discovered" (based on theory):
>
> Lisp (McCarthy)
> Iswim (Landin)
> Scheme (Steele and Sussman)
> ML (Milner, Gordon, Wadsworth)
> Haskell (Hudak, Hughes, Peyton Jones, Wadler)
> O'Caml (Leroy)
> Erlang (Armstrong, Virding, Williams)
> Scala (Odersky)
> F# (Syme)
> Clojure (Hickey)
> Elm (Czaplicki)
>
> At about minute 43 we hear:
>
> "Not all of these languages are based on lambda calculus ...
> but there is a core that is "discovered". Now most of you work
> in languages like Java, C++, or Python and those languages I will
> claim are not discovered; they are "invented". Looking at them
> you can tell they are invented. So this is my invitation to you
> to work in languages that are "discovered".
>
> Somebody asked before about "dependent types". It turns out that
> when you extend into dependent types you now get languages that
> have "for all" and "there exists" that corresponds to a feature
> called "dependent types". So this means that you can encode very
> sophisticated proofs, pretty much everything you can name as a
> program. And so the standard way to get a computer to check a
> proof for you and to help you with that proof is to represent that
> as a program in typed lambda calculus.
>
> All of these systems are based on a greater or lesser extent on
> that idea:
>
> Automath (de Bruijn)
> Type Theory (Martin Lof)
> Mizar (Trybulec)
> ML/LCF (Milner, Gordon, Wadsworth)
> NuPrl (COnstable)
> HOL (Gordon, Melham)
> Coq (Huet, Coquand)
> Isabelle (Paulson)
> Epigram (McBride, McKinna)
> Agda (Norell)
>
> (end quote)
>
> Axiom is using Coq for its proof platform because Axiom needs
> dependent types (e.g. specifying matrix sizes by parameters).
>
> In addition, Coq is capable of generating a program from a
> proof and the plan is to reshape the Spad solution to more
> closely mirror the proof-generated code. Also, of course, we need
> to remove any errors in the Spad code found during proofs.
>
> It seems there must be an isomorphism between Coq and Spad.
>
> At the moment it seems that Coq's 'nat' matches Axiom's
> NonNegativeInteger. Coq also has a 'Group' type which needs
> to be matched with the Axiom type. The idea is to find many
> isomorphisms of primitive types which will generate lemmas
> that can be used to prove more complex code.
>
> Given that Axiom has an abstract algebra scaffold it seems likely
> that a reasonable subset can be proven (modulo the fact that there
> are arguable differences from the abstract algebra type hierarchy).
>
> Currently Coq is run during the Axiom build to check any proofs
> of Spad code that are included. ACL2 is also run during the build
> to check any proofs of Lisp code that are included.
>
> I'm taking a course at Carnegie-Mellon this semester using Lean
> (a Coq offshoot) in order to try to make some working examples
> of proving Spad code correct.
>
>
> On Thu, Jan 12, 2017 at 10:14 PM, Gabriel Dos Reis <
> gdr@integrable-solutions.net> wrote:
>
>> There were implementations of C in Lisp. So C shares that formal logic
>> basis, or that it was discovered?
>>
>> On Wed, Jan 11, 2017 at 8:17 PM, Tim Daly <axiomcas@gmail.com> wrote:
>>
>>> I'm making progress on proving Axiom correct both at the Spad level and
>>> the Lisp level. One interesting talk by Phillip Wadler on "Propositions
>>> as
>>> Types", a very entertaining talk, is here:
>>> https://www.youtube.com/watch?v=IOiZatlZtGU
>>>
>>> He makes the interesting point late in the talk that some languages are
>>> "discovered" based on fundamental logic principles (e.g.Lisp) and others
>>> are "invented" with no formal basis (e.g. C). As he says, "you can tell
>>> whether your language is discovered or invented".
>>>
>>> The point is that Lisp has a formal logic basis and, as Spad is really
>>> just a domain specific language implemented in Lisp then Spad shares
>>> the formal logic basis.

\start
Date: Wed, 25 Jan 2017 10:39:05 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>,
	axiom-dev <axiom-developer@nongnu.org>, 
	Tim Daly <daly@axiom-developer.org>
Subject: Re: [Axiom-developer] Proving Axiom Correct

I got the tongue-in-cheek aspect but Axiom's formal logic basis is
important.

In the 1980s Expert Systems were going to take over the world. We tried to
prove our version
correct using the Boyer-Moore theorem proving technology. We failed
miserably, partly
because the technology was not up to the task but mostly because we were
not up to the
task. Proving programs correct, at the time, was pretty much based on
reasoning about
pre- and -post-conditions. That's the "assembly language" of proof
techniques these days.
There was a complete mismatch with the rule-based expert systems technology.

Because Axiom is so close to the math and Coq is so close to Axiom it seems
there
is hope that this effort will make a lot more progress.

Coq is astonishingly good at proving things. It has a very small trusted
kernel based on
logic. But it has things like a 'tactics' language that enables automation
of proof steps
to the point where a proof might be just a single tactic, a 1-line
statement. This really
simplifies what is usually a hair-tearing struggle. Lean (a Microsoft/CMU)
system is
the basis of a course I'm taking at CMU and it seems even more
user-affectionate.

Even better, Coq has dependent types so it is possible to state, for
instance, the size
of a matrix. Since types can be user-defined we can create Axiom-specific
types in Coq
that mirror the Category structure.Even sweeter is that the syntax is very
close to Spad.
For example, Spad

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

and Coq

   Fixpoint gcd x y :=
      match x with
      | O => y
      | S x' => gcd (y mod (S x')) (S 'x)

where S is the Peano Successor function. Coq can prove this directly and
automatically infer that the type signature is

  gcd(x:nat,y:nat):nat

Coq proofs are now integrated into the build. The next commit will likely
include complete
automation of the proof, calling Coq during the build process with GCD as
the first case.

Once that happens the game seems to be creating the Axiom type tower in Coq.
Axiom's NNI becomes Coq's 'nat' type. This enables writing Axiom types
directly
in Coq proofs.

The ideal case would be to modify Axiom's compiler to accept the Coq/ML
syntax
but that's a large effort.

Another, more likely effort, would be to implement Coq's trusted kernel in
Axiom.
That would permit the compiler and interpreter to prove running code.

It is time to formalize computational mathematics and put computer algebra
on
a firm mathematical basis. The technolgy is here (although the funding is
not).


On Wed, Jan 25, 2017 at 3:18 AM, Gabriel Dos Reis <
gdr@integrable-solutions.net> wrote:

> I was largely poking, tongue in cheek, at the earlier syllogism:
>
> >> The point is that Lisp has a formal logic basis and, as Spad is really
> >> just a domain specific language implemented in Lisp then Spad shares
> >> the formal logic basis.
>
> -- Gaby
>
> On Thu, Jan 12, 2017 at 10:35 PM, Tim Daly <axiomcas@gmail.com> wrote:
>
>> > There were implementations of C in Lisp. So C shares that formal logic
>> basis, or that it was discovered?
>>
>> According to Wadler, C is an "invented" language, not a "discovered"
>> language.
>>
>> Wadler (https://www.youtube.com/watch?v=aeRVdYN6fE8)  at around 40
>> minutes
>> shows the logician's view versus the computer science view of various
>> theories.
>> He makes a distinction betwen invented and discovered langauges.
>>
>> (begin quote of Wadler)
>>
>> Every interesting logic has a corresponding language feature:
>>
>> Natural Deduction (Gentzen) <==> Typed Lambda Calculus (Church)
>> Type Schemes (Hindley) <==> ML Type System (Milner)
>> System F (Girard) <==> Polymorphic Lambda Calculus (Reynolds)
>> Modal Logic (Lewis) <==> Monads (state, exceptions) (Kleisli, Moggi)
>> Classical-Intuitionistic Embedding (Godel) <==> Continuation Passing
>> (Reynolds)
>> Linear Logic (Girard) <==> Session Types (Honda)
>>
>> Languages which were "discovered" (based on theory):
>>
>> Lisp (McCarthy)
>> Iswim (Landin)
>> Scheme (Steele and Sussman)
>> ML (Milner, Gordon, Wadsworth)
>> Haskell (Hudak, Hughes, Peyton Jones, Wadler)
>> O'Caml (Leroy)
>> Erlang (Armstrong, Virding, Williams)
>> Scala (Odersky)
>> F# (Syme)
>> Clojure (Hickey)
>> Elm (Czaplicki)
>>
>> At about minute 43 we hear:
>>
>> "Not all of these languages are based on lambda calculus ...
>> but there is a core that is "discovered". Now most of you work
>> in languages like Java, C++, or Python and those languages I will
>> claim are not discovered; they are "invented". Looking at them
>> you can tell they are invented. So this is my invitation to you
>> to work in languages that are "discovered".
>>
>> Somebody asked before about "dependent types". It turns out that
>> when you extend into dependent types you now get languages that
>> have "for all" and "there exists" that corresponds to a feature
>> called "dependent types". So this means that you can encode very
>> sophisticated proofs, pretty much everything you can name as a
>> program. And so the standard way to get a computer to check a
>> proof for you and to help you with that proof is to represent that
>> as a program in typed lambda calculus.
>>
>> All of these systems are based on a greater or lesser extent on
>> that idea:
>>
>> Automath (de Bruijn)
>> Type Theory (Martin Lof)
>> Mizar (Trybulec)
>> ML/LCF (Milner, Gordon, Wadsworth)
>> NuPrl (COnstable)
>> HOL (Gordon, Melham)
>> Coq (Huet, Coquand)
>> Isabelle (Paulson)
>> Epigram (McBride, McKinna)
>> Agda (Norell)
>>
>> (end quote)
>>
>> Axiom is using Coq for its proof platform because Axiom needs
>> dependent types (e.g. specifying matrix sizes by parameters).
>>
>> In addition, Coq is capable of generating a program from a
>> proof and the plan is to reshape the Spad solution to more
>> closely mirror the proof-generated code. Also, of course, we need
>> to remove any errors in the Spad code found during proofs.
>>
>> It seems there must be an isomorphism between Coq and Spad.
>>
>> At the moment it seems that Coq's 'nat' matches Axiom's
>> NonNegativeInteger. Coq also has a 'Group' type which needs
>> to be matched with the Axiom type. The idea is to find many
>> isomorphisms of primitive types which will generate lemmas
>> that can be used to prove more complex code.
>>
>> Given that Axiom has an abstract algebra scaffold it seems likely
>> that a reasonable subset can be proven (modulo the fact that there
>> are arguable differences from the abstract algebra type hierarchy).
>>
>> Currently Coq is run during the Axiom build to check any proofs
>> of Spad code that are included. ACL2 is also run during the build
>> to check any proofs of Lisp code that are included.
>>
>> I'm taking a course at Carnegie-Mellon this semester using Lean
>> (a Coq offshoot) in order to try to make some working examples
>> of proving Spad code correct.
>>
>>
>> On Thu, Jan 12, 2017 at 10:14 PM, Gabriel Dos Reis <
>> gdr@integrable-solutions.net> wrote:
>>
>>> There were implementations of C in Lisp. So C shares that formal logic
>>> basis, or that it was discovered?
>>>
>>> On Wed, Jan 11, 2017 at 8:17 PM, Tim Daly <axiomcas@gmail.com> wrote:
>>>
>>>> I'm making progress on proving Axiom correct both at the Spad level and
>>>> the Lisp level. One interesting talk by Phillip Wadler on "Propositions
>>>> as
>>>> Types", a very entertaining talk, is here:
>>>> https://www.youtube.com/watch?v=IOiZatlZtGU
>>>>
>>>> He makes the interesting point late in the talk that some languages are
>>>> "discovered" based on fundamental logic principles (e.g.Lisp) and others
>>>> are "invented" with no formal basis (e.g. C). As he says, "you can tell
>>>> whether your language is discovered or invented".
>>>>
>>>> The point is that Lisp has a formal logic basis and, as Spad is really
>>>> just a domain specific language implemented in Lisp then Spad shares
>>>> the formal logic basis.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Axiom-developer mailing list
>>>> Axiom-developer@nongnu.org
>>>> https://lists.nongnu.org/mailman/listinfo/axiom-developer
>>>>
>>>>
>>>
>>
>



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