\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: Fri, 2 Jan 2015 11:19:39 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Axiom docker image

Docker is a "container technology". It allows Axiom images that should
"just run" without users having to install software. When a docker
container is built all of the required software is "inside the
container".

Microsoft, Apple, and the Linux distros all support docker images.
Currently the Microsoft and Apple versions use VirtualBox but both
companies plan to support native docker containers.

Rather than build a new image for each platform, docker provides a
cross-platform solution. Work is being done to automate the Axiom
build process, including automatically constructing and building
docker containers. This will provide a continuous build process which
makes the latest Axiom always available.

Axiom is now available in docker. Assuming you have docker installed:

  docker pull daly/axiom
  docker run -i -t daly/axiom axiom




You might run into a few issues if you have never used docker.

======================================================================
PROBLEM: DOCKER IS NOT INSTALLED

To install docker type

  apt-get update
  apt-get install docker.io (ubuntu)

  yum update
  yum install docker.io     (fedora)

======================================================================
PROBLEM: SILENCE ... THE OTHER DOCKER COMMAND

Note that there is an app named "docker" which is not the same thing.
You might have to remove it first due to name conflicts.

  sudo apt-get remove -y docker
  sudo apt-get install -y docker.io

======================================================================
PROBLEM: SOCKET ERROR MESSAGE

You might get an error message like:

  docker pull daly/axiom
  2014/12/22 11:19:38 Get http:///var/run/docker.sock/v1.15/info: dial unix

which means that the docker daemon is not running. To fix this type

  sudo systemctl start docker
  sudo systemctl enable docker

The first command starts the docker daemon. The second command 
enables docker to run when the system starts.

======================================================================
PROBLEM: USER LEVEL PERMISSION 

You might need to add yourself to the docker group and reboot

  sudo usermod -a -G docker (your username)
  sudo reboot

Now as a non-root user you should be able to do

  docker run -i -t daly/axiom axiom



Please let me know if you have any problems.

Tim

\start
Date: Fri, 02 Jan 2015 12:46:26 -0500
From: Eugene Surowitz <surow@attglobal.net>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Axiom docker image

Wonderful!

But do you know what levels of the OS's are required?

Gene

On 1/2/2015 12:19 PM, daly@axiom-developer.org wrote:
> Docker is a "container technology". It allows Axiom images that should
> "just run" without users having to install software. When a docker
> container is built all of the required software is "inside the
> container".
>
> Microsoft, Apple, and the Linux distros all support docker images.
> Currently the Microsoft and Apple versions use VirtualBox but both
> companies plan to support native docker containers.
>
> Rather than build a new image for each platform, docker provides a
> cross-platform solution. Work is being done to automate the Axiom
> build process, including automatically constructing and building
> docker containers. This will provide a continuous build process which
> makes the latest Axiom always available.
>
> Axiom is now available in docker. Assuming you have docker installed:
>
>    docker pull daly/axiom
>    docker run -i -t daly/axiom axiom
>
>
>
>
> You might run into a few issues if you have never used docker.
>
> ======================================================================
> PROBLEM: DOCKER IS NOT INSTALLED
>
> To install docker type
>
>    apt-get update
>    apt-get install docker.io (ubuntu)
>
>    yum update
>    yum install docker.io     (fedora)
>
> ======================================================================
> PROBLEM: SILENCE ... THE OTHER DOCKER COMMAND
>
> Note that there is an app named "docker" which is not the same thing.
> You might have to remove it first due to name conflicts.
>
>    sudo apt-get remove -y docker
>    sudo apt-get install -y docker.io
>
> ======================================================================
> PROBLEM: SOCKET ERROR MESSAGE
>
> You might get an error message like:
>
>    docker pull daly/axiom
>    2014/12/22 11:19:38 Get http:///var/run/docker.sock/v1.15/info: dial unix
>
> which means that the docker daemon is not running. To fix this type
>
>    sudo systemctl start docker
>    sudo systemctl enable docker
>
> The first command starts the docker daemon. The second command
> enables docker to run when the system starts.
>
> ======================================================================
> PROBLEM: USER LEVEL PERMISSION
>
> You might need to add yourself to the docker group and reboot
>
>    sudo usermod -a -G docker (your username)
>    sudo reboot
>
> Now as a non-root user you should be able to do
>
>    docker run -i -t daly/axiom axiom
>
>
>
> Please let me know if you have any problems.
>
> Tim
>

\start
Date: Fri, 2 Jan 2015 13:47:18 -0600
From: daly@axiom-developer.org
To: Eugene Surowitz <surow@attglobal.net>
Subject: Re: [Axiom-developer] Axiom docker image

>> But do you know what levels of the OS's are required?

>I have run it the latest distributions of Fedora, Ubuntu, and Debian.
>I have also run it in a VirtualBox on MAC. VirtualBox implementations
>run on MAC and Windows. 

>See https://docs.docker.com/installation for installation on
>MAC OS X, Ubuntu, Red Hat Enterprise Linux, Oracle Linux, CentOS,
>Debian, Gentoo, Google Cloud Platorm, Rackspace Cloud, Amazon EC2,
>IBM Softlayer, Arch Linux, FrugalWare, Fedora, SUSE, CRUX Linux,
>and Microsoft Windows.

>Axiom's docker image should run on all of those although I believe
>docker requires a 64-bit image, at least in the VirtualBox images.

I just tried the Windows installation.

1) visit https://docs.docker.com/installation/windows
2) click on the DockerforWindows link
3) execute the downloaded file
4) click on Boot2Docker icon
5) type "docker pull daly/axiom"
6) type "docker run -i -t daly/axiom axiom"

and you have a running Axiom on Windows. Total time less than 5 minutes.

Tim

\start
Date: Fri, 2 Jan 2015 17:06:14 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Axiom docker image -- running hyperdoc

For the brave of heart ...

It is possible to run hyperdoc on your local X server from the docker
image. There are two issues. One is a missing package which I will add
and the other is that the docker image does not know the local IP
address. Both of these can be fixed from the command line with:

docker run -i -t daly/axiom bash -c "( apt-get install -y libxpm-dev ; export DISPLAY=192.168.1.228:0.0 ; export AXIOM=/usr/local/axiom/mnt/ubuntu ; export PATH=/usr/local/axiom/mnt/ubuntu/bin:$PATH ; exec /usr/local/axiom/mnt/ubuntu/bin/sman -clef -ht -ws /usr/local/axiom/mnt/ubuntu/bin/AXIOMsys )"

Just to be clear, the command line options are
 1) fix the missing package
      apt-get install -y libxpm-dev
 2) tell X what your IP address is (your IP will differ...)
      export DISPLAY=192.168.1.228:0.0
 3) export the AXIOM shell variable
      export AXIOM=/usr/local/axiom/mnt/ubuntu
 4) update the PATH shell variable
      export PATH=/usr/local/axiom/mnt/ubuntu/bin:$PATH
 5) execute AXIOM with Hyperdoc and Clef enabled
      exec /usr/local/axiom/mnt/ubuntu/bin/sman -clef -ht 
                 -ws /usr/local/axiom/mnt/ubuntu/bin/AXIOMsys

Graphics should also work but it needs GCC installed.
That will be fixed also.

On Windows there is an X server called Xming
   http://sourceforge.net/projects/xming
which will allow Windows users to have Hyperdoc and Graphics.

Now that I've beaten this problem into submission I'll figure out
how to pass a command-line variable to a docker container and 
automate this process. I will push a new docker image with all
of the extensions.

Tim

\start
Date: Tue, 6 Jan 2015 09:30:32 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Axiom Design Musings

A primary goal of the LP rewrite is to make it much easier to
maintain and modify Axiom.

In particular, the current LP focus is on the interpreter code.

HISTORY

Historically the interpreter was written by several people in a
mixture of lisp styles. Some of the early work was done in Maclisp.
Another layer, called Meta, was added to study language design.  A
domain-specific language called Boot was created in Meta, which had a
syntax similar in spirit to the Spad language. When the system was
ported to VMLisp a layer of macros and functions covered some
differences. As each new lisp became available an additional layer of
macros and functions were created.

Meanwhile the world had created a well-defined standard language,
Common Lisp. More macro work was done and eventually Axiom was easily
ported to about a dozen Common Lisp implementations. IBM contracted
with William Schelter to create a Common Lisp called Austin-Kyoto
Common Lisp (AKCL), now called Gnu Common Lisp (GCL) that was 
specifically optimized to run Axiom.

THE PRESENT SITUATION

The current effort aims at "strength reducing" the code. That is, to
remove all of the artifacts of the historical layering, rewriting it
into Common Lisp.

The Meta language is gone. The Boot language is gone.  Removing Meta
and Boot removed many files and reduced the Makefile complexity.  It
also improved build times considerably. In the long term the build
system will be a Common Lisp function.

What remains is lisp code with many layers of macros and functions
that still mimic older lisp versions. Work is being done to remove the
Maclisp and VMLisp idioms. These are not widely known and the manuals
for these languages are considered collectors items.

Portions of the interpreter are still in machine-generated form
waiting to be rewritten by human hand. This effort will likely consume
most of 2015.

Overall the code is converging on simplified, by-the-book Common Lisp.
Soon the only reference document needed for Axiom internals will be
the Common Lisp book. But this is just a plateau for future
improvement.

THE NEAR FUTURE

Axiom internals are still quite opaque.

Consider the global variable situation. Shared, mutable state is
now known to be a source of bugs and a barrier to understanding.

Axiom has a whole sea of global variables, the so-called dollar
variables, which hold shared state information. Mutable, shared state
makes it very difficult to maintain and modify code. It would be good
to document the state but it would be better to restructure the code
to minimize it.

Some of the dollar variables represent truly global state such as
which stream is being used for output. Other dollar variables are
"locally-global" state shared within functions such as the undo
code. The first step will be to distinguish truly global state
from locally-global state. 

A near-term approach would be to encapulate locally-global state
in defstructs and pass the structure in as an environment argument
to the function. That would remove a lot of dollar variables and
make it clear that the state is an argument to the function.

THE NEXT HORIZON

The dollar variables will be restructured "in the small" but there
is a design question about system structure "in the large". For
instance, there is an "undo" facility. One design goal would be
to make it possible to maintain and modify this functionality
without impacting the rest of the system. How can this be done?

Object-oriented programming is one possible approach. Objects can
encapsulate state making it clear which functions can and cannot
manipulate it. Lisp has at least two approaches to creating
object-like behavior, either using Let-Over-Lambdas (LOL) or the
Common Lisp Object System (CLOS). 

Functional programming is also possible. Data structures can be
reimplemented as immutable objects and procedures can be rewritten
as pure functions. A side-effect would be to make "undo" trivial.

We could also consider "lifting" the code into Spad, trying to
make Axiom mostly self-hosting. This may be a bridge-too-far though
as Spad has abstract algebra, a good mathematical scaffold, but a
poor notion of low-level implementation concepts. Additionally,
making Spad self-hosting brings back the need-Axiom-to-make-Axiom
circle that was fixed in 2001.

It is not clear what the most understandable alternative might be.
Whatever is it, the focus is on clarity. The design needs to be
easy to explain, maintain, and modify.

Tim

\start
Date: Tue, 6 Jan 2015 19:32:25 -0600
From: daly@axiom-developer.org
To: panAxiom@first.in-berlin.de
Subject: Re: [Axiom-developer] Aldor and Axiom workshop

>I found this page:
>
>   Aldor & Axiom Workshop 2008
>      
>http://compgroups.net/comp.lang.lisp/-ann-aldor-axiom-openaxiom-fricas-workshop-200/705328
>
>
>Will there be another event like this in the near future?

I was unaware this took place.

Tim

\start
Date: Wed, 7 Jan 2015 04:59:02 -0800
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: daly@axiom-developer.org
Subject: Re: [Axiom-developer] [Axiom-math] Aldor and Axiom workshop
Cc: axiom-dev <axiom-developer@nongnu.org>, panAxiom@first.in-berlin.de,
	axiom-math@nongnu.org

On Tue, Jan 6, 2015 at 5:32 PM, <daly@axiom-developer.org> wrote:

> >I found this page:
> >
> >   Aldor & Axiom Workshop 2008
> >
> >
> http://compgroups.net/comp.lang.lisp/-ann-aldor-axiom-openaxiom-fricas-workshop-200/705328
> >
> >
> >Will there be another event like this in the near future?
>
> I was unaware this took place.
>
> Tim
>

My recollection was that it was widely advertised to the larger AXIOM
community -- all flavors included.

-- Gaby

\start
Date: Wed, 07 Jan 2015 10:56:00 +0000
From: Martin Baker <ax87438@martinb.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Axiom Design Musings

Tim,

Thank you for the interesting post about Axiom design and use of lisp.

I wondered if you ever considered Clojure?

I have very little practical experience of Lisp, so please forgive my 
ignorance but, I get the impression that Clojure has better type checking?

Also use of JVM means it has access to extensive Libraries (powerful 
graphics and so on). Also concurrency so no need for 'C' code.

I am also curios why SPAD has "poor notion of low-level implementation 
concepts". From what I can see SPAD appears to implement code as an 
algorithm like other languages and (for instance) structures tend to be 
built up from lists rather than sets. I'm not advocating SPAD as a 
system language I'm just curious about what the real issue is.

Martin

\start
Date: Wed, 7 Jan 2015 05:17:59 -0800
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Bill Page <bill.page@newsynthesis.org>
Subject: Re: [Axiom-developer] [fricas-devel] documentation standards

On Mon, Dec 29, 2014 at 1:05 PM, Bill Page <bill.page@newsynthesis.org>
wrote:

[...]


> It is remarkable to me how our perceptions differ! When did you last
> look at OpenAxiom? I think the effort in OpenAxiom has been mostly of
> an internal nature: extensions to the SPAD language, improvements in
> coding style and preparations for re-basing the system on LLVM rather
> than Lisp.  Last summer FriCAS had a Google Summer-Of-Code funded
> project with similar goals.


I missed the announcement of that SoC project.  What happened to it?

As for the larger question as to whether OpenAxiom is dead, not it is not.
Most of my slow activities in the last couple of years is largely
attributable to my taking on new roles (changing main job and employer),
relocating entire family from Texas to the Pacific Northwest, and finding
new home.  That, on top of daytime job, well... It is easily summarized in
in two sentences but it is no small potato :-)

Happy New Year!

-- Gaby

\start
Date: Wed, 7 Jan 2015 08:54:39 -0600
From: daly@axiom-developer.org
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
Subject: [Axiom-developer] (no subject)

>My recollection was that it was widely advertised to the larger AXIOM
>community -- all flavors included.

Indeed I see there are entries in the Axiom email archives.
The first mention appears to be under the topic of moving 
the Wiki so it was a fairly chaotic time in my life.

My memory is not nearly as good as it never was :-)

Axiom no longer supports Aldor. 
All of the support code has been removed.

Tim

\start
Date: Wed, 7 Jan 2015 21:23:04 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Projects: January 7th update

Goal: Literate Programming

  Interpreter (bookvol5). Add chapters for frames, history, undo,
  and exposure groups. 

Goal: Continuous Integration

  Failing regression tests were fixed. 
  Failing tests were added to the bug list

Goal: Port Axiom to Windows/MAC/Linux

  Create a docker image

Goal: Axiom Website

  Move the videos links up

Goal: Axiom Misc. Cleanup

  Remove CCL, Meta, and tla tar.gzips from the zips directory.

\start
Date: Wed, 28 Jan 2015 06:10:17 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Axiom Design musings

Axiom is at the beginning of another major transition.

There have been several major transitions in Axiom which were the
result of design choices.

There was a transition from the NAG version to the open source version.  
The NAG version required a running Axiom to build Axiom. The open 
source version had to bootstrap from nothing. This involved design 
choices about building from scratch.  These choices were encoded in 
the makefile structure.

There was a transition from CCL to GCL. The CCL version was a highly
portable, byte coded Common Lisp subset. Portions of Axiom were hard
coded for performance. GCL was a full Common Lisp. At IBM Axiom was
rewritten to be portable among about a dozen Common Lisps so it could
be run on many platforms. GCL was hand-optimized internally to support
Axiom with the best performance. Porting from CCL back to Common Lisp
was a design choice to make the Axiom code conform to the Common Lisp
standard. This involved a large, low-level rewrite. The choices were
defined by the standard.

There was a transition from raw code files to pamphlet files. Raw code
files did not provide a suitable medium for communicating ideas from
one developer to another, leading to a loss of information in each
generation of developers. Pamphlet files restructured the system so
that raw code was contained in a document format which could provide
space for explaining (not "documenting") code.  This design choice
swept through all the files, resulting in individual, tiny pamphlet
files.

There was a transition from BOOT code to Common Lisp code.  BOOT was
ad-hoc and spoken by a few people at most. Common Lisp is a standard
and spoken by a large community. This design choice eliminated all
BOOT code by compiling it to Common Lisp. The resulting compiler
output had to be hand rewritten to human format. This transition is
still ongoing and is expected to be completed by the end of this year.

There was a transition to test automation.  The problem was that
testing was ad-hoc. This made it difficult to say what was different
about any instance. The regression test files were automated.  A
regression file format was designed and implemented. In addition, a
large scale Computer Algebra Test Suite (CATS) was built to create
test cases from published outside sources. CATS work is ongoing in
collaboration with Albert Rich, and Series and Products work using
Gradshteyn and Ryzhik.

There was a transition in release cycles. Release cycles were set on a
two-month cycle. A new transition to continuous integration and
continuous deployment is taking place (Jenkins and Docker).  The test
automation work supports this effort, making it less likely that bad
builds will reach the outside world.

There was a transition from Makefiles to Common Lisp build
mechanisms. Makefiles are unable to take advantage of information
embedded in the system. The Common Lisp build mechanism has global
information it can exploit, eliminating the need to keep track of
modifications, such as adding or reorganizing algebra code. This will
eliminate makefiles. This is ongoing and is expected to complete by
next year.

There was a transition from tree-structures of tiny files to
books. Tiny files are a historical artifact of tiny 1970s machine
memories. They splatter source code over a directory tree, depending
on directory and filenames for minimal semantics.  Books provide
higher level organization, allowing a flow of organization and
explanation of the ideas along with the associated code implementing
those ideas. This transition is still ongoing and is expected to last
as long as people find ideas worth explaining. A primary Axiom goal is
to provide a teaching platform for future computational mathematicians. 
It is important to communicate ideas and the book form supports this.

There was a transition to video. Written documents cannot easily
capture "process-like" actions, such as system maintenance and
debugging activities. They are also not good for showing the power
and ease of the user interface. A new set of video documentation
is being created and posted to the website.

There was a transition from C code to a browser. The C code depends on
X11 which is stable but fading. The universal front end of systems
seems to be moving to browsers. The Axiom read-evaluate-print loop has
been moved to the browser. The hyperdoc structure is partially
moved. The graphics code still needs to be rewritten into canvas
form. The Crystal structure needs definition. This work is ongoing.

There was a transition from symbolic to symbolic/numeric support.
Historically Axiom had support for the NAG libraries. This did
not survive the transition to open source. Work is ongoing to
rebuild this and other numeric capabilities as well as work on
support for numerical analysis to allow for facilities such as
explicit error bounding. (book volume 10.5)

There was a transition to literate support in the interpreter
so code and test cases could be automatically tangled from the
books and pamphlets. This support was used to improve the
automated testing (the tangle and regress commands).

There was a transition to full and automated cross referencing,
automated access to published literature, and bibliographic references
underlying the algebra. A repository of bibliographic papers was
created.  An effort is underway to build a geneology tree of the
algorithms in order to show the current Axiom state and suggest work
to bring Axiom up to the latest published state of the art. Work is
ongoing.


Now there is a new transition...

The majority of the code in the system now lives in books.  The first
steps toward organizing these code piles has begun.  The design goal
and the challenge is to make it possible to navigate the system in
some coherent way. The "mental model" is similar to what is found in
the preface of books explaining which chapters can be read and how
they depend on each other. Thought needs to be given to good, clear,
and well-supported navigation pathways and tools based on intent
(Crystal). Ideas need to be presented in hyperlinked graphics.

The current focus is on the Interpreter (book volume 5). There are
many things that need to be done to make it into a useful, readable,
and pleasant document. It represents a real design challenge.

Looking from the "top-down" there should be a seamless transition
from the Jenks book (book volume 0) and the Daly book (book volume
1), which are written at the user level, to the high level structure
of the interpreter. This can be thought of as a flat (user) surface
with underlying layers of support (e.g. the history mechanism)

====================( User Interface )============
    ====      ====     ====     ====    ==== ...
    ====      ====     ====     ====    ====
 (history)   (undo)  (reading) (eval)  (print)

Things like eval and printing are supported by the algebra

====================( User Interface )============
    ====      ====     ====     ====    ==== ...
    ====      ====     ====     ====    ====
 (history)   (undo)  (reading) (eval)  (print)
                                 (algebra)

and that is supported by the databases

====================( User Interface )============
    ====      ====     ====     ====    ==== ...
    ====      ====     ====     ====    ====
 (history)   (undo)  (reading) (eval)  (print)
                                 (algebra)
                                (databases)

But life is so much more complex than that. For instance, some of the
algebra is hard coded in Lisp, such as the coercions from one domain
to another. There is also algebra performance optimizing code written
in Lisp.

====================( User Interface )============
    ====      ====     ====     ====    ====
    ====      ====     ====     ====    ====
 (history)   (undo)  (reading) (eval)  (print)
                                |- (algebra)
                                +-- (databases)
                                |
                              (coercion, performance)

There is shared code used by both the interpreter and the compiler
(book volume 9).

====================( User Interface )============
    ====      ====  |   ====     ====    ====
    ====      ====  |   ====     ====    ====
 (history)   (undo) | (reading) (eval)  (print)
                    |            |- (algebra)
                    |           +-- (databases)
               (compiler)       |
                              (coercion, performance)

There is code to support "external code", notably hyperdoc,
graphics, and the browser

====================( User Interface )================
    ====      ====  |   ====     ====    ====     ====
    ====      ====  |   ====     ====    ====   (socket)
 (history)   (undo) | (reading) (eval)  (print)    +-> hyperdoc
                    |            |- (algebra)      +-> graphics
                    |           +-- (databases)    +-> browser
               (compiler)       |
                              (coercion, performance)

>From a "bottom-up" perspective there is code to support multiple
Common Lisps, infinite precision arithmetic, sockets, performance
macros, multiple semantics (MACLISP vs VMLisp vs Common Lisp). There
are subsystems such as the Burge parser and the Charybdis mathematics
printer which need to be packaged into coherent wholes, organized,
and explained. There is legacy code to purge such as the Saturn
and Aldor interfaces.

Since Axiom is a "typed system" there needs to be an effort to
recognize, name, classify, categorize, and explain the types of the
data structures in the interpreter. Work has started to provide every
Lisp function a "signature line" using these types, just like the
algebra above it.  The lisp signatures need to compile to optimization
declarations for the Lisp compiler which will improve Axiom
performance.  Code needs to be rewritten to be more functional rather
than modifying structured arguments when it makes sense. This will
support the future "proof system" effort.

All of this needs to be thought about and organized in ways that will
support understanding. Developers need to understand the printing
mechanism. Mathematicians need to understand the coercion interpreter
system. Users need to understand the undo mechanism.

This latest transition is slowly taking shape. It will involve
massive writing efforts and massive code refactoring.  It will involve
building things that exist nowhere such as a mechanism to hyperlink
and cross-reference everything to everything (Crystal).

There are future transitions "in plan", such as developing a proof
mechanism (book volume 13). There are tools to provide proofs at
various interfaces (e.g. math to spad (COX), spad to lisp (ACL2), lisp
to C (LLVM tool), C to machine (FX)).

The current "gold standard" for literate software is the Pharr and
Humphrey's book "Physically Based Rendering" which I highly recommend.
If the algebra was written in that style it would make it easier to
understand the algorithms and the underlying mathematics.  But we must
raise our eyes past that level as Axiom is well over a million lines
of code and multiple books.

That "30 Year Horizon" looks mighty close.

Stay tuned....

Tim

\start
Date: Wed, 28 Jan 2015 08:01:28 -0500
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Axiom Design musings

On 01/28/2015 07:10 AM, daly@axiom-developer.org wrote:
> Axiom is at the beginning of another major transition.
>
> There have been several major transitions in Axiom which were the
> result of design choices.
> m)
>
> ====================( User Interface )============
>      ====      ====     ====     ====    ==== ...
>      ====      ====     ====     ====    ====
>   (history)   (undo)  (reading) (eval)  (print)
>
> Things like eval and printing are supported by the algebra
>
> ====================( User Interface )============
>      ====      ====     ====     ====    ==== ...
>      ====      ====     ====     ====    ====
>   (history)   (undo)  (reading) (eval)  (print)
>                                   (algebra)
>
> and that is supported by the databases
>
> ====================( User Interface )============
>      ====      ====     ====     ====    ==== ...
>      ====      ====     ====     ====    ====
>   (history)   (undo)  (reading) (eval)  (print)
>                                   (algebra)
>                                  (databases)
>
> But life is so much more complex than that. For instance, some of the
> algebra is hard coded in Lisp, such as the coercions from one domain
> to another. There is also algebra performance optimizing code written
> in Lisp.
>
> ====================( User Interface )============
>      ====      ====     ====     ====    ====
>      ====      ====     ====     ====    ====
>   (history)   (undo)  (reading) (eval)  (print)
>                                  |- (algebra)
>                                  +-- (databases)
>                                  |
>                                (coercion, performance)
>
> There is shared code used by both the interpreter and the compiler
> (book volume 9).
>
> ====================( User Interface )============
>      ====      ====  |   ====     ====    ====
>      ====      ====  |   ====     ====    ====
>   (history)   (undo) | (reading) (eval)  (print)
>                      |            |- (algebra)
>                      |           +-- (databases)
>                 (compiler)       |
>                                (coercion, performance)
>
> There is code to support "external code", notably hyperdoc,
> graphics, and the browser
>
> ====================( User Interface )================
>      ====      ====  |   ====     ====    ====     ====
>      ====      ====  |   ====     ====    ====   (socket)
>   (history)   (undo) | (reading) (eval)  (print)    +-> hyperdoc
>                      |            |- (algebra)      +-> graphics
>                      |           +-- (databases)    +-> browser
>                 (compiler)       |
>                                (coercion, performance)
>
>  From a "bottom-up" perspective there is code to support multiple
> Common Lisps, infinite precision arithmetic, sockets, performance
> macros, multiple semantics (MACLISP vs VMLisp vs Common Lisp). There
> are subsystems such as the Burge parser and the Charybdis mathematics
> printer which need to be packaged into coherent wholes, organized,
> and explained. There is legacy code to purge such as the Saturn
> and Aldor interfaces.
>
> Since Axiom is a "typed system" there needs to be an effort to
> recognize, name, classify, categorize, and explain the types of the
> data structures in the interpreter. Work has started to provide every
> Lisp function a "signature line" using these types, just like the
> algebra above it.  The lisp signatures need to compile to optimization
> declarations for the Lisp compiler which will improve Axiom
> performance.  Code needs to be rewritten to be more functional rather
> than modifying structured arguments when it makes sense. This will
> support the future "proof system" effort.
>
> All of this needs to be thought about and organized in ways that will
> support understanding. Developers need to understand the printing
> mechanism. Mathematicians need to understand the coercion interpreter
> system. Users need to understand the undo mechanism.
>
> This latest transition is slowly taking shape. It will involve
> massive writing efforts and massive code refactoring.  It will involve
> building things that exist nowhere such as a mechanism to hyperlink
> and cross-reference everything to everything (Crystal).
>
> There are future transitions "in plan", such as developing a proof
> mechanism (book volume 13). There are tools to provide proofs at
> various interfaces (e.g. math to spad (COX), spad to lisp (ACL2), lisp
> to C (LLVM tool), C to machine (FX)).
>
> The current "gold standard" for literate software is the Pharr and
> Humphrey's book "Physically Based Rendering" which I highly recommend.
> If the algebra was written in that style it would make it easier to
> understand the algorithms and the underlying mathematics.  But we must
> raise our eyes past that level as Axiom is well over a million lines
> of code and multiple books.
>
> That "30 Year Horizon" looks mighty close.
>
> Stay tuned....
>
> Tim
I think the goal is certainly correct and in and of itself a 
contribution to any CAS,

An eccentric recommendation: I think the categories/classifications 
should have a target structure of Database access.  Without a structured 
organization of the organization (a meta-organization if you will)  the 
result will still be difficult to navigate.
A Lewis Carrol, Charles Lutwidge Dodgson, caution on maps

Thats another thing weve learned from your Nation, said Mein Herr, 
map-making. But weve carried it much further than you. What do you 
consider the largest map that would be really useful?

About six inches to the mile.

Only six inches! exclaimed Mein Herr. We very soon got to six yards 
to the mile. Then we tried a hundred yards to the mile. And then came 
the grandest idea of all! We actually made a map of the country, on the 
scale of a mile to the mile!

Have you used it much? I enquired.

It has never been spread out, yet, said Mein Herr: the farmers 
objected: they said it would cover the whole country, and shut out the 
sunlight! So we now use the country itself, as its own map, and I assure 
you it does nearly as well.


-- 
  Two views on life:
life is an art not to be learned by observation.
George Santayana:Interpretations of Poetry and Religion
It's kinda nice to participate in your life
Raymond Rogers


--------------020104030100080107050203
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 01/28/2015 07:10 AM,
      <a class="moz-txt-link-abbreviated" href="mailto:daly@axiom-developer.org">daly@axiom-developer.org</a> wrote:<br>
    </div>
    <blockquote
      cite="mid:201501281210.t0SCAHtL020951@axiom-developer.org"
      type="cite">
      <pre wrap="">Axiom is at the beginning of another major transition.

There have been several major transitions in Axiom which were the
result of design choices.
m)

====================( User Interface )============
    ====      ====     ====     ====    ==== ...
    ====      ====     ====     ====    ====
 (history)   (undo)  (reading) (eval)  (print)

Things like eval and printing are supported by the algebra

====================( User Interface )============
    ====      ====     ====     ====    ==== ...
    ====      ====     ====     ====    ====
 (history)   (undo)  (reading) (eval)  (print)
                                 (algebra)

and that is supported by the databases

====================( User Interface )============
    ====      ====     ====     ====    ==== ...
    ====      ====     ====     ====    ====
 (history)   (undo)  (reading) (eval)  (print)
                                 (algebra)
                                (databases)

But life is so much more complex than that. For instance, some of the
algebra is hard coded in Lisp, such as the coercions from one domain
to another. There is also algebra performance optimizing code written
in Lisp.

====================( User Interface )============
    ====      ====     ====     ====    ====
    ====      ====     ====     ====    ====
 (history)   (undo)  (reading) (eval)  (print)
                                |- (algebra)
                                +-- (databases)
                                |
                              (coercion, performance)

There is shared code used by both the interpreter and the compiler
(book volume 9).

====================( User Interface )============
    ====      ====  |   ====     ====    ====
    ====      ====  |   ====     ====    ====
 (history)   (undo) | (reading) (eval)  (print)
                    |            |- (algebra)
                    |           +-- (databases)
               (compiler)       |
                              (coercion, performance)

There is code to support "external code", notably hyperdoc,
graphics, and the browser

====================( User Interface )================
    ====      ====  |   ====     ====    ====     ====
    ====      ====  |   ====     ====    ====   (socket)
 (history)   (undo) | (reading) (eval)  (print)    +-&gt; hyperdoc
                    |            |- (algebra)      +-&gt; graphics
                    |           +-- (databases)    +-&gt; browser
               (compiler)       |
                              (coercion, performance)

>From a "bottom-up" perspective there is code to support multiple
Common Lisps, infinite precision arithmetic, sockets, performance
macros, multiple semantics (MACLISP vs VMLisp vs Common Lisp). There
are subsystems such as the Burge parser and the Charybdis mathematics
printer which need to be packaged into coherent wholes, organized,
and explained. There is legacy code to purge such as the Saturn
and Aldor interfaces.

Since Axiom is a "typed system" there needs to be an effort to
recognize, name, classify, categorize, and explain the types of the
data structures in the interpreter. Work has started to provide every
Lisp function a "signature line" using these types, just like the
algebra above it.  The lisp signatures need to compile to optimization
declarations for the Lisp compiler which will improve Axiom
performance.  Code needs to be rewritten to be more functional rather
than modifying structured arguments when it makes sense. This will
support the future "proof system" effort.

All of this needs to be thought about and organized in ways that will
support understanding. Developers need to understand the printing
mechanism. Mathematicians need to understand the coercion interpreter
system. Users need to understand the undo mechanism.

This latest transition is slowly taking shape. It will involve
massive writing efforts and massive code refactoring.  It will involve
building things that exist nowhere such as a mechanism to hyperlink
and cross-reference everything to everything (Crystal).

There are future transitions "in plan", such as developing a proof
mechanism (book volume 13). There are tools to provide proofs at
various interfaces (e.g. math to spad (COX), spad to lisp (ACL2), lisp
to C (LLVM tool), C to machine (FX)).

The current "gold standard" for literate software is the Pharr and
Humphrey's book "Physically Based Rendering" which I highly recommend.
If the algebra was written in that style it would make it easier to
understand the algorithms and the underlying mathematics.  But we must
raise our eyes past that level as Axiom is well over a million lines
of code and multiple books.

That "30 Year Horizon" looks mighty close.

Stay tuned....

Tim
</pre>
    </blockquote>
    I think the goal is certainly correct and in and of itself a
    contribution to any CAS,<br>
    <br>
    An eccentric recommendation: I think the categories/classifications
    should have a target structure of Database access. Without a
    structured organization of the organization (a meta-organization if
    you will) the result will still be difficult to navigate.<br>
    A Lewis Carrol, <span style="color: rgb(34, 34, 34); font-family:
      arial, sans-serif; font-size: 13px; font-style: normal;
      font-variant: normal; font-weight: normal; letter-spacing: normal;
      line-height: 16.1200008392334px; orphans: auto; text-align: left;
      text-indent: 0px; text-transform: none; white-space: normal;
      widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
      display: inline !important; float: none; background-color:
      rgb(255, 255, 255);">Charles Lutwidge Dodgson,</span> caution on
    maps<br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=windows-1252">
    Thats another thing weve learned from your Nation, said Mein
    Herr, map-making. But weve carried it much further than you. What
    do you consider the largest map that would be really useful?<br>
    <br>
    About six inches to the mile.<br>
    <br>
    Only six inches! exclaimed Mein Herr. We very soon got to six
    yards to the mile. Then we tried a hundred yards to the mile. And
    then came the grandest idea of all! We actually made a map of the
    country, on the scale of a mile to the mile!<br>
    <br>
    Have you used it much? I enquired.<br>
    <br>
    It has never been spread out, yet, said Mein Herr: the farmers
    objected: they said it would cover the whole country, and shut out
    the sunlight! So we now use the country itself, as its own map, and
    I assure you it does nearly as well.<br>
    <br>
    <blockquote
      cite="mid:201501281210.t0SCAHtL020951@axiom-developer.org"
      type="cite">
      <pre wrap="">
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
 Two views on life:
life is an art not to be learned by observation.
George Santayana:Interpretations of Poetry and Religion
It's kinda nice to participate in your life
Raymond Rogers 
</pre>
  </body>
</html>

--------------020104030100080107050203--

\start
Date: Fri, 30 Jan 2015 04:36:56 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Proving Axiom correct

Leslie Lamport has an interesting talk on hierarchical proofs.

If you have any interest in proving Spad programs correct then this
is an interesting talk[1]

I've been looking at various tools to prove Spad algorithms at all
layers (math->spad, spad->lisp, lisp->C, C->machine) In particular,
I'm focusing on the GCD algorithm in EUCDOM as the proof of the
algorithm is widely known. The first step of this kind of proof is to
do the (math->spad) phase.

Lamport has a system called TLA which allows hierarchical structuring
of proofs in math. COQ does machine-checked proofs, especially those
with types. Since Axiom is hierarchical it seems that TLA can
structure the proof into sub-proofs (e.g.  showing that unitCanonical
is correct) and COQ can be used to focus on each layer.

In any case, it is time to try to take baby-steps toward putting Axiom
on a firm mathematical foundation.

If you know of any other interesting lectures please let me know.

Tim

[1] http://hits.mediasite.com/mediasite/Play/29d825439b3c49f088d35555426fbdf81d





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