\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, 1 Mar 2017 09:18:59 -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>, Jeremy Avigad <avigad@cmu.edu>,
	Barry M Trager <bmt@us.ibm.com>, 
	Renaud Rioboo <renaud.rioboo@ensiie.fr>, Kurt Pagani <nilqed@gmail.com>
Subject: [Axiom-developer] Proving Axiom Correct -- Design musings

The Curry-Howard Isomorphism has been around since about 1969
https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

I first heard of it in 2003 working with Gilbert Baumslag at CCNY.
It seemed "interesting" but I didn't understand how important it is.

The field of proof theory has grown beyond belief in the past decade
and the systems are much more powerful than the Nthqm system I
used at IBM. It seems that these systems are now capable of providing
a solid basis for implementing proofs in/of Axiom.

The essential idea (for Axiom) is that a proof is a first-class object with
a well-defined type. The "type of a proof" is the statement of the theorem.
In Axiom, that would be contained in the Category.

The "implementation of the type" is the proof itself. In Axiom. that would
be contained in the Domain, just like one would implement any other
operation.

So, in Axiom terms, it is possible to give signatures in Axiom Categories,
such as "Commutative":

Commutative : Category ==

   TH ==> Theorem
   PR ==> Proof

   commutative : TH -> PR

 == add

Inheriting Commutative is no longer an empty promise. It requires a domain
to provide an implementation (aka a proof) of commutativity.

Similar towers of Theorem/Proof requirements can be built up using the
existing Category structure. For example, Group could inherit a tower of
theorems that need to be proven by a Domain that is a Group.

For example (using Lean syntax http://leanprover.github.io/ ):

class semigroup (=CE=B1 : Type u) extends has_mul =CE=B1 :=
(mul_assoc : =E2=88=80 a b c : =CE=B1, a * b * c = a * (b * c))

class comm_semigroup (=CE=B1 : Type u) extends semigroup =CE=B1 :=
(mul_comm : =E2=88=80 a b : =CE=B1, a * b = b * a)

class left_cancel_semigroup (=CE=B1 : Type u) extends semigroup =CE=B1 :=
(mul_left_cancel : =E2=88=80 a b c : =CE=B1, a * b = a * c =E2=86=92 b =
= c)

class right_cancel_semigroup (=CE=B1 : Type u) extends semigroup =CE=B1 :=
=
(mul_right_cancel : =E2=88=80 a b c : =CE=B1, a * b = c * b =E2=86=92 a =
= c)

class monoid (=CE=B1 : Type u) extends semigroup =CE=B1, has_one =CE=B1 :=
=
(one_mul : =E2=88=80 a : =CE=B1, 1 * a = a) (mul_one : =E2=88=80 a : =CE=
=B1, a * 1 = a)

class comm_monoid (=CE=B1 : Type u) extends monoid =CE=B1, comm_semigroup =
=CE=B1

class group (=CE=B1 : Type u) extends monoid =CE=B1, has_inv =CE=B1 :=
(mul_left_inv : =E2=88=80 a : =CE=B1, a=E2=81=BB=C2=B9 * a = 1)

Each of these theorems needs to be proven by a Domain which claims to
be a Group. The theorems themselves are essentially 'types' and the
proofs are essentially 'programs'. So, in Axiom-speak, a Domain which is
a Group has to "provide an implementation for the theorem signatures" by
creating a proof for each inherited signature, similar to the requirements
for other signatures, using operations from the Domain.

This use of "existing empty Categories" (like Commutative) seems to be
a reasonable place to insert theorem/proofs into Axiom's type tower.
At the moment, these are simply unproven declarations.

There are design questions of how to handle the 'forall', 'implies', and
other
syntax/semantics. Axiom's compiler needs extensions. Systems like Lean,
mentioned above, provide a server API which might be used to provide the
actual proof service to the Axiom compiler.

There are further questions which this does not address. For example, the
proof systems like to use Peano posulates for "natural numbers" whereas
Axiom uses Lisp integers for "NonNegativeIntegers". So there needs to be
some path to provide "ground truth" to proofs, all the way down to the
hardware.

The current path is a "tower of provers" extending from Spad to the
hardware:

 Spad <-> COQ
 Lisp <-> ACL2
 C <-> Intel  (using C0 from Pfenning at CMU?; GCL compiles to C)
 Intel <-> (my prior Intel instruction semantics work on
Conditional-Concurrent
               Assignments [1][2])


In the "upward" direction there needs to be some connection between the
theorems/proofs in a paper (e.g. integration, groebner, etc) and the Axiom
Spad implementations. I'm collecting references and decorating the
algorithms
where I can find a connection. But that is only some groundwork. I have no
insight into this question yet. In the future there ought to be a stronger
formal
connection between the published theory and its implementation in Axiom.

Comments? Suggestions?

Tim


[1] Burns, Daly: "FXplorer: Exploration of Computed Software Behavior"
HICSS 2009
"
http://daly.axiom-developer.org/TimothyDaly_files/publications/sei/hicss09.=
pdf

[2] Mili, Daly, Pleszkoch, Prowell HICSS 2006
"A Sematic Recognizer Infrastructure for Computing Loop Behavior"
http://daly.axiom-developer.org//TimothyDaly_files/publications/sei/hic.pdf

\start
Date: Fri, 3 Mar 2017 19:21:37 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Jeremy Avigad <avigad@cmu.edu>, Tim Daly <daly@axiom-developer.org>, 
	axiom-dev <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Ad-hoc polymorphism paper

Jeremy,

I read Wadler's paper. I find it amusing because these ideas were
implemented in Axiom long before the paper was published.
(
http://202.3.77.10/users/karkare/courses/2010/cs653/Papers/ad-hoc-polymorphism.pdf
)

One advantage, though, is their formalization. In the computer
algebra world there was work by Santas "A Type System for
Computer Algebra (http://daly.axiom-developer.org/Sant95.pdf)
who visited the Axiom group at IBM Research.

Axiom introduces the idea of "conditional categories" which does
not seem to be anywhere else. (see Santas paper) You can say

C0: Category == with (if % has Ring then Ring)

so you can assert Ring in the current Domain (called %)
if the Category chain includes Ring. Knowing that, the
Domain (Instance in Lean) can conditionally add functions

D0 : C0 ==

  if % has Ring then
      foo: % -> %

Axiom was far ahead of its time and once it has a proof mechanism
it will be far ahead of all other computer algebra systems.

I'd really like to replace the current type-resolution machinery in Axiom
with a more formal approach. The compiler requires explicit types
everywhere. The interpreter does type inference. It would be interesting
to re-implement it using a Hindley/Milner style machine. I suspect that
would raise some interesting research questions as Axiom implements
a very general coerce/convert mechanism. Even so, there are special
cases hard-coded into the interpreter.

A theory-based machine would be much easier to prove correct.

Tim

\start
Date: Sat, 4 Mar 2017 02:05:37 -0500
From: Tim Daly <axiomcas@gmail.com>
To: Jeremy Avigad <avigad@cmu.edu>, Tim Daly <daly@axiom-developer.org>, 
	axiom-dev <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Type Theory and Axiom

Weber's Thesis
http://cg.cs.uni-bonn.de/personal-pages/weber/publications/pdf/WeberA/Weber93b.pdf
is an excellent "cross-over" document between type theory and Axiom. In
particular,
he talks about type classes, which we have been discussing, in Axiom terms.
Many
of these topics, such as coercions, are relevant.

The thesis abstract reads:

We study type systems for computer algebra systems, which frequently
correspond
to the "pragmatically developed" typing constructions used in Axiom.

A central concept is that of type classes which correspoind to Axiom
categories. We
will show that types can be syntactically described as terms of a regular
order-sorted
signature if no type parameters are allowed. Using results obtained for the
functional
programming language Haskell we will show that the problem of type
inference is
decidable. This result still holds if higher-order functions are present
and parametric
polymorphism is used. These additional constructs are useful for further
extensions
of existing computer algebra systems. These typing concepts can be used to
implement
category theory and algebra.

On the one hand we will show that there are well known techniques to
specify many
important type classes algebraically, and we will also show that a formal
and
algorithmically Feasible treatment of the interactions of algebraically
specified data
types and type classes is possible. On the other hand we will prove that
there are
quite elementary examples arising in computer algebra which need very
"strong"
formalisms to be specified and are thus hard to handle algorithmically.

We will show that it is necessary to distinguish between types and elements
as
parameters of parametrized type classes. The type inference problem for the
former
remains decidable whereas for the latter it becomes undecidable. We will
also show
that such a distinction can be made quite naturally.

Type classes are second-order types. Although we will show that there are
constructions used in mathematics which imply that type classes have to
become
first-order types in order to model the examples naturally, we will also
argue that this
does not seem to be the case in areas currently accessible for an algebra
system.
We will only sketch some systems that have been developed during the last
years
in which the concept of type classes as first-order types can be expressed.
For some
of these systems the type inference problem was proven to be undecidable.

Another fundamental concept for a type system of a computer algebra system
--
at least for the purpose of a user interface -- are coercions. We will show
that there
are cases which can be modeled by coercions but not by an "inheritance
mechanism", i.e. the concept of coercions is not only orthogonal to the one
of
type classes but also to more general formalisms as are used in
object-oriented
languages. We will define certain classes of coercions and impose
conditions on
important classes of coercions which will imply that the meaning of an
expression
is independent of the particular coercions that are used in order to type
it.

We shall also impose some conditions on the interaction between polymorphic
operations defined in type classes and coercions that will yield a unique
meaning
of an expression independent of the type which is assigned to it -- if
coercions are
present there will very frequently be several possiblities to assign types
to expressions.

Often it is not only possible to coerce one type into another but it will
be the case
that two types are actually isomorphic. We will show that isomorphic types
have
properties that cannot be deduced from the properties of coercions and will
shortly
discuss other possibilities to model type isomorphisms. There are natural
examples
of type isomorphisms occurring in the area of computer algebra that have a
"problematic" behavior. So we will prove for a certain example that the type
isomorphisms cannot be captured by a finite set of coercions by proving that
the naturally associated equational theory is not finitely axiomatizable.

Up to now few results are known that would give a clear dividing line
between
classes of coercions which have a decidable type inference problem and
classes for which type inference becomes undecidable. We will give a type
inference algorithm for some important class of coercions.

Other typing constructs which are again quite orthogonal to the previous
ones
are those of partial functions and of types depending on elements. We will
link
the treatment of partial functions in Axiom to the one used in order-sorted
algebras
and will show some problems which arise if a seemingly more expressive
solution
were used. There are important cases in which types depending on elements
arise
naturally. We will show that not only type inference but even type checking
is
undecidable for relevant cases occurring in computer algebra.

Tim

\start
Date: Mon, 6 Mar 2017 00:54:50 -0500
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] Roads and Bridges (re: open source software)

https://fordfoundcontentthemes.blob.core.windows.net/media/2976/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf

\start
Date: Mon, 6 Mar 2017 07:37:50 -0800
From: Arthur Ralfs <arthur@mathbrane.ca>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Roads and Bridges (re: open source software)

On 03/05/2017 09:54 PM, Tim Daly wrote:
> https://fordfoundcontentthemes.blob.core.windows.net/media/2976/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf
>

Meanwhile adolescents get paid $28 million a year so people can watch 
them chase a ball around.

Arthur

\start
Date: Sat, 11 Mar 2017 23:00:41 -0800
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Tim Daly <axiomcas@gmail.com>
Subject: Re: [Axiom-developer] Ad-hoc polymorphism paper

Reimplementing AXIOM systems with a Hindley-Milner style polymorphism will
take the computer algebra community at least three or four decades back --
with no improvement.

-- Gaby

On Fri, Mar 3, 2017 at 4:21 PM, Tim Daly <axiomcas@gmail.com> wrote:

> Jeremy,
>
> I read Wadler's paper. I find it amusing because these ideas were
> implemented in Axiom long before the paper was published.
> (http://202.3.77.10/users/karkare/courses/2010/cs653/
> Papers/ad-hoc-polymorphism.pdf)
>
> One advantage, though, is their formalization. In the computer
> algebra world there was work by Santas "A Type System for
> Computer Algebra (http://daly.axiom-developer.org/Sant95.pdf)
> who visited the Axiom group at IBM Research.
>
> Axiom introduces the idea of "conditional categories" which does
> not seem to be anywhere else. (see Santas paper) You can say
>
> C0: Category == with (if % has Ring then Ring)
>
> so you can assert Ring in the current Domain (called %)
> if the Category chain includes Ring. Knowing that, the
> Domain (Instance in Lean) can conditionally add functions
>
> D0 : C0 ==
>
>   if % has Ring then
>       foo: % -> %
>
> Axiom was far ahead of its time and once it has a proof mechanism
> it will be far ahead of all other computer algebra systems.
>
> I'd really like to replace the current type-resolution machinery in Axiom
> with a more formal approach. The compiler requires explicit types
> everywhere. The interpreter does type inference. It would be interesting
> to re-implement it using a Hindley/Milner style machine. I suspect that
> would raise some interesting research questions as Axiom implements
> a very general coerce/convert mechanism. Even so, there are special
> cases hard-coded into the interpreter.
>
> A theory-based machine would be much easier to prove correct.
>
> Tim
>

\start
Date: Sun, 12 Mar 2017 04:55:02 -0400
From: Tim Daly <axiomcas@gmail.com>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>,
	Tim Daly <daly@axiom-developer.org>
Subject: Re: [Axiom-developer] Ad-hoc polymorphism paper

Indeed. Apparently the bleeding edge is actually Homotopy Type Theory.

I'm taking a course from Robert Harper on the subject now. I'm meeting
with a couple profs over spring break (this week), hoping to interest them
in Axiom. Unfortunately there is no grant funding behind Axiom so I'm
not sure if anything will come of it.

I'm also taking a course with Jeremy Avigad on the details of Lean
and Interactive Theorem Proving. I've been reading the source code
of the Lean kernel to try to understand how it works.

So much to know, so little time.

It is clear, however, that there is a nice mapping between these ideas
and Axiom's ideas. The goal is to get a "thin thread" through the system
that involves a proof of the GCD but to do it in such a way that proofs
become first-class objects, implemented in the Domain and propositions
are types defined in the Category, requiring proof in the Domain.

The idea of 'typeclass' matches the idea of Category (Axiom) nicely.
The idea of 'instance' matches the idea of Domain nicely.

Tim


On Sun, Mar 12, 2017 at 3:00 AM, Gabriel Dos Reis <
gdr@integrable-solutions.net> wrote:

> Reimplementing AXIOM systems with a Hindley-Milner style polymorphism will
> take the computer algebra community at least three or four decades back --
> with no improvement.
>
> -- Gaby
>
> On Fri, Mar 3, 2017 at 4:21 PM, Tim Daly <axiomcas@gmail.com> wrote:
>
>> Jeremy,
>>
>> I read Wadler's paper. I find it amusing because these ideas were
>> implemented in Axiom long before the paper was published.
>> (http://202.3.77.10/users/karkare/courses/2010/cs653/Papers/
>> ad-hoc-polymorphism.pdf)
>>
>> One advantage, though, is their formalization. In the computer
>> algebra world there was work by Santas "A Type System for
>> Computer Algebra (http://daly.axiom-developer.org/Sant95.pdf)
>> who visited the Axiom group at IBM Research.
>>
>> Axiom introduces the idea of "conditional categories" which does
>> not seem to be anywhere else. (see Santas paper) You can say
>>
>> C0: Category == with (if % has Ring then Ring)
>>
>> so you can assert Ring in the current Domain (called %)
>> if the Category chain includes Ring. Knowing that, the
>> Domain (Instance in Lean) can conditionally add functions
>>
>> D0 : C0 ==
>>
>>   if % has Ring then
>>       foo: % -> %
>>
>> Axiom was far ahead of its time and once it has a proof mechanism
>> it will be far ahead of all other computer algebra systems.
>>
>> I'd really like to replace the current type-resolution machinery in Axiom
>> with a more formal approach. The compiler requires explicit types
>> everywhere. The interpreter does type inference. It would be interesting
>> to re-implement it using a Hindley/Milner style machine. I suspect that
>> would raise some interesting research questions as Axiom implements
>> a very general coerce/convert mechanism. Even so, there are special
>> cases hard-coded into the interpreter.
>>
>> A theory-based machine would be much easier to prove correct.
>>
>> Tim
>>

\start
Date: Mon, 13 Mar 2017 11:57:52 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] [IGNORE] Receipt for 9 year renewal of
 axiom-developer.org

This is certain to get lost over time. It is posted here for reference.

Receipt for 9 year renewal of axiom-developer.org

From: Network Solutions <support@networksolutions.com>
Date: Mon, 13 Mar 2017 11:33:32 -0400 (EDT)

Here is your order comfirmation:

Order Number: 760549201
Today's Charges: $332.91
Future Charges: $0.00

Ordered By:

User ID: AXIOM-DEVELOPER
User Name: Timothy Daly
Account Number: 28771866
Account Holder: Timothy Daly
Primary Contact: Timothy Daly (AXIOM-DEVELOPER)

Renewal of:
domain .ORG
AXIOM-DEVELOPER.ORG
Quantity: 1
Term 9 year(s)
Today's Charges: $332.91
Exp. Date**: 2026-04-01

\start
Date: Mon, 27 Mar 2017 08:08:44 +0000
From: "Clancy, Dominic" <Dominic.Clancy@uibk.ac.at>
To: "axiom-developer@nongnu.org" <axiom-developer@nongnu.org>
Subject: [Axiom-developer] Problem building axiom on Fedora 25

--_002_149060212328792cameluibkacat_
Content-Type: text/plain; charset="utf-8"
Content-ID: <D0DC2996F81A6F4892F3BD2944503553@exchange.uibk.ac.at>
Content-Transfer-Encoding: base64

RGVhciBEZXZlbG9wZXJzLMKgDQoNClBsZWFzZSBhY2NlcHQgbXkgYXBvbG9naWVzIGluIGFkdmFu
Y2UgZm9yIGJvdGhlcmluZyB5b3XCoA0Kd2l0aCBhIHRlZGlvdXMgYnVpbGQgcHJvYmxlbS4gSG93
ZXZlciwgZGVzcGl0ZSBzZXZlcmFsIGhlcm9pYw0KYXR0ZW1wdHMsIEkgY291bGRuJ3QgZmlndXJl
IG91dCBob3cgdG8gZ2V0IGF4aW9tIHRvIGJ1aWxkIG9uwqANCkZlZG9yYS4NCg0KQWZ0ZXIgZG93
bmxvYWRpbmcgdGhlIGF4aW9tLW1hc3Rlci50YXIuZ3ogZGlyZWN0b3J5IGZyb20gdGhlwqANCmdp
dGh1YiBhcmNoaXZlLCAvZGFseS9heGlvbSwgSSBhdHRlbXB0ZWQgdG8gYnVpbGQgYXhpb20gb27C
oA0KRmVkb3JhIDI1IExpbnV4LiAoNC45LjE0LTIwMC5mYzI1Lng4Nl82NCBMaW51eC4pDQrCoA0K
U3BlY2lmaWNhbGx5LCBhZnRlciBkb3dubG9hZGluZyBhbmQgdW5wYWNraW5nIHRoZSBheGlvbS1t
YXN0ZXLCoA0KemlwIGRpcmVjdG9yeSBmcm9tIGdpdGh1YiBpbnRvIGEgZGlyZWN0b3J5IGNhbGxl
ZMKgDQoNCi9ob21lL2RvbWluaWMvYXhpb23CoA0KDQpJIGZpcnN0IGlzc3VlZCB0aGUgY29tbWFu
ZDoNCg0KwqAgc2V0c2Vib29sIC1QIGFsbG93X2V4ZWNoZWFwIDENCg0KZm9sbG93aW5nIHRoZSBz
dWdnZXN0aW9uIGdpdmVuIGluIEZBUSA1MywgYW5kIHRoZW4gZXhlY3V0ZWQ6wqANCg0KwqAgZXhw
b3J0IEFYSU9NPS9ob21lL2RvbWluaWMvYXhpb20vbW50L2ZlZG9yYTY0DQrCoCBleHBvcnQgUEFU
SD0kQVhJT00vYmluOiRQQVRIwqANCsKgIG1ha2UgTk9JU0U9IHwgdGVlIGNvbnNvbGUNCg0KVGhl
IGJ1aWxkIHByb2Nlc3MgZmFpbGVkIGFmdGVyIGp1c3QgYSBmZXcgbWludXRlcyzCoA0KYW5kIEkg
aGF2ZSBubyBpZGVhIHdoeS4gSSBoYXZlIGF0dGFjaGVkIHRoZSBNYWtlZmlsZS5wZGbCoA0KYW5k
IHRoZcKgbG9nIGZpbGUgImNvbnNvbGUiIGluIGEgdGFycmVkIGFyY2hpdmUgZm9ywqANCnlvdXIg
ZWRpZmljYXRpb24uwqDCoA0KDQpBbnkgcG9saXRlIHN1Z2dlc3Rpb25zIGZvciBhIGRpYWdub3Np
cyBhbmQgdHJlYXRtZW50Pw0KRG8gSSBoYXZlIHNvbWUgdGV4bGl2ZSBwYWNrYWdlcyBtaXNzaW5n
IHBlcmhhcHMsIGlzwqANCml0IGEgcHJvYmxlbSB3aXRoIFNFTGludXgsIG9yIGlzIGl0IHNvbWV0
aGluZyBlbnRpcmVsecKgDQpkaWZmZXJlbnQ/DQoNCg0KTWFueSB0aGFua3MhDQoNCkRvbWluaWMN
Ci0tIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KDQpEciBEb21pbmljIENsYW5jeQ0KSW5zdGl0dXRlIGZvciBBc3Ryby0g
YW5kIFBhcnRpY2xlIFBoeXNpY3MNClVuaXZlcnNpdHkgb2YgSW5uc2JydWNrDQpBdXN0cmlhDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19f

--_002_149060212328792cameluibkacat_

\start
Date: Mon, 27 Mar 2017 11:55:16 -0400
From: Tim Daly <axiomcas@gmail.com>
To: dominic.clancy@uibk.ac.at, Tim Daly <daly@axiom-developer.org>, 
	axiom-dev <axiom-developer@nongnu.org>
Subject: Re: [Axiom-developer] Problem building axiom on Fedora 25

The problem appears to be that GCC has changed the meaning of
'inline' and 'extern' which causes GCL (the underlying lisp) to fail to
build. This is supposed to be fixed in the next release of GCL.

The fix is calling gcc with -std=gnu89 when compiling GCL

The next release of GCL is still 'experimental' so Axiom has not
yet integrated it into the build. There are several short-term workarounds.

Currently Axiom is released on Docker when the algebra changes. Most
of the other changes are documenation which is available on the
Axiom website or Wikipedia so there is no need to update Docker.

If you're only interested in using (rather than developing) you could
   yum install axiom
from the debian version.

Another alternative is to run it in VirtualBox using Ubuntu 16.04

Tim

\start
Date: Thu, 30 Mar 2017 23:51:22 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <daly@axiom-developer.org>
Subject: [Axiom-developer] Terry Tso's three stages of mathematics

It will hardly come as a surprise that I think computational mathematics
is in Tso's Stage 1.

>From Terry Tso's blog

https://terrytao.wordpress.com/career-advice/there%E2%80%99s-more-to-mathem=
atics-than-rigour-and-proofs/

One can roughly divide mathematical education into three stages:

   1. The =E2=80=9Cpre-rigorous=E2=80=9D stage, in which mathematics is tau=
ght in an
   informal, intuitive manner, based on examples, fuzzy notions, and
   hand-waving. (For instance, calculus is usually first introduced in term=
s
   of slopes, areas, rates of change, and so forth.) The emphasis is more o=
n
   computation than on theory. This stage generally lasts until the early
   undergraduate years.
   2. The =E2=80=9Crigorous=E2=80=9D stage, in which one is now taught that=
 in order to do
   maths =E2=80=9Cproperly=E2=80=9D, one needs to work and think in a much =
more precise and
   formal manner (e.g. re-doing calculus by using epsilons and deltas all o=
ver
   the place). The emphasis is now primarily on theory; and one is expected=
 to
   be able to comfortably manipulate abstract mathematical objects without
   focusing too much on what such objects actually =E2=80=9Cmean=E2=80=9D. =
This stage usually
   occupies the later undergraduate and early graduate years.
   3. The =E2=80=9Cpost-rigorous=E2=80=9D stage, in which one has grown com=
fortable with
   all the rigorous foundations of one=E2=80=99s chosen field, and is now r=
eady to
   revisit and refine one=E2=80=99s pre-rigorous intuition on the subject, =
but this
   time with the intuition solidly buttressed by rigorous theory. (For
   instance, in this stage one would be able to quickly and accurately perf=
orm
   computations in vector calculus by using analogies with scalar calculus,=
 or
   informal and semi-rigorous use of infinitesimals, big-O notation, and so
   forth, and be able to convert all such calculations into a rigorous
   argument whenever required.) The emphasis is now on applications,
   intuition, and the =E2=80=9Cbig picture=E2=80=9D. This stage usually occ=
upies the late
   graduate years and beyond.

\start
Date: Fri, 31 Mar 2017 00:34:48 -0400
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, "state of the art" report

I've spent a lot of time talking to professors at CMU about
Type Theory and the Curry-Howard correspondence. There
are excellent lectures online, taught every summer in Oregon.
https://www.cs.uoregon.edu/research/summerschool/summer16/curriculum.php

Type theory has advanced considerably in recent years. It appears
that there is a correspondence between Axiom's world and the formal
theory world.

Axiom has "Categories", which correspond the "Typeclasses".
Axiom had "Domains", which correspond to "Instances".

However, I've adusted the "Typeclasses" and "Instances" ideas
a bit to better match Axiom's construction.

Typeclasses have 3 parts:
   carrier -- the representation data structure
   signatures -- the functions
   propositions -- the logical type requirements

In Axiom we currently only have signatures in Categories.
We put the "carrier" in the Domain as the Rep.

Consider the Axiom Domain NonNegativeInteger. NNI roughly
corresponds to the Type theory "Nat" construction. They differ
in that Axiom uses Lisp Integers whereas Type theory uses
Peano arithmetic (a zero and a successor function) but for
our purposes this does not matter at the moment.

NNI inherits a requirement for an "=" signature from the BasicType
Category. Type theory expects that "=" should satisfy three
propositions,
  reflexive:  x = x
  symmetric: x = y iff y = x
  transitive: x = y and y = z implies x = z

But these propositions are "types", per Curry-Howard. That means
that we can state these "types" in BasicType. They are no
different from the signatures we currently use.

  reflexive: x:% = x:%
  symmetric: x:% = y:% <-> y:% = x:%
  transitive: x:% = y:% /\ y:% = z:% -> x:% = z:%


But that implies that when we create an Axiom Domain we need
to do three things:
1) we need to define the "carrier" (Axiom's Rep) which we already do
2) we need to implement the function signature (we already do)
3) we need to provide proofs for each proposition and since the
    inherited propositions are type signatures that means we need
    to prove each one using operations and elements from the
    Domain we are creating.

We currently do not write Category propositions, nor do we yet have
a proof language for the Domain proofs.

However it appears that some systems (e.g. Lean)
https://github.com/leanprover
can operate in "server mode".

Which means that it might be possible to include the Category level
propositions as comments and the Domain level proofs as comments.
The compiler can pass these comments to the proof server and get
back a verification that the proof is correct. This is a short term
solution which is not "first class".

At present Axiom extracts these during the build and calls the
proof checker (COQ) to show that the proofs are correct. I am
trying to get a "thin thread" all the way through the system in
order to prove propositions about the NNI GCD function.

In the ideal case Axiom implements a trusted kernel in Lisp and
the propositions and proofs are native to the compiler/interpreter.
I'm currently studying the "trusted kernel" source code of various
systems to see what it would take to implement this.

A secondary effort involves coercions and conversions. Type theory
doesn't seem to say a lot about these operations. Fortenbacher
wrote a short paper years ago. Coercions are orthogonal to Types.
We really need a strong theory of coercions, most notably to
formalize their role in the interpreter.

Anyway, that's the current "state of the art" with respect to Axiom.

Tim

\start
Date: Fri, 31 Mar 2017 11:51:20 +0100
From: Martin Baker <ax87438@martinb.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Proving Axiom Correct,
 "state of the art" report

On 31/03/17 05:34, Tim Daly wrote:
> Consider the Axiom Domain NonNegativeInteger. NNI roughly
> corresponds to the Type theory "Nat" construction. They differ
> in that Axiom uses Lisp Integers whereas Type theory uses
> Peano arithmetic (a zero and a successor function) but for
> our purposes this does not matter at the moment.

Perhaps there are issues around this that will matter? Given that there 
are two formulations of each algebra, one like this:

zero: () -> $
succ: ($) -> $

and one like this:

+ ($,$) -> $

If one form is needed for inductive proofs and the other form for 
applied mathematics. Could Axiom hold both forms in a single 
category/domain and switch between them as needed?

Martin

\start
Date: Fri, 31 Mar 2017 12:34:16 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Martin Baker <ax87438@martinb.com>,
	Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>, Jeremy Avigad <avigad@cmu.edu>
Subject: Re: [Axiom-developer] Proving Axiom Correct

>Perhaps there are issues around this that will matter? Given that there
>are two formulations of each algebra, one like this:

>zero: () -> $
>succ: ($) -> $

>and one like this:

>+ ($,$) -> $

>If one form is needed for inductive proofs and the other form for
>applied mathematics. Could Axiom hold both forms in a single
>category/domain and switch between them as needed?

Indeed this is a fundamental question.

Holding both forms is not the correct path
since it keeps the "mathematical form" separate from the
"computational form". The point of this work is to "ground"
computational mathematics. So it is  necessary to
unify these two forms.

The approach to this problem relies on the fact that Axiom has
proofs not only at the spad layer (using COQ) but also at the
lisp layer (using ACL2). After that comes C and then Intel. There
is  a "proof tower" architecture (I failed to mention):

Spad: COQ
Lisp; ACL2
C: ? (Frank Pfenning at CMU has OC, a proven subset
        and there is some LLVM based work I've seen)
Intel: I spent 6 years developing the semantics of the Intel
        Instruction Set as a Lisp program. It goes from binary
        to Conditional Concurrent Assignments which can be
        used for reasoning about hardware state:
(
http://daly.axiom-developer.org/TimothyDaly_files/publications/sei/intel/intel.pdf
)

When you drill down to the spad implementation of equality you find
calls to lisp functions. One of the open research questions is how
to ground the recursive reasoning usually based on the Peano math
on Lisp primitives.Hopefully there is a "firewall" of proven lisp
primitives that can be used to support spad recursive proofs,
similar to the Peano mechanism.

So, in summary, one research question is what it means to ground
computational mathematics. That's one of the key questions to
answer when creating the "thin thread" from BasicType to NNI.

Tim

\start
Date: Fri, 31 Mar 2017 23:16:13 -0400
From: Tim Daly <axiomcas@gmail.com>
To: axiom-dev <axiom-developer@nongnu.org>, Martin Baker <ax87438@martinb.com>,
	Tim Daly <daly@axiom-developer.org>,
	Laurent Thery <Laurent.Thery@inria.fr>, 
	Jeremy Avigad <avigad@cmu.edu>, Renaud Rioboo <renaud.rioboo@ensiie.fr>,
	Kurt Pagani <nilqed@gmail.com>, Frank Pfenning <fp@cs.cmu.edu>
Subject: Re: [Axiom-developer] Proving Axiom Correct -- at the C level

I previously mentioned the "proof tower" approach to the question
of proving code at many different layers. Spad code proven in COQ,
Lisp code in ACL2, and Intel code in CCAs. The missing step in the
tower was C.

Apparently there is work in COQ (http://robbertkrebbers.nl/research/ch2o/)
on the CH2O formalization of ISO C11 by Robbert Krebbers. CH2) provides
an operational, executable, and axiomatic semantics for a significant
fragment of C11. So this provides COQ support for the missing layer in
the proof tower.

Now all we need are Category props and Domain proofs. What could be easier?
:-)

Tim



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