[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Patches for book--main--1
|
From: |
Kai Kaminski |
|
Subject: |
[Axiom-developer] Patches for book--main--1 |
|
Date: |
Fri, 13 Jan 2006 14:57:24 +0100 |
|
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (darwin) |
Hi everyone!
Over the christmas holidays I added a few things to the developer
documentation (bookvol4). Mostly about the HyperDoc. The new table of
contents looks like this (stars mark the sections that I added/modified):
{1}Getting Axiom}
{1.1}The savannah website
{1.2}The axiom-developer website
{2}Building Axiom
{2.1}Makefiles
{2.2}Noweb
{2.3}Directory Structure(*)
I added a list of almost all directories not including those which
are created at build time.
{2.4}Packages in zip
{2.5}Lisp
{2.6}Boot Compiler
{2.7}Interpreter
{2.8}Share
{2.9}Algebra
{2.10}Etc
{2.11}Clef
{2.12}Doc
{2.13}Graph
{2.14}Sman
{2.15}Input
{3}Modifying Axiom
{4}Becoming a Developer
{4.1}Using Arch(*)
{4.1.1}Other branches(*)
A list of all existing branches.
{4.1.2}Committing changes(*)
{4.2}Contributing Patches(*)
{4.3}Coding Guidelines(*)
{4.3.1}General(*)
{4.3.2}Lisp(*)
{4.4}Workflow(*)
A description of (a part of) Tim's workflow.
{5}Architecture and Implementation(*)
{5.1}Processes(*)
{5.2}Languages(*)
{5.2.1}BOOT(*)
{5.2.2}Lisp(*)
{5.2.3}SPAD(*)
{5.2.4}Aldor(*)
{5.2.5}HyperTex(*)
{5.2.6}C(*)
{5.2.7}Other languages(*)
{5.3}The BOOT{} Language(*)
{5.4}The HyperDoc(*)
{5.5}The Markup Language for HyperDoc Pages(*)
{5.5.1}The Patch/Paste Mechanism(*)
{5.5.2}Databases(*)
The HyperDoc Database Format(*)
{6}THINGS TO BE INTEGRATED(*)
Kai
--- book--main--1--patch-6/bookvol4.pamphlet 2006-01-13 14:21:47.000000000
+0100
+++ Projekte/axiom/book--main--1--patch-6/bookvol4.pamphlet 2006-01-13
13:17:20.000000000 +0100
@@ -103,6 +103,22 @@
\newcommand\UpBitmap{{\setlength{\unitlength}{0.01in}\begin{picture}(50,16)(0,0)\special{psfile=ps/up.ps}\end{picture}}}
\newcommand{\tpd}[5]{{\setlength{\unitlength}{0.01in}\begin{picture}(#1,#2)(#3,#4)\special{psfile=#5}\end{picture}}}
+\newcommand{\hyperdoc}{HyperDoc}
+\newcommand{\spad}{SPAD}
+\newcommand{\aldor}{Aldor}
+\newcommand{\axiom}{Axiom}
+\newcommand{\ansicl}{ANSI Common Lisp}
+\newcommand{\boot}{BOOT}
+\newcommand{\hypertex}{HyperTex}
+\newcommand{\foam}{FOAM}
+
+\newcommand{\manual}{user manual}
+\newcommand{\hypercmd}[1]{{\tt \\#1}}
+\newcommand{\axiomprog}[1]{{\tt #1}}
+
+\newcommand{\bs}{\textbackslash} % Should produce a backslash in an itemize
+ % environment
+
\begin{document}
\begin{titlepage}
\center{\includegraphics{ps/axiomFront.ps}}
@@ -230,2414 +246,3493 @@
\section{Makefiles}
\section{Noweb}
\section{Directory Structure}
-\section{Packages in zip}
-\section{Lisp}
-\section{Boot Compiler}
-\section{Interpreter}
-\section{Share}
-\section{Algebra}
-\section{Etc}
-\section{Clef}
-\section{Doc}
-\section{Graph}
-\section{Sman}
-\section{Input}
-\chapter{Modifying Axiom}
-\chapter{Becoming a Developer}
-\section{Using Arch}
-\chapter{THINGS TO BE INTEGRATED}
-\section{email 2}
-\begin{verbatim}
-There is something called the "add-chain formed by domain
-extensions" which is described in the Glossary of the Axiom
-book:
+\begin{itemize}
+\item {\tt \$AXIOM/license}
- "add-chain
+ License information.
- a hierarchy formed by domain extensions. If domain A extends
- domain B and domain B extends domain C, then A has add-chain
- B-C."
+\item {\tt \$AXIOM/lsp}
-and
+ Contains a makefile for building GNU Common Lisp. The build process
+ itself happens in this directory, too.
- "domain extension
+\item {\tt \$AXIOM/src}
- a domain constructor A is said to extend a domain constructor B
- if A's definition has the form A == Badd.... This intuitively
- means "functions not defined by A are assumed to come from B."
- Successive domain extensions form add-chains affecting the
- search order for functions not implemented directly by the
- domain during dynamic lookup.
+ Contains all Axiom source code.
- "dynamic lookup
+\item {\tt \$AXIOM/src/algebra}
- In Axiom, a domain may or may not explicitly provide function
- definitions for all its exported operations. These definitions
- may instead come from domains in the add-chain or from default
- packages. When a function call is made for an operation in the
- domain, up to five steps are carried out.
- 1. If the domain itself implements a function for the operation,
- that function is returned.
- 2. Each of the domains in the add-chain are searched; if one
- of these domains implements the function, that function is
- returned.
- 3. Each of the default packages for the domain are searched in
- order of the lineage. If any of the default packages implements
- the function, the first one found is returned.
- 4. Each of the default packages for each of the domains in the
- add-chain are searched in the order of their lineage. If any
- of the default packages implements the function, the first
- one found is returned.
- 5. If all of the above steps fail, an error message is reported.
+ The mathematical libraries written in \spad.
----------
+\item {\tt \$AXIOM/src/booklets}
-\end{verbatim}
-\section{email 2}
-\begin{verbatim}
->
-> > The list of prerequisites for running axiom is huge, and
-> > getting worse it seems!
-> ...
-> > So in the interest of having something people can download
-> > that is functional with a minimum of effort, I think axiom
-> > (and any help system or hyperdoc) should be decoupled from
-> > zope and zwiki. A download (think windoze users here) which
-> > included zope, zwiki, latex, ghostscript, python, PIL, gcl,
-> > gcc, *and* axiom, is too much, methinks.
->
-> Heh - even I agree there. Perhaps it would be best to
-> acknowledge the reality that if one wants to take advantage
-> of all the vast possibilities of open source software, that's
-> going to be at odds with having the full power of the system
-> available on all platforms, particularly Windows, as a single
-> package. Surely power users who are willing and able to use
-> the full web-like setup, instead of just a TeXmacs or Mathematica
-> like document interface, would be willing to set it up or at
-> the very least boot a live Linux CD loaded with the full set
-> of Axiom tools and dependencies.
->
+ Articles on specific areas of Axiom.
-Personally, although I have tried knoppix and some variants on
-several occasions I have always been a little disappointed
-and frustrated. The problem is that I live in linux about 1/2
-the time and windows the other 1/2 and when I boot one of these
-"live" things I feel like I am in neither. It's fun to play for
-an hour or so but then it goes in the desk draw with all the
-other things that once fascinated me but I haven't looked at
-for so long that they are now collecting dust. So I am quite
-sceptical about the utility of a "live" Axiom/Doyen CD except
-as a kind of conference "promotional gimmick".
+\item {\tt \$AXIOM/src/boot}
-Let's put the list in the following order and fill it in a
-few more:
+ The BOOT compiler.
- gcc
- / | \
- gcl latex python
- / | | \
- / noweb | zope
- / / | | /
- axiom ghostscript PIL zwiki
- \ \ | /
- \ LatexWiki
- \ /
- MathAction
+\item {\tt \$AXIOM/src/clef}
-Add your favourite text editor and browser and set it all up
-in Linux/Unix or Windows.
+ Axiom's readline equivalent.
-There. Now that doesn't seem so large and complex does it?
-(: At least not if you compare it to the list of capabilities
-that this remarkable combination of entirely open source
-software provides... :) I am quite sure that this would all
-easily fit on one-side of a Cdrom, including documentation.
-And of course we can add as many more optional add-on packages
-as we want, such as Reduce, Aldor, Maxima, ... eventually all
-integrated with a common web interface.
+\item {\tt \$AXIOM/src/doc}
-What this gives you a fully web-integrated, collaborative
-mathematical research and development, hyper-linked publishing
-environment right on your desktop, or even in your pocket (I run
-almost all of this on a Zaurus 5600). This is all easily doable
-right now for free. I would have given my left arm for something
-like this back when I was a student!
+ Additional developer documentation.
+ % TODO kai: Should this be reorganized and integrated with this
+ % document?)
-\end{verbatim}
-\section{email 4}
-\begin{verbatim}
-> > Next we see the transition to compiling the non-BOOTSTRAP algebra.
-> > This is done in the interpsys image. It is also done in an image
-> > that has access to only the BOOTSTRAP algebra code. Thus the
-> > new compiler might not have all of the algebra-defined replacements
-> > available at compile time. Notice the autoload files that contain
-> > the optimizations.
-> >
->
-> What do you mean by "algebra-defined replacements". Where are
-> these replacements defined? How are they different than the
-> "optimizations" contained in the autoload files?
+\item {\tt \$AXIOM/src/doc/french}
-The BOOTSTRAP files contain lsp and spad code. The build steps
-for the initial BOOTSTRAP layer use "depsys" to compile the lisp
-code. So, in this case, we see VECTOR.lsp being compiled in the
-depsys image. VECTOR.lsp is the last algebra file that contains
-BOOTSTRAP code. So in this phase we see:
+ Additional documentation in French.
+ % TODO kai: This seems to contain non-developer documentation as
+ % well, which should probably go somewhere else.
-VECTOR.lsp (BOOTSTRAP) -> VECTOR.o
+\item {\tt \$AXIOM/src/doc/msgs}
-Once we leave the phase (shown in the printout) we start using
-an "interpsys" image to compile spad code. Much later in the console
-VECTOR.spad will be compiled and replaces the lisp. However the
-"interpsys" environment in VECTOR.spad differs significantly from
-the "depsys" environment that compiles VECTOR.lsp BOOSTRAP code.
-So we see
+\item {\tt \$AXIOM/src/doc/ps}
-VECTOR.spad + SINT.NRLIB -> VECTOR.lsp -> VECTOR.o (replaced previous version)
+\item {\tt \$AXIOM/src/etc}
-Suppose VECTOR.spad used something from SINT.spad. When the
-VECTOR.lsp BOOTSTRAP file is compiled by depsys it contains
-(+ ... ...) and generates untyped and unoptimized code.
+\item {\tt \$AXIOM/src/graph}
-Later when VECTOR.spad is compiled and SINT.o is available
-then the spad compiler will use the optimization information
-to generate (QSADD1 ... ...)
+ The graph viewer.
-> What do you mean by "expose". Why does this cause interpsys to
-> be re-built? That is necessary if code is going to be generated
-> based on new optimizations isn't it?
+\item {\tt \$AXIOM/src/graph/Gdraws}
-expose == make available
-Due to my lack of foresight in choosing the VECTOR.lsp BOOTSTRAP
-code I did not use the most highly optimized version. But in the
-algebra recompile of VECTOR.spad later in the build this gets
-corrected because the operations are made available (exposed) by
-previously compiled .spad code. So:
+\item {\tt \$AXIOM/src/graph/include}
-VECTOR.lsp (BOOTSTRAP) uses SINT.o
+\item {\tt \$AXIOM/src/graph/include/bitmaps}
-But the VECTOR.lsp has (+ ... ...) instead of (QSADD1 ... ...)
-because the rewriting of "+" to "QSADD1" is done by the spad
-compiler, not the GCL compiler and we are not yet in a position
-to use the spad compiler.
+\item {\tt \$AXIOM/src/graph/include/purty}
-Later when
+\item {\tt \$AXIOM/src/graph/view2D}
-VECTOR.spad -> VECTOR.lsp -> VECTOR.o (replaced previous version)
+\item {\tt \$AXIOM/src/graph/view3D}
-the spad compiler was invoked and it gets a chance to change
-"+" to "QSADD1".
+\item {\tt \$AXIOM/src/graph/viewAlone}
-Because I grabbed the wrong version of .lsp file for BOOTSTRAP
-code you are able to see this difference. The work you and steve
-are doing is to find stable versions of the .lsp files.
+\item {\tt \$AXIOM/src/graph/viewman}
-> > Since these are only optimizations the final results should not
-> > be affected.
-> >
->
-> But it could have an impact on overall performance, right?
+\item {\tt \$AXIOM/src/hyper}
-Oh, clearly. (QSADD1 ... ...) is faster than (+ ... ...)
+ The \hyperdoc{} browser.
-Furthermore, there is another optimization step we could take
-during the build but we do not (yet). When the GCL compiler
-compiles VECTOR.lsp it generates VECTOR.fn. If you look in these
-.fn files you'll find exact type information for each function call.
+\item {\tt \$AXIOM/src/hyper/bitmaps}
-VECTOR.lsp -> VECTOR.o + VECTOR.fn (unoptimized, but type generated)
+ Bitmaps for buttons and logos used by the \hyperdoc{} browser.
-If this exact type information was available at compile time then
-the GCL compiler can lay down faster code. However there is a
-bootstrap problem here also since the GCL compiler has to compile
-the code one time in order to generate the .fn file.
+\item {\tt \$AXIOM/src/hyper/pages}
-VECTOR.lsp + VECTOR.fn -> VECTOR.o (type optimized)
+ The \hyperdoc{} pages.
-So the full, proper procedure, which I have yet to do, would actually
-call the GCL compile once to generate the .fn file with exact type
-information for function calls, load the .fn file, and the recompile
-the lisp file. Since the second compile has exact type information
-the generated code will be (potentially much) shorter.
+\item {\tt \$AXIOM/src/hyper/viewports}
-For each lisp file do
-(
- VECTOR.lsp -> VECTOR.o + VECTOR.fn (unoptimized, but type generated)
- VECTOR.lsp + VECTOR.fn -> VECTOR.o (type optimized)
-)
+ Images that are used on \hyperdoc{} pages.
+\item {\tt \$AXIOM/src/include}
-> Still after reading the interp and algebra Makefiles again,
-> I do not see why interpsys is being rebuilt after I delete
-> all the *.NRLIB's and repeat the 'make'. I am still missing
-> something somewhere. Is there some "missing link" that still
-> connects the algebra/Makefile back to the inter/Makefile?
+ Header files for the C source code in Axiom.
-I have to think about this (I'm getting ready for work so I'll
-give it some "drive-time cycles") but I believe that the issue
-is related to using fresh databases. The databases are used
-during the algebra compiles to resolve algebra calls. However
-recompiling the algebra generates NRLIBs and, from these NRLIBs
-a fresh database is built thus:
+\item {\tt \$AXIOM/src/input}
-DATABASES -> NRLIBs -> FRESH DATABASES
+\item {\tt \$AXIOM/src/interp}
-This is yet a third bootstrap issue. There are more but not with
-the algebra files.
+ The \spad{} interpreter and miscellaneous code, e.g. socket code.
+\item {\tt \$AXIOM/src/lib}
+\item {\tt \$AXIOM/src/scripts}
-\end{verbatim}
-\section{email 4}
-\begin{verbatim}
-Yet one other opportunity for speed optimization is available at
-build time....
+\item {\tt \$AXIOM/src/scripts/tex}
-Remember that every lisp file generates a .fn file:
+\item {\tt \$AXIOM/src/share}
-foo.lsp -> foo.o + foo.fn
+\item {\tt \$AXIOM/src/share/algebra}
-and that a second compile with the .fn file loaded is faster:
+\item {\tt \$AXIOM/src/share/doc}
-foo.lsp + foo.fn -> faster foo.o
+\item {\tt \$AXIOM/src/share/doc/hypertex}
-However if we look at the type information in the foo.fn file
-we find that it only contains type information for functions
-defined in foo.lsp. But suppose there are two lisp files with
-functions from one using functions from the other. The sub-optimal
-sequence is:
+\item {\tt \$AXIOM/src/share/doc/hypertex/pages}
-foo.lsp -> foo.o + foo.fn
-foo.lsp + foo.fn -> faster foo.o
+\item {\tt \$AXIOM/src/share/doc/msgs}
-bar.lsp -> bar.o + bar.fn
-bar.lsp + bar.fn -> faster bar.o
+\item {\tt \$AXIOM/src/sman}
-The optimal sequence is:
+ The sman process, which starts and supervises the other \axiom{}
+ processes. See \ref{sec:Processes} for details.
-foo.lsp -> foo.o + foo.fn
-bar.lsp -> bar.o + bar.fn
+\item {\tt \$AXIOM/zips}
-foo.lsp + (foo.fn + bar.fn) -> even faster foo.o
-bar.lsp + (foo.fn + bar.fn) -> even faster bar.o
+ Software packages that are needed to build Axiom, e.g. GNU Common
+ Lisp and noweb.
+\end{itemize}
-So, really what we should do is cache ALL of the .fn files from all of
-the compiles, batch them into a big file, and the completely rebuild
-the system with the batched .fn files loaded.
-
-I've started this process but have not yet completed it.
-See the file src/boot/boot-proclaims.lisp
-
-So there is a faster Axiom coming in the future but the build
-complexity will be even greater. And Camm, I believe, is doing
-even more with type propagation which will improve things more.
+\section{Packages in zip}
+\section{Lisp}
+\section{Boot Compiler}
+\section{Interpreter}
+\section{Share}
+\section{Algebra}
+\section{Etc}
+\section{Clef}
+\section{Doc}
+\section{Graph}
+\section{Sman}
+\section{Input}
+\chapter{Modifying Axiom}
+\chapter{Becoming a Developer}
+\section{Using Arch}
+The \axiom{} project uses GNU Arch for version control, which is
+available at {\tt gnuarch.org}. There one can also find installation
+instructions, tutorials and various tools. Once Arch is installed
+follow these steps:
+\begin{itemize}
+\item Tell Arch who you are:
+\begin{verbatim}
+$ tla my-id "Firstname Lastname <address@hidden>"
+\end{verbatim}
+\item Register the \axiom{} archive:
+\begin{verbatim}
+$ tla register-archive address@hidden \
+ http://axiom-developer.org/archive/axiom
\end{verbatim}
-\section{email 5}
+
+\item Setup the default archive:
\begin{verbatim}
-How I Built Axiom on Windows
+$ tla my-default-archive address@hidden
+\end{verbatim}
- I installed a completely new MinGW/MSYS configuration from the
-'current' file list at:
+\item Check out the latest \axiom{} sources:
+\begin{verbatim}
+$ tla get axiom--main--1
+\end{verbatim}
+\end{itemize}
-http://www.mingw.org/download.shtml#hdr2
+Arch can be intimidating at first and is somewhat complicated to
+use. On {\tt gnuarch.org} there are many tools to help the user,
+e.g. xtla for Emacs.
-In the following order:
+\subsection{Other branches}
+\label{sec:OtherBranches}
-1 MinGW-3.1.0-1.exe
+There are other branches than {\tt axiom--main--1} for code that is
+not yet stable enough to be merged with the main branch. Currently
+there are the following branches:
+\begin{itemize}
+\item {\tt axiom--main--1}
- http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download
+ The main development branch. This branch will be mirrored to the CVS
+ on Savannah when it is stable and tested. Currently in step 4 of
+ development.
-2 MSYS-1.0.10.exe
+\item {\tt axiom--hyperdoc--1}
- http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download
+ This branch has been merged and is now dead.
-3 msysDTK-1.0.1.exe
+\item {\tt axiom--BSD--1}
- http://prdownloads.sf.net/mingw/msysDTK-1.0.1.exe?download
+ Port to BSD work with Mark Murray <address@hidden>. Currently in
+ step 1 of development.
-4 Then untarred the following:
-
- cd /mingw; tar xzvf /home/bpage/...
+\item {\tt axiom--MACOSX--1}
- gcc-core-3.4.2-20040916-1.tar.gz
-
- http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download
+ Port to MacOS X work with Chuck Miller <cfm at ms.unimelb.edu.au>.
+ Currently in step 1 of development.
-5 binutils-2.15.91-20040904-1.tar.gz
-
- http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download
+\item {\tt book--main--1}
-6 w32api-3.1.tar.gz
+ Axiom book work with community to clean up the book for printing.
+ Currently in step 1 of development.
+ %TODO kai: I can't see how the 'step' scheme applies to this branch.
- http://prdownloads.sf.net/mingw/w32api-3.1.tar.gz?download
+\item {\tt axiom--solaris--1}
-7 mingw-runtime-3.5.tar.gz
+ Port to Solaris work with Kostas Oikonomou <ko at research.att.com>.
+ Currently in step 1 of development.
- http://prdownloads.sf.net/mingw/mingw-runtime-3.5.tar.gz?download
+\item {\tt axiom--graphics--1}
-8 You will also need tla for windows from
+ This branch has been merged and is now dead.
- http://download.sipsolutions.de/tla-setup.exe
+\item {\tt axiom--windows--1}
-9 and the windows LaTeX packaged called MikTex
+ Port to Windows work with Mike Thomas <mike.thomas at
+ brisbane.paradigmgeo.com>. Currently in step 1 of development.
- http://www.miktex.org/setup.html
+\item {\tt axiom--language--1}
- The "Small MiKTeX" package is sufficient if your windows box is
- connected to the Internet. Or if you want you can install the
- complete system.
+ Explore Axiom language modifications work with Stephen Wilson
+ <wilsons at multiboard.com>. Currently in step 1 of development.
-10 download the axiom--windows--1 branch
+\item {\tt axiom--sbcl--1}
- See deteails instructions at ArchUsage
+ Port Axiom to Steel Bank Common Lisp work with Tim Daly Jr. <tim at
+ tenkan.org> and Nate Daly <address@hidden>. Currently in step 1
+ of development.
- 1 tla my-id "First Last <address@hidden>"
+\item {\tt zlc--main--1}
- 2 tla register-archive address@hidden
-http://axiom-developer.org/archive/axiom
+ Add a zero learning curve interface to Axiom work with Jinzhong Niu
+ <address@hidden> and Xaiowei Xu <address@hidden>. Currently
+ in step 1 of development.
- 3 tla my-default-archive address@hidden
+\item {\tt axiom--algebra--1}
- 4 tla get axiom--windows--1 axiom--windows--1
+ Prototype algebra code. Currently in step 1 of development.
- Or see ArchUsage to use 'sftp://' protocol if you intend to submit changes.
+\item {\tt axiom--GUI--1}
-11 configure and make
+ Portable GUI interface work with Kai Kaminski <kai.kaminski at
+ gmail.com>. Currently in step 1 of development.
+\end{itemize}
- cd axiom--windows--1
- ./configure -- Cut-and-paste environmnet variables to avoid typing errors
+\subsection{Committing changes}
+\label{sec:CommittingChanges}
- make -- the build takes between 3 to 6 hours on 2.4 GHz Windows XP
+If you need write access to the archive you need to follow these steps:
+\begin{itemize}
+\item Create a key by typing:
+\begin{verbatim}
+$ ssh-keygen -t dsa
+\end{verbatim}
+ This will create a file called {\tt .ssh/id\_dsa.pub}. You need to send the
+ contents of this file to Tim Daly <address@hidden> so your
+ interactions can be enabled.
+\item Next you need to register an archive:
+\begin{verbatim}
+$ tla register-archive address@hidden
sftp://address@hidden/home/arch/archive/axiom
+\end{verbatim}
+\item Then set up a default archive:
+\begin{verbatim}
+$ tla my-default-archive address@hidden
\end{verbatim}
-\section{email 6}
+
+\item In order to get the latest source for the Axiom main line type:
\begin{verbatim}
-What is MinGW?
+$ tla get axiom--main--1
+\end{verbatim}
- MinGW ("Minimalistic GNU for Windows") refers to a set of runtime headers,
-used in building a compiler system based on the GNU GCC and binutils projects.
-It compiles and links code to be run on Win32 platforms... providing C, C++
and
-Fortran compilers plus other related tools. If you see references to "mingw32"
-instead of "MinGW", they are referring to the same compiler system. The
-project's name changed from mingw32 to MinGW is to prevent the implication
that
-MinGW will only works on 32 bit systems (as 64 and higher bit machines become
-more common, MinGW will evolve to work with them). MinGW uses the Microsoft
-runtime libraries, distributed with the Windows operating system. Unlike other
-ports of GCC to Windows, the runtime libraries are not distributed using Gnu's
-General Public License (GPL). You, therefore, do not have to distribute your
-source code with your programs unless, of course, you use a GPL library in
your
-programs.
+\item Now you can change the sources. In order to commit the changes
+ you need to create a log file that summarizes the changes. You can
+ create and edit the log file using:
+\begin{verbatim}
+$ emacs `tla make-log`
+\end{verbatim}
-What is MSYS?
+\item Finally you commit the changes with:
+\begin{verbatim}
+$ tla commit
+\end{verbatim}
+\end{itemize}
- MSYS or Minimal SYStem is a POSIX and Bourne shell environment use with
-MinGW. It provides a hand picked set of tools to allow a typical configuration
-script with Bourne syntax to execute. This allows most of the GNU packages to
-create a Makefile just from executing the typical configure script which can
-then be used to build the package using the native MinGW version of GCC.
-The POSIX layer used by MSYS is a fork of the 1.3.3 version of Cygwin . Cygwin
-is a full POSIX layer and UNIX-like environment for Win32 providing both
server
-and client utilites.
+\section{Contributing Patches}
+\label{sec:ContributingPatches}
-\end{verbatim}
-\section{email 7}
+To create a patch for the file or directory {\tt foo} use the command
\begin{verbatim}
-The build sequence should be:
+diff -Naur foo foo.new >foo.patch
+\end{verbatim}
+and send {\tt foo.patch} to address@hidden and the
+axiom-developer mailing list. Please observe the Coding Guidelines
+(see \ref{sec:CodingGuidelines}).
-obj/linux/bin/lisp ... contains the socket extensions
-obj/linux/bin/bootsys ... contains the boot -> lisp compiler
- used to compile the interp/*.boot files
-obj/linux/bin/depsys ... contains macros used by axiom
- used for compiling the intermediate lisp files
-obj/linux/bin/interpsys ... contains the final image
- used to compile the algebra
-obj/linux/bin/AXIOMsys contains the final image
- a clean copy for the end user
+\section{Coding Guidelines}
+\label{sec:CodingGuidelines}
+Code in Axiom tries to follow certain guidelines, which aim to improve
+readability and the documentation of the implementation.
-I've attached the interesting part of a console log. At this point
-the Axiom build is making the transition from building the BOOTSTRAP
-algebra to building the non-BOOTSTRAP algebra.
+Unfortunately many of these guidelines have only been applied since
+Axiom became available under an open source license on September 3,
+2002. Hence many parts of Axiom do not follow these guidelines at all
+or only superficially\footnote{For example, all source files have been
+ converted to pamphlet files. In general, though, they are not
+ documented or structured in any useful way, yet. They simply contain
+ one big chunk of code.}. If you gained understanding of an as-yet
+undocumented part of Axiom, please document and edit it according to
+these guidelines and submit a patch to the maintainers of Axiom (see
+\ref{sec:ContributingPatches}).
-Notice that the BOOTSTRAP algebra is just lisp code. This code is
-compiled in a DEPSYS image so that macros are properly expanded.
-However it is clear that the BOOTSTRAP lisp code was not compiled by
-the "new" compiler.
+\subsection{General}
+\label{sec:CodingGuidelinesGeneral}
-Next we see the transition to compiling the non-BOOTSTRAP algebra.
-This is done in the interpsys image. It is also done in an image
-that has access to only the BOOTSTRAP algebra code. Thus the
-new compiler might not have all of the algebra-defined replacements
-available at compile time. Notice the autoload files that contain
-the optimizations.
-A second or third round of compiles will expose the algebra-based
-optimizations and these will be compiled into the code. Since these
-are only optimizations the final results should not be affected.
+\begin{quotation}
+ Thus, programs must be written for people to read, and only
+ incidentally for machines to execute.
-Also note that the BOOTSTRAP algebra is recompiled as the last step
-of building the algebra from scratch so that it can use the circular
-definitions.
+ -- {\it Structure and Interpretation of Computer Programs}
+\end{quotation}
-==========================================================================
-==== running DEPSYS image ===============================================
-==========================================================================
+\subsection{Lisp}
+\label{sec:CodingGuideLinesLisp}
-BOOT>0 making /home/arch/axiom--hyperdoc--1--base-0/int/algebra/VECTOR.lsp
from
-/home/arch/axiom--hyperdoc--1--base-0/src/algebra/vector.spad.pamphlet
-0 making /home/arch/axiom--hyperdoc--1--base-0/int/algebra/VECTOR.o from
-/home/arch/axiom--hyperdoc--1--base-0/int/algebra/VECTOR.lsp
+Stick to \ansicl{} and modern Lisp style, i.e. do not write in all-caps
+and make use of all data structures available, if appropriate. Also
+provide documentation strings for all functions, global variables,
+constants, classes etc.
->
-Compiling VECTOR.lsp.
-End of Pass 1.
-End of Pass 2.
-OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
-Finished compiling VECTOR.o.
-#p"VECTOR.o"
-BOOT>0 making /home/arch/axiom--hyperdoc--1--base-0/int/algebra/AHYP.spad from
-/home/arch/axiom--hyperdoc--1--base-0/src/algebra/trigcat.spad.pamphlet
+\section{Workflow}
+\label{sec:Workflow}
-==========================================================================
-==== running AXIOMSYS image =============================================
-==========================================================================
+Naturally the workflow varies between developers, but usually there
+are some common elements. In this section we describe a somewhat
+rudimentary workflow for developing Axiom\footnote{The rest of this
+ section is mostly an edited version of an email by Tim Daly, in
+ which he describes how he develops \axiom{}. His workflow is rudimentary in
the
+ sense that he uses almost none of Emacs' advanced features.}.
+The most important thing in programming is the "OODA" loop (it means
+"orient-observe-decide-act") which, in programming, refers to the
+issue of how long it takes to fix a bug.
-0 making /home/arch/axiom--hyperdoc--1--base-0/int/algebra/AHYP.NRLIB from
-/home/arch/axiom--hyperdoc--1--base-0/int/algebra/AHYP.spad
- AXIOM Computer Algebra System
- Version of Friday November 19, 2004 at 16:36:16
------------------------------------------------------------------------------
- Issue )copyright to view copyright notices.
- Issue )summary for a summary of useful system commands.
- Issue )quit to leave AXIOM and return to shell.
------------------------------------------------------------------------------
-
- Using local database
-/home/arch/axiom--hyperdoc--1--base-0/src/share/algebra/compress.daase..
-Using local database
-/home/arch/axiom--hyperdoc--1--base-0/src/share/algebra/interp.daase..
- Using local database
-/home/arch/axiom--hyperdoc--1--base-0/src/share/algebra/operation.daase..
- Using local database
-/home/arch/axiom--hyperdoc--1--base-0/src/share/algebra/category.daase..
- Using local database
-/home/arch/axiom--hyperdoc--1--base-0/src/share/algebra/browse.daase..
-(1) -> Loading
-/home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/apply.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/c-doc.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/c-util.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/profile.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/category.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/compiler.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/define.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/functor.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/info.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/iterator.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/modemap.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/nruncomp.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/package.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/htcheck.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/xruncomp.
- Compiling AXIOM source code from file
- /home/arch/axiom--hyperdoc--1--base-0/int/algebra/AHYP.spad using
- old system compiler.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/parsing.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/bootlex.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/def.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/fnewmeta.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/metalex.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/metameta.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/parse.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/postpar.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/postprop.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/preparse.
- AHYP abbreviates category ArcHyperbolicFunctionCategory
-------------------------------------------------------------------------
- initializing NRLIB AHYP for ArcHyperbolicFunctionCategory
- compiling into NRLIB AHYP
+Suppose you are running a program (in any language) and it hits a bug
+(say, a syntax error or something trivial) and fails. How long does it
+take to find the bug behavior, figure out what might cause it, decide
+where it is and fix it so that you're back to the point of the bug?
-;;; *** |ArcHyperbolicFunctionCategory| REDEFINED
-Time: 0 SEC.
+All really productive programmers strive to minimize their OODA
+loop. One approach to achieve this goal is the following.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/bc-matrix.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/bc-misc.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/bc-solve.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/bc-util.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/ht-util.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/htsetvar.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/ht-root.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-con.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-data.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/showimp.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-op1.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-op2.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-search.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-util.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/topics.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-prof.
- Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-saturn.
- finalizing NRLIB AHYP
- Processing ArcHyperbolicFunctionCategory for Browser database:
---------(acosh ($ $))---------
---------(acoth ($ $))---------
---------(acsch ($ $))---------
---------(asech ($ $))---------
---------(asinh ($ $))---------
---------(atanh ($ $))---------
---------constructor---------
-Compiling
/home/arch/axiom--hyperdoc--1--base-0/int/algebra/AHYP.NRLIB/code.lsp.
+Suppose you have a file {\tt foo.pamphlet} and the corresponding
+makefile {\tt Makefile.foo}, which is also contained in the {\tt
+ @<<*>>} chunk of {\tt foo.pamphlet}.
-
+Split your Emacs frame vertically {\tt C-x 2}, with foo.pamphlet in
+one window and a shell buffer in the other.
+Now edit {\tt foo.pamphlet} to your hearts content. Once you are ready
+to test your changes, execute a keyboard macro ({\tt C-x e}) that
+\begin{enumerate}
+\item saves the current buffer, i.e. foo.pamphlet ({\tt C-x C-s})
+\item switches to the shell buffer ({\tt C-x o})
+\item goes to the bottom of the shell buffer ({\tt M->})
+\item executes {\tt make -f Makefile.foo}, which extracts code and
+ documentation from the pamphlet, runs latex on the latter and
+ executes the test cases
+\item switches back to the other buffer, i.e. {\tt foo.pamphlet} ({\tt
+ C-x o})
+\end{enumerate}
+To record such a keyboard macro, make sure that the cursor is in the
+{\tt foo.pamphlet} buffer and press the following keys: {\tt C-x (},
+{\tt C-x C-s}, {\tt C-x o}, {\tt M->}, {\tt make -f Makefile.foo},
+{\tt C-x o}, {\tt C-x )}. You could also give this keyboard macro a
+name and even save it. Read the Emacs manual for further details.
-\end{verbatim}
-\section{email 8}
+% TODO kai: Write an Elisp function that works with any pamphlet.
+The following (untested) Elisp function should do the same and more.
\begin{verbatim}
-MiKTeX is an up-to-date TeX implementation for the Windows operating system.
+(defun make-pamphlet ()
+ "Saves the current buffer, which is assumed to be visiting
+ a pamphlet file, and calls 'make -f Makefile.foo', where 'foo'
+ is the name of the pamphlet without the '.pamphlet' suffix.
-TeX is a typesetting system written by Donald E. Knuth, who says that it is
-"intended for the creation of beautiful books - and especially for books that
-contain a lot of mathematics".
+ The prefix arg is passed on to save-buffer."
+ (interactive)
+ (let* ((file-name (buffer-file-name (current-buffer)))
+ (is-pamphlet (and file-name
+ (string-match "\\(.*?\\)\\([^/]+\\)\.pamphlet"
file-name)
+ t)))
+ (if (not is-pamphlet)
+ (message "This doesn't seem to be a pamphlet file.")
+ (let ((pamphlet-name (match-string 2 file-name))
+ (pamphlet-path (match-string 1 file-name)))
+ (call-interactively 'save-buffer)
+ (shell-command (format "(cd %s; make -f Makefile.%s)" pamphlet-path
pamphlet-name))))))
+\end{verbatim}
-MiKTeX offers a complete set of utilities, macro packages and fonts, e.g.,
-LaTeX, pdfTeX, ConTeXt, just to name a few.
+Figure \ref{fig:ExamplePamphlet} shows an almost minimal example
+pamphlet.
-http://www.miktex.org\end{verbatim}
-\section{email 9}
+\begin{figure}
+ \centering
\begin{verbatim}
-> > Next we see the transition to compiling the non-BOOTSTRAP algebra.
-> > This is done in the interpsys image. It is also done in an image
-> > that has access to only the BOOTSTRAP algebra code. Thus the
-> > new compiler might not have all of the algebra-defined replacements
-> > available at compile time. Notice the autoload files that contain
-> > the optimizations.
-> >
->
-> What do you mean by "algebra-defined replacements". Where are
-> these replacements defined? How are they different than the
-> "optimizations" contained in the autoload files?
+\documentclass{article}
+\usepackage{axiom}
+\begin{document}
+\title{Foo considered harmful}
+\author{John Doe}
+\maketitle
+\begin{abstract}
+\end{abstract}
+\eject
+\tableofcontents
+\eject
-The BOOTSTRAP files contain lsp and spad code. The build steps
-for the initial BOOTSTRAP layer use "depsys" to compile the lisp
-code. So, in this case, we see VECTOR.lsp being compiled in the
-depsys image. VECTOR.lsp is the last algebra file that contains
-BOOTSTRAP code. So in this phase we see:
+@<<foo.lisp>>=
+(defun foo ()
+ 'foo)
-VECTOR.lsp (BOOTSTRAP) -> VECTOR.o
+(defun test-foo ()
+ (unless (eq 'foo (foo))
+ (write-string "test-foo failed!")))
-Once we leave the phase (shown in the printout) we start using
-an "interpsys" image to compile spad code. Much later in the console
-VECTOR.spad will be compiled and replaces the lisp. However the
-"interpsys" environment in VECTOR.spad differs significantly from
-the "depsys" environment that compiles VECTOR.lsp BOOSTRAP code.
-So we see
+(test-foo)
+@@
-VECTOR.spad + SINT.NRLIB -> VECTOR.lsp -> VECTOR.o (replaced previous version)
+\section{Makefile}
+@<<*>>=
+TANGLE=/usr/local/bin/NOTANGLE
+WEAVE=/usr/local/bin/NOWEAVE
+LATEX=/usr/bin/latex
+LISP=/sei/lisp
-Suppose VECTOR.spad used something from SINT.spad. When the
-VECTOR.lsp BOOTSTRAP file is compiled by depsys it contains
-(+ ... ...) and generates untyped and unoptimized code.
+all: doc code run
-Later when VECTOR.spad is compiled and SINT.o is available
-then the spad compiler will use the optimization information
-to generate (QSADD1 ... ...)
+doc:
+ ${WEAVE} -t8 -delay foo.pamphlet >foo.tex
+ ${LATEX} foo.tex 2>/dev/null 1>/dev/null
+ ${LATEX} foo.tex 2>/dev/null 1>/dev/null
-> What do you mean by "expose". Why does this cause interpsys to
-> be re-built? That is necessary if code is going to be generated
-> based on new optimizations isn't it?
+code: foo.pamphlet
+ ${TANGLE} -Rfoo.lisp foo.pamphlet >foo.lisp
-expose == make available
-Due to my lack of foresight in choosing the VECTOR.lsp BOOTSTRAP
-code I did not use the most highly optimized version. But in the
-algebra recompile of VECTOR.spad later in the build this gets
-corrected because the operations are made available (exposed) by
-previously compiled .spad code. So:
+run:
+ cat foo.lisp | ${LISP}
-VECTOR.lsp (BOOTSTRAP) uses SINT.o
+remake:
+ ${TANGLE} -t8 foo.pamphlet >Makefile.foo
-But the VECTOR.lsp has (+ ... ...) instead of (QSADD1 ... ...)
-because the rewriting of "+" to "QSADD1" is done by the spad
-compiler, not the GCL compiler and we are not yet in a position
-to use the spad compiler.
+@@
+\eject
+\begin{thebibliography}{99}
+\bibitem{1} nothing
+\end{thebibliography}
+\end{document}
+\end{verbatim}
+ \caption{Example pamphlet}
+ \label{fig:ExamplePamphlet}
+\end{figure}
-Later when
+\chapter{Architecture and Implementation}
+\label{chap:ArchitectureAndImlementation}
-VECTOR.spad -> VECTOR.lsp -> VECTOR.o (replaced previous version)
+This chapter describes the overall architecture of Axiom and its
+components and contains some comments on the implementation. More
+detailed information on the implementation of a function or component
+can usually be found in the corresponding pamphlet. If not, please
+consider writing documentation for that part of Axiom and submit a
+patch to the Axiom maintainers (see \ref{sec:ContributingPatches}).
-the spad compiler was invoked and it gets a chance to change
-"+" to "QSADD1".
+\section{Processes}
+\label{sec:Processes}
-Because I grabbed the wrong version of .lsp file for BOOTSTRAP
-code you are able to see this difference. The work you and steve
-are doing is to find stable versions of the .lsp files.
+A running \axiom{} consists of several different processes, depending on
+the user's actions. \axiom{} is usually started using the {\tt
+ \$AXIOM/src/etc/axiom} shellscript, which does some option
+processing and then starts {\tt sman}.
-> > Since these are only optimizations the final results should not
-> > be affected.
-> >
->
-> But it could have an impact on overall performance, right?
+% TODO: Detail the processes
-Oh, clearly. (QSADD1 ... ...) is faster than (+ ... ...)
-Furthermore, there is another optimization step we could take
-during the build but we do not (yet). When the GCL compiler
-compiles VECTOR.lsp it generates VECTOR.fn. If you look in these
-.fn files you'll find exact type information for each function call.
+\section{Languages}
+\label{sec:Languages}
-VECTOR.lsp -> VECTOR.o + VECTOR.fn (unoptimized, but type generated)
+%TODO kai: How do we integrate
+%http://wiki.axiom-developer.org/AxiomDevelopment?
-If this exact type information was available at compile time then
-the GCL compiler can lay down faster code. However there is a
-bootstrap problem here also since the GCL compiler has to compile
-the code one time in order to generate the .fn file.
+Axiom is built using several different (programming) languages, some
+of which are undocumented. This section gives a short description of
+each language as well as its uses. More detailed information on these
+languages can usually be found in other chapters of this book.
-VECTOR.lsp + VECTOR.fn -> VECTOR.o (type optimized)
-So the full, proper procedure, which I have yet to do, would actually
-call the GCL compile once to generate the .fn file with exact type
-information for function calls, load the .fn file, and the recompile
-the lisp file. Since the second compile has exact type information
-the generated code will be (potentially much) shorter.
+\subsection{BOOT}
+\label{sec:BOOT}
-For each lisp file do
-(
- VECTOR.lsp -> VECTOR.o + VECTOR.fn (unoptimized, but type generated)
- VECTOR.lsp + VECTOR.fn -> VECTOR.o (type optimized)
-)
+\boot{} is what most of the \spad{} interpreter/compiler is written
+in. It is implemented in Lisp and \boot{} itself, which introduces
+some bootstrap issues. \boot{} programs are compiled to Lisp and then
+compiled and executed by the Lisp system. The source code to the
+\boot{} compiler can be found in {\tt \$AXIOM/src/boot}.
-> Still after reading the interp and algebra Makefiles again,
-> I do not see why interpsys is being rebuilt after I delete
-> all the *.NRLIB's and repeat the 'make'. I am still missing
-> something somewhere. Is there some "missing link" that still
-> connects the algebra/Makefile back to the inter/Makefile?
-I have to think about this (I'm getting ready for work so I'll
-give it some "drive-time cycles") but I believe that the issue
-is related to using fresh databases. The databases are used
-during the algebra compiles to resolve algebra calls. However
-recompiling the algebra generates NRLIBs and, from these NRLIBs
-a fresh database is built thus:
+\subsection{Lisp}
+\label{sec:Lisp}
-DATABASES -> NRLIBs -> FRESH DATABASES
+The use of Lisp in \axiom{} is pervasive but somewhat peculiar. This
+stems mostly from two facts. First of all, during its lifetime \axiom{} has
been ported to
+many different Lisps. Furthermore Lisp is mostly used as a low-level
+language and only very rudimentary Lisp features are used.
-This is yet a third bootstrap issue. There are more but not with
-the algebra files.
+Currently \axiom{} runs on GNU Common Lisp in CLtL1 mode. There is an
+effort to port it to GCL's ANSI mode and other standard-compliant
+Lisps, like SBCL and CMUCL.
-\end{verbatim}
-\section{email 9}
-\begin{verbatim}
-Yet one other opportunity for speed optimization is available at
-build time....
+The Lisp code in Axiom is distributed over several packages, which are
+defined in {\tt \$AXIOM/src/interp/sys-pkg.lisp.pamphlet}.
+% TODO kai: There are several dead Lisp packages in the list
+% below. Why do we keep them around?
-Remember that every lisp file generates a .fn file:
+\begin{itemize}
+\item {\tt SCRATCHPAD\_COMPILER}
-foo.lsp -> foo.o + foo.fn
+ The \spad{} compiler package (probably dead, all symbols have been
+ moved to the {\tt BOOT} package).
-and that a second compile with the .fn file loaded is faster:
+\item {\tt SPECFNSF}
-foo.lsp + foo.fn -> faster foo.o
+ The special functions package (dead). There was originally Lisp
+ code to support hardcoded knowledge of special functions like {\tt
+ gamma}. The functions in this package have been lifted to the
+ algebra level.
-However if we look at the type information in the foo.fn file
-we find that it only contains type information for functions
-defined in foo.lsp. But suppose there are two lisp files with
-functions from one using functions from the other. The sub-optimal
-sequence is:
+\item {\tt VMLISP}
-foo.lsp -> foo.o + foo.fn
-foo.lsp + foo.fn -> faster foo.o
+ This package originally contained the VMLisp macros but in fact
+ contains macros to support several other Lisps. It is essentially
+ the place where most of the macros to support idioms from prior
+ ports are, e.g. {\tt RDEFIOSTREAM} and {\tt FILEACTQ}. In the long
+ term this package should probably go away, since \axiom{} is being
+ moved to \ansicl.
-bar.lsp -> bar.o + bar.fn
-bar.lsp + bar.fn -> faster bar.o
+\item {\tt BOOTTRAN}
-The optimal sequence is:
+ This is the \boot{} to Lisp compiler package used by the files in {\tt
+ \$AXIOM/src/boot}. It is the \boot{} translator package.
-foo.lsp -> foo.o + foo.fn
-bar.lsp -> bar.o + bar.fn
+\item {\tt BOOT}
-foo.lsp + (foo.fn + bar.fn) -> even faster foo.o
-bar.lsp + (foo.fn + bar.fn) -> even faster bar.o
+ Everything in Axiom that the user references eventually shows up
+ here. The interpreter and the algebra are run after switching to the
+ boot package {\tt (in-package "BOOT")}. Hence any symbol that the
+ interpreter or algebra uses has to appear here.
-So, really what we should do is cache ALL of the .fn files from all of
-the compiles, batch them into a big file, and the completely rebuild
-the system with the batched .fn files loaded.
+\item {\tt FOAM}
-I've started this process but have not yet completed it.
-See the file src/boot/boot-proclaims.lisp
+ \foam{} is the intermediate language for the \aldor{} compiler. \foam{}
+ means ``First Order Abstract Machine'' and functions similar to RTL
+ for the GCC compiler. It is a "machine" that is used as the target
+ for meta-assembler level statements. These are eventually expanded
+ for the real target machine or interpreted directly.
-So there is a faster Axiom coming in the future but the build
-complexity will be even greater. And Camm, I believe, is doing
-even more with type propagation which will improve things more.
+\item {\tt FOAM-USER}
+ {\tt foam-user} is the package containing foam statements and macros
+ that get inserted into user code versus the foam package which
+ provides support for compiler code.
+\end{itemize}
-\end{verbatim}
-\section{email 10}
-\begin{verbatim}
-I am no longer baffled. The explanation for the generic arith
-vs. fixnum arith is in macros.lisp. In the following code from
--REPEAT, X is bound to a form such as '((STEP |i| 3 1)):
- (COND ((AND (EQ (CAAR X) 'STEP)
- (|member| (CADDAR X) '(2 1 0 (|One|) (|Zero|)))
- (|member| (CADR (CDDAR X)) '(1 (|One|))))
- (SETQ X (CONS (CONS 'ISTEP (CDAR X)) (CDR X))) ))
- ; A hack to increase the likelihood of small integers
+\subsection{\spad}
+\label{sec:SPAD}
-So, one `rule' is, if you iterate with a sequence with lower bound
-0,1, or 2, with an increment of 1, you get fixnum arith. Otherwise you
-get generic arithmetic.
+\spad{} is the programming language for mathematics. All the code in
+{\tt \$AXIOM/src/algebra} is written in \spad. It is a user-level
+language. More detailed information on \spad{} can be found in the
+\manual{}.
-However, this is not a hard and fast rule, since the compiler can say
-'(ISTEP |i| 5 23) [say] during code generation and force fixnum arith.
+\subsection{\aldor}
+\label{sec:Aldor}
-This leads to a question. Tim, in interp/wi2.boot we have a
-redefinition of compIterator (default implementation is in
-iterator.boot). This new definition makes an attempt at deciding when
-fixnum stepping code should be generated. Do you have an explanation
-as to why is this not the default definition? The original version of
-the code in iterator.boot is what gets called.
+\aldor{} is the successor of \spad. There are still remnants of \aldor
+support in the current codebase, but the only working implementation
+of \aldor{} is written in C and available at http://www.aldor.org/,
+unfortunately not under an open source license. There is some support
+for using that \aldor{} implementation with \axiom{} and it is planned to
+move all of \axiom{} to \aldor.
-I'm wondering if it is possible that during the fixedPoint build if
-some of the new definitions (particularly those in wi2.boot,
-xruncomp.boot) are being autoloaded during compilation. The changes
-which I have already noted in the generated lisp seem to support this
-(fixnum arith vs. generic arith, inlining of trivial coercions,
-etc). All the changes make sense if they are the result of calling one
-of the `improved' functions which these files redefine.
+\subsection{\hypertex}
+\label{sec:Hypertex}
-Sincerely,
-Steve
+\hypertex{} is similar in appearance to \TeX/\LaTeX and is used by the
+\hyperdoc{} as a markup language. More information can be found in the
+chapter on \hyperdoc{} (see \ref{sec:TheHyperDoc}) and in \manual.
+\subsection{C}
+\label{sec:C}
-On Mon, Jan 17, 2005 at 01:39:45PM -0500, Stephen Wilson wrote:
->
-> Tim,
->
-> I compleatly fine with the fixnum declaration. We just need to make
-> sure it is a rule programmers can rely on. Consider:
->
-> )abbrev package ITER Iter
-> Iter(): E == I where
-> E == with
-> iter: () -> Void
-> I == add
-> iter(): Void ==
-> for i in 2.. repeat
-> print(i::OutputForm)
->
->
-> The relavent lisp decalres we are using fixnums:
->
-> (LETT |i| (QSADD1 |i|) |ITER;iter;V;1|)
->
->
-> Now compile the above with a lower bound of 3:
->
-> for i in 3.. repeat
-> print(i::OutputForm)
->
->
-> We get generic arithmetic:
->
-> (LETT |i| (+ |i| 1) |ITER;iter;V;1|)
->
->
-> Baffled,
-> Steve
->
->
-> On Mon, Jan 17, 2005 at 12:23:36PM -0500, root wrote:
-> > Steve,
-> >
-> > I don't know if there is an actual statement to the effect that
-> > the upper bound on a loop would be a register-sized number (32
-> > or 64 bits) but at 6Mhz it seemed impossible that one could
-> > run a loop of any consequence for greater than 2^32 or 2^64
-> > iterations. If you wanted to do that you'd have to do the
-> > looping using some other construct. In general it is safe to
-> > assume that the upper bound of the register size cannot be
-> > exceeded. There is a practical performance difference to
-> > be gained by using (declare (fixnum as the compiler can,
-> > in the best case, assign a register to the loop variable.
-> >
-> > t
+\subsection{Other languages}
+\label{sec:OtherLanguages}
+There are also Meta and CHARYBDIS.
+\section{The \boot{} Language}
+\label{sec:TheBootLanguage}
-\end{verbatim}
-\section{email 11}
-\begin{verbatim}
-I installed "Aldor version 1.0.2 for LINUX(glibc2.3)" on
-axiom-developer.org several months ago. The date on the
-aldor tarball in /home/page is May 19 2004. Aldor should
-be accessible to you when you log in at axiom-developer.
-Just add
- export ALDORROOT=/usr/local/aldor/linux/1.0.2
- export PATH=$ALDORROOT/bin:$PATH
-to your .bashrc, do
+\section{The HyperDoc}
+\label{sec:TheHyperDoc}
- . .bashrc
+The HyperDoc is the pre-web hypertext documentation system for
+Axiom. It supports not only (limited) text markup and hyperlinks, but
+also dynamically generated pages and interactive examples.
-and your should be able to type
- aldor ...
+\section{The Markup Language for HyperDoc Pages}
+\label{sec:TheMarkupLanguageForHyperDocPages}
-You should find the libaries in the standard locations.
+% Comment: This section might be useful to end-users and thus fit better
+% into Volume 2. On the other hand, \hyperdoc{} will not survive in its
+% current form and part of the problem is the language described in this
+% section.
-There is apparently a fairly up to date windows binary
-version as well, but I haven't had much time to play
-with this yet.
+The syntax for \hyperdoc{} pages follows the syntax of \TeX/\LaTeX\ in the
+sense that after defining a few \hyperdoc{} specific commands through
+{\tt \\newcommand} and adding a document header the \hyperdoc{} pages are
+valid LaTeX documents.
-At the time I was planning to implement a MathAction-
-Aldor web interface that would look something like this
+\hyperdoc{} files usually have an {\tt .ht} or {\tt .pht} suffix,
+depending on wether they contain pages or patches and pastes (see
+\ref{sec:ThePatchPasteMechanism}). A single file can contain several
+\hyperdoc{} pages\footnote{From now on we do not mention patches or
+ pastes. Their syntax is almost the same, though.}. The content of a
+page is contained in a \hypercmd{page} environment, which takes two
+parameters: the page name and the page title. The former is the
+internal identifier and has to be a single word ({\tt
+ [a-zA-Z][a-zA-Z0-9]*}), the latter is shown to the user and can be
+arbitrary text containing abbreviations defined through
+\hypercmd{newcommand} in the same file. A typical example for a page
+is {\tt AlgebraPage}, which is contained in {\tt algebra.ht} (see
+\ref{fig:AlgebraPageSource}).
-\begin{aldor}
-... aldor code ...
-\end{aldor}
+\begin{figure}
+ \centering
+\begin{verbatim}
+\begin{page}{AlgebraPage}{Abstract Algebra}
+ \beginscroll
+ \Language{} provides various facilities for treating topics in abstract
+ algebra.
+ \beginmenu
+ \menulink{Number Theory}{NumberTheoryPage} \newline
+ Topics in algebraic number theory.
+ % \menulink{Algebraic Geometry}{AlgebraicGeometryPage} \newline
+ % Computational algebraic geometry: Groebner bases, integral bases,
+ % divisors on curves.
+ \menulink{Group Theory}{GroupTheoryPage} \newline
+ Permutation groups; representation theory.
+ \endmenu
+ \endscroll
+ \autobuttons
+\end{page}
+\end{verbatim}
-and which could be intermixed with Axiom code on the
-MathAction website. I got distracted by other things
-and so have not yet completed the integration with
-MathAction but there is not a lot more to do. Recent
-discussions here about getting Axiom and Aldor working
-together again suggest that it might be time for me
-to raise the priority to make this possible.
+ \caption{The source of {\tt AlgebraPage} from {\tt algebra.ht}}
+ \label{fig:AlgebraPageSource}
+\end{figure}
-Ralf Hemmecke wrote:
->
-> If you mean cvs.aldor.org, then it might be that May 16 2004
-> is a bit late. The libraries have changed since then.
->
-> You could however download the latest precompiled version
-> 1.0.2 from
->
-> http://www.aldor.org/downl.html
->
-
-> If you really want to compile the libraries yourself, ask
-> me again. I think the newest cvs-version should compile,
-> but if they don't ... There has been some work on the
-> Makefiles since May 16.
->
-> Ralf
->
-> root wrote:
-> > Martin, Peter,
-> >
-> > I tried to build aldor last night. I succeeded in building
-> > the compiler but not the libraries. I have a CVS checkout
-> > from May 16.
-> >
-> > I've been reading the Makefiles but they all seem to dissolve
-> > into home-grown tools (makeon, docc, etc) which undermines my
-> > ability to figure out what is happening. It's been years since
-> > I built aldor.
-> >
-> > Peter, could you provide the required steps to build a working
-> > compiler? e.g.
-> >
-> > edit Makefile.globals to change.... make aldorcompiler
-> > ....
-> >
+The aforementioned figure already shows a few common commands that can
+be used inside a page. It also shows that sometimes LaTeX-like
+environments, i.e. {\tt \bs begin{foo} ... \bs end{foo}}, are used, and
+sometimes TeX-like constructs, i.e. {\tt \bs beginmenu ... \bs endmenu}.
+The list of \LaTeX-like environments is reasonably short.
+\begin{itemize}
+\item {\tt items}
-\end{verbatim}
-\section{email 12}
-\begin{verbatim}
-Oops, sorry that I have not read the documentation of Any.
-I had a look at Any now. Well, from that I just got the feeling that a
programmer should never use Any if there are better types around (and often
there are). Any seems to be connected to the interpreter. Since everything must
have a type and the interpreter cannot figure out something reasonable, it
falls back to Any.
+ Similar to the {\tt itemize} environment of \LaTeX. Entries are
+ started with {\tt item}.
-I'd rather be happy if the interpreter is clearly separated from the compiler.
+\item {\tt page}
-The interpreter is for working with Axiom, so it could help the (lazy) user
and find/guesss appropriate types for him/her. However there should be NO
guessing when it comes to writing new library code.
+ Defines a new page (see above).
-Looking at the code of Any reminds me much of the things I have suggested here
+\item {\tt paste}
address@hidden">http://page.axiom-developer.org/zope/mathaction/address@hidden
-The code is in cvs.aldor.org/aldor/aldorug/samples/object*.as.
+ Defines a new paste (see \ref{sec:ThePatchPasteMechanism}).
+\item {\tt patch}
-The problem I still have with any is that it says
+ Defines a new patch (see \ref{sec:ThePatchPasteMechanism}).
+\item {\tt scroll}
- Rep := Record(dm: SExpression, ob: None)
- dom x == x.dm
+ Marks the scrollable part of the page. See also {\tt beginscroll}.
+\item {\tt spadsrc}
-which looks very near to some LISP thing.
-So I can ask for the domain a: Any by calling dom(a). Then I will get an
SExpression which makes me feel lost.
+ Contains SPAD source code, similar to the {\tt verbatim} environment.
-Unfortunately, I have no runnig Axiom at the moment :-(
-And I cannot compile axim--main--1 (bfd.h is missing and I have no idea what
to install).
+\item {\tt verbatim}
-So I tested on
+ As in \TeX/\LaTeX.
+\end{itemize}
+The list of TeX-like environments:
-http://page.axiom-developer.org/zope/mathaction/AxiomInterface
+\begin{itemize}
+\item {\tt Important}
+\item {\tt items}
+\item {\tt menu}
+ This is similar to the {\tt itemize} environment of \LaTeX. Each
+ entry is prepended by one of {\tt menulink}, {\tt menudownlink},
+ {\tt menumemolink}, {\tt menuwindowlink}, {\tt
+ menulispcommand}, {\tt menulispdownlink}, {\tt
+ menulispmemolink}, {\tt menulispwindowlink} and {\tt
+ menuunixcmd}.
-i: Integer := 1
- Type: Integer
+\item {\tt scroll}
+ Defines the scrolling portion of the \hyperdoc{} page. There can be
+ only one such construct per page.
-a: Any := i::Any
- Type: Integer <----- very interesting!!!
+\end{itemize}
+Finally we present an alphabetical list of (almost) all commands
+understood in \hyperdoc{} pages. While some of these commands are
+hard-wired into \hyperdoc, many of them are defined in {\tt
+ \$AXIOM/src/hyper/pages/util.ht}.
-dom a
- Type: SExpression
-obj a
- Type: None
+\begin{itemize}
+\item {\tt Browse}
-j: Integer := a :: Integer
- Type: Integer
+ Produces the string {\tt Browse}.
+\item {\tt Clef}
-It seems the interpreter is quite smart.
+ Produces the string {\tt Clef}.
+\item {\tt Gallery}
+ Produces the string {\tt \{AXIOM Images\}}.
+\item {\tt HDexptypeindex}
+ See {\tt HDindex}.
-s: String := "I am a string"
- Type: String
+\item {\tt HDindex}
+ Hidden behind special comment markers ('\%-\%') and used for
+ indexing with TeX.
-b: Any := s::Any
- Type: String
+\item {\tt HDsyscmdindex}
+ See {\tt HDindex}.
-dom b
- Type: SExpression?
+\item {\tt HyperName}
+ Produces the string HyperDoc.
-obj b
- Type: None
+\item {\tt Language}
+ Produces the string {\tt AXIOM}.
-k: Integer := b :: Integer
- Cannot convert from type Any to Integer for value
- "I am a string"
+\item {\tt Lisp}
+ Produces the string {\tt Common LISP}.
+\item {\tt MenuDotBitmap}
-This Error is OK. And I think for manually working with Axiom, one just needs
to type dom(...) and then coerce to the now known type.
-But how to use Any in a program is totally unclear to me. I have no idea to
get the domain back from the SExpression.
-\end{verbatim}
-\section{email 13}
-\begin{verbatim}
-> ...
-> I am, however, very much against the Any type. It is like
-> building a strongly typed language and than trying to forget
-> about types.
->
+ Displays a little bitmap showing a dot. Used by many menu commands
+ and defined in {\tt \$AXIOM/src/hyper/pages/util.ht}.
-Well that is more or less what I naively thought as well but
-from the ANY.spad file I read that:
+\item {\tt ReturnButton}
+\item {\tt TeX}
-)abbrev domain ANY Any
-++ Author: Robert S. Sutor
-++ Basic Functions: any, domainOf, objectOf, dom, obj,
-++ showTypeInOutput
-++ Related Constructors: AnyFunctions1
-++ Description:
-++ \spadtype{Any} implements a type that packages up objects and
-++ their types in objects of \spadtype{Any}. Roughly speaking
-++ that means that if \spad{s : S} then when converted to
-++ \spadtype{Any}, the new object will include both the original
-++ object and its type. This is a way of converting arbitrary
-++ objects into a single type **without losing any** of the
-++ original information. Any object can be converted to one of
-++ \spadtype{Any}.
+ As in \TeX/\LaTeX.
-and in the related file ANY1.spad
+\item {\tt UpBitmap}
+\item {\tt UpButton}
+\item {\tt aliascon}
+\item {\tt allowbreak}
+\item {\tt argDef}
+\item {\tt autobutt}
-)abbrev package ANY1 AnyFunctions1
-++ Basic Functions: coerce, retractIfCan, retractable?, retract
-++ Description:
-++ \spadtype{AnyFunctions1} implements several utility functions
-++ for working with \spadtype{Any}. These functions are used to
-++ go back and forth between objects of \spadtype{Any} and objects
-++ of other types.
+ An alias for {\tt helppage}.
-So the situation is not quiet so simple. Apparently Any does not
-mean Any in the sense of throwing away essential information.
+\item {\tt autobuttons}
-\end{verbatim}
-\section{email 14}
-\begin{verbatim}
-Ralf Hemmecke wrote:
->
-> Hi Bill,
->
-> >>Foo: with { g: (n: PositiveInteger, k: PositiveInteger) ->
-> >>PrimeField(n) } == add {
-> >>g(n: PositiveInteger, k: PositiveInteger ): PrimeField(n) ==
-> >> k::Integer::PrimeField(n) }
->
-> > Ok, I will work with this example. Yes, it is better.
->
-> Well, I haven't checked whether it should really work, but
-> shouldn't be
->
-> Foo: with {
-> g: (n: PositiveInteger, k: PositiveInteger) ->
-> (P: PrimeFieldCategory, x: P)
-> } == add {
-> g(n: PositiveInteger, k: PositiveInteger ):
-> (P: PrimeFieldCategory, x:P) == {
-> (PrimeField(n), k::Integer::PrimeField(n)
-> }
-> }
->
-> be even better?
+ Does nothing at all.
-In fact you just pointed a way to solve the problem! Notice that you are in
-effect constructing a domain! So first create this domain (call this anything
-else you like):
+\item {\tt axiom}
+\item {\tt axiomFun}
+\item {\tt axiomFunFrom}
+\item {\tt axiomFunX}
+\item {\tt axiomOp}
+\item {\tt axiomOpFrom}
+\item {\tt axiomSig}
+\item {\tt axiomSyntax}
+\item {\tt axiomType}
+\item {\tt axiomcommand}
+\item {\tt axiomxl}
+\item {\tt beep}
+\item {\tt blankline}
+\item {\tt bound}
+\item {\tt boxvalue}
+\item {\tt caption}
+\item {\tt cdots}
+\item {\tt center}
+\item {\tt centerline}
+\item {\tt cite}
+\item {\tt def}
+\item {\tt displaystyle}
+\item {\tt downlink}
+\item {\tt end}
+\item {\tt endImportant}
+\item {\tt enditems}
+\item {\tt endmenu}
+\item {\tt endscroll}
+\item {\tt env}
+\item {\tt epsffile}
+\item {\tt eth}
+\item {\tt example}
+\item {\tt examplenumber}
+\item {\tt expr}
+\item {\tt fakeAxiomFun}
+\item {\tt fbox}
+\item {\tt footnote}
+\item {\tt free}
+\item {\tt frenchspacing}
+\item {\tt funArgs}
+\item {\tt funSyntax}
+\item {\tt graphpaste}
+\item {\tt head}
+\item {\tt helpbit}
+\item {\tt helppage}
+\item {\tt hfill}
+\item {\tt horizontalline}
+\item {\tt hspace}
+\item {\tt htbitmap}
+\item {\tt httex}
---%PointedPrimeField
-)abbrev domain PPF PointedPrimeField
-PointedPrimeField(n:PositiveInteger):Cat==Dog where
- Cat == FiniteFieldCategory with
- foo:PositiveInteger->PrimeField(n)
- Dog == PrimeField(n) add
- foo(k)==k::Integer::PrimeField(n)
+ Takes two parameters and ignores the second. Usually the second
+ parameter is a \TeX/\LaTeX version of the first. By redefining this
+ command one can produce a more beautiful version of the page using
+ \TeX/\LaTeX. See also {\tt texht}.
-After compiling, define in the interpreter
+\item {\tt ifcond}
+\item {\tt indent}
-g(n,k)==foo(k)$PPF(n)
+ Sets the indentation level to n spaces, where n is the first
+ parameter.
-and it works (in Axiom)! (Do not declare the types for g because n is not
-defined).
+\item {\tt indentrel}
-But I have trouble with path in windows:
- Processing PointedPrimeField for Browser database:
---->-->PointedPrimeField((foo ((PrimeField n) (PositiveInteger)))): Not
document
-ed!!!!
---->-->PointedPrimeField(constructor): Not documented!!!!
---->-->PointedPrimeField(): Missing Description
-h:/dostools/rm.exe: j:/program: No such file or directory
-h:/dostools/rm.exe:
j:/progra~1/axiom/mnt/windows/lib/files/axiom/mnt/windows/li
-b/ppf.nrlib: No such file or directory
+ Adds the first parameter to the current indentation level. Negative
+ values are allowed.
- >> System error:
- Cannot rename the file #P"j:/Program Files/axiom/mnt/windows/lib/PPF.erlib"
t
-o #P"j:/Program Files/axiom/mnt/windows/lib/PPF.NRLIB".
+\item {\tt index}
+\item {\tt input}
+\item {\tt inputbitmap}
+\item {\tt inputbox}
+\item {\tt inputimage}
+\item {\tt inputstring}
+\item {\tt item}
-protected-symbol-warn called with (NIL)
+ Starts a new entry in an {\tt items} or {\tt menu} environment.
-But that is just because "Program Files" need be in quotes?
+\item {\tt label}
+\item {\tt labelSpace}
+\item {\tt lanb}
+\item {\tt lispcommand}
+\item {\tt lispdownlink}
+\item {\tt lispmemolink}
+\item {\tt lispwindowlink}
+\item {\tt ll}
+\item {\tt localinfo}
-\end{verbatim}
-\section{email 15}
-\begin{verbatim}
-Foo: with { g: (n: PositiveInteger, k: PositiveInteger) -> PrimeField(n) } ==
add {
-g(n: PositiveInteger, k: PositiveInteger ): PrimeField(n) ==
-k::Integer::PrimeField(n) }
-Ok, I will work with this example. Yes, it is better.
+ Hook for including a local menu item on the rootpage.
+\item {\tt mapsto}
+\item {\tt mathOrSpad}
+\item {\tt memolink}
+\item {\tt menudownlink}
+\item {\tt menuitemstyle}
+\item {\tt menulink}
-Well, I haven't checked whether it should really work, but
-shouldn't be
+ An alias for {\tt menudownlink}, both of which are frequently used.
+\item {\tt menulispcommand}
+\item {\tt menulispdownlink}
+\item {\tt menulispmemolink}
+\item {\tt menulispwindowlink}
+\item {\tt menumemolink}
+\item {\tt menuunixcommand}
+\item {\tt menuunixlink}
+\item {\tt menuunixwindow}
+\item {\tt menuwindowlink}
+\item {\tt menuxmpref}
+\item {\tt naglib}
-Foo: with {
- g: (n: PositiveInteger, k: PositiveInteger) ->
- (P: PrimeFieldCategory, x: P)
-} == add {
- g(n: PositiveInteger, k: PositiveInteger ):
- (P: PrimeFieldCategory, x:P) == {
- (PrimeField(n), k::Integer::PrimeField(n)
- }
-}
+ Produces the string {\tt NAG Foundation Library}.
+\item {\tt newcommand}
-be even better? The above code will not compile in Aldor, since it does not
have PositiveInteger. And maybe it will even not compile with appropriate
substitutions since the compiler cannot handle such a construction. I am,
however, very much against the Any type. It is like building a strongly typed
language and than trying to forget about types. For the interpreter it maybe
OK, but not for the compiler.
+ Defines new commands as in \TeX/\LaTeX.
-Programming in Axiom should mean writing programs for the compiler. I would
say that programming in the interpreter is just writing short scripts but not
real programs.
+\item {\tt newline}
-See also
-http://www.aldor.org/docs/HTML/chap23.html#10\end{verbatim}
-\section{email 16}
-\begin{verbatim}
-On Wednesday, January 12, 2005 8:30 AM you wrote:
-> Bill Page wrote:
-> >
-> > I don't really understand when the use of parameterized
-> > return types on functions would be useful. What information
-> > is being returned as part of the type of the result that is
-> > not already known because of it's value?
->
-> The above is an example. Perhaps, more convincing:
->
-> Foo: with { g: (n: PositiveInteger, k: PositiveInteger) ->
-> PrimeField(n) } == add {
-> g(n: PositiveInteger, k: PositiveInteger ): PrimeField(n) ==
-> k::Integer::PrimeField(n) }
->
+ Inserts a linebreak.
-Ok, I will work with this example. Yes, it is better.
-
-> Another example is Marcus Better's problem, more examples
-> are in expr2ups.spad, where Any is used a lot.
+\item {\tt newpage}
-Ok.
+ Does nothing but is used in the \TeX part of {\tt texht} and
+ probably needed to make the parser happy.
-> The type tells you in what domain to interpret the value.
-> But sometimes, the type will have to depend on a parameter
-> of the function, as above.
+\item {\tt noOutputXtc}
-That is still now clear to me, at least when it is possible
-to use a Union.
+ Alias for {\tt xtc}.
->
-> > As I see it the concept does considerable damage to the
-> > notion of the 'domain' of a function. How should we
-> > interpret the expressioin `PrimeField(n)' when n is
-> > unknown? Does it represent the Union over all values n?
-> > We can no longer write the signature of a function in
-> > the simple form:
-> >
-> > f: PositiveInteger -> PrimeField
->
-> Yes you can: Aldor does it. The signature is
->
-> f: (n: PositiveInteger) -> PrimeField n
->
+\item {\tt noindent}
+\item {\tt nonLibAxiomType}
+\item {\tt nullXtc}
-That does not look like a *signature* to me. What is the
-value of n? If you can't tell me, then how can I interpret
-`PrimeField n'? A signature should specify the domains of
-the function, but `PrimeField n' is not a domain until `n'
-is replaced with some PositiveInteger. The only interpretation
-of `PrimeField n' as a domain that I can think of would be
-to claim that it represents some kind of Union over the
-primes.
+ Alias for {\tt xtc}.
- Union(PrimeField n for n=1.. | prime? n)
+\item {\tt optArg}
+\item {\tt outdent}
+\item {\tt pageref}
+\item {\tt pastebutton}
+\item {\tt pp}
-But of course we can't write it quite this nicely right now
-in Axiom...
+ Produces a {\tt newline}. To be used instead of {\tt par}. Only used
+ in {\tt \$AXIOM/src/hyper/pages/rootpage.ht} and {\tt
+ \$AXIOM/src/hyper/pages/util.ht}. Otherwise not used or commented
+ out.
-This is similar to Axiom's insistence that
+\item {\tt pred}
+\item {\tt psXtc}
- A:Integer
+ Takes three parameters, ignores the third and feeds the first two to
+ {\tt xtc}.
-can not be used in the expression
+\item {\tt pspadfun}
+\item {\tt pspadtype}
+\item {\tt quad}
+\item {\tt radiobox}
+\item {\tt radioboxes}
+\item {\tt ref}
+\item {\tt returnbutton}
+\item {\tt rm}
+\item {\tt searchwindow}
+\item {\tt sf}
+\item {\tt showBlurb}
+\item {\tt small}
+\item {\tt smath}
+\item {\tt space}
+\item {\tt spad}
+\item {\tt spadFileExt}
+\item {\tt spadSyntax}
+\item {\tt spadatt}
+\item {\tt spadcmd}
+\item {\tt spadcommand}
+\item {\tt spadfun}
+\item {\tt spadfunFrom}
+\item {\tt spadfunFromX}
+\item {\tt spadfunX}
+\item {\tt spadglos}
+\item {\tt spadgloss}
+\item {\tt spadglossSee}
+\item {\tt spadignore}
+\item {\tt spadkey}
+\item {\tt spadop}
+\item {\tt spadopFrom}
+\item {\tt spadpaste}
+\item {\tt spadsig}
+\item {\tt spadsys}
+\item {\tt spadtype}
+\item {\tt special}
+\item {\tt stringvalue}
+\item {\tt subscriptIt}
+\item {\tt subscriptText}
+\item {\tt syscmdindex}
+\item {\tt tab}
+\item {\tt table}
+\item {\tt texht}
- A+1
+ The same as {\tt httex} but with the meaning of the parameters
+ swapped.
-until A is assigned a value. I this case I think it should
-be ok to say that if A has no assigned value then it
-represents the domain
+\item {\tt threedim}
- {+/-n for n=0..}
-
-> > Can you explain again why you don't find the usual
-> > Axiom solution to this situation acceptible? I.e. the
-> > use of the `Any' domain:
-> >
-> > f:PositiveInteger->Any
-> > f(n) == n::PrimeField(n)
->
-> Because you cannot use it in compiled code and because you
-> are using all of the type information, which is the main
-> point of Axiom.
+ Abbreviation for {\tt three-dimensional}.
-But as you said, `Any' is used extensively in expr2ups.spad.
+\item {\tt twodim}
-> Of course, the example you just gave doesn't
-> make any sense, the result is always zero, but given the
-> function
->
-> Bar: with { h: (n: PositiveInteger, k: PositiveInteger) -> Any }
-> == add { g(n: PositiveInteger, k: PositiveInteger ): Any ==
-> k::Any }
->
-> you cannot use this function in compiled code anymore. The
-> interpreter can deal with it, not the compiler.
+ Abbreviation for {\tt two-dimensional}.
-I would write it something like this:
+\item {\tt unixcommand}
+\item {\tt unixlink}
+\item {\tt upbutton}
+\item {\tt userfun}
+\item {\tt vertline}
+\item {\tt void}
-(2) -> h:(PositiveInteger,PositiveInteger)->Union( _
-PrimeField(2),PrimeField(3),PrimeField(5),PrimeField(7))
- Type: Void
-(3) -> h(n,k)==k::PrimeField(n)
- Type: Void
-(4) -> x:=h(7,2)
+ Abbreviation for {\tt the unique value of \bs spadtype{Void}}.
- (4) 2
- Type: Union(PrimeField 7,...)
-(5) -> trace x
+\item {\tt vspace}
+\item {\tt windowid}
+\item {\tt windowlink}
+\item {\tt xdefault}
+\item {\tt xtc}
- (5) 2
- Type: PrimeField 7
->
-> Look at Marcus code for a really convincing example: He wants
-> to construct recursively an algebraic extension of a ring,
-> adding elements one at the time. At the end of the process
-> he wants to return an element of the final ring. It is tricky
-> to do this in Axiom currently.
+ Is defined through
+\begin{verbatim}
+\newcommand{\xtc}[2]{#1 #2}
+\end{verbatim}
+ which means that it takes two parameters appends them. Looks silly
+ and probably is.
-I will take a closer look at the emails from Marcus.
+\end{itemize}
->
-> Note, for example, if you have a signature
->
-> f: Integer -> Any
->
-> but really, f returns a SimpleAlgebraicExtension of some
-> ring, you cannot do any calculations with the result in
-> compiled code anymore, unless you know *exactly* the defining
-> polynomial of the ring.
+\subsection{The Patch/Paste Mechanism}
+\label{sec:ThePatchPasteMechanism}
-I agree that Any throws away too much information, except
-in the interpreter where it tries to do a better job. But
-I think even there Any is (usually) not a good choice for
-the domain.
-
->
-> So one way out -- in this specific case -- would be to
-> return a record containing the result of type Any and
-> the defining polynomial. I hope you admit that this is
-> ugly.
-I agree that that is ugly. Using an explicit "streaming Union"
-(iterator) domain would be my (future) choice. Unfortunately
-for now:
+\subsection{Databases}
+\label{sec:HyperDocDatabases}
-(6) -> Union(PrimeField(i) for i in 1..10)
- Local variable or parameter used in type
- We will attempt to interpret the code.
+Axiom keeps one or several database files around to speed up finding a
+page (or a patch/paste). To add a file to the database one can use
+\axiomprog{htadd}.
- Category, domain or package constructor COLLECT is not available.
-(6) -> Union(PrimeField(i) for i in 1..)
- Loading C:/Program Files/axiom/mnt/windows/algebra/UNISEG.o for
- domain UniversalSegment
- Loading C:/Program Files/axiom/mnt/windows/algebra/INCRMAPS.o for
- package IncrementingMaps
- Loading C:/Program Files/axiom/mnt/windows/algebra/ITUPLE.o for
- domain InfiniteTuple
- Loading C:/Program Files/axiom/mnt/windows/algebra/STREAM.o for
- domain Stream
- Local variable or parameter used in type
- We will attempt to interpret the code.
- Interpret-Code mode is not supported for stream bodies.
-(6) ->
+\subsubsection{The HyperDoc Database Format}
+\label{sec:TheHyperDocDatabaseFormat}
-\end{verbatim}
-\section{email 17}
+The \hyperdoc{} database file(s) consist of several sections, each of
+which is started by a line like the following:
\begin{verbatim}
- > > #include "axiom"
- > >
- > > Test: with { f: (n: PositiveInteger) -> PrimeField(n) }
- > > == add { f(n: PositiveInteger): PrimeField(n) ==
- > > 10::Integer::PrimeField(n) }
- > >
- > > Note that such a construction -- the resulting domain depending on the
- > > function parameter -- is currently illegal in Axiom. In Aldor it is fine.
- >
- > I don't really understand when the use of parameterized return types on
- > functions would be useful. What information is being returned as part of the
- > type of the result that is not already known because of it's value?
+ BBTREE.ht 1104291828
+\end{verbatim}
+It starts with a tab character and contains a filename and a
+timestamp, which is taken from the {\tt st\_mtime} field of the {\tt
+ struct stat} returned by {\tt stat}. This timestamp is used to check
+wether the database is current or not. % TODO kai: How does this work
+ % precisely? Who's checking and when?
-The above is an example. Perhaps, more convincing:
+The following lines are the records for the current file and consist
+of the following fields separated by spaces: type, name, offset of the
+definition in characters and the linenumber where the definition
+starts.
-Foo: with { g: (n: PositiveInteger, k: PositiveInteger) -> PrimeField(n) }
- == add { g(n: PositiveInteger, k: PositiveInteger ): PrimeField(n) ==
- k::Integer::PrimeField(n) }
-
-Another example is Marcus Better's problem, more examples are in
-expr2ups.spad, where Any is used a lot. The type tells you in what domain to
-interpret the value. But sometimes, the type will have to depend on a parameter
-of the function, as above.
+The type field is always one of {\tt \\newcommand}, {\tt \\page} and {\tt
+ \\patch}.
- > As I see it the concept does considerable damage to the notion of the
- > 'domain' of a function. How should we interpret the expressioin
- > `PrimeField(n)' when n is unknown? Does it represent the Union over all
- > values n? We can no longer write the signature of a function in the simple
- > form:
- >
- > f: PositiveInteger -> PrimeField
+\begin{verbatim}
+\newcommand BalancedBinaryTreeXmpTitle 140 3
+\newcommand BalancedBinaryTreeXmpNumber 201 4
+\page BalancedBinaryTreeXmpPage 322 7
+\end{verbatim}
-Yes you can: Aldor does it. The signature is
- f: (n: PositiveInteger) -> PrimeField n
+\chapter{THINGS TO BE INTEGRATED}
- > Can you explain again why you don't find the usual Axiom solution to this
- > situation acceptible? I.e. the use of the `Any' domain:
- >
- > f:PositiveInteger->Any
- > f(n) == n::PrimeField(n)
-Because you cannot use it in compiled code and because you are using all of the
-type information, which is the main point of Axiom. Of course, the example you
-just gave doesn't make any sense, the result is always zero, but given the
-function
+\section{Building/Internals}
-Bar: with { h: (n: PositiveInteger, k: PositiveInteger) -> Any }
- == add { g(n: PositiveInteger, k: PositiveInteger ): Any ==
- k::Any }
+\subsection{email 5}
+\begin{verbatim}
+How I Built Axiom on Windows
-you cannot use this function in compiled code anymore. The interpreter can deal
-with it, not the compiler.
+ I installed a completely new MinGW/MSYS configuration from the
+'current' file list at:
-Look at Marcus code for a really convincing example: He wants to construct
-recursively an algebraic extension of a ring, adding elements one at the
-time. At the end of the process he wants to return an element of the final
-ring. It is tricky to do this in Axiom currently.
+http://www.mingw.org/download.shtml#hdr2
-Note, for example, if you have a signature
+In the following order:
- f: Integer -> Any
+1 MinGW-3.1.0-1.exe
-but really, f returns a SimpleAlgebraicExtension of some ring, you cannot do
-any calculations with the result in compiled code anymore, unless you know
-*exactly* the defining polynomial of the ring.
+ http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download
-So one way out -- in this specific case -- would be to return a record
-containing the result of type Any and the defining polynomial. I hope you admit
-that this is ugly.\end{verbatim}
-\section{email 18}
-\begin{verbatim}
-I have been thinking about your example code.
+2 MSYS-1.0.10.exe
-On Tuesday, January 11, 2005 9:44 AM you wrote:
-> ...
-> I just tried another example, which is in fact the reason
-> why I would love to have Aldor working. I did not expect
-> it to work, and it does not, but it works *almost*. The
-> code is as follows:
->
-> #include "axiom"
->
-> Test: with { f: (n: PositiveInteger) -> PrimeField(n) }
-> == add { f(n: PositiveInteger): PrimeField(n) ==
-> 10::Integer::PrimeField(n) }
->
-> Note that such a construction -- the resulting domain
-> depending on the function parameter -- is currently
-> illegal in Axiom. In Aldor it is fine.
+ http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download
-I don't really understand when the use of parameterized
-return types on functions would be useful. What information
-is being returned as part of the type of the result that
-is not already known because of it's value?
+3 msysDTK-1.0.1.exe
-As I see it the concept does considerable damage to the
-notion of the 'domain' of a function. How should we interpret
-the expressioin `PrimeField(n)' when n is unknown? Does it
-represent the Union over all values n? We can no longer
-write the signature of a function in the simple form:
+ http://prdownloads.sf.net/mingw/msysDTK-1.0.1.exe?download
- f: PositiveInteger -> PrimeField
+4 Then untarred the following:
+
+ cd /mingw; tar xzvf /home/bpage/...
-Can you explain again why you don't find the usual Axiom
-solution to this situation acceptible? I.e. the use of
-the `Any' domain:
+ gcc-core-3.4.2-20040916-1.tar.gz
+
+ http://prdownloads.sf.net/mingw/gcc-core-3.4.2-20040916-1.tar.gz?download
- f:PositiveInteger->Any
- f(n) == n::PrimeField(n)
+5 binutils-2.15.91-20040904-1.tar.gz
+
+ http://prdownloads.sf.net/mingw/binutils-2.15.91-20040904-1.tar.gz?download
-Perhaps in some cases the use of a Union might even be
-better:
+6 w32api-3.1.tar.gz
- f:PositiveInteger->Union(PrimeField(2),PrimeField(3),
- PrimeField(5), ...)
- f(n) == n::PrimeField(n)
+ http://prdownloads.sf.net/mingw/w32api-3.1.tar.gz?download
-The union allows a 'case' construction like this:
+7 mingw-runtime-3.5.tar.gz
- f(3) case PrimeField(3)
+ http://prdownloads.sf.net/mingw/mingw-runtime-3.5.tar.gz?download
-In fact this sort of thing works in Axiom:
+8 You will also need tla for windows from
-(1) -> f:PositiveInteger->Union(PrimeField(2),PrimeField(3), _
- PrimeField(5),PrimeField(7),"Failed")
- f(n) == ( prime? n and n<=7 => n::PrimeField(n); "Failed")
+ http://download.sipsolutions.de/tla-setup.exe
- Function declaration f : PositiveInteger -> Union(PrimeField 2,
- PrimeField 3,PrimeField 5,PrimeField 7,Failed) has been added to
- workspace.
- Type: Void
-(2) -> f(2)
- Cannot compile conversion for types involving local variables. In
- particular, could not compile the expression involving ::
- PrimeField #1
- AXIOM will attempt to step through and interpret the code.
- Compiling function f with type PositiveInteger -> Union(PrimeField 2
- ,PrimeField 3,PrimeField 5,PrimeField 7,Failed)
+9 and the windows LaTeX packaged called MikTex
- (2) 0
- Type: Union(PrimeField 2,...)
-(3) -> f(3)
+ http://www.miktex.org/setup.html
- (3) 0
- Type: Union(PrimeField 3,...)
-(4) -> f(4)
+ The "Small MiKTeX" package is sufficient if your windows box is
+ connected to the Internet. Or if you want you can install the
+ complete system.
- (4) Failed
- Type: Union(Failed,...)
-(5) -> f(5)
+10 download the axiom--windows--1 branch
- (5) 0
- Type: Union(PrimeField 5,...)
+ See deteails instructions at ArchUsage
-(6) -> x:=f(5)
+ 1 tla my-id "First Last <address@hidden>"
- (6) 0
- Type: Union(PrimeField 5,...)
+ 2 tla register-archive address@hidden
+http://axiom-developer.org/archive/axiom
-(7) -> x case PrimeField(5)
+ 3 tla my-default-archive address@hidden
- (7) true
- Type: Boolean
-(8) -> x case PrimeField(3)
+ 4 tla get axiom--windows--1 axiom--windows--1
- (8) false
- Type: Boolean
-etc.\end{verbatim}
-\section{email 19}
-\begin{verbatim}
-Peter Broadbery writes:
- > On Tue, 2005-01-11 at 14:30 +0100, Martin Rubey wrote:
- > > Dear Peter,
- > >
- > > this is just great stuff -- nearly... I had to try it out right away, but
I
- > > experienced two problems.
- > >
- > > the minor one is, that )co inside axiom still does not work:
- > >
- > > (1) ->
- > > (1) -> )co test.as
- > > Compiling AXIOM source code from file
- > > /home/rubey/martin/Axiom/test.as using AXIOM-XL compiler and
- > > options
- > > -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y
- > > $AXIOM/algebra
- > > Use the system command )set compiler args to change these
- > > options.
- > >
- > > >> System error:
- > > NIL is not of type STRING.
- >
- >
- > ln -s $ALDORROOT $AXIOM/compiler may help here. fixing i-syscmd.boot to
- > produce a nice error would be nice, I guess.
+ Or see ArchUsage to use 'sftp://' protocol if you intend to submit changes.
-I tried that, but it won't work. Tim, is there a way to trace what's happening?
+11 configure and make
-Note that both $ALDORROOT and $AXIOM were set correctly. In other words, the
-link above produced a directory "compiler" in "axiom/mnt/linux", containing the
-following directories of Aldor: bin/ doc/ include/ lib/ src/ tests/
+ cd axiom--windows--1
- > The .as file isn't in CVS (the file is compiled - don't be fooled by the
- > readable coding style)
+ ./configure -- Cut-and-paste environmnet variables to avoid typing errors
-Sorry, my mistake. Only lsp files. By the way, there i *lots* of stuff in the
-directories under /lsp/ccl/src, some look like they could be really useful...
+ make -- the build takes between 3 to 6 hours on 2.4 GHz Windows XP
-Tim: could you rename them to .pamphlet and correct the \usepackage line in
-each one of them? Thanks!
-
- > > (1) -> fact(5)$Test
- > >
- > > (1) 120
- > > Type:
- > > PositiveInteger
- > > (2) -> fact(4)$Test
- > >
- > > >> System error:
- > > #<vector 08cf4150> is not of type LIST.
- > >
- >
- > Fixed by the patch I send earlier (I hope)...
-
-Yes indeed! (I found that there was only one line you had to comment out?)
-
- > The significant bit is removing an unbound variable from as.boot, the
- > rest is to fix the )co command (obviously not bullet proof), and the .ap
- > file generation.
- >
- > In terms of aldor internal knowledge, you don't need that much, the hard
- > work is on the axiom side. The trick is to load all the aldor runtime
- > env interpreted and see what breaks (this includes daase.lisp, as.clisp
- > & interop.clisp, plus the aldor .lsp files). This stuff used to vaguely
- > work, so putting it back in shape can't be too bad.
-
-In another mail, you wrote:
-
- > As long as you don't use the sig. from the interpreter, you will be ok
- > (which misses the point,, I know). As far as fixing the error, not really,
- > I don't know the axiom interpreter that well. Finding how & where the type
- > is substituted would be a good start [There must be someone who does...]
-
-Who could this be? It would be just wonderful to get this working!
-
-Thanks a million times,
\end{verbatim}
-\section{email 20}
+\subsection{email 6}
\begin{verbatim}
-On Tue, 2005-01-11 at 14:30 +0100, Martin Rubey wrote:
-> Dear Peter,
->
-> this is just great stuff -- nearly... I had to try it out right away, but I
-> experienced two problems.
->
-> the minor one is, that )co inside axiom still does not work:
->
-> (1) ->
-> (1) -> )co test.as
-> Compiling AXIOM source code from file
-> /home/rubey/martin/Axiom/test.as using AXIOM-XL compiler and
-> options
-> -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra
-> Use the system command )set compiler args to change these
-> options.
->
-> >> System error:
-> NIL is not of type STRING.
-
-
-ln -s $ALDORROOT $AXIOM/compiler may help here. fixing i-syscmd.boot to
-produce a nice error would be nice, I guess.
+What is MinGW?
+ MinGW ("Minimalistic GNU for Windows") refers to a set of runtime headers,
+used in building a compiler system based on the GNU GCC and binutils projects.
+It compiles and links code to be run on Win32 platforms... providing C, C++
and
+Fortran compilers plus other related tools. If you see references to "mingw32"
+instead of "MinGW", they are referring to the same compiler system. The
+project's name changed from mingw32 to MinGW is to prevent the implication
that
+MinGW will only works on 32 bit systems (as 64 and higher bit machines become
+more common, MinGW will evolve to work with them). MinGW uses the Microsoft
+runtime libraries, distributed with the Windows operating system. Unlike other
+ports of GCC to Windows, the runtime libraries are not distributed using Gnu's
+General Public License (GPL). You, therefore, do not have to distribute your
+source code with your programs unless, of course, you use a GPL library in
your
+programs.
-> (1) ->
->
-> Never mind.
->
-> Unfortunately, there is a more severe issue. I put the following simple
domain
-> in a file "test.as" and compiled it using
->
-> aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom test.as
->
-> without any problem. There is only the warning
->
-> #1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
->
-> but I suspect that this is of no importance.
+What is MSYS?
-Yep.
+ MSYS or Minimal SYStem is a POSIX and Bourne shell environment use with
+MinGW. It provides a hand picked set of tools to allow a typical configuration
+script with Bourne syntax to execute. This allows most of the GNU packages to
+create a Makefile just from executing the typical configure script which can
+then be used to build the package using the native MinGW version of GCC.
+The POSIX layer used by MSYS is a fork of the 1.3.3 version of Cygwin . Cygwin
+is a full POSIX layer and UNIX-like environment for Win32 providing both
server
+and client utilites.
+\end{verbatim}
+\subsection{email 7}
+\begin{verbatim}
+The build sequence should be:
->
->
->
-------------------------------------------------------------------------------
-> #include "axiom.as"
->
-> Test: with { fact: PositiveInteger -> PositiveInteger }
-> == add { fact(n: PositiveInteger): PositiveInteger ==
-> { n <= 1 => 1;
-> res: PositiveInteger := 1;
-> while n > 1 repeat {
-> res := res * n;
-> n := n-1; }
-> res } }
->
-------------------------------------------------------------------------------
->
-> After this I start axiom and load runtime and axextend. By the way axextend
-> *is* in the distribution, it's only a little hidden... There is even more
-> obscure stuff in theis directory, maybe it's of use to you!
->
+obj/linux/bin/lisp ... contains the socket extensions
+obj/linux/bin/bootsys ... contains the boot -> lisp compiler
+ used to compile the interp/*.boot files
+obj/linux/bin/depsys ... contains macros used by axiom
+ used for compiling the intermediate lisp files
+obj/linux/bin/interpsys ... contains the final image
+ used to compile the algebra
+obj/linux/bin/AXIOMsys contains the final image
+ a clean copy for the end user
-The .as file isn't in CVS (the file is compiled - don't be fooled by the
-readable coding style)
-> (1) -> )sh Test
-> Test is a domain constructor
-> Abbreviation for Test is TEST
-> This constructor is exposed in this frame.
-> Issue )edit test.as to see algebra source code for TEST
->
-> ------------------------------- Operations --------------------------------
-> fact : PositiveInteger -> PositiveInteger
->
-> (1) -> fact(5)$Test
->
-> (1) 120
-> Type: PositiveInteger
-> (2) -> fact(4)$Test
->
-> >> System error:
-> #<vector 08cf4150> is not of type LIST.
->
+I've attached the interesting part of a console log. At this point
+the Axiom build is making the transition from building the BOOTSTRAP
+algebra to building the non-BOOTSTRAP algebra.
-Fixed by the patch I send earlier (I hope)...
+Notice that the BOOTSTRAP algebra is just lisp code. This code is
+compiled in a DEPSYS image so that macros are properly expanded.
+However it is clear that the BOOTSTRAP lisp code was not compiled by
+the "new" compiler.
+Next we see the transition to compiling the non-BOOTSTRAP algebra.
+This is done in the interpsys image. It is also done in an image
+that has access to only the BOOTSTRAP algebra code. Thus the
+new compiler might not have all of the algebra-defined replacements
+available at compile time. Notice the autoload files that contain
+the optimizations.
-> By the way, could you explain what your patches are doing? It's just a
mystery
-> to me! I suspect that one needs some knowledge of Aldor internals?
+A second or third round of compiles will expose the algebra-based
+optimizations and these will be compiled into the code. Since these
+are only optimizations the final results should not be affected.
-The significant bit is removing an unbound variable from as.boot, the
-rest is to fix the )co command (obviously not bullet proof), and the .ap
-file generation.
+Also note that the BOOTSTRAP algebra is recompiled as the last step
+of building the algebra from scratch so that it can use the circular
+definitions.
-In terms of aldor internal knowledge, you don't need that much, the hard
-work is on the axiom side. The trick is to load all the aldor runtime
-env interpreted and see what breaks (this includes daase.lisp, as.clisp
-& interop.clisp, plus the aldor .lsp files). This stuff used to vaguely
-work, so putting it back in shape can't be too bad. \end{verbatim}
-\section{email 21}
-\begin{verbatim}
-I just tried another example, which is in fact the reason why I would love to
-have Aldor working. I did not expect it to work, and it does not, but it works
-*almost*. The code is as follows:
+==========================================================================
+==== running DEPSYS image ===============================================
+==========================================================================
-#include "axiom"
+BOOT>0 making /home/arch/axiom--hyperdoc--1--base-0/int/algebra/VECTOR.lsp
from
+/home/arch/axiom--hyperdoc--1--base-0/src/algebra/vector.spad.pamphlet
+0 making /home/arch/axiom--hyperdoc--1--base-0/int/algebra/VECTOR.o from
+/home/arch/axiom--hyperdoc--1--base-0/int/algebra/VECTOR.lsp
-Test: with { f: (n: PositiveInteger) -> PrimeField(n) }
- == add { f(n: PositiveInteger): PrimeField(n) ==
- 10::Integer::PrimeField(n) }
+>
+Compiling VECTOR.lsp.
+End of Pass 1.
+End of Pass 2.
+OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
+Finished compiling VECTOR.o.
+#p"VECTOR.o"
-Note that such a construction -- the resulting domain depending on the function
-parameter -- is currently illegal in Axiom. In Aldor it is fine.
+BOOT>0 making /home/arch/axiom--hyperdoc--1--base-0/int/algebra/AHYP.spad from
+/home/arch/axiom--hyperdoc--1--base-0/src/algebra/trigcat.spad.pamphlet
-I compiled it with Aldor as usual, and then loaded it into Axiom. As signature
-I got the slightly unusual
+==========================================================================
+==== running AXIOMSYS image =============================================
+==========================================================================
-(1) -> )di op f
-There is one unexposed function called f :
- [1] PositiveInteger -> PrimeField n from Test
+0 making /home/arch/axiom--hyperdoc--1--base-0/int/algebra/AHYP.NRLIB from
+/home/arch/axiom--hyperdoc--1--base-0/int/algebra/AHYP.spad
+ AXIOM Computer Algebra System
+ Version of Friday November 19, 2004 at 16:36:16
+-----------------------------------------------------------------------------
+ Issue )copyright to view copyright notices.
+ Issue )summary for a summary of useful system commands.
+ Issue )quit to leave AXIOM and return to shell.
+-----------------------------------------------------------------------------
+
+ Using local database
+/home/arch/axiom--hyperdoc--1--base-0/src/share/algebra/compress.daase..
+Using local database
+/home/arch/axiom--hyperdoc--1--base-0/src/share/algebra/interp.daase..
+ Using local database
+/home/arch/axiom--hyperdoc--1--base-0/src/share/algebra/operation.daase..
+ Using local database
+/home/arch/axiom--hyperdoc--1--base-0/src/share/algebra/category.daase..
+ Using local database
+/home/arch/axiom--hyperdoc--1--base-0/src/share/algebra/browse.daase..
+(1) -> Loading
+/home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/apply.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/c-doc.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/c-util.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/profile.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/category.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/compiler.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/define.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/functor.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/info.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/iterator.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/modemap.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/nruncomp.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/package.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/htcheck.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/xruncomp.
+ Compiling AXIOM source code from file
+ /home/arch/axiom--hyperdoc--1--base-0/int/algebra/AHYP.spad using
+ old system compiler.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/parsing.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/bootlex.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/def.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/fnewmeta.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/metalex.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/metameta.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/parse.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/postpar.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/postprop.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/preparse.
+ AHYP abbreviates category ArcHyperbolicFunctionCategory
+------------------------------------------------------------------------
+ initializing NRLIB AHYP for ArcHyperbolicFunctionCategory
+ compiling into NRLIB AHYP
-and trying it out I obtained
+;;; *** |ArcHyperbolicFunctionCategory| REDEFINED
+Time: 0 SEC.
-(1) -> f(5)$Test
- Loading /home/rubey/axiom/mnt/linux/algebra/PF.o for domain
- PrimeField
- Loading /home/rubey/axiom/mnt/linux/algebra/IPF.o for domain
- InnerPrimeField
- Loading /home/rubey/axiom/mnt/linux/algebra/TABLE.o for domain Table
-
- Loading /home/rubey/axiom/mnt/linux/algebra/HASHTBL.o for domain
- HashTable
- Loading /home/rubey/axiom/mnt/linux/algebra/INTABL.o for domain
- InnerTable
- Loading /home/rubey/axiom/mnt/linux/algebra/ZMOD.o for domain
- IntegerMod
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/bc-matrix.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/bc-misc.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/bc-solve.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/bc-util.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/ht-util.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/htsetvar.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/ht-root.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-con.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-data.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/showimp.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-op1.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-op2.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-search.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-util.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/topics.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-prof.
+ Loading /home/arch/axiom--hyperdoc--1--base-0/mnt/linux/autoload/br-saturn.
+ finalizing NRLIB AHYP
+ Processing ArcHyperbolicFunctionCategory for Browser database:
+--------(acosh ($ $))---------
+--------(acoth ($ $))---------
+--------(acsch ($ $))---------
+--------(asech ($ $))---------
+--------(asinh ($ $))---------
+--------(atanh ($ $))---------
+--------constructor---------
+Compiling
/home/arch/axiom--hyperdoc--1--base-0/int/algebra/AHYP.NRLIB/code.lsp.
-
- >> System error:
- |n| is not of type NUMBER.
+
-protected-symbol-warn called with (NIL)
-which is roughly what I expected. However, to my great surprise, if you turn on
-the debugger (beforehand. You always have to start a fresh axiom because of the
-error I told you about in my previous message) with
-)lisp (setq |$monitorNewWorld| t)
+\end{verbatim}
-and thus trace
+\subsection{email 2}
+\begin{verbatim}
+>
+> > The list of prerequisites for running axiom is huge, and
+> > getting worse it seems!
+> ...
+> > So in the interest of having something people can download
+> > that is functional with a minimum of effort, I think axiom
+> > (and any help system or hyperdoc) should be decoupled from
+> > zope and zwiki. A download (think windoze users here) which
+> > included zope, zwiki, latex, ghostscript, python, PIL, gcl,
+> > gcc, *and* axiom, is too much, methinks.
+>
+> Heh - even I agree there. Perhaps it would be best to
+> acknowledge the reality that if one wants to take advantage
+> of all the vast possibilities of open source software, that's
+> going to be at odds with having the full power of the system
+> available on all platforms, particularly Windows, as a single
+> package. Surely power users who are willing and able to use
+> the full web-like setup, instead of just a TeXmacs or Mathematica
+> like document interface, would be willing to set it up or at
+> the very least boot a live Linux CD loaded with the full set
+> of Axiom tools and dependencies.
+>
-(1) -> f(1783)$Test
+Personally, although I have tried knoppix and some variants on
+several occasions I have always been a little disappointed
+and frustrated. The problem is that I live in linux about 1/2
+the time and windows the other 1/2 and when I boot one of these
+"live" things I feel like I am in neither. It's fun to play for
+an hour or so but then it goes in the desk draw with all the
+other things that once fascinated me but I haven't looked at
+for so long that they are now collecting dust. So I am quite
+sceptical about the utility of a "live" Axiom/Doyen CD except
+as a kind of conference "promotional gimmick".
-the final bit reads
+Let's put the list in the following order and fill it in a
+few more:
-protected-symbol-warn called with (NIL)..IntegerMod 1783 wants
- positiveRemainder : (%,%) -> % from Integer
----->Integer----> searching op table for:
- positiveRemainder : (%,%) -> % from Integer
-<----#<compiled-function |INT;positiveRemainder;3$;28|> Integer
-goget stuffing slot 47 of IntegerMod 1783
-<------#<compiled-function |INT;positiveRemainder;3$;28|> Integer
+ gcc
+ / | \
+ gcl latex python
+ / | | \
+ / noweb | zope
+ / / | | /
+ axiom ghostscript PIL zwiki
+ \ \ | /
+ \ LatexWiki
+ \ /
+ MathAction
-PrimeField n activating lazy slot 8: Integer
-PrimeField n activating lazy slot 9: IntegerPrimesPackage Integer
+Add your favourite text editor and browser and set it all up
+in Linux/Unix or Windows.
-..PrimeField n wants
- prime? : Integer -> Boolean from IntegerPrimesPackage Integer
----->IntegerPrimesPackage Integer----> searching op table for:
- prime? : Integer -> Boolean from IntegerPrimesPackage Integer
-<----#<compiled-function |PRIMES;prime?;IB;4|>(IntegerPrimesPackage,Integer)
-goget stuffing slot 10 of PrimeField n
-<------#<compiled-function |PRIMES;prime?;IB;4|>(IntegerPrimesPackage,Integer)
-
+There. Now that doesn't seem so large and complex does it?
+(: At least not if you compare it to the list of capabilities
+that this remarkable combination of entirely open source
+software provides... :) I am quite sure that this would all
+easily fit on one-side of a Cdrom, including documentation.
+And of course we can add as many more optional add-on packages
+as we want, such as Reduce, Aldor, Maxima, ... eventually all
+integrated with a common web interface.
-which clearly tells you, that the calculation is done alright, only the
-signature interferes with success.
+What this gives you a fully web-integrated, collaborative
+mathematical research and development, hyper-linked publishing
+environment right on your desktop, or even in your pocket (I run
+almost all of this on a Zaurus 5600). This is all easily doable
+right now for free. I would have given my left arm for something
+like this back when I was a student!
-Any ideas?\end{verbatim}
-\section{email 22}
+\end{verbatim}
+
+\subsection{email 4}
\begin{verbatim}
-this is just great stuff -- nearly... I had to try it out right away, but I
-experienced two problems.
+> > Next we see the transition to compiling the non-BOOTSTRAP algebra.
+> > This is done in the interpsys image. It is also done in an image
+> > that has access to only the BOOTSTRAP algebra code. Thus the
+> > new compiler might not have all of the algebra-defined replacements
+> > available at compile time. Notice the autoload files that contain
+> > the optimizations.
+> >
+>
+> What do you mean by "algebra-defined replacements". Where are
+> these replacements defined? How are they different than the
+> "optimizations" contained in the autoload files?
-the minor one is, that )co inside axiom still does not work:
+The BOOTSTRAP files contain lsp and spad code. The build steps
+for the initial BOOTSTRAP layer use "depsys" to compile the lisp
+code. So, in this case, we see VECTOR.lsp being compiled in the
+depsys image. VECTOR.lsp is the last algebra file that contains
+BOOTSTRAP code. So in this phase we see:
- AXIOM Computer Algebra System
- Version: Axiom 3.0 Beta (February 2005)
- Timestamp: Tuesday January 11, 2005 at 14:02:04
------------------------------------------------------------------------------
- Issue )copyright to view copyright notices.
- Issue )summary for a summary of useful system commands.
- Issue )quit to leave AXIOM and return to shell.
------------------------------------------------------------------------------
-
- Re-reading compress.daase Re-reading interp.daase
- Re-reading operation.daase
- Re-reading category.daase
- Re-reading browse.daase
-(1) ->
-(1) -> )co test.as
- Compiling AXIOM source code from file
- /home/rubey/martin/Axiom/test.as using AXIOM-XL compiler and
- options
--O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra
- Use the system command )set compiler args to change these
- options.
-
- >> System error:
- NIL is not of type STRING.
+VECTOR.lsp (BOOTSTRAP) -> VECTOR.o
-protected-symbol-warn called with (NIL)
-(1) -> )co test
- Compiling AXIOM source code from file
- /home/rubey/martin/Axiom/test.as using AXIOM-XL compiler and
- options
--O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra
- Use the system command )set compiler args to change these
- options.
-
- >> System error:
- NIL is not of type STRING.
+Once we leave the phase (shown in the printout) we start using
+an "interpsys" image to compile spad code. Much later in the console
+VECTOR.spad will be compiled and replaces the lisp. However the
+"interpsys" environment in VECTOR.spad differs significantly from
+the "depsys" environment that compiles VECTOR.lsp BOOSTRAP code.
+So we see
-protected-symbol-warn called with (NIL)
-(1) ->
+VECTOR.spad + SINT.NRLIB -> VECTOR.lsp -> VECTOR.o (replaced previous version)
-Never mind.
+Suppose VECTOR.spad used something from SINT.spad. When the
+VECTOR.lsp BOOTSTRAP file is compiled by depsys it contains
+(+ ... ...) and generates untyped and unoptimized code.
-Unfortunately, there is a more severe issue. I put the following simple domain
-in a file "test.as" and compiled it using
+Later when VECTOR.spad is compiled and SINT.o is available
+then the spad compiler will use the optimization information
+to generate (QSADD1 ... ...)
-aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom test.as
+> What do you mean by "expose". Why does this cause interpsys to
+> be re-built? That is necessary if code is going to be generated
+> based on new optimizations isn't it?
-without any problem. There is only the warning
+expose == make available
+Due to my lack of foresight in choosing the VECTOR.lsp BOOTSTRAP
+code I did not use the most highly optimized version. But in the
+algebra recompile of VECTOR.spad later in the build this gets
+corrected because the operations are made available (exposed) by
+previously compiled .spad code. So:
-#1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
+VECTOR.lsp (BOOTSTRAP) uses SINT.o
-but I suspect that this is of no importance.
+But the VECTOR.lsp has (+ ... ...) instead of (QSADD1 ... ...)
+because the rewriting of "+" to "QSADD1" is done by the spad
+compiler, not the GCL compiler and we are not yet in a position
+to use the spad compiler.
+Later when
--------------------------------------------------------------------------------
-#include "axiom.as"
+VECTOR.spad -> VECTOR.lsp -> VECTOR.o (replaced previous version)
-Test: with { fact: PositiveInteger -> PositiveInteger }
- == add { fact(n: PositiveInteger): PositiveInteger ==
- { n <= 1 => 1;
- res: PositiveInteger := 1;
- while n > 1 repeat {
- res := res * n;
- n := n-1; }
- res } }
--------------------------------------------------------------------------------
+the spad compiler was invoked and it gets a chance to change
+"+" to "QSADD1".
-After this I start axiom and load runtime and axextend. By the way axextend
-*is* in the distribution, it's only a little hidden... There is even more
-obscure stuff in theis directory, maybe it's of use to you!
+Because I grabbed the wrong version of .lsp file for BOOTSTRAP
+code you are able to see this difference. The work you and steve
+are doing is to find stable versions of the .lsp files.
- AXIOM Computer Algebra System
- Version: Axiom 3.0 Beta (February 2005)
- Timestamp: Tuesday January 11, 2005 at 14:02:04
------------------------------------------------------------------------------
- Issue )copyright to view copyright notices.
- Issue )summary for a summary of useful system commands.
- Issue )quit to leave AXIOM and return to shell.
------------------------------------------------------------------------------
-
- Re-reading compress.daase Re-reading interp.daase
- Re-reading operation.daase
- Re-reading category.daase
- Re-reading browse.daase
-(1) ->
-(1) -> )lisp (load "/home/rubey/aldor/linux/1.0.2/lib/runtime.lsp")
+> > Since these are only optimizations the final results should not
+> > be affected.
+> >
+>
+> But it could have an impact on overall performance, right?
-Value = T
-(1) -> )lisp (load
-"/home/rubey/axiom--main--1--patch-24/lsp/ccl/src/axbase/compiler/lib/axextend.lsp")
+Oh, clearly. (QSADD1 ... ...) is faster than (+ ... ...)
-Value = T
-(1) -> )lib test
- Reading /home/rubey/martin/Axiom/test.asy
- Loading /home/rubey/axiom/mnt/linux/autoload/bc-matrix.
- Loading /home/rubey/axiom/mnt/linux/autoload/bc-misc.
- Loading /home/rubey/axiom/mnt/linux/autoload/bc-solve.
- Loading /home/rubey/axiom/mnt/linux/autoload/bc-util.
- Loading /home/rubey/axiom/mnt/linux/autoload/ht-util.
- Loading /home/rubey/axiom/mnt/linux/autoload/htsetvar.
- Loading /home/rubey/axiom/mnt/linux/autoload/ht-root.
- Loading /home/rubey/axiom/mnt/linux/autoload/br-con.
- Loading /home/rubey/axiom/mnt/linux/autoload/br-data.
- Loading /home/rubey/axiom/mnt/linux/autoload/showimp.
- Loading /home/rubey/axiom/mnt/linux/autoload/br-op1.
- Loading /home/rubey/axiom/mnt/linux/autoload/br-op2.
- Loading /home/rubey/axiom/mnt/linux/autoload/br-search.
- Loading /home/rubey/axiom/mnt/linux/autoload/br-util.
- Loading /home/rubey/axiom/mnt/linux/autoload/topics.
- Loading /home/rubey/axiom/mnt/linux/autoload/br-prof.
- Loading /home/rubey/axiom/mnt/linux/autoload/br-saturn.
- Test is now explicitly exposed in frame frame0
- Test will be automatically loaded when needed from
- /home/rubey/martin/Axiom/test
-(1) -> )sh Test
- Test is a domain constructor
- Abbreviation for Test is TEST
- This constructor is exposed in this frame.
- Issue )edit test.as to see algebra source code for TEST
+Furthermore, there is another optimization step we could take
+during the build but we do not (yet). When the GCL compiler
+compiles VECTOR.lsp it generates VECTOR.fn. If you look in these
+.fn files you'll find exact type information for each function call.
-------------------------------- Operations --------------------------------
- fact : PositiveInteger -> PositiveInteger
+VECTOR.lsp -> VECTOR.o + VECTOR.fn (unoptimized, but type generated)
-(1) -> fact(5)$Test
+If this exact type information was available at compile time then
+the GCL compiler can lay down faster code. However there is a
+bootstrap problem here also since the GCL compiler has to compile
+the code one time in order to generate the .fn file.
- (1) 120
- Type: PositiveInteger
-(2) -> fact(4)$Test
-
- >> System error:
- #<vector 08cf4150> is not of type LIST.
+VECTOR.lsp + VECTOR.fn -> VECTOR.o (type optimized)
-protected-symbol-warn called with (NIL)
+So the full, proper procedure, which I have yet to do, would actually
+call the GCL compile once to generate the .fn file with exact type
+information for function calls, load the .fn file, and the recompile
+the lisp file. Since the second compile has exact type information
+the generated code will be (potentially much) shorter.
+For each lisp file do
+(
+ VECTOR.lsp -> VECTOR.o + VECTOR.fn (unoptimized, but type generated)
+ VECTOR.lsp + VECTOR.fn -> VECTOR.o (type optimized)
+)
-:-(
-I am already very very happy, but another patch and/or explanation would
-greatly improve this...
+> Still after reading the interp and algebra Makefiles again,
+> I do not see why interpsys is being rebuilt after I delete
+> all the *.NRLIB's and repeat the 'make'. I am still missing
+> something somewhere. Is there some "missing link" that still
+> connects the algebra/Makefile back to the inter/Makefile?
-By the way, could you explain what your patches are doing? It's just a mystery
-to me! I suspect that one needs some knowledge of Aldor internals?
+I have to think about this (I'm getting ready for work so I'll
+give it some "drive-time cycles") but I believe that the issue
+is related to using fresh databases. The databases are used
+during the algebra compiles to resolve algebra calls. However
+recompiling the algebra generates NRLIBs and, from these NRLIBs
+a fresh database is built thus:
-\end{verbatim}
-\section{email 23}
-\begin{verbatim}
-I've been playing with the aldor/axiom stuff a little, and the following
-patch may help get things going(I used to work on it, and thought it'd
-be fun to get it going again).
+DATABASES -> NRLIBs -> FRESH DATABASES
+
+This is yet a third bootstrap issue. There are more but not with
+the algebra files.
-There are further problems:
-- aldor "extend" does not work - it ought to, I think
-- The algebra defined in libaxiom.al is not current, and for it to be
-rebuilt various .as files need to be available to the build process
-(axextend.as and friends) - any reason why they're left out of the
-distribution?
-- exported attributes from aldor domains are explicitly killed off by
-this patch (it's probably easy to fix, just no time atm).
-- Only tested the most trivial domains I could find.
-Peter.
\end{verbatim}
-\section{email 24}
-\begin{verbatim}
-? Makefile
-? Makefile.dvi
-Index: as.boot.pamphlet
-===================================================================
-RCS file: /cvsroot/axiom/axiom/src/interp/as.boot.pamphlet,v
-retrieving revision 1.3
-diff -u -r1.3 as.boot.pamphlet
---- as.boot.pamphlet 24 May 2004 22:53:49 -0000 1.3
-+++ as.boot.pamphlet 8 Jan 2005 19:01:23 -0000
-@@ -389,7 +389,8 @@
- HPUT(ht,id,[entry,:HGET(ht,id)])
- opalist := [ [op,:REMDUP HGET(ht,op)] for op in HKEYS ht]
- --HPUT($opHash,con,[ancestorAlist,attributeAlist,:opalist])
-- HPUT($opHash,con,[ancestorAlist,attributeAlist,:opalist])
-+ --HPUT($opHash,con,[ancestorAlist,attributeAlist,:opalist])
-+ HPUT($opHash,con,[ancestorAlist,nil,:opalist])
-
- hackToRemoveAnd p ==
- ---remove this as soon as .asy files do not contain forms (And pred) forms
-Index: ax.boot.pamphlet
-===================================================================
-RCS file: /cvsroot/axiom/axiom/src/interp/ax.boot.pamphlet,v
-retrieving revision 1.3
-diff -u -r1.3 ax.boot.pamphlet
---- ax.boot.pamphlet 24 May 2004 22:53:49 -0000 1.3
-+++ ax.boot.pamphlet 8 Jan 2005 19:01:26 -0000
-@@ -80,11 +80,29 @@
- axForms :=
- [ ['Foreign, ['Declare, 'dummyDefault, 'Exit], 'Lisp], :axForms]
- axForms := APPEND(axDoLiterals(), axForms)
-- axForm := ['Sequence, ['Import, [], 'AxiomLib], :axForms]
-+ axForm := ['Sequence, ['Import, [], 'AxiomLib], ['Import, [], 'Boolean],
:axForms]
- st := MAKE_-OUTSTREAM(filename)
- PPRINT(axForm,st)
- CLOSE st
-
-+makeAxExportForm(filename, constructors) ==
-+ $defaultFlag : local := false
-+ $literals := []
-+ axForms :=
-+ [modemapToAx(modemap) for cname in constructors |
-+ (modemap:=GETDATABASE(cname,'CONSTRUCTORMODEMAP)) and
-+ (not cname in '(Tuple Exit Type)) and
-+ not isDefaultPackageName cname]
-+ if $baseForms then
-+ axForms := [:$baseForms, :axForms]
-+ if $defaultFlag then
-+ axForms :=
-+ [ ['Foreign, ['Declare, 'dummyDefault, 'Exit], 'Lisp], :axForms]
-+ axForms := APPEND(axDoLiterals(), axForms)
-+ axForm := ['Sequence, ['Import, [], 'AxiomLib], ['Import, [], 'Boolean],
:axForms]
-+ axForm
-+
-+
- stripType type ==
- $stripTypes =>
- categoryForm? type => 'Type
-Index: i-syscmd.boot.pamphlet
-===================================================================
-RCS file: /cvsroot/axiom/axiom/src/interp/i-syscmd.boot.pamphlet,v
-retrieving revision 1.4
-diff -u -r1.4 i-syscmd.boot.pamphlet
---- i-syscmd.boot.pamphlet 28 Dec 2004 07:42:45 -0000 1.4
-+++ i-syscmd.boot.pamphlet 8 Jan 2005 19:01:36 -0000
-@@ -642,7 +642,7 @@
- if ^beQuiet then sayKeyedMsg("S2IZ0038A",[namestring args, asharpArgs])
-
- command :=
-- STRCONC(TRUENAME(STRCONC(GETENV('"AXIOM"),'"/compiler/bin/")),"axiomxl
", asharpArgs, '" ", namestring args)
-+ STRCONC(STRCONC(GETENV('"AXIOM"),'"/compiler/bin/"),"axiomxl ",
asharpArgs, '" ", namestring args)
- rc := OBEY command
-
- if (rc = 0) and doCompileLisp then
-\end{verbatim}
-\section{email 25}
+\subsection{email 4}
\begin{verbatim}
-> It is not so clear to me why the build appears to succeed
-> even though these definitions are missing. In other languages
-> I would presume that this situation would be easily caught
-> as a missing file during `linking'. But here we have this
-> "domain vector" thing. Is there not some why that the
-> compilation could be made more robust by verifying the
-> domain vector at compile time?
+Yet one other opportunity for speed optimization is available at
+build time....
-Bill, there is no "linking" step in any sense of the word.
-This needs to be documented somewhere.
+Remember that every lisp file generates a .fn file:
-If we look at one of the random BOOTSTRAP files, say, CHAR we see:
+foo.lsp -> foo.o + foo.fn
-Character: OrderedFinite() with
- ord: % -> Integer
- ++ ord(c) provides an integral code corresponding to the
- ++ character c. It is always true that \spad{char ord c = c}.
- char: Integer -> %
- ++ char(i) provides a character corresponding to the integer
- ++ code i. It is always true that \spad{ord char i = i}.
- char: String -> %
- ++ char(s) provides a character from a string s of length one.
- space: () -> %
- ++ space() provides the blank character.
- quote: () -> %
- ++ quote() provides the string quote character, \spad{"}.
- escape: () -> %
- ++ escape() provides the escape character, \spad{_}, which
- ++ is used to allow quotes and other characters {\em within}
- ++ strings.
- upperCase: % -> %
- ++ upperCase(c) converts a lower case letter to the corresponding
- ++ upper case letter. If c is not a lower case letter, then
- ++ it is returned unchanged.
- lowerCase: % -> %
- ++ lowerCase(c) converts an upper case letter to the corresponding
- ++ lower case letter. If c is not an upper case letter, then
- ++ it is returned unchanged.
- digit?: % -> Boolean
- ++ digit?(c) tests if c is a digit character,
- ++ i.e. one of 0..9.
- hexDigit?: % -> Boolean
- ++ hexDigit?(c) tests if c is a hexadecimal numeral,
- ++ i.e. one of 0..9, a..f or A..F.
- alphabetic?: % -> Boolean
- ++ alphabetic?(c) tests if c is a letter,
- ++ i.e. one of a..z or A..Z.
- upperCase?: % -> Boolean
- ++ upperCase?(c) tests if c is an upper case letter,
- ++ i.e. one of A..Z.
- lowerCase?: % -> Boolean
- ++ lowerCase?(c) tests if c is an lower case letter,
- ++ i.e. one of a..z.
- alphanumeric?: % -> Boolean
- ++ alphanumeric?(c) tests if c is either a letter or number,
- ++ i.e. one of 0..9, a..z or A..Z.
+and that a second compile with the .fn file loaded is faster:
- == add
- Rep := SingleInteger -- 0..255
+foo.lsp + foo.fn -> faster foo.o
- CC ==> CharacterClass()
- import CC
+However if we look at the type information in the foo.fn file
+we find that it only contains type information for functions
+defined in foo.lsp. But suppose there are two lisp files with
+functions from one using functions from the other. The sub-optimal
+sequence is:
- --cl: Record(dig:CC,hex:CC,upp:CC,low:CC,alpha:CC,alnum:CC) :=
- -- [ digit(), hexDigit(),
- -- upperCase(), lowerCase(), alphabetic(), alphanumeric() ]
+foo.lsp -> foo.o + foo.fn
+foo.lsp + foo.fn -> faster foo.o
+
+bar.lsp -> bar.o + bar.fn
+bar.lsp + bar.fn -> faster bar.o
+
+The optimal sequence is:
+
+foo.lsp -> foo.o + foo.fn
+bar.lsp -> bar.o + bar.fn
+
+foo.lsp + (foo.fn + bar.fn) -> even faster foo.o
+bar.lsp + (foo.fn + bar.fn) -> even faster bar.o
+
+So, really what we should do is cache ALL of the .fn files from all of
+the compiles, batch them into a big file, and the completely rebuild
+the system with the batched .fn files loaded.
+
+I've started this process but have not yet completed it.
+See the file src/boot/boot-proclaims.lisp
+
+So there is a faster Axiom coming in the future but the build
+complexity will be even greater. And Camm, I believe, is doing
+even more with type propagation which will improve things more.
+
+
+\end{verbatim}
+
+\subsection{email 8}
+\begin{verbatim}
+MiKTeX is an up-to-date TeX implementation for the Windows operating system.
+
+TeX is a typesetting system written by Donald E. Knuth, who says that it is
+"intended for the creation of beautiful books - and especially for books that
+contain a lot of mathematics".
+
+MiKTeX offers a complete set of utilities, macro packages and fonts, e.g.,
+LaTeX, pdfTeX, ConTeXt, just to name a few.
+
+http://www.miktex.org
+\end{verbatim}
+\subsection{email 9}
+\begin{verbatim}
+> > Next we see the transition to compiling the non-BOOTSTRAP algebra.
+> > This is done in the interpsys image. It is also done in an image
+> > that has access to only the BOOTSTRAP algebra code. Thus the
+> > new compiler might not have all of the algebra-defined replacements
+> > available at compile time. Notice the autoload files that contain
+> > the optimizations.
+> >
+>
+> What do you mean by "algebra-defined replacements". Where are
+> these replacements defined? How are they different than the
+> "optimizations" contained in the autoload files?
+
+The BOOTSTRAP files contain lsp and spad code. The build steps
+for the initial BOOTSTRAP layer use "depsys" to compile the lisp
+code. So, in this case, we see VECTOR.lsp being compiled in the
+depsys image. VECTOR.lsp is the last algebra file that contains
+BOOTSTRAP code. So in this phase we see:
+
+VECTOR.lsp (BOOTSTRAP) -> VECTOR.o
+
+Once we leave the phase (shown in the printout) we start using
+an "interpsys" image to compile spad code. Much later in the console
+VECTOR.spad will be compiled and replaces the lisp. However the
+"interpsys" environment in VECTOR.spad differs significantly from
+the "depsys" environment that compiles VECTOR.lsp BOOSTRAP code.
+So we see
+
+VECTOR.spad + SINT.NRLIB -> VECTOR.lsp -> VECTOR.o (replaced previous version)
+
+Suppose VECTOR.spad used something from SINT.spad. When the
+VECTOR.lsp BOOTSTRAP file is compiled by depsys it contains
+(+ ... ...) and generates untyped and unoptimized code.
+
+Later when VECTOR.spad is compiled and SINT.o is available
+then the spad compiler will use the optimization information
+to generate (QSADD1 ... ...)
+
+> What do you mean by "expose". Why does this cause interpsys to
+> be re-built? That is necessary if code is going to be generated
+> based on new optimizations isn't it?
+
+expose == make available
+Due to my lack of foresight in choosing the VECTOR.lsp BOOTSTRAP
+code I did not use the most highly optimized version. But in the
+algebra recompile of VECTOR.spad later in the build this gets
+corrected because the operations are made available (exposed) by
+previously compiled .spad code. So:
+
+VECTOR.lsp (BOOTSTRAP) uses SINT.o
+
+But the VECTOR.lsp has (+ ... ...) instead of (QSADD1 ... ...)
+because the rewriting of "+" to "QSADD1" is done by the spad
+compiler, not the GCL compiler and we are not yet in a position
+to use the spad compiler.
+
+Later when
+
+VECTOR.spad -> VECTOR.lsp -> VECTOR.o (replaced previous version)
+
+the spad compiler was invoked and it gets a chance to change
+"+" to "QSADD1".
+
+Because I grabbed the wrong version of .lsp file for BOOTSTRAP
+code you are able to see this difference. The work you and steve
+are doing is to find stable versions of the .lsp files.
+
+> > Since these are only optimizations the final results should not
+> > be affected.
+> >
+>
+> But it could have an impact on overall performance, right?
+
+Oh, clearly. (QSADD1 ... ...) is faster than (+ ... ...)
+
+Furthermore, there is another optimization step we could take
+during the build but we do not (yet). When the GCL compiler
+compiles VECTOR.lsp it generates VECTOR.fn. If you look in these
+.fn files you'll find exact type information for each function call.
+
+VECTOR.lsp -> VECTOR.o + VECTOR.fn (unoptimized, but type generated)
+
+If this exact type information was available at compile time then
+the GCL compiler can lay down faster code. However there is a
+bootstrap problem here also since the GCL compiler has to compile
+the code one time in order to generate the .fn file.
+
+VECTOR.lsp + VECTOR.fn -> VECTOR.o (type optimized)
+
+So the full, proper procedure, which I have yet to do, would actually
+call the GCL compile once to generate the .fn file with exact type
+information for function calls, load the .fn file, and the recompile
+the lisp file. Since the second compile has exact type information
+the generated code will be (potentially much) shorter.
+
+For each lisp file do
+(
+ VECTOR.lsp -> VECTOR.o + VECTOR.fn (unoptimized, but type generated)
+ VECTOR.lsp + VECTOR.fn -> VECTOR.o (type optimized)
+)
+
+
+> Still after reading the interp and algebra Makefiles again,
+> I do not see why interpsys is being rebuilt after I delete
+> all the *.NRLIB's and repeat the 'make'. I am still missing
+> something somewhere. Is there some "missing link" that still
+> connects the algebra/Makefile back to the inter/Makefile?
+
+I have to think about this (I'm getting ready for work so I'll
+give it some "drive-time cycles") but I believe that the issue
+is related to using fresh databases. The databases are used
+during the algebra compiles to resolve algebra calls. However
+recompiling the algebra generates NRLIBs and, from these NRLIBs
+a fresh database is built thus:
+
+DATABASES -> NRLIBs -> FRESH DATABASES
+
+This is yet a third bootstrap issue. There are more but not with
+the algebra files.
+
+\end{verbatim}
+\subsection{email 9}
+\begin{verbatim}
+Yet one other opportunity for speed optimization is available at
+build time....
+
+Remember that every lisp file generates a .fn file:
+
+foo.lsp -> foo.o + foo.fn
+
+and that a second compile with the .fn file loaded is faster:
+
+foo.lsp + foo.fn -> faster foo.o
+
+However if we look at the type information in the foo.fn file
+we find that it only contains type information for functions
+defined in foo.lsp. But suppose there are two lisp files with
+functions from one using functions from the other. The sub-optimal
+sequence is:
+
+foo.lsp -> foo.o + foo.fn
+foo.lsp + foo.fn -> faster foo.o
+
+bar.lsp -> bar.o + bar.fn
+bar.lsp + bar.fn -> faster bar.o
+
+The optimal sequence is:
+
+foo.lsp -> foo.o + foo.fn
+bar.lsp -> bar.o + bar.fn
+
+foo.lsp + (foo.fn + bar.fn) -> even faster foo.o
+bar.lsp + (foo.fn + bar.fn) -> even faster bar.o
+
+So, really what we should do is cache ALL of the .fn files from all of
+the compiles, batch them into a big file, and the completely rebuild
+the system with the batched .fn files loaded.
+
+I've started this process but have not yet completed it.
+See the file src/boot/boot-proclaims.lisp
+
+So there is a faster Axiom coming in the future but the build
+complexity will be even greater. And Camm, I believe, is doing
+even more with type propagation which will improve things more.
+
+
+\end{verbatim}
+\subsection{email 10}
+\begin{verbatim}
+I am no longer baffled. The explanation for the generic arith
+vs. fixnum arith is in macros.lisp. In the following code from
+-REPEAT, X is bound to a form such as '((STEP |i| 3 1)):
+
+ (COND ((AND (EQ (CAAR X) 'STEP)
+ (|member| (CADDAR X) '(2 1 0 (|One|) (|Zero|)))
+ (|member| (CADR (CDDAR X)) '(1 (|One|))))
+ (SETQ X (CONS (CONS 'ISTEP (CDAR X)) (CDR X))) ))
+ ; A hack to increase the likelihood of small integers
+
+So, one `rule' is, if you iterate with a sequence with lower bound
+0,1, or 2, with an increment of 1, you get fixnum arith. Otherwise you
+get generic arithmetic.
+
+However, this is not a hard and fast rule, since the compiler can say
+'(ISTEP |i| 5 23) [say] during code generation and force fixnum arith.
+
+
+This leads to a question. Tim, in interp/wi2.boot we have a
+redefinition of compIterator (default implementation is in
+iterator.boot). This new definition makes an attempt at deciding when
+fixnum stepping code should be generated. Do you have an explanation
+as to why is this not the default definition? The original version of
+the code in iterator.boot is what gets called.
+
+I'm wondering if it is possible that during the fixedPoint build if
+some of the new definitions (particularly those in wi2.boot,
+xruncomp.boot) are being autoloaded during compilation. The changes
+which I have already noted in the generated lisp seem to support this
+(fixnum arith vs. generic arith, inlining of trivial coercions,
+etc). All the changes make sense if they are the result of calling one
+of the `improved' functions which these files redefine.
+
+Sincerely,
+Steve
+
+
+
+On Mon, Jan 17, 2005 at 01:39:45PM -0500, Stephen Wilson wrote:
+>
+> Tim,
+>
+> I compleatly fine with the fixnum declaration. We just need to make
+> sure it is a rule programmers can rely on. Consider:
+>
+> )abbrev package ITER Iter
+> Iter(): E == I where
+> E == with
+> iter: () -> Void
+> I == add
+> iter(): Void ==
+> for i in 2.. repeat
+> print(i::OutputForm)
+>
+>
+> The relavent lisp decalres we are using fixnums:
+>
+> (LETT |i| (QSADD1 |i|) |ITER;iter;V;1|)
+>
+>
+> Now compile the above with a lower bound of 3:
+>
+> for i in 3.. repeat
+> print(i::OutputForm)
+>
+>
+> We get generic arithmetic:
+>
+> (LETT |i| (+ |i| 1) |ITER;iter;V;1|)
+>
+>
+> Baffled,
+> Steve
+>
+>
+> On Mon, Jan 17, 2005 at 12:23:36PM -0500, root wrote:
+> > Steve,
+> >
+> > I don't know if there is an actual statement to the effect that
+> > the upper bound on a loop would be a register-sized number (32
+> > or 64 bits) but at 6Mhz it seemed impossible that one could
+> > run a loop of any consequence for greater than 2^32 or 2^64
+> > iterations. If you wanted to do that you'd have to do the
+> > looping using some other construct. In general it is safe to
+> > assume that the upper bound of the register size cannot be
+> > exceeded. There is a practical performance difference to
+> > be gained by using (declare (fixnum as the compiler can,
+> > in the best case, assign a register to the loop variable.
+> >
+> > t
+
+
+
+\end{verbatim}
+
+\subsection{email 24}
+\begin{verbatim}
+? Makefile
+? Makefile.dvi
+Index: as.boot.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/interp/as.boot.pamphlet,v
+retrieving revision 1.3
+diff -u -r1.3 as.boot.pamphlet
+--- as.boot.pamphlet 24 May 2004 22:53:49 -0000 1.3
++++ as.boot.pamphlet 8 Jan 2005 19:01:23 -0000
+@@ -389,7 +389,8 @@
+ HPUT(ht,id,[entry,:HGET(ht,id)])
+ opalist := [ [op,:REMDUP HGET(ht,op)] for op in HKEYS ht]
+ --HPUT($opHash,con,[ancestorAlist,attributeAlist,:opalist])
+- HPUT($opHash,con,[ancestorAlist,attributeAlist,:opalist])
++ --HPUT($opHash,con,[ancestorAlist,attributeAlist,:opalist])
++ HPUT($opHash,con,[ancestorAlist,nil,:opalist])
+
+ hackToRemoveAnd p ==
+ ---remove this as soon as .asy files do not contain forms (And pred) forms
+Index: ax.boot.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/interp/ax.boot.pamphlet,v
+retrieving revision 1.3
+diff -u -r1.3 ax.boot.pamphlet
+--- ax.boot.pamphlet 24 May 2004 22:53:49 -0000 1.3
++++ ax.boot.pamphlet 8 Jan 2005 19:01:26 -0000
+@@ -80,11 +80,29 @@
+ axForms :=
+ [ ['Foreign, ['Declare, 'dummyDefault, 'Exit], 'Lisp], :axForms]
+ axForms := APPEND(axDoLiterals(), axForms)
+- axForm := ['Sequence, ['Import, [], 'AxiomLib], :axForms]
++ axForm := ['Sequence, ['Import, [], 'AxiomLib], ['Import, [], 'Boolean],
:axForms]
+ st := MAKE_-OUTSTREAM(filename)
+ PPRINT(axForm,st)
+ CLOSE st
+
++makeAxExportForm(filename, constructors) ==
++ $defaultFlag : local := false
++ $literals := []
++ axForms :=
++ [modemapToAx(modemap) for cname in constructors |
++ (modemap:=GETDATABASE(cname,'CONSTRUCTORMODEMAP)) and
++ (not cname in '(Tuple Exit Type)) and
++ not isDefaultPackageName cname]
++ if $baseForms then
++ axForms := [:$baseForms, :axForms]
++ if $defaultFlag then
++ axForms :=
++ [ ['Foreign, ['Declare, 'dummyDefault, 'Exit], 'Lisp], :axForms]
++ axForms := APPEND(axDoLiterals(), axForms)
++ axForm := ['Sequence, ['Import, [], 'AxiomLib], ['Import, [], 'Boolean],
:axForms]
++ axForm
++
++
+ stripType type ==
+ $stripTypes =>
+ categoryForm? type => 'Type
+Index: i-syscmd.boot.pamphlet
+===================================================================
+RCS file: /cvsroot/axiom/axiom/src/interp/i-syscmd.boot.pamphlet,v
+retrieving revision 1.4
+diff -u -r1.4 i-syscmd.boot.pamphlet
+--- i-syscmd.boot.pamphlet 28 Dec 2004 07:42:45 -0000 1.4
++++ i-syscmd.boot.pamphlet 8 Jan 2005 19:01:36 -0000
+@@ -642,7 +642,7 @@
+ if ^beQuiet then sayKeyedMsg("S2IZ0038A",[namestring args, asharpArgs])
+
+ command :=
+- STRCONC(TRUENAME(STRCONC(GETENV('"AXIOM"),'"/compiler/bin/")),"axiomxl
", asharpArgs, '" ", namestring args)
++ STRCONC(STRCONC(GETENV('"AXIOM"),'"/compiler/bin/"),"axiomxl ",
asharpArgs, '" ", namestring args)
+ rc := OBEY command
+
+ if (rc = 0) and doCompileLisp then
+\end{verbatim}
+
+\subsection{email 25}
+\begin{verbatim}
+> It is not so clear to me why the build appears to succeed
+> even though these definitions are missing. In other languages
+> I would presume that this situation would be easily caught
+> as a missing file during `linking'. But here we have this
+> "domain vector" thing. Is there not some why that the
+> compilation could be made more robust by verifying the
+> domain vector at compile time?
+
+Bill, there is no "linking" step in any sense of the word.
+This needs to be documented somewhere.
+
+If we look at one of the random BOOTSTRAP files, say, CHAR we see:
+
+Character: OrderedFinite() with
+ ord: % -> Integer
+ ++ ord(c) provides an integral code corresponding to the
+ ++ character c. It is always true that \spad{char ord c = c}.
+ char: Integer -> %
+ ++ char(i) provides a character corresponding to the integer
+ ++ code i. It is always true that \spad{ord char i = i}.
+ char: String -> %
+ ++ char(s) provides a character from a string s of length one.
+ space: () -> %
+ ++ space() provides the blank character.
+ quote: () -> %
+ ++ quote() provides the string quote character, \spad{"}.
+ escape: () -> %
+ ++ escape() provides the escape character, \spad{_}, which
+ ++ is used to allow quotes and other characters {\em within}
+ ++ strings.
+ upperCase: % -> %
+ ++ upperCase(c) converts a lower case letter to the corresponding
+ ++ upper case letter. If c is not a lower case letter, then
+ ++ it is returned unchanged.
+ lowerCase: % -> %
+ ++ lowerCase(c) converts an upper case letter to the corresponding
+ ++ lower case letter. If c is not an upper case letter, then
+ ++ it is returned unchanged.
+ digit?: % -> Boolean
+ ++ digit?(c) tests if c is a digit character,
+ ++ i.e. one of 0..9.
+ hexDigit?: % -> Boolean
+ ++ hexDigit?(c) tests if c is a hexadecimal numeral,
+ ++ i.e. one of 0..9, a..f or A..F.
+ alphabetic?: % -> Boolean
+ ++ alphabetic?(c) tests if c is a letter,
+ ++ i.e. one of a..z or A..Z.
+ upperCase?: % -> Boolean
+ ++ upperCase?(c) tests if c is an upper case letter,
+ ++ i.e. one of A..Z.
+ lowerCase?: % -> Boolean
+ ++ lowerCase?(c) tests if c is an lower case letter,
+ ++ i.e. one of a..z.
+ alphanumeric?: % -> Boolean
+ ++ alphanumeric?(c) tests if c is either a letter or number,
+ ++ i.e. one of 0..9, a..z or A..Z.
+
+ == add
+ Rep := SingleInteger -- 0..255
+
+ CC ==> CharacterClass()
+ import CC
+
+ --cl: Record(dig:CC,hex:CC,upp:CC,low:CC,alpha:CC,alnum:CC) :=
+ -- [ digit(), hexDigit(),
+ -- upperCase(), lowerCase(), alphabetic(), alphanumeric() ]
+
+ OutChars:PrimitiveArray(OutputForm) :=
+ construct [NUM2CHAR(i)$Lisp for i in 0..255]
+
+ minChar := minIndex OutChars
+
+ a = b == a =$Rep b
+ a < b == a <$Rep b
+ size() == 256
+ index n == char((n - 1)::Integer)
+ lookup c == (1 + ord c)::PositiveInteger
+ char(n:Integer) == n::%
+ ord c == convert(c)$Rep
+ random() == char(random()$Integer rem size())
+ space == QENUM(" ", 0$Lisp)$Lisp
+ quote == QENUM("_" ", 0$Lisp)$Lisp
+ escape == QENUM("__ ", 0$Lisp)$Lisp
+ coerce(c:%):OutputForm == OutChars(minChar + ord c)
+ digit? c == member?(c pretend Character, digit())
+ hexDigit? c == member?(c pretend Character, hexDigit())
+ upperCase? c == member?(c pretend Character, upperCase())
+ lowerCase? c == member?(c pretend Character, lowerCase())
+ alphabetic? c == member?(c pretend Character, alphabetic())
+ alphanumeric? c == member?(c pretend Character, alphanumeric())
+
+ latex c ==
+ concat("\mbox{`", concat(new(1,c pretend Character)$String,
+"'}")$String)$String
+
+ char(s:String) ==
+-- one?(#s) => s(minIndex s) pretend %
+ (#s) = 1 => s(minIndex s) pretend %
+ error "String is not a single character"
+
+ upperCase c ==
+ QENUM(PNAME(UPCASE(NUM2CHAR(ord c)$Lisp)$Lisp)$Lisp,
+ 0$Lisp)$Lisp
+
+ lowerCase c ==
+ QENUM(PNAME(DOWNCASE(NUM2CHAR(ord c)$Lisp)$Lisp)$Lisp,
+ 0$Lisp)$Lisp
+
+
+
+The BOOTSTRAP code, annotated, looks like:
+
+
+=====================================================================
+The VERSIONCHECK variable came about when we were writing the Aldor
+compiler. We had completely reimplemented the algebra so that it was
+incompatible with previous versions. This is checked on loading.
+
+(|/VERSIONCHECK| 2)
+
+=====================================================================
+This implements the
+ a = b == a =$Rep b
+function. Note that the function name |CHAR;=;2$B;1| is constructed
+from the domain abbreviation; the function name; the number of arguments
+and their types; and a unique number
+
+Also note that the compiler claims that it knows that the '='
+function can be replaced with lisp 'EQL' in compiled code so
+this function is never run. It uses a property list marker
+'|SPADreplace|' on the function symbol to implement the replacement
+during compiles.
+
+(PUT (QUOTE |CHAR;=;2$B;1|) (QUOTE |SPADreplace|) (QUOTE EQL))
+
+(DEFUN |CHAR;=;2$B;1| (|a| |b| |$|) (EQL |a| |b|))
+
+=====================================================================
+This implements the
+ a < b == a <$Rep b
+function. Again note that the compiler knows that calls to this
+function can be replaced by the lisp QSLESSP function. The 'QS'
+prefix is a VMLisp idiom. 'Q' == quick (no type check) 'S'=singleinteger
+which, at least in VMLisp turns into a single instruction. QSLESSP
+(uppercased here because spad is case-sensitive and lisp is not)
+is defined in src/interp/vmlisp.lisp.pamphlet as a macro with
+embedded type information.
+
+(PUT (QUOTE |CHAR;<;2$B;2|) (QUOTE |SPADreplace|) (QUOTE QSLESSP))
+
+(DEFUN |CHAR;<;2$B;2| (|a| |b| |$|) (QSLESSP |a| |b|))
+
+=====================================================================
+This implements
+ size() == 256
+and just returns a "boxed integer" (XLAM is a marker for boxing).
+
+(PUT (QUOTE |CHAR;size;Nni;3|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL 256)))
+
+(DEFUN |CHAR;size;Nni;3| (|$|) 256)
+
+=====================================================================
+This implements the
+ index n == char((n - 1)::Integer)
+function. Notice that this does a 'QREFELT'. This is another VMLisp
+idiom 'Q' is quick, 'REFELT' is a vector lookup function. This is
+also implmented as a macro in src/interp/vmlisp.lisp.pamphlet where
+it does a 'svref', simple vector reference into the current domain
+(that's what '|$|' means) and calls the 18th element from this domain.
+
+The domain is represented by a vector (the domain vector) which you'll
+find at the bottom of this file. The domain vector for a domain is
+kept on the property list of the domain name symbol, in this case it
+is "Character". So we see the code:
+
+(MAKEPROP (QUOTE |Character|) (QUOTE |infovec|) (LIST (QUOTE #(NIL NIL ...
+
+The |infovec|, the information vector, contains a lot of domain specific
+information which is looked up at runtime. In this case we are doing a
+(QVREFELT |$| 18). If you count 18 elements into the |infovec| you'll
+find |CHAR;char;I$;6|. If you examine the symbol name carefully you
+can decode that it is a function from the domain "CHAR" (this domain)
+called "char" that takes one argument of type "I" (integer), and is
+the 6th function in this domain, which happens to be
+ char(n:Integer) == n::%
+
+So this function does what it says, it subtracts 1 from its argument,
+treats it as an integer and returns the integer. The reason this works
+is that "Characters" have a representation of SingleInteger:
+ Rep := SingleInteger -- 0..255
+
+(DEFUN |CHAR;index;Pi$;4| (|n| |$|) (SPADCALL (|-| |n| 1) (QREFELT |$| 18)))
+
+.....[snip]....
+
+=====================================================================
+This is the function that gets executed when "Character" gets instantiated.
+This function has the effect, if memory serves, of putting the function
+"Character;" into the |$ConstructorCache|. The |$ConstructorCache| is a
+hash table used for fast lookup and function dispatch. The call to
+|Character| will call |Character;| (see below).
+
+(DEFUN |Character| NIL
+ (PROG NIL
+ (RETURN
+ (PROG (#1=#:G90941)
+ (RETURN
+ (COND
+ ((LETT #1# (HGET |$ConstructorCache| (QUOTE |Character|))
+ |Character|)
+ (|CDRwithIncrement| (CDAR #1#)))
+ ((QUOTE T)
+ (|UNWIND-PROTECT|
+ (PROG1
+ (CDDAR
+ (HPUT |$ConstructorCache|
+ (QUOTE |Character|)
+ (LIST
+ (CONS NIL (CONS 1 (|Character;|))))))
+ (LETT #1# T |Character|))
+ (COND
+ ((NOT #1#)
+ (HREM |$ConstructorCache| (QUOTE |Character|))))))))))))
+
+=====================================================================
+This function initializes the |infovec| data structure. Notice the calls
+to QSETREFV, another VMLisp-ism, which does a "(setf (svref ...", that
+is, it sets an element of a simple vector (|infovec|). Notice the call
+to |SingleInteger|. This will cause the domain SingleInteger to be loaded,
+initialized, and put in the constructor cache. This domain needs the
+SingleInteger domain for its representation.
+
+(DEFUN |Character;| NIL
+ (PROG (|dv$| |$| |pv$| #1=#:G90939 |i|)
+ (RETURN
+ (SEQ
+ (PROGN
+ (LETT |dv$| (QUOTE (|Character|)) . #2=(|Character|))
+ (LETT |$| (GETREFV 53) . #2#)
+ (QSETREFV |$| 0 |dv$|)
+ (QSETREFV |$| 3 (LETT |pv$| (|buildPredVector| 0 0 NIL) . #2#))
+ (|haddProp| |$ConstructorCache| (QUOTE |Character|) NIL (CONS 1 |$|))
+ (|stuffDomainSlots| |$|)
+ (QSETREFV |$| 6 (|SingleInteger|))
+ (QSETREFV |$| 10
+ (SPADCALL
+ (PROGN
+ (LETT #1# NIL . #2#)
+ (SEQ
+ (LETT |i| 0 . #2#)
+ G190
+ (COND
+ ((QSGREATERP |i| 255) (GO G191)))
+ (SEQ
+ (EXIT
+ (LETT #1# (CONS (NUM2CHAR |i|) #1#) . #2#)))
+ (LETT |i| (QSADD1 |i|) . #2#)
+ (GO G190)
+ G191
+ (EXIT (NREVERSE0 #1#))))
+ (QREFELT |$| 9)))
+ (QSETREFV |$| 11 0) |$|)))))
+
+=====================================================================
+This is the actual representation of the Character domain. The main
+point of the compiler is to construct the |infovec|. I'm not up to
+explaining the details of this at this moment.
+
+(MAKEPROP
+ (QUOTE |Character|)
+ (QUOTE |infovec|)
+ (LIST
+ (QUOTE
+ #(NIL NIL NIL NIL NIL NIL (QUOTE |Rep|) (|List| 28) (|PrimitiveArray| 28)
+ (0 . |construct|) (QUOTE |OutChars|) (QUOTE |minChar|) (|Boolean|)
+ |CHAR;=;2$B;1| |CHAR;<;2$B;2| (|NonNegativeInteger|) |CHAR;size;Nni;3|
+ (|Integer|) |CHAR;char;I$;6| (|PositiveInteger|) |CHAR;index;Pi$;4|
+ |CHAR;ord;$I;7| |CHAR;lookup;$Pi;5| (5 . |coerce|) |CHAR;random;$;8|
+ |CHAR;space;$;9| |CHAR;quote;$;10| |CHAR;escape;$;11| (|OutputForm|)
+ |CHAR;coerce;$Of;12| (|CharacterClass|) (10 . |digit|) (|Character|)
+ (14 . |member?|) |CHAR;digit?;$B;13| (20 . |hexDigit|)
+ |CHAR;hexDigit?;$B;14| (24 . |upperCase|) |CHAR;upperCase?;$B;15|
+ (28 . |lowerCase|) |CHAR;lowerCase?;$B;16| (32 . |alphabetic|)
+ |CHAR;alphabetic?;$B;17| (36 . |alphanumeric|) |CHAR;alphanumeric?;$B;18|
+ (|String|) |CHAR;latex;$S;19| (40 . |minIndex|) (45 . |elt|)
+ |CHAR;char;S$;20| |CHAR;upperCase;2$;21| |CHAR;lowerCase;2$;22|
+ (|SingleInteger|))) (QUOTE #(|~=| 51 |upperCase?| 57 |upperCase| 62
+ |space| 67 |size| 71 |random| 75 |quote| 79 |ord| 83 |min| 88 |max| 94
+ |lowerCase?| 100 |lowerCase| 105 |lookup| 110 |latex| 115 |index| 120
+ |hexDigit?| 125 |hash| 130 |escape| 135 |digit?| 139 |coerce| 144 |char|
+ 149 |alphanumeric?| 159 |alphabetic?| 164 |>=| 169 |>| 175 |=| 181 |<=|
+ 187 |<| 193)) (QUOTE NIL)
+ (CONS (|makeByteWordVec2| 1
+ (QUOTE (0 0 0 0 0 0)))
+ (CONS
+ (QUOTE #(NIL |OrderedSet&| NIL |SetCategory&| |BasicType&| NIL))
+ (CONS
+ (QUOTE #((|OrderedFinite|) (|OrderedSet|) (|Finite|)
+ (|SetCategory|) (|BasicType|) (|CoercibleTo| 28)))
+ (|makeByteWordVec2| 52
+ (QUOTE
+ (1 8 0 7 9 1 6 0 17 23 0 30 0 31 2 30 12 32 0 33 0 30 0 35 0
+ 30 0 37 0 30 0 39 0 30 0 41 0 30 0 43 1 45 17 0 47 2 45 32 0
+ 17 48 2 0 12 0 0 1 1 0 12 0 38 1 0 0 0 50 0 0 0 25 0 0 15 16
+ 0 0 0 24 0 0 0 26 1 0 17 0 21 2 0 0 0 0 1 2 0 0 0 0 1 1 0 12
+ 0 40 1 0 0 0 51 1 0 19 0 22 1 0 45 0 46 1 0 0 19 20 1 0 12 0
+ 36 1 0 52 0 1 0 0 0 27 1 0 12 0 34 1 0 28 0 29 1 0 0 45 49 1
+ 0 0 17 18 1 0 12 0 44 1 0 12 0 42 2 0 12 0 0 1 2 0 12 0 0 1 2
+ 0 12 0 0 13 2 0 12 0 0 1 2 0 12 0 0 14))))))
+ (QUOTE |lookupComplete|)))
+
+(MAKEPROP (QUOTE |Character|) (QUOTE NILADIC) T)
+
+
+
+
+
+\end{verbatim}
+\subsection{email 26}
+\begin{verbatim}
+=====================================================================
+This is the function that gets executed when "Character" gets instantiated.
+This function has the effect, if memory serves, of PUTTING THE FUNCTION
+ ^^^^^^^^^^^^^^^^^^^^
+ wrong, wrong, wrong
+
+"Character;" into the |$ConstructorCache|. The |$ConstructorCache| is a
+hash table used for fast lookup and function dispatch. The call to
+|Character| will call |Character;| (see below).
+
+(DEFUN |Character| NIL
+=====================================================================
+
+
+
+is slightly wrong. It does NOT put the function |Character;| in the
+|$ConstructorCache|, it puts the RESULT of calling (|Character;|)
+in the cache, which is a fully initialized |infovec| object.
+
+
+You'll also find the function call
+
+ (|stuffDomainSlots| |$|)
+
+in |Character;| interesting. The function is actually defined in
+src/interp/nrunopt.boot.pamphlet. From that function you can
+reverse-engineer the contents of the initial slots (which are just
+ #(NIL NIL NIL NIL NIL NIL ....
+at compile time.
+
+Clearly documenting stuffDomainSlots would help as would documenting
+all of the rest of it.
+
+Also, for your amusement, try the following:
+
+axiom
+(1)-> )lisp (setq $DALYMODE t)
+(1)-> )set message autoload on
+(1)-> (maphash #'(lambda (key val) (format t "key=~a val=~a~%~%" key val))
+|$ConstructorCache|)
+(1)-> 1
+(1)-> (maphash #'(lambda (key val) (format t "key=~a val=~a~%~%" key val))
+|$ConstructorCache|)
+
+The first maphash returns NIL
+
+The second maphash returns the loaded domains. The messages that get
+printed (from loadlib in src/interp/lisplib.boot.pamphlet) turn out
+to be the same domains you'll see in the constructor cache. Loading
+the domain causes it to be "instantiated" which means that the
+infovec for the domain gets filled in and stuck in the constructorcache.
+
+If a domain is already in the constructor cache it will not be loaded.
+Thus domain loading occurs on demand and only once.
+
+\end{verbatim}
+\subsection{email 27}
+\begin{verbatim}
+On Mon, Jan 10, 2005 at 09:47:36PM -0500, root wrote:
+> The code was changed. It used to read:
+>
+> one?(x) == ONEP(x)$Lisp
+>
+> It now reads:
+>
+> one?(x) == x = 1
+
+
+True, but the bootstrap code does not contain any definition. We have:
+
+(DEFUN |SINT;zero?;$B;38| (|x| $) (QSZEROP |x|))
+
+(DEFUN |SINT;max;3$;39| (|x| |y| $) (QSMAX |x| |y|))
+
+
+The last number in the function names gives the order of the function
+in definition in the domain. The definition of `one?' follows
+`zero?'. With fresh code we have:
+
+(DEFUN |SINT;zero?;$B;38| (|x| $) (QSZEROP |x|))
+
+(DEFUN |SINT;one?;$B;39| (|x| $) (EQL |x| 1))
+
+(DEFUN |SINT;max;3$;40| (|x| |y| $) (QSMAX |x| |y|))
+
+
+It was precisely this change in sequence that allowed me to spot this
+missing function by looking at the domain vectors. All domains which
+relied of functions defined in SINT with `sequence number' > 38
+shifted by one in the second pass of the fixed-point build.
+
+\end{verbatim}
+
+
+\section{Aldor/Algebra}
+
+\subsection{email 11}
+\begin{verbatim}
+I installed "Aldor version 1.0.2 for LINUX(glibc2.3)" on
+axiom-developer.org several months ago. The date on the
+aldor tarball in /home/page is May 19 2004. Aldor should
+be accessible to you when you log in at axiom-developer.
+Just add
+
+ export ALDORROOT=/usr/local/aldor/linux/1.0.2
+ export PATH=$ALDORROOT/bin:$PATH
+
+to your .bashrc, do
+
+ . .bashrc
+
+and your should be able to type
+
+ aldor ...
+
+You should find the libaries in the standard locations.
+
+There is apparently a fairly up to date windows binary
+version as well, but I haven't had much time to play
+with this yet.
+
+At the time I was planning to implement a MathAction-
+Aldor web interface that would look something like this
+
+\begin{aldor}
+... aldor code ...
+\end{aldor}
+
+and which could be intermixed with Axiom code on the
+MathAction website. I got distracted by other things
+and so have not yet completed the integration with
+MathAction but there is not a lot more to do. Recent
+discussions here about getting Axiom and Aldor working
+together again suggest that it might be time for me
+to raise the priority to make this possible.
+
+Ralf Hemmecke wrote:
+>
+> If you mean cvs.aldor.org, then it might be that May 16 2004
+> is a bit late. The libraries have changed since then.
+>
+> You could however download the latest precompiled version
+> 1.0.2 from
+>
+> http://www.aldor.org/downl.html
+>
+
+> If you really want to compile the libraries yourself, ask
+> me again. I think the newest cvs-version should compile,
+> but if they don't ... There has been some work on the
+> Makefiles since May 16.
+>
+> Ralf
+>
+> root wrote:
+> > Martin, Peter,
+> >
+> > I tried to build aldor last night. I succeeded in building
+> > the compiler but not the libraries. I have a CVS checkout
+> > from May 16.
+> >
+> > I've been reading the Makefiles but they all seem to dissolve
+> > into home-grown tools (makeon, docc, etc) which undermines my
+> > ability to figure out what is happening. It's been years since
+> > I built aldor.
+> >
+> > Peter, could you provide the required steps to build a working
+> > compiler? e.g.
+> >
+> > edit Makefile.globals to change.... make aldorcompiler
+> > ....
+> >
+
+
+\end{verbatim}
+
+\subsection{email 2}
+\begin{verbatim}
+There is something called the "add-chain formed by domain
+extensions" which is described in the Glossary of the Axiom
+book:
+
+ "add-chain
+
+ a hierarchy formed by domain extensions. If domain A extends
+ domain B and domain B extends domain C, then A has add-chain
+ B-C."
+
+and
+
+ "domain extension
+
+ a domain constructor A is said to extend a domain constructor B
+ if A's definition has the form A == Badd.... This intuitively
+ means "functions not defined by A are assumed to come from B."
+ Successive domain extensions form add-chains affecting the
+ search order for functions not implemented directly by the
+ domain during dynamic lookup.
+
+ "dynamic lookup
+
+ In Axiom, a domain may or may not explicitly provide function
+ definitions for all its exported operations. These definitions
+ may instead come from domains in the add-chain or from default
+ packages. When a function call is made for an operation in the
+ domain, up to five steps are carried out.
+ 1. If the domain itself implements a function for the operation,
+ that function is returned.
+ 2. Each of the domains in the add-chain are searched; if one
+ of these domains implements the function, that function is
+ returned.
+ 3. Each of the default packages for the domain are searched in
+ order of the lineage. If any of the default packages implements
+ the function, the first one found is returned.
+ 4. Each of the default packages for each of the domains in the
+ add-chain are searched in the order of their lineage. If any
+ of the default packages implements the function, the first
+ one found is returned.
+ 5. If all of the above steps fail, an error message is reported.
+
+---------
+
+\end{verbatim}
+
+
+\subsection{email 12}
+\begin{verbatim}
+Oops, sorry that I have not read the documentation of Any.
+I had a look at Any now. Well, from that I just got the feeling that a
programmer should never use Any if there are better types around (and often
there are). Any seems to be connected to the interpreter. Since everything must
have a type and the interpreter cannot figure out something reasonable, it
falls back to Any.
+
+I'd rather be happy if the interpreter is clearly separated from the compiler.
+
+The interpreter is for working with Axiom, so it could help the (lazy) user
and find/guesss appropriate types for him/her. However there should be NO
guessing when it comes to writing new library code.
+
+Looking at the code of Any reminds me much of the things I have suggested here
+
address@hidden">http://page.axiom-developer.org/zope/mathaction/address@hidden
+The code is in cvs.aldor.org/aldor/aldorug/samples/object*.as.
+
+
+The problem I still have with any is that it says
+
+
+ Rep := Record(dm: SExpression, ob: None)
+ dom x == x.dm
+
+
+which looks very near to some LISP thing.
+So I can ask for the domain a: Any by calling dom(a). Then I will get an
SExpression which makes me feel lost.
+
+Unfortunately, I have no runnig Axiom at the moment :-(
+And I cannot compile axim--main--1 (bfd.h is missing and I have no idea what
to install).
+
+So I tested on
+
+
+http://page.axiom-developer.org/zope/mathaction/AxiomInterface
+
+
+i: Integer := 1
+ Type: Integer
+
+
+a: Any := i::Any
+ Type: Integer <----- very interesting!!!
+
+
+dom a
+ Type: SExpression
+obj a
+ Type: None
+
+
+j: Integer := a :: Integer
+ Type: Integer
+
+
+It seems the interpreter is quite smart.
+
+
+
+
+
+s: String := "I am a string"
+ Type: String
+
+
+b: Any := s::Any
+ Type: String
+
+
+dom b
+ Type: SExpression?
+
+
+obj b
+ Type: None
+
+
+k: Integer := b :: Integer
+ Cannot convert from type Any to Integer for value
+ "I am a string"
+
+
+
+This Error is OK. And I think for manually working with Axiom, one just needs
to type dom(...) and then coerce to the now known type.
+But how to use Any in a program is totally unclear to me. I have no idea to
get the domain back from the SExpression.
+\end{verbatim}
+\subsection{email 13}
+\begin{verbatim}
+> ...
+> I am, however, very much against the Any type. It is like
+> building a strongly typed language and than trying to forget
+> about types.
+>
+
+Well that is more or less what I naively thought as well but
+from the ANY.spad file I read that:
+
+)abbrev domain ANY Any
+++ Author: Robert S. Sutor
+++ Basic Functions: any, domainOf, objectOf, dom, obj,
+++ showTypeInOutput
+++ Related Constructors: AnyFunctions1
+++ Description:
+++ \spadtype{Any} implements a type that packages up objects and
+++ their types in objects of \spadtype{Any}. Roughly speaking
+++ that means that if \spad{s : S} then when converted to
+++ \spadtype{Any}, the new object will include both the original
+++ object and its type. This is a way of converting arbitrary
+++ objects into a single type **without losing any** of the
+++ original information. Any object can be converted to one of
+++ \spadtype{Any}.
+
+and in the related file ANY1.spad
+
+)abbrev package ANY1 AnyFunctions1
+++ Basic Functions: coerce, retractIfCan, retractable?, retract
+++ Description:
+++ \spadtype{AnyFunctions1} implements several utility functions
+++ for working with \spadtype{Any}. These functions are used to
+++ go back and forth between objects of \spadtype{Any} and objects
+++ of other types.
+
+So the situation is not quiet so simple. Apparently Any does not
+mean Any in the sense of throwing away essential information.
+
+\end{verbatim}
+\subsection{email 14}
+\begin{verbatim}
+Ralf Hemmecke wrote:
+>
+> Hi Bill,
+>
+> >>Foo: with { g: (n: PositiveInteger, k: PositiveInteger) ->
+> >>PrimeField(n) } == add {
+> >>g(n: PositiveInteger, k: PositiveInteger ): PrimeField(n) ==
+> >> k::Integer::PrimeField(n) }
+>
+> > Ok, I will work with this example. Yes, it is better.
+>
+> Well, I haven't checked whether it should really work, but
+> shouldn't be
+>
+> Foo: with {
+> g: (n: PositiveInteger, k: PositiveInteger) ->
+> (P: PrimeFieldCategory, x: P)
+> } == add {
+> g(n: PositiveInteger, k: PositiveInteger ):
+> (P: PrimeFieldCategory, x:P) == {
+> (PrimeField(n), k::Integer::PrimeField(n)
+> }
+> }
+>
+> be even better?
+
+In fact you just pointed a way to solve the problem! Notice that you are in
+effect constructing a domain! So first create this domain (call this anything
+else you like):
+
+--%PointedPrimeField
+)abbrev domain PPF PointedPrimeField
+PointedPrimeField(n:PositiveInteger):Cat==Dog where
+ Cat == FiniteFieldCategory with
+ foo:PositiveInteger->PrimeField(n)
+ Dog == PrimeField(n) add
+ foo(k)==k::Integer::PrimeField(n)
+
+After compiling, define in the interpreter
+
+g(n,k)==foo(k)$PPF(n)
+
+and it works (in Axiom)! (Do not declare the types for g because n is not
+defined).
+
+But I have trouble with path in windows:
+ Processing PointedPrimeField for Browser database:
+--->-->PointedPrimeField((foo ((PrimeField n) (PositiveInteger)))): Not
document
+ed!!!!
+--->-->PointedPrimeField(constructor): Not documented!!!!
+--->-->PointedPrimeField(): Missing Description
+h:/dostools/rm.exe: j:/program: No such file or directory
+h:/dostools/rm.exe:
j:/progra~1/axiom/mnt/windows/lib/files/axiom/mnt/windows/li
+b/ppf.nrlib: No such file or directory
+
+ >> System error:
+ Cannot rename the file #P"j:/Program Files/axiom/mnt/windows/lib/PPF.erlib"
t
+o #P"j:/Program Files/axiom/mnt/windows/lib/PPF.NRLIB".
+
+protected-symbol-warn called with (NIL)
+
+But that is just because "Program Files" need be in quotes?
+
+\end{verbatim}
+\subsection{email 15}
+\begin{verbatim}
+Foo: with { g: (n: PositiveInteger, k: PositiveInteger) -> PrimeField(n) } ==
add {
+g(n: PositiveInteger, k: PositiveInteger ): PrimeField(n) ==
+k::Integer::PrimeField(n) }
+Ok, I will work with this example. Yes, it is better.
+
+
+Well, I haven't checked whether it should really work, but
+shouldn't be
+
+
+Foo: with {
+ g: (n: PositiveInteger, k: PositiveInteger) ->
+ (P: PrimeFieldCategory, x: P)
+} == add {
+ g(n: PositiveInteger, k: PositiveInteger ):
+ (P: PrimeFieldCategory, x:P) == {
+ (PrimeField(n), k::Integer::PrimeField(n)
+ }
+}
+
+
+be even better? The above code will not compile in Aldor, since it does not
have PositiveInteger. And maybe it will even not compile with appropriate
substitutions since the compiler cannot handle such a construction. I am,
however, very much against the Any type. It is like building a strongly typed
language and than trying to forget about types. For the interpreter it maybe
OK, but not for the compiler.
+
+Programming in Axiom should mean writing programs for the compiler. I would
say that programming in the interpreter is just writing short scripts but not
real programs.
+
+See also
+http://www.aldor.org/docs/HTML/chap23.html#10\end{verbatim}
+\subsection{email 16}
+\begin{verbatim}
+On Wednesday, January 12, 2005 8:30 AM you wrote:
+> Bill Page wrote:
+> >
+> > I don't really understand when the use of parameterized
+> > return types on functions would be useful. What information
+> > is being returned as part of the type of the result that is
+> > not already known because of it's value?
+>
+> The above is an example. Perhaps, more convincing:
+>
+> Foo: with { g: (n: PositiveInteger, k: PositiveInteger) ->
+> PrimeField(n) } == add {
+> g(n: PositiveInteger, k: PositiveInteger ): PrimeField(n) ==
+> k::Integer::PrimeField(n) }
+>
+
+Ok, I will work with this example. Yes, it is better.
+
+> Another example is Marcus Better's problem, more examples
+> are in expr2ups.spad, where Any is used a lot.
+
+Ok.
+
+> The type tells you in what domain to interpret the value.
+> But sometimes, the type will have to depend on a parameter
+> of the function, as above.
+
+That is still now clear to me, at least when it is possible
+to use a Union.
+
+>
+> > As I see it the concept does considerable damage to the
+> > notion of the 'domain' of a function. How should we
+> > interpret the expressioin `PrimeField(n)' when n is
+> > unknown? Does it represent the Union over all values n?
+> > We can no longer write the signature of a function in
+> > the simple form:
+> >
+> > f: PositiveInteger -> PrimeField
+>
+> Yes you can: Aldor does it. The signature is
+>
+> f: (n: PositiveInteger) -> PrimeField n
+>
+
+That does not look like a *signature* to me. What is the
+value of n? If you can't tell me, then how can I interpret
+`PrimeField n'? A signature should specify the domains of
+the function, but `PrimeField n' is not a domain until `n'
+is replaced with some PositiveInteger. The only interpretation
+of `PrimeField n' as a domain that I can think of would be
+to claim that it represents some kind of Union over the
+primes.
+
+ Union(PrimeField n for n=1.. | prime? n)
+
+But of course we can't write it quite this nicely right now
+in Axiom...
+
+This is similar to Axiom's insistence that
+
+ A:Integer
+
+can not be used in the expression
+
+ A+1
+
+until A is assigned a value. I this case I think it should
+be ok to say that if A has no assigned value then it
+represents the domain
+
+ {+/-n for n=0..}
+
+> > Can you explain again why you don't find the usual
+> > Axiom solution to this situation acceptible? I.e. the
+> > use of the `Any' domain:
+> >
+> > f:PositiveInteger->Any
+> > f(n) == n::PrimeField(n)
+>
+> Because you cannot use it in compiled code and because you
+> are using all of the type information, which is the main
+> point of Axiom.
+
+But as you said, `Any' is used extensively in expr2ups.spad.
+
+> Of course, the example you just gave doesn't
+> make any sense, the result is always zero, but given the
+> function
+>
+> Bar: with { h: (n: PositiveInteger, k: PositiveInteger) -> Any }
+> == add { g(n: PositiveInteger, k: PositiveInteger ): Any ==
+> k::Any }
+>
+> you cannot use this function in compiled code anymore. The
+> interpreter can deal with it, not the compiler.
+
+I would write it something like this:
+
+(2) -> h:(PositiveInteger,PositiveInteger)->Union( _
+PrimeField(2),PrimeField(3),PrimeField(5),PrimeField(7))
+ Type: Void
+(3) -> h(n,k)==k::PrimeField(n)
+ Type: Void
+(4) -> x:=h(7,2)
+
+ (4) 2
+ Type: Union(PrimeField 7,...)
+(5) -> trace x
+
+ (5) 2
+ Type: PrimeField 7
+>
+> Look at Marcus code for a really convincing example: He wants
+> to construct recursively an algebraic extension of a ring,
+> adding elements one at the time. At the end of the process
+> he wants to return an element of the final ring. It is tricky
+> to do this in Axiom currently.
+
+I will take a closer look at the emails from Marcus.
+
+>
+> Note, for example, if you have a signature
+>
+> f: Integer -> Any
+>
+> but really, f returns a SimpleAlgebraicExtension of some
+> ring, you cannot do any calculations with the result in
+> compiled code anymore, unless you know *exactly* the defining
+> polynomial of the ring.
+
+I agree that Any throws away too much information, except
+in the interpreter where it tries to do a better job. But
+I think even there Any is (usually) not a good choice for
+the domain.
+
+>
+> So one way out -- in this specific case -- would be to
+> return a record containing the result of type Any and
+> the defining polynomial. I hope you admit that this is
+> ugly.
+
+I agree that that is ugly. Using an explicit "streaming Union"
+(iterator) domain would be my (future) choice. Unfortunately
+for now:
+
+(6) -> Union(PrimeField(i) for i in 1..10)
+ Local variable or parameter used in type
+ We will attempt to interpret the code.
+
+ Category, domain or package constructor COLLECT is not available.
+(6) -> Union(PrimeField(i) for i in 1..)
+ Loading C:/Program Files/axiom/mnt/windows/algebra/UNISEG.o for
+ domain UniversalSegment
+ Loading C:/Program Files/axiom/mnt/windows/algebra/INCRMAPS.o for
+ package IncrementingMaps
+ Loading C:/Program Files/axiom/mnt/windows/algebra/ITUPLE.o for
+ domain InfiniteTuple
+ Loading C:/Program Files/axiom/mnt/windows/algebra/STREAM.o for
+ domain Stream
+ Local variable or parameter used in type
+ We will attempt to interpret the code.
+
+ Interpret-Code mode is not supported for stream bodies.
+(6) ->
+
+\end{verbatim}
+\subsection{email 17}
+\begin{verbatim}
+ > > #include "axiom"
+ > >
+ > > Test: with { f: (n: PositiveInteger) -> PrimeField(n) }
+ > > == add { f(n: PositiveInteger): PrimeField(n) ==
+ > > 10::Integer::PrimeField(n) }
+ > >
+ > > Note that such a construction -- the resulting domain depending on the
+ > > function parameter -- is currently illegal in Axiom. In Aldor it is fine.
+ >
+ > I don't really understand when the use of parameterized return types on
+ > functions would be useful. What information is being returned as part of the
+ > type of the result that is not already known because of it's value?
+
+The above is an example. Perhaps, more convincing:
+
+Foo: with { g: (n: PositiveInteger, k: PositiveInteger) -> PrimeField(n) }
+ == add { g(n: PositiveInteger, k: PositiveInteger ): PrimeField(n) ==
+ k::Integer::PrimeField(n) }
+
+Another example is Marcus Better's problem, more examples are in
+expr2ups.spad, where Any is used a lot. The type tells you in what domain to
+interpret the value. But sometimes, the type will have to depend on a parameter
+of the function, as above.
+
+ > As I see it the concept does considerable damage to the notion of the
+ > 'domain' of a function. How should we interpret the expressioin
+ > `PrimeField(n)' when n is unknown? Does it represent the Union over all
+ > values n? We can no longer write the signature of a function in the simple
+ > form:
+ >
+ > f: PositiveInteger -> PrimeField
+
+Yes you can: Aldor does it. The signature is
- OutChars:PrimitiveArray(OutputForm) :=
- construct [NUM2CHAR(i)$Lisp for i in 0..255]
+ f: (n: PositiveInteger) -> PrimeField n
- minChar := minIndex OutChars
+ > Can you explain again why you don't find the usual Axiom solution to this
+ > situation acceptible? I.e. the use of the `Any' domain:
+ >
+ > f:PositiveInteger->Any
+ > f(n) == n::PrimeField(n)
- a = b == a =$Rep b
- a < b == a <$Rep b
- size() == 256
- index n == char((n - 1)::Integer)
- lookup c == (1 + ord c)::PositiveInteger
- char(n:Integer) == n::%
- ord c == convert(c)$Rep
- random() == char(random()$Integer rem size())
- space == QENUM(" ", 0$Lisp)$Lisp
- quote == QENUM("_" ", 0$Lisp)$Lisp
- escape == QENUM("__ ", 0$Lisp)$Lisp
- coerce(c:%):OutputForm == OutChars(minChar + ord c)
- digit? c == member?(c pretend Character, digit())
- hexDigit? c == member?(c pretend Character, hexDigit())
- upperCase? c == member?(c pretend Character, upperCase())
- lowerCase? c == member?(c pretend Character, lowerCase())
- alphabetic? c == member?(c pretend Character, alphabetic())
- alphanumeric? c == member?(c pretend Character, alphanumeric())
+Because you cannot use it in compiled code and because you are using all of the
+type information, which is the main point of Axiom. Of course, the example you
+just gave doesn't make any sense, the result is always zero, but given the
+function
- latex c ==
- concat("\mbox{`", concat(new(1,c pretend Character)$String,
-"'}")$String)$String
+Bar: with { h: (n: PositiveInteger, k: PositiveInteger) -> Any }
+ == add { g(n: PositiveInteger, k: PositiveInteger ): Any ==
+ k::Any }
- char(s:String) ==
--- one?(#s) => s(minIndex s) pretend %
- (#s) = 1 => s(minIndex s) pretend %
- error "String is not a single character"
+you cannot use this function in compiled code anymore. The interpreter can deal
+with it, not the compiler.
- upperCase c ==
- QENUM(PNAME(UPCASE(NUM2CHAR(ord c)$Lisp)$Lisp)$Lisp,
- 0$Lisp)$Lisp
+Look at Marcus code for a really convincing example: He wants to construct
+recursively an algebraic extension of a ring, adding elements one at the
+time. At the end of the process he wants to return an element of the final
+ring. It is tricky to do this in Axiom currently.
- lowerCase c ==
- QENUM(PNAME(DOWNCASE(NUM2CHAR(ord c)$Lisp)$Lisp)$Lisp,
- 0$Lisp)$Lisp
+Note, for example, if you have a signature
+ f: Integer -> Any
+but really, f returns a SimpleAlgebraicExtension of some ring, you cannot do
+any calculations with the result in compiled code anymore, unless you know
+*exactly* the defining polynomial of the ring.
-The BOOTSTRAP code, annotated, looks like:
+So one way out -- in this specific case -- would be to return a record
+containing the result of type Any and the defining polynomial. I hope you admit
+that this is ugly.\end{verbatim}
+\subsection{email 18}
+\begin{verbatim}
+I have been thinking about your example code.
+On Tuesday, January 11, 2005 9:44 AM you wrote:
+> ...
+> I just tried another example, which is in fact the reason
+> why I would love to have Aldor working. I did not expect
+> it to work, and it does not, but it works *almost*. The
+> code is as follows:
+>
+> #include "axiom"
+>
+> Test: with { f: (n: PositiveInteger) -> PrimeField(n) }
+> == add { f(n: PositiveInteger): PrimeField(n) ==
+> 10::Integer::PrimeField(n) }
+>
+> Note that such a construction -- the resulting domain
+> depending on the function parameter -- is currently
+> illegal in Axiom. In Aldor it is fine.
-=====================================================================
-The VERSIONCHECK variable came about when we were writing the Aldor
-compiler. We had completely reimplemented the algebra so that it was
-incompatible with previous versions. This is checked on loading.
+I don't really understand when the use of parameterized
+return types on functions would be useful. What information
+is being returned as part of the type of the result that
+is not already known because of it's value?
-(|/VERSIONCHECK| 2)
+As I see it the concept does considerable damage to the
+notion of the 'domain' of a function. How should we interpret
+the expressioin `PrimeField(n)' when n is unknown? Does it
+represent the Union over all values n? We can no longer
+write the signature of a function in the simple form:
-=====================================================================
-This implements the
- a = b == a =$Rep b
-function. Note that the function name |CHAR;=;2$B;1| is constructed
-from the domain abbreviation; the function name; the number of arguments
-and their types; and a unique number
+ f: PositiveInteger -> PrimeField
+
+Can you explain again why you don't find the usual Axiom
+solution to this situation acceptible? I.e. the use of
+the `Any' domain:
+
+ f:PositiveInteger->Any
+ f(n) == n::PrimeField(n)
+
+Perhaps in some cases the use of a Union might even be
+better:
+
+ f:PositiveInteger->Union(PrimeField(2),PrimeField(3),
+ PrimeField(5), ...)
+ f(n) == n::PrimeField(n)
+
+The union allows a 'case' construction like this:
+
+ f(3) case PrimeField(3)
+
+In fact this sort of thing works in Axiom:
+
+(1) -> f:PositiveInteger->Union(PrimeField(2),PrimeField(3), _
+ PrimeField(5),PrimeField(7),"Failed")
+ f(n) == ( prime? n and n<=7 => n::PrimeField(n); "Failed")
+
+ Function declaration f : PositiveInteger -> Union(PrimeField 2,
+ PrimeField 3,PrimeField 5,PrimeField 7,Failed) has been added to
+ workspace.
+ Type: Void
+(2) -> f(2)
+ Cannot compile conversion for types involving local variables. In
+ particular, could not compile the expression involving ::
+ PrimeField #1
+ AXIOM will attempt to step through and interpret the code.
+ Compiling function f with type PositiveInteger -> Union(PrimeField 2
+ ,PrimeField 3,PrimeField 5,PrimeField 7,Failed)
+
+ (2) 0
+ Type: Union(PrimeField 2,...)
+(3) -> f(3)
+
+ (3) 0
+ Type: Union(PrimeField 3,...)
+(4) -> f(4)
+
+ (4) Failed
+ Type: Union(Failed,...)
+(5) -> f(5)
+
+ (5) 0
+ Type: Union(PrimeField 5,...)
+
+(6) -> x:=f(5)
+
+ (6) 0
+ Type: Union(PrimeField 5,...)
+
+(7) -> x case PrimeField(5)
+
+ (7) true
+ Type: Boolean
+(8) -> x case PrimeField(3)
+
+ (8) false
+ Type: Boolean
+etc.\end{verbatim}
+\subsection{email 19}
+\begin{verbatim}
+Peter Broadbery writes:
+ > On Tue, 2005-01-11 at 14:30 +0100, Martin Rubey wrote:
+ > > Dear Peter,
+ > >
+ > > this is just great stuff -- nearly... I had to try it out right away, but
I
+ > > experienced two problems.
+ > >
+ > > the minor one is, that )co inside axiom still does not work:
+ > >
+ > > (1) ->
+ > > (1) -> )co test.as
+ > > Compiling AXIOM source code from file
+ > > /home/rubey/martin/Axiom/test.as using AXIOM-XL compiler and
+ > > options
+ > > -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y
+ > > $AXIOM/algebra
+ > > Use the system command )set compiler args to change these
+ > > options.
+ > >
+ > > >> System error:
+ > > NIL is not of type STRING.
+ >
+ >
+ > ln -s $ALDORROOT $AXIOM/compiler may help here. fixing i-syscmd.boot to
+ > produce a nice error would be nice, I guess.
+
+I tried that, but it won't work. Tim, is there a way to trace what's happening?
+
+Note that both $ALDORROOT and $AXIOM were set correctly. In other words, the
+link above produced a directory "compiler" in "axiom/mnt/linux", containing the
+following directories of Aldor: bin/ doc/ include/ lib/ src/ tests/
+
+ > The .as file isn't in CVS (the file is compiled - don't be fooled by the
+ > readable coding style)
+
+Sorry, my mistake. Only lsp files. By the way, there i *lots* of stuff in the
+directories under /lsp/ccl/src, some look like they could be really useful...
+
+Tim: could you rename them to .pamphlet and correct the \usepackage line in
+each one of them? Thanks!
+
+ > > (1) -> fact(5)$Test
+ > >
+ > > (1) 120
+ > > Type:
+ > > PositiveInteger
+ > > (2) -> fact(4)$Test
+ > >
+ > > >> System error:
+ > > #<vector 08cf4150> is not of type LIST.
+ > >
+ >
+ > Fixed by the patch I send earlier (I hope)...
+
+Yes indeed! (I found that there was only one line you had to comment out?)
+
+ > The significant bit is removing an unbound variable from as.boot, the
+ > rest is to fix the )co command (obviously not bullet proof), and the .ap
+ > file generation.
+ >
+ > In terms of aldor internal knowledge, you don't need that much, the hard
+ > work is on the axiom side. The trick is to load all the aldor runtime
+ > env interpreted and see what breaks (this includes daase.lisp, as.clisp
+ > & interop.clisp, plus the aldor .lsp files). This stuff used to vaguely
+ > work, so putting it back in shape can't be too bad.
+
+In another mail, you wrote:
+
+ > As long as you don't use the sig. from the interpreter, you will be ok
+ > (which misses the point,, I know). As far as fixing the error, not really,
+ > I don't know the axiom interpreter that well. Finding how & where the type
+ > is substituted would be a good start [There must be someone who does...]
+
+Who could this be? It would be just wonderful to get this working!
+
+Thanks a million times,
+
+\end{verbatim}
+\subsection{email 20}
+\begin{verbatim}
+On Tue, 2005-01-11 at 14:30 +0100, Martin Rubey wrote:
+> Dear Peter,
+>
+> this is just great stuff -- nearly... I had to try it out right away, but I
+> experienced two problems.
+>
+> the minor one is, that )co inside axiom still does not work:
+>
+> (1) ->
+> (1) -> )co test.as
+> Compiling AXIOM source code from file
+> /home/rubey/martin/Axiom/test.as using AXIOM-XL compiler and
+> options
+> -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra
+> Use the system command )set compiler args to change these
+> options.
+>
+> >> System error:
+> NIL is not of type STRING.
-Also note that the compiler claims that it knows that the '='
-function can be replaced with lisp 'EQL' in compiled code so
-this function is never run. It uses a property list marker
-'|SPADreplace|' on the function symbol to implement the replacement
-during compiles.
-(PUT (QUOTE |CHAR;=;2$B;1|) (QUOTE |SPADreplace|) (QUOTE EQL))
+ln -s $ALDORROOT $AXIOM/compiler may help here. fixing i-syscmd.boot to
+produce a nice error would be nice, I guess.
-(DEFUN |CHAR;=;2$B;1| (|a| |b| |$|) (EQL |a| |b|))
-=====================================================================
-This implements the
- a < b == a <$Rep b
-function. Again note that the compiler knows that calls to this
-function can be replaced by the lisp QSLESSP function. The 'QS'
-prefix is a VMLisp idiom. 'Q' == quick (no type check) 'S'=singleinteger
-which, at least in VMLisp turns into a single instruction. QSLESSP
-(uppercased here because spad is case-sensitive and lisp is not)
-is defined in src/interp/vmlisp.lisp.pamphlet as a macro with
-embedded type information.
+> (1) ->
+>
+> Never mind.
+>
+> Unfortunately, there is a more severe issue. I put the following simple
domain
+> in a file "test.as" and compiled it using
+>
+> aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom test.as
+>
+> without any problem. There is only the warning
+>
+> #1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
+>
+> but I suspect that this is of no importance.
-(PUT (QUOTE |CHAR;<;2$B;2|) (QUOTE |SPADreplace|) (QUOTE QSLESSP))
+Yep.
-(DEFUN |CHAR;<;2$B;2| (|a| |b| |$|) (QSLESSP |a| |b|))
-=====================================================================
-This implements
- size() == 256
-and just returns a "boxed integer" (XLAM is a marker for boxing).
-(PUT (QUOTE |CHAR;size;Nni;3|) (QUOTE |SPADreplace|) (QUOTE (XLAM NIL 256)))
+>
+>
+>
-------------------------------------------------------------------------------
+> #include "axiom.as"
+>
+> Test: with { fact: PositiveInteger -> PositiveInteger }
+> == add { fact(n: PositiveInteger): PositiveInteger ==
+> { n <= 1 => 1;
+> res: PositiveInteger := 1;
+> while n > 1 repeat {
+> res := res * n;
+> n := n-1; }
+> res } }
+>
-------------------------------------------------------------------------------
+>
+> After this I start axiom and load runtime and axextend. By the way axextend
+> *is* in the distribution, it's only a little hidden... There is even more
+> obscure stuff in theis directory, maybe it's of use to you!
+>
-(DEFUN |CHAR;size;Nni;3| (|$|) 256)
+The .as file isn't in CVS (the file is compiled - don't be fooled by the
+readable coding style)
-=====================================================================
-This implements the
- index n == char((n - 1)::Integer)
-function. Notice that this does a 'QREFELT'. This is another VMLisp
-idiom 'Q' is quick, 'REFELT' is a vector lookup function. This is
-also implmented as a macro in src/interp/vmlisp.lisp.pamphlet where
-it does a 'svref', simple vector reference into the current domain
-(that's what '|$|' means) and calls the 18th element from this domain.
+> (1) -> )sh Test
+> Test is a domain constructor
+> Abbreviation for Test is TEST
+> This constructor is exposed in this frame.
+> Issue )edit test.as to see algebra source code for TEST
+>
+> ------------------------------- Operations --------------------------------
+> fact : PositiveInteger -> PositiveInteger
+>
+> (1) -> fact(5)$Test
+>
+> (1) 120
+> Type: PositiveInteger
+> (2) -> fact(4)$Test
+>
+> >> System error:
+> #<vector 08cf4150> is not of type LIST.
+>
-The domain is represented by a vector (the domain vector) which you'll
-find at the bottom of this file. The domain vector for a domain is
-kept on the property list of the domain name symbol, in this case it
-is "Character". So we see the code:
+Fixed by the patch I send earlier (I hope)...
-(MAKEPROP (QUOTE |Character|) (QUOTE |infovec|) (LIST (QUOTE #(NIL NIL ...
-The |infovec|, the information vector, contains a lot of domain specific
-information which is looked up at runtime. In this case we are doing a
-(QVREFELT |$| 18). If you count 18 elements into the |infovec| you'll
-find |CHAR;char;I$;6|. If you examine the symbol name carefully you
-can decode that it is a function from the domain "CHAR" (this domain)
-called "char" that takes one argument of type "I" (integer), and is
-the 6th function in this domain, which happens to be
- char(n:Integer) == n::%
+> By the way, could you explain what your patches are doing? It's just a
mystery
+> to me! I suspect that one needs some knowledge of Aldor internals?
-So this function does what it says, it subtracts 1 from its argument,
-treats it as an integer and returns the integer. The reason this works
-is that "Characters" have a representation of SingleInteger:
- Rep := SingleInteger -- 0..255
+The significant bit is removing an unbound variable from as.boot, the
+rest is to fix the )co command (obviously not bullet proof), and the .ap
+file generation.
-(DEFUN |CHAR;index;Pi$;4| (|n| |$|) (SPADCALL (|-| |n| 1) (QREFELT |$| 18)))
+In terms of aldor internal knowledge, you don't need that much, the hard
+work is on the axiom side. The trick is to load all the aldor runtime
+env interpreted and see what breaks (this includes daase.lisp, as.clisp
+& interop.clisp, plus the aldor .lsp files). This stuff used to vaguely
+work, so putting it back in shape can't be too bad. \end{verbatim}
+\subsection{email 21}
+\begin{verbatim}
+I just tried another example, which is in fact the reason why I would love to
+have Aldor working. I did not expect it to work, and it does not, but it works
+*almost*. The code is as follows:
-.....[snip]....
+#include "axiom"
-=====================================================================
-This is the function that gets executed when "Character" gets instantiated.
-This function has the effect, if memory serves, of putting the function
-"Character;" into the |$ConstructorCache|. The |$ConstructorCache| is a
-hash table used for fast lookup and function dispatch. The call to
-|Character| will call |Character;| (see below).
+Test: with { f: (n: PositiveInteger) -> PrimeField(n) }
+ == add { f(n: PositiveInteger): PrimeField(n) ==
+ 10::Integer::PrimeField(n) }
-(DEFUN |Character| NIL
- (PROG NIL
- (RETURN
- (PROG (#1=#:G90941)
- (RETURN
- (COND
- ((LETT #1# (HGET |$ConstructorCache| (QUOTE |Character|))
- |Character|)
- (|CDRwithIncrement| (CDAR #1#)))
- ((QUOTE T)
- (|UNWIND-PROTECT|
- (PROG1
- (CDDAR
- (HPUT |$ConstructorCache|
- (QUOTE |Character|)
- (LIST
- (CONS NIL (CONS 1 (|Character;|))))))
- (LETT #1# T |Character|))
- (COND
- ((NOT #1#)
- (HREM |$ConstructorCache| (QUOTE |Character|))))))))))))
+Note that such a construction -- the resulting domain depending on the function
+parameter -- is currently illegal in Axiom. In Aldor it is fine.
-=====================================================================
-This function initializes the |infovec| data structure. Notice the calls
-to QSETREFV, another VMLisp-ism, which does a "(setf (svref ...", that
-is, it sets an element of a simple vector (|infovec|). Notice the call
-to |SingleInteger|. This will cause the domain SingleInteger to be loaded,
-initialized, and put in the constructor cache. This domain needs the
-SingleInteger domain for its representation.
+I compiled it with Aldor as usual, and then loaded it into Axiom. As signature
+I got the slightly unusual
-(DEFUN |Character;| NIL
- (PROG (|dv$| |$| |pv$| #1=#:G90939 |i|)
- (RETURN
- (SEQ
- (PROGN
- (LETT |dv$| (QUOTE (|Character|)) . #2=(|Character|))
- (LETT |$| (GETREFV 53) . #2#)
- (QSETREFV |$| 0 |dv$|)
- (QSETREFV |$| 3 (LETT |pv$| (|buildPredVector| 0 0 NIL) . #2#))
- (|haddProp| |$ConstructorCache| (QUOTE |Character|) NIL (CONS 1 |$|))
- (|stuffDomainSlots| |$|)
- (QSETREFV |$| 6 (|SingleInteger|))
- (QSETREFV |$| 10
- (SPADCALL
- (PROGN
- (LETT #1# NIL . #2#)
- (SEQ
- (LETT |i| 0 . #2#)
- G190
- (COND
- ((QSGREATERP |i| 255) (GO G191)))
- (SEQ
- (EXIT
- (LETT #1# (CONS (NUM2CHAR |i|) #1#) . #2#)))
- (LETT |i| (QSADD1 |i|) . #2#)
- (GO G190)
- G191
- (EXIT (NREVERSE0 #1#))))
- (QREFELT |$| 9)))
- (QSETREFV |$| 11 0) |$|)))))
+(1) -> )di op f
-=====================================================================
-This is the actual representation of the Character domain. The main
-point of the compiler is to construct the |infovec|. I'm not up to
-explaining the details of this at this moment.
+There is one unexposed function called f :
+ [1] PositiveInteger -> PrimeField n from Test
-(MAKEPROP
- (QUOTE |Character|)
- (QUOTE |infovec|)
- (LIST
- (QUOTE
- #(NIL NIL NIL NIL NIL NIL (QUOTE |Rep|) (|List| 28) (|PrimitiveArray| 28)
- (0 . |construct|) (QUOTE |OutChars|) (QUOTE |minChar|) (|Boolean|)
- |CHAR;=;2$B;1| |CHAR;<;2$B;2| (|NonNegativeInteger|) |CHAR;size;Nni;3|
- (|Integer|) |CHAR;char;I$;6| (|PositiveInteger|) |CHAR;index;Pi$;4|
- |CHAR;ord;$I;7| |CHAR;lookup;$Pi;5| (5 . |coerce|) |CHAR;random;$;8|
- |CHAR;space;$;9| |CHAR;quote;$;10| |CHAR;escape;$;11| (|OutputForm|)
- |CHAR;coerce;$Of;12| (|CharacterClass|) (10 . |digit|) (|Character|)
- (14 . |member?|) |CHAR;digit?;$B;13| (20 . |hexDigit|)
- |CHAR;hexDigit?;$B;14| (24 . |upperCase|) |CHAR;upperCase?;$B;15|
- (28 . |lowerCase|) |CHAR;lowerCase?;$B;16| (32 . |alphabetic|)
- |CHAR;alphabetic?;$B;17| (36 . |alphanumeric|) |CHAR;alphanumeric?;$B;18|
- (|String|) |CHAR;latex;$S;19| (40 . |minIndex|) (45 . |elt|)
- |CHAR;char;S$;20| |CHAR;upperCase;2$;21| |CHAR;lowerCase;2$;22|
- (|SingleInteger|))) (QUOTE #(|~=| 51 |upperCase?| 57 |upperCase| 62
- |space| 67 |size| 71 |random| 75 |quote| 79 |ord| 83 |min| 88 |max| 94
- |lowerCase?| 100 |lowerCase| 105 |lookup| 110 |latex| 115 |index| 120
- |hexDigit?| 125 |hash| 130 |escape| 135 |digit?| 139 |coerce| 144 |char|
- 149 |alphanumeric?| 159 |alphabetic?| 164 |>=| 169 |>| 175 |=| 181 |<=|
- 187 |<| 193)) (QUOTE NIL)
- (CONS (|makeByteWordVec2| 1
- (QUOTE (0 0 0 0 0 0)))
- (CONS
- (QUOTE #(NIL |OrderedSet&| NIL |SetCategory&| |BasicType&| NIL))
- (CONS
- (QUOTE #((|OrderedFinite|) (|OrderedSet|) (|Finite|)
- (|SetCategory|) (|BasicType|) (|CoercibleTo| 28)))
- (|makeByteWordVec2| 52
- (QUOTE
- (1 8 0 7 9 1 6 0 17 23 0 30 0 31 2 30 12 32 0 33 0 30 0 35 0
- 30 0 37 0 30 0 39 0 30 0 41 0 30 0 43 1 45 17 0 47 2 45 32 0
- 17 48 2 0 12 0 0 1 1 0 12 0 38 1 0 0 0 50 0 0 0 25 0 0 15 16
- 0 0 0 24 0 0 0 26 1 0 17 0 21 2 0 0 0 0 1 2 0 0 0 0 1 1 0 12
- 0 40 1 0 0 0 51 1 0 19 0 22 1 0 45 0 46 1 0 0 19 20 1 0 12 0
- 36 1 0 52 0 1 0 0 0 27 1 0 12 0 34 1 0 28 0 29 1 0 0 45 49 1
- 0 0 17 18 1 0 12 0 44 1 0 12 0 42 2 0 12 0 0 1 2 0 12 0 0 1 2
- 0 12 0 0 13 2 0 12 0 0 1 2 0 12 0 0 14))))))
- (QUOTE |lookupComplete|)))
+and trying it out I obtained
-(MAKEPROP (QUOTE |Character|) (QUOTE NILADIC) T)
+(1) -> f(5)$Test
+ Loading /home/rubey/axiom/mnt/linux/algebra/PF.o for domain
+ PrimeField
+ Loading /home/rubey/axiom/mnt/linux/algebra/IPF.o for domain
+ InnerPrimeField
+ Loading /home/rubey/axiom/mnt/linux/algebra/TABLE.o for domain Table
+
+ Loading /home/rubey/axiom/mnt/linux/algebra/HASHTBL.o for domain
+ HashTable
+ Loading /home/rubey/axiom/mnt/linux/algebra/INTABL.o for domain
+ InnerTable
+ Loading /home/rubey/axiom/mnt/linux/algebra/ZMOD.o for domain
+ IntegerMod
+
+
+ >> System error:
+ |n| is not of type NUMBER.
+
+protected-symbol-warn called with (NIL)
+
+which is roughly what I expected. However, to my great surprise, if you turn on
+the debugger (beforehand. You always have to start a fresh axiom because of the
+error I told you about in my previous message) with
+)lisp (setq |$monitorNewWorld| t)
+and thus trace
+(1) -> f(1783)$Test
+the final bit reads
-\end{verbatim}
-\section{email 26}
+protected-symbol-warn called with (NIL)..IntegerMod 1783 wants
+ positiveRemainder : (%,%) -> % from Integer
+---->Integer----> searching op table for:
+ positiveRemainder : (%,%) -> % from Integer
+<----#<compiled-function |INT;positiveRemainder;3$;28|> Integer
+goget stuffing slot 47 of IntegerMod 1783
+<------#<compiled-function |INT;positiveRemainder;3$;28|> Integer
+
+PrimeField n activating lazy slot 8: Integer
+PrimeField n activating lazy slot 9: IntegerPrimesPackage Integer
+
+..PrimeField n wants
+ prime? : Integer -> Boolean from IntegerPrimesPackage Integer
+---->IntegerPrimesPackage Integer----> searching op table for:
+ prime? : Integer -> Boolean from IntegerPrimesPackage Integer
+<----#<compiled-function |PRIMES;prime?;IB;4|>(IntegerPrimesPackage,Integer)
+goget stuffing slot 10 of PrimeField n
+<------#<compiled-function |PRIMES;prime?;IB;4|>(IntegerPrimesPackage,Integer)
+
+
+which clearly tells you, that the calculation is done alright, only the
+signature interferes with success.
+
+Any ideas?\end{verbatim}
+\subsection{email 22}
\begin{verbatim}
-=====================================================================
-This is the function that gets executed when "Character" gets instantiated.
-This function has the effect, if memory serves, of PUTTING THE FUNCTION
- ^^^^^^^^^^^^^^^^^^^^
- wrong, wrong, wrong
+this is just great stuff -- nearly... I had to try it out right away, but I
+experienced two problems.
-"Character;" into the |$ConstructorCache|. The |$ConstructorCache| is a
-hash table used for fast lookup and function dispatch. The call to
-|Character| will call |Character;| (see below).
+the minor one is, that )co inside axiom still does not work:
-(DEFUN |Character| NIL
-=====================================================================
+ AXIOM Computer Algebra System
+ Version: Axiom 3.0 Beta (February 2005)
+ Timestamp: Tuesday January 11, 2005 at 14:02:04
+-----------------------------------------------------------------------------
+ Issue )copyright to view copyright notices.
+ Issue )summary for a summary of useful system commands.
+ Issue )quit to leave AXIOM and return to shell.
+-----------------------------------------------------------------------------
+
+ Re-reading compress.daase Re-reading interp.daase
+ Re-reading operation.daase
+ Re-reading category.daase
+ Re-reading browse.daase
+(1) ->
+(1) -> )co test.as
+ Compiling AXIOM source code from file
+ /home/rubey/martin/Axiom/test.as using AXIOM-XL compiler and
+ options
+-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra
+ Use the system command )set compiler args to change these
+ options.
+
+ >> System error:
+ NIL is not of type STRING.
+protected-symbol-warn called with (NIL)
+(1) -> )co test
+ Compiling AXIOM source code from file
+ /home/rubey/martin/Axiom/test.as using AXIOM-XL compiler and
+ options
+-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra
+ Use the system command )set compiler args to change these
+ options.
+
+ >> System error:
+ NIL is not of type STRING.
+protected-symbol-warn called with (NIL)
+(1) ->
-is slightly wrong. It does NOT put the function |Character;| in the
-|$ConstructorCache|, it puts the RESULT of calling (|Character;|)
-in the cache, which is a fully initialized |infovec| object.
+Never mind.
+Unfortunately, there is a more severe issue. I put the following simple domain
+in a file "test.as" and compiled it using
-You'll also find the function call
+aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom test.as
- (|stuffDomainSlots| |$|)
+without any problem. There is only the warning
-in |Character;| interesting. The function is actually defined in
-src/interp/nrunopt.boot.pamphlet. From that function you can
-reverse-engineer the contents of the initial slots (which are just
- #(NIL NIL NIL NIL NIL NIL ....
-at compile time.
+#1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
-Clearly documenting stuffDomainSlots would help as would documenting
-all of the rest of it.
+but I suspect that this is of no importance.
-Also, for your amusement, try the following:
-axiom
-(1)-> )lisp (setq $DALYMODE t)
-(1)-> )set message autoload on
-(1)-> (maphash #'(lambda (key val) (format t "key=~a val=~a~%~%" key val))
-|$ConstructorCache|)
-(1)-> 1
-(1)-> (maphash #'(lambda (key val) (format t "key=~a val=~a~%~%" key val))
-|$ConstructorCache|)
+-------------------------------------------------------------------------------
+#include "axiom.as"
-The first maphash returns NIL
+Test: with { fact: PositiveInteger -> PositiveInteger }
+ == add { fact(n: PositiveInteger): PositiveInteger ==
+ { n <= 1 => 1;
+ res: PositiveInteger := 1;
+ while n > 1 repeat {
+ res := res * n;
+ n := n-1; }
+ res } }
+-------------------------------------------------------------------------------
-The second maphash returns the loaded domains. The messages that get
-printed (from loadlib in src/interp/lisplib.boot.pamphlet) turn out
-to be the same domains you'll see in the constructor cache. Loading
-the domain causes it to be "instantiated" which means that the
-infovec for the domain gets filled in and stuck in the constructorcache.
+After this I start axiom and load runtime and axextend. By the way axextend
+*is* in the distribution, it's only a little hidden... There is even more
+obscure stuff in theis directory, maybe it's of use to you!
-If a domain is already in the constructor cache it will not be loaded.
-Thus domain loading occurs on demand and only once.
+ AXIOM Computer Algebra System
+ Version: Axiom 3.0 Beta (February 2005)
+ Timestamp: Tuesday January 11, 2005 at 14:02:04
+-----------------------------------------------------------------------------
+ Issue )copyright to view copyright notices.
+ Issue )summary for a summary of useful system commands.
+ Issue )quit to leave AXIOM and return to shell.
+-----------------------------------------------------------------------------
+
+ Re-reading compress.daase Re-reading interp.daase
+ Re-reading operation.daase
+ Re-reading category.daase
+ Re-reading browse.daase
+(1) ->
+(1) -> )lisp (load "/home/rubey/aldor/linux/1.0.2/lib/runtime.lsp")
-\end{verbatim}
-\section{email 27}
-\begin{verbatim}
-On Mon, Jan 10, 2005 at 09:47:36PM -0500, root wrote:
-> The code was changed. It used to read:
->
-> one?(x) == ONEP(x)$Lisp
->
-> It now reads:
->
-> one?(x) == x = 1
+Value = T
+(1) -> )lisp (load
+"/home/rubey/axiom--main--1--patch-24/lsp/ccl/src/axbase/compiler/lib/axextend.lsp")
+
+Value = T
+(1) -> )lib test
+ Reading /home/rubey/martin/Axiom/test.asy
+ Loading /home/rubey/axiom/mnt/linux/autoload/bc-matrix.
+ Loading /home/rubey/axiom/mnt/linux/autoload/bc-misc.
+ Loading /home/rubey/axiom/mnt/linux/autoload/bc-solve.
+ Loading /home/rubey/axiom/mnt/linux/autoload/bc-util.
+ Loading /home/rubey/axiom/mnt/linux/autoload/ht-util.
+ Loading /home/rubey/axiom/mnt/linux/autoload/htsetvar.
+ Loading /home/rubey/axiom/mnt/linux/autoload/ht-root.
+ Loading /home/rubey/axiom/mnt/linux/autoload/br-con.
+ Loading /home/rubey/axiom/mnt/linux/autoload/br-data.
+ Loading /home/rubey/axiom/mnt/linux/autoload/showimp.
+ Loading /home/rubey/axiom/mnt/linux/autoload/br-op1.
+ Loading /home/rubey/axiom/mnt/linux/autoload/br-op2.
+ Loading /home/rubey/axiom/mnt/linux/autoload/br-search.
+ Loading /home/rubey/axiom/mnt/linux/autoload/br-util.
+ Loading /home/rubey/axiom/mnt/linux/autoload/topics.
+ Loading /home/rubey/axiom/mnt/linux/autoload/br-prof.
+ Loading /home/rubey/axiom/mnt/linux/autoload/br-saturn.
+ Test is now explicitly exposed in frame frame0
+ Test will be automatically loaded when needed from
+ /home/rubey/martin/Axiom/test
+(1) -> )sh Test
+ Test is a domain constructor
+ Abbreviation for Test is TEST
+ This constructor is exposed in this frame.
+ Issue )edit test.as to see algebra source code for TEST
+------------------------------- Operations --------------------------------
+ fact : PositiveInteger -> PositiveInteger
-True, but the bootstrap code does not contain any definition. We have:
+(1) -> fact(5)$Test
-(DEFUN |SINT;zero?;$B;38| (|x| $) (QSZEROP |x|))
+ (1) 120
+ Type: PositiveInteger
+(2) -> fact(4)$Test
+
+ >> System error:
+ #<vector 08cf4150> is not of type LIST.
-(DEFUN |SINT;max;3$;39| (|x| |y| $) (QSMAX |x| |y|))
+protected-symbol-warn called with (NIL)
-The last number in the function names gives the order of the function
-in definition in the domain. The definition of `one?' follows
-`zero?'. With fresh code we have:
+:-(
-(DEFUN |SINT;zero?;$B;38| (|x| $) (QSZEROP |x|))
+I am already very very happy, but another patch and/or explanation would
+greatly improve this...
-(DEFUN |SINT;one?;$B;39| (|x| $) (EQL |x| 1))
+By the way, could you explain what your patches are doing? It's just a mystery
+to me! I suspect that one needs some knowledge of Aldor internals?
-(DEFUN |SINT;max;3$;40| (|x| |y| $) (QSMAX |x| |y|))
+\end{verbatim}
+\subsection{email 23}
+\begin{verbatim}
+I've been playing with the aldor/axiom stuff a little, and the following
+patch may help get things going(I used to work on it, and thought it'd
+be fun to get it going again).
+There are further problems:
+- aldor "extend" does not work - it ought to, I think
+- The algebra defined in libaxiom.al is not current, and for it to be
+rebuilt various .as files need to be available to the build process
+(axextend.as and friends) - any reason why they're left out of the
+distribution?
+- exported attributes from aldor domains are explicitly killed off by
+this patch (it's probably easy to fix, just no time atm).
+- Only tested the most trivial domains I could find.
-It was precisely this change in sequence that allowed me to spot this
-missing function by looking at the domain vectors. All domains which
-relied of functions defined in SINT with `sequence number' > 38
-shifted by one in the second pass of the fixed-point build.
+Peter.
\end{verbatim}
-\section{email 28}
+
+\subsection{email 28}
\begin{verbatim}
It is possible to use the Aldor compiler to compile functions which you then
can use in Axiom. Unfortunately, I could not get Domains and Packages to work.
@@ -2701,7 +3796,7 @@
)lib fact
fact(5)\end{verbatim}
-\section{email 29}
+\subsection{email 29}
\begin{verbatim}
root writes:
> I'm sorry but your note suffers from "context depravation", that is,
@@ -2734,7 +3829,4 @@
do not work. They should, but they don't. I would be *VERY* grateful, if you
could give me pointers.\end{verbatim}
-\section{email 30}
-\begin{verbatim}
-\end{verbatim}
\end{document}
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Axiom-developer] Patches for book--main--1,
Kai Kaminski <=