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

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Sun, 02 Jul 2006 15:09:21 +0200
From: Ralf Hemmecke
To: list
Subject: .svn recursive copying bug

Hello,

I've just looked into the problem with the double copying of .svn 
directories and I think I've found the offending lines.

It is in Makefile.pamphlet in the root directory.

There we find

<<literate commands>>=
${MNT}/${SYS}/bin/Makefile.pamphlet:
	@echo 0 ${ENV}
	@echo 10 copying ${SRC}/scripts to ${MNT}/${SYS}/bin
	@cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin

@

and

<<rootdirs>>=
rootdirs: ${MNT}/${SYS}/bin/Makefile.pamphlet
	@echo 11 checking directory structure
	@echo 12 Environment: ${ENV}
	@mkdir -p ${INT}
	@mkdir -p ${OBJ}/${SYS}
	@mkdir -p ${TMP}
	@mkdir -p ${MNT}/${SYS}/bin/lib
	@mkdir -p ${MNT}/${SYS}/doc/src
	@cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin
@

As you can see, the rootdirs target depends on 
${MNT}/${SYS}/bin/Makefile.pamphlet. That means that the copying has 
already done. So the last line in the rootdirs commands is completely 
useless and can be removed.

After fixing that there must be a second fix. MAKE proceeds then into 
the subdirectory src/scripts and processes the Makefile.pamphlet. But 
that file says

OUT=${MNT}/${SYS}/bin

all:
	@echo 1 making ${SRC}/scripts
	@cp -pr * ${OUT}
	@mkdir -p ${OUT}/tex
	@rm -f ${OUT}/Makefile*

clean:
	@echo 2 cleaning ${SRC}/scripts

So, it is another unnecessary copy, since according to the way the build 
is done, that directory is the the first thing that will be created 
anyway. (See toplevel Makefile target "all".

Since I don't quite understand all of the build, I would suggest to do 
the above copy in src/scripts/Makefile.pamphlet in a similar way as in 
the top-level Makefile.

##BEGIN
OUT=${MNT}/${SYS}/bin

all: ${OUT}/Makefile.pamphlet
	-@mkdir -p ${OUT}/tex

${OUT}/Makefile.pamphlet:
	@echo 1 making ${SRC}/scripts
	@cp -pr * ${OUT}
##END



Ralf

----------------------------------------------
 > ~/OTHER/Axiom/silver/axiom>make NOISE=
13 making noweb
patching file modules.c
patching file Makefile
mnt.o(.text+0x366): In function `emitfile':
: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
make[1]: [install-shell] Error 1 (ignored)
make[1]: [install-code] Error 1 (ignored)
texhash: /usr/local/share/texmf/ls-R: no write permission. Skipping...
texhash: /usr/local/lib/texmf/ls-R: no write permission. Skipping...
texhash: /var/lib/texmf/ls-R: no write permission. Skipping...
texhash: /var/lib/texmf/ls-R-TEXMFMAIN: no write permission. Skipping...
texhash: /var/cache/fonts/ls-R: no write permission. Skipping...
make[1]: [install-elisp] Error 1 (ignored)
0 SPAD=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux SYS=linux 
SPD=/home/hemmecke/OTHER/Axiom/silver/axiom 
LSP=/home/hemmecke/OTHER/Axiom/silver/axiom/lsp 
GCLDIR=/home/hemmecke/OTHER/Axiom/silver/axiom/lsp/gcl-2.6.8pre 
SRC=/home/hemmecke/OTHER/Axiom/silver/axiom/src 
INT=/home/hemmecke/OTHER/Axiom/silver/axiom/int 
OBJ=/home/hemmecke/OTHER/Axiom/silver/axiom/obj 
MNT=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt 
ZIPS=/home/hemmecke/OTHER/Axiom/silver/axiom/zips 
TMP=/home/hemmecke/OTHER/Axiom/silver/axiom/obj/tmp 
SPADBIN=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin 
INC=/home/hemmecke/OTHER/Axiom/silver/axiom/src/include 
CCLBASE=/home/hemmecke/OTHER/Axiom/silver/axiom/obj/linux/ccl/ccllisp 
PART=cprogs SUBPART=everything NOISE= GCLVERSION=gcl-2.6.8pre 
TANGLE=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/lib/notangle 
VERSION=Axiom (April 2006) 
PATCH=patchDOCUMENT=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/document 
WEAVE=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/lib/noweave
10 copying /home/hemmecke/OTHER/Axiom/silver/axiom/src/scripts to 
/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin
1 making a linux system, PART=cprogs SUBPART=everything
2 Environment SPAD=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux 
SYS=linux SPD=/home/hemmecke/OTHER/Axiom/silver/axiom 
LSP=/home/hemmecke/OTHER/Axiom/silver/axiom/lsp 
GCLDIR=/home/hemmecke/OTHER/Axiom/silver/axiom/lsp/gcl-2.6.8pre 
SRC=/home/hemmecke/OTHER/Axiom/silver/axiom/src 
INT=/home/hemmecke/OTHER/Axiom/silver/axiom/int 
OBJ=/home/hemmecke/OTHER/Axiom/silver/axiom/obj 
MNT=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt 
ZIPS=/home/hemmecke/OTHER/Axiom/silver/axiom/zips 
TMP=/home/hemmecke/OTHER/Axiom/silver/axiom/obj/tmp 
SPADBIN=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin 
INC=/home/hemmecke/OTHER/Axiom/silver/axiom/src/include 
CCLBASE=/home/hemmecke/OTHER/Axiom/silver/axiom/obj/linux/ccl/ccllisp 
PART=cprogs SUBPART=everything NOISE= GCLVERSION=gcl-2.6.8pre 
TANGLE=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/lib/notangle 
VERSION=Axiom (April 2006)PATCH=patch 
DOCUMENT=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/document 
WEAVE=/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/lib/noweave
This is e-TeX, Version 3.14159-2.1 (Web2C 7.4.5)
entering extended mode
(./Makefile.tex
LaTeX2e <2001/06/01>
Babel <v3.7h> and hyphenation patterns for american, french, german, 
ngerman, b
ahasa, basque, catalan, croatian, czech, danish, dutch, finnish, greek, 
iceland
ic, irish, italian, latin, magyar, norsk, norsk, portuges, romanian, 
russian, s
lovak, slovene, spanish, swedish, turkish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo)) (./src/scripts/tex/axiom.sty)
No file Makefile.aux.
[1]
No file Makefile.toc.
[2] [3]
Overfull \hbox (41.71167pt too wide) in paragraph at lines 74--78
\OT1/cmr/m/n/10 for de-bug-ging pur-poses. We use the spe-cific file 
\OT1/cmtt/
m/n/10 ${MNT}/${SYS}/bin/Makefile.pamphlet
[4] [5] [6] [7] [8]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 290--293
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 
vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[9] [10] [11] [12]
Overfull \hbox (48.74657pt too wide) in paragraph at lines 460--460
[]\OT1/cmtt/m/n/10 the {\tt{}noweb.src.shell.roff.mm.patch} file remove 
the ins
ecure temp file[]

Overfull \hbox (17.24684pt too wide) in paragraph at lines 460--460
[]\OT1/cmtt/m/n/10 {\tt{}noweb.src.lib.toascii.patch} because this is 
not a sou
rce file.[]
[13]
Overfull \hbox (53.99652pt too wide) in paragraph at lines 460--460
[]        \OT1/cmtt/m/n/10 ${ENV} ${MAKE} BIN=${MNT}/${SYS}/bin/lib 
LIB=${MNT}/
${SYS}/bin/lib \[]

Overfull \hbox (48.74657pt too wide) in paragraph at lines 460--460
[]                \OT1/cmtt/m/n/10 TEXINPUTS=${MNT}/${SYS}/bin/tex all 
install
 >${TMP}/trace )[]

Overfull \hbox (22.4968pt too wide) in paragraph at lines 460--460
[]        \OT1/cmtt/m/n/10 @echo The file marks the fact that noweb has 
been ma
de > noweb[]
[14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28]
[29]
Overfull \hbox (83.99927pt too wide) in paragraph at lines 1127--1127
  []\OT1/cmtt/m/n/10 CCF="-O2 -pipe -fno-strength-reduce -Wall 
-D_GNU_SOURCE -D$
{PLF} -I/usr/X11R6/include -I/usr/local/include"[]
[30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44]
[45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] (./Makefile.aux)

LaTeX Warning: Label(s) may have changed. Rerun to get cross-references 
right.

  )
(see the transcript file for additional information)
Output written on Makefile.dvi (55 pages, 81740 bytes).
Transcript written on Makefile.log.
This is e-TeX, Version 3.14159-2.1 (Web2C 7.4.5)
entering extended mode
(./Makefile.tex
LaTeX2e <2001/06/01>
Babel <v3.7h> and hyphenation patterns for american, french, german, 
ngerman, b
ahasa, basque, catalan, croatian, czech, danish, dutch, finnish, greek, 
iceland
ic, irish, italian, latin, magyar, norsk, norsk, portuges, romanian, 
russian, s
lovak, slovene, spanish, swedish, turkish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo)) (./src/scripts/tex/axiom.sty)
(./Makefile.aux) [1] (./Makefile.toc [2]) [3] [4]
Overfull \hbox (41.71167pt too wide) in paragraph at lines 74--78
\OT1/cmr/m/n/10 for de-bug-ging pur-poses. We use the spe-cific file 
\OT1/cmtt/
m/n/10 ${MNT}/${SYS}/bin/Makefile.pamphlet
[5] [6] [7] [8] [9]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 290--293
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 
vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[10] [11] [12] [13]
Overfull \hbox (48.74657pt too wide) in paragraph at lines 460--460
[]\OT1/cmtt/m/n/10 the {\tt{}noweb.src.shell.roff.mm.patch} file remove 
the ins
ecure temp file[]

Overfull \hbox (17.24684pt too wide) in paragraph at lines 460--460
[]\OT1/cmtt/m/n/10 {\tt{}noweb.src.lib.toascii.patch} because this is 
not a sou
rce file.[]
[14]
Overfull \hbox (53.99652pt too wide) in paragraph at lines 460--460
[]        \OT1/cmtt/m/n/10 ${ENV} ${MAKE} BIN=${MNT}/${SYS}/bin/lib 
LIB=${MNT}/
${SYS}/bin/lib \[]

Overfull \hbox (48.74657pt too wide) in paragraph at lines 460--460
[]                \OT1/cmtt/m/n/10 TEXINPUTS=${MNT}/${SYS}/bin/tex all 
install
 >${TMP}/trace )[]

Overfull \hbox (22.4968pt too wide) in paragraph at lines 460--460
[]        \OT1/cmtt/m/n/10 @echo The file marks the fact that noweb has 
been ma
de > noweb[]
[15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]
[30]
Overfull \hbox (83.99927pt too wide) in paragraph at lines 1127--1127
  []\OT1/cmtt/m/n/10 CCF="-O2 -pipe -fno-strength-reduce -Wall 
-D_GNU_SOURCE -D$
{PLF} -I/usr/X11R6/include -I/usr/local/include"[]
[31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45]
[46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] (./Makefile.aux) )
(see the transcript file for additional information)
Output written on Makefile.dvi (56 pages, 105364 bytes).
Transcript written on Makefile.log.
make[1]: Entering directory `/home/hemmecke/OTHER/Axiom/silver/axiom'
11 checking directory structure
12 Environment: PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall 
-D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib 
CC=gcc AWK=gawk RANLIB=ranlib TOUCH=touch TAR=tar 
AXIOMXLROOT=/home/hemmecke/software/Axiom/mnt/linux/compiler O=o BYE=bye 
LISP=lsp DAASE=/home/hemmecke/OTHER/Axiom/silver/axiom/src/share 
XLIB=/usr/X11R6/lib GCLOPTS=--enable-vssize=65536*2 --enable-statsysbfd 
--enable-maxpage=256*1024 SRCDIRS=bootdir interpdir sharedir algebradir 
etcdir clefdir docdir graphdir smandir hyperdir inputdir  PATCH=patch
cp: cannot create regular file 
`/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/tex/.svn/text-base/axiom.sty.svn-base': 
Permission denied
cp: cannot create regular file 
`/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/tex/.svn/prop-base/axiom.sty.svn-base': 
Permission denied
cp: cannot create regular file 
`/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/tex/.svn/props/axiom.sty.svn-work': 
Permission denied
cp: cannot create regular file 
`/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/tex/.svn/wcprops/axiom.sty.svn-work': 
Permission denied
cp: cannot create regular file 
`/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/tex/.svn/entries': 
Permission denied
cp: cannot create regular file 
`/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/tex/.svn/empty-file': 
Permission denied
cp: cannot create regular file 
`/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/tex/.svn/README.txt': 
Permission denied
cp: cannot create regular file 
`/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/tex/.svn/format': 
Permission denied
cp: cannot create regular file 
`/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/bin/tex/.svn/dir-wcprops': 
Permission denied
make[1]: *** [rootdirs] Error 1
make[1]: Leaving directory `/home/hemmecke/OTHER/Axiom/silver/axiom'
make: *** [all] Error 2

\start
Date: Sun, 02 Jul 2006 14:54:06 +0200
From: Ralf Hemmecke
To: list
Subject: src/lib/bsdsignal.c.pamphlet

I have problems in building AXIOM silver. It cannot run the document 
command on

src/lib/bsdsignal.c.pamphlet

With "make NOISE="

I found out that LaTeX complains not knowing about a \wf
command in the line

       & process subsequently issues a {\wf wait()} (or equivalent),\\

I could not find a definition of \wf. So what should it be? Perhaps \sl 
as it appears some lines above in that file? Or perhaps \bf?

\start
Date: Sun, 02 Jul 2006 15:21:53 +0200
From: Ralf Hemmecke
To: list
Subject: bookvol5 does not compile

Another problem...

axiomFront.ps is missing

Well, it appears under src/doc/ps/axiomFront.ps but could not be found 
for the compilation of the book.

The reason is that there is on ps directory in the place where bookvol5 
is compiled.

The corresponding chunk in src/interp/Makefile.pamphlet is

<<bookvol5.dvi (DOC from IN)>>=
${DOC}/bookvol5.dvi: ${IN}/bookvol5.pamphlet ${DOC}/axiom.sty
	@echo 299 making ${DOC}/bookvol5.dvi from ${IN}/bookvol5.pamphlet
	@(cd ${DOC} ; \
	cp ${IN}/bookvol5.pamphlet ${DOC} ; \
	${DOCUMENT} ${NOISE} bookvol5 ; \
	rm -f ${DOC}/bookvol5.pamphlet ; \
	rm -f ${DOC}/bookvol5.tex ; \
	rm -f ${DOC}/bookvol5 )
@

and it is missing a dependency on the directory src/doc/ps.

I still have no complete picture of the building process, but maybe a 
simple solution would be to say

TEXINPUTS=${SRC}/doc:${TEXINPUTS} ${DOCUMENT} ${NOISE} bookvol5 ; \

instead of the line above.

Otherwise copying of the ps directory is necessary, but then one would 
have to take care that this is not done in some other place.

In any case referring to ${SRC}/doc is not a good thing since that 
directory lives at the same level as src/interp and I would rather 
prefer if src/interp does not know about other directories on the same 
directory level.

Ralf

------------------------

299 making 
/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/doc/src/interp/bookvol5.dvi 
from /home/hemmecke/OTHER/Axiom/silver/axiom/src/interp/bookvol5.pamphlet
This is e-TeX, Version 3.14159-2.1 (Web2C 7.4.5)
entering extended mode
(./bookvol5.tex
LaTeX2e <2001/06/01>
Babel <v3.7h> and hyphenation patterns for american, french, german, 
ngerman, b
ahasa, basque, catalan, croatian, czech, danish, dutch, finnish, greek, 
iceland
ic, irish, italian, latin, magyar, norsk, norsk, portuges, romanian, 
russian, s
lovak, slovene, spanish, swedish, turkish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/book.cls
Document Class: book 2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/bk10.clo)) (./axiom.sty)
(/usr/share/texmf/tex/latex/graphics/graphicx.sty
(/usr/share/texmf/tex/latex/graphics/keyval.sty)
(/usr/share/texmf/tex/latex/graphics/graphics.sty
(/usr/share/texmf/tex/latex/graphics/trig.sty)
(/usr/share/texmf/tex/latex/config/graphics.cfg)
(/usr/share/texmf/tex/latex/graphics/dvips.def)))
No file bookvol5.aux.

LaTeX Warning: File `ps/axiomFront.ps' not found on input line 15.


! LaTeX Error: File `ps/axiomFront.ps' not found.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
  ...

l.15 \center{\includegraphics{ps/axiomFront.ps}
                                                }
?

\start
Date: Sun, 2 Jul 2006 14:37:17 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: .svn recursive copying bug

seems reasonable.
could you please do:

diff -Naur Makefile.original Makefile.new

and post the results. That way I won't miss any changes. --Tim

\start
Date: 02 Jul 2006 22:13:33 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: .svn recursive copying bug

Tim Daly writes:

| seems reasonable.
| could you please do:
| 
| diff -Naur Makefile.original Makefile.new
| 
| and post the results. That way I won't miss any changes. --Tim

In case it is approved by Tim, please apply it to silver branch, with
entry the appropriate ChangeLog.

\start
Date: Sun, 2 Jul 2006 15:16:37 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: src/lib/bsdsignal.c.pamphlet

src/lib/bsdsignal.c.pamphlet {\wc -> {\sl -- fixed in the next release --t

\start
Date: Sun, 02 Jul 2006 22:26:44 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: .svn recursive copying bug

Hello Tim, hello Gaby,

I am a bit confused now, Why do we have the silver branch if all goes 
immediately to Tim's private gold branch? Shouldn't we have the policy 
that a patch is sent to silver then it needs someone to approve and then 
  Tim could easily extract it from the silver branch (even together with 
the svn log and/or ChangeLog).

For this simple modification of the TWO files
   Makefile.pamphlet and
   src/scripts/Makefile.pamphlet
it is perhaps not a big modification so that I could commit it directly 
to the trunk. But, Gaby, what is the general rule (for someone who has 
write access to Silver)?

Would that be as follows?

   1) open up a new branch
   2) make modifications (fix bugs or whatever)
   3) announce the bugfix to the list
   4) wait for approval of some other axiom-developer
   5) someone (who?) merges the changes back to the trunk
   6) Tim could extract modifications to his private Gold-branch

Would that be a reasonable policy? In fact, I would be happy if I could 
find such a policy somewhere on the wiki. In particular, I would like 
just to do one single 'diff -Naur', but that seems to force me to have 
an extra unmodified branch on my harddisk.

I am not for any SCM war I am just eager to learn about maintaining big 
projects. In particular for Axiom, submitting patches that apply to 
several files should be made simpler. It should be allowed to simply 
commit to a branch at Axiom silver.

Ralf


On 07/02/2006 10:13 PM, Gabriel Dos Reis wrote:
> Tim Daly writes:
> 
> | seems reasonable.
> | could you please do:
> | 
> | diff -Naur Makefile.original Makefile.new
> | 
> | and post the results. That way I won't miss any changes. --Tim
> 
> In case it is approved by Tim, please apply it to silver branch, with
> entry the appropriate ChangeLog.

\start
Date: 02 Jul 2006 23:57:18 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: src/lib/bsdsignal.c.pamphlet

Tim Daly writes:

| src/lib/bsdsignal.c.pamphlet {\wc -> {\sl -- fixed in the next release --t

Tim. please could you commit this to silver too?  Thanks.

\start
Date: 03 Jul 2006 00:03:42 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: .svn recursive copying bug

Ralf Hemmecke writes:

| Hello Tim, hello Gaby,
| 
| I am a bit confused now, Why do we have the silver branch if all goes
| immediately to Tim's private gold branch? Shouldn't we have the policy
| that a patch is sent to silver then it needs someone to approve and
| then Tim could easily extract it from the silver branch (even together
| with the svn log and/or ChangeLog).

That has always been my understanding.

The situation I would like to avoid is that patches are checked in on
gold branch, but not the vislver branch -- when the problem affects
all branches.

| For this simple modification of the TWO files
|    Makefile.pamphlet and
|    src/scripts/Makefile.pamphlet
| it is perhaps not a big modification so that I could commit it
| directly to the trunk.

Completely agreed.

| But, Gaby, what is the general rule (for
| someone who has write access to Silver)?

The general algorithm is
 
  (1) send a patch  (against silver branch)
  (2) get it reviewed and approved
  (3) apply it to silver branch

| Would that be as follows?
| 
|    1) open up a new branch
|    2) make modifications (fix bugs or whatever)
|    3) announce the bugfix to the list
|    4) wait for approval of some other axiom-developer
|    5) someone (who?) merges the changes back to the trunk
|    6) Tim could extract modifications to his private Gold-branch

I thinkk step 1) is necessary if and only if the fix involves very
substantial modification as the one being done with recent algebra
commits.  Step 5) should be done by the maintainer of the branch.

| Would that be a reasonable policy? In fact, I would be happy if I
| could find such a policy somewhere on the wiki. In particular, I would
| like just to do one single 'diff -Naur', but that seems to force me to
| have an extra unmodified branch on my harddisk.
| 
| I am not for any SCM war I am just eager to learn about maintaining
| big projects. In particular for Axiom, submitting patches that apply
| to several files should be made simpler. It should be allowed to
| simply commit to a branch at Axiom silver.

Point taken and I very much appreciate the you looking into these
issues.

\start
Date: Sun, 02 Jul 2006 23:24:55 +0200
From: Ralf Hemmecke
To: list
Subject: docfix for transsolve.spad

Since Axiom should "just work" I wonder how with all the tests that Tim 
runs all the time something like

-----
\begin{verbatim}
   solve(sinh(z)=cosh(z),z)
\end{verbatim}
generates the error (reported as bug # 102):
\begin{verbatim}
  >> Error detected within library code:
     No identity element for reduce of empty list using operation append
\end{verbatim}
-----

can be read in src/algebra/transsolve.spad.pamphlet. Of course, the # 
must be escaped to \#.

Patch is attached.

silver/axiom/src/algebra>diff -Naur transsolve.spad.pamphlet 
transsolve.spad.pamphlet.new > patch.transsolve.spad.pamphlet

Ralf

--------------070802010801090105040203
 name="patch.transsolve.spad.pamphlet"
 filename="patch.transsolve.spad.pamphlet"

--- transsolve.spad.pamphlet	2006-07-02 23:05:52.000000000 +0200
+++ transsolve.spad.pamphlet.new	2006-07-02 23:13:27.000000000 +0200
@@ -510,7 +510,7 @@
 \begin{verbatim}
   solve(sinh(z)=cosh(z),z)
 \end{verbatim}
-generates the error (reported as bug # 102):
+generates the error (reported as bug \# 102):
 \begin{verbatim}
  >> Error detected within library code:
     No identity element for reduce of empty list using operation append

--------------070802010801090105040203--

\start
Date: Sun, 02 Jul 2006 23:32:47 +0200
From: Ralf Hemmecke
To: list
Subject: recursive copying problem with .svn

My compilation does still not go through. Now I've found something near

4 making /home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/doc/book.dvi 
from /home/hemmecke/OTHER/Axiom/silver/axiom/src/doc/book.pamphlet
4 making 
/home/hemmecke/OTHER/Axiom/silver/axiom/mnt/linux/doc/bookvol1.dvi from 
/home/hemmecke/OTHER/Axiom/silver/axiom/src/doc/bookvol1.pamphlet
cp: cannot create regular file 
`/home/hemmecke/OTHER/Axiom/silver/axiom/int/doc/ps/.svn/text-base/modbessc.ps.svn-base': 
Permission denied

But it is too late in my place to figure out the reason for that problem 
today.

In fact, I would suggest to remove all the @ signs from the Makefiles. 
It is so simple to make 'make' quiet by adding -s to the commandline.

Or does somebody know whether I could make 'make' telling me the 
commands it executes even if they have a @ in front of them?

\start
Date: Sun, 02 Jul 2006 23:46:18 +0200
From: Ralf Hemmecke
To: list
Subject: src/doc/Makefile.pamphlet

OK, it was not late enough... I think the file src/doc/Makefile.pamphlet 
needs a lot of rewrite. A line like

	cp -r ${IN}/ps ${DVI}

appears again and again.

First of all, it does not work with having the .svn subdirs. And second, 
why not taking advantage of 'make' having a target like

${DVI}/ps:
	cp -r ${IN}/ps ${DVI}

and then simply say

'${MAKE} ${DVI}/ps' in places where 'cp -r ${IN}/ps ${DVI}' appears?
That would avoid all this needless copying time.

Is there a particular reason why the copying must be done at all? 
Couldn't tex just given another input directory via the TEXINPUTS variable?

\start
Date: 03 Jul 2006 22:25:17 +0200
From: Martin Rubey
To: list, Bill Page
Subject: IssueTracker modified by non-registered people

Dear Bill,

as you certainly witnessed, some robot or whatever is corrupting our
IssueTracker. I think that this is quite a serious issue...

I see two options:

1) only registered people can modify Issues

2) only registered people can submit or modify Issues.

I vote for 1), if possible, otherwise 2)

Hope you are fine,

\start
Date: 04 Jul 2006 23:35:09 +0200
From: Martin Rubey
To: list
Subject: Why is Axiom so slow?

Dear all,

I am just submitting my article about guessing formulas. One important aspect
of this article is that I am - contrary to the other packages - using fast
algorithms.

So, I wanted to do a speed comparison. I must say, I am shocked. Even though I
used certainly the best algorithms available, they are still *much* slower than
the naive versions in Mathematica or Maple.

I just did another test:

In[2]:= Timing[Table[Random[Integer, 100]+Random[Integer, 100], {i,1,10000}]][[1]]

Out[2]= 0.1 Second

In[3]:= Timing[Table[Random[Integer, 100]+Random[Integer, 100], {i,1,100000}]][[1]]

Out[3]= 1.01 Second


(1) -> 
(1) -> )se me au of
(1) -> )time on
(1) -> l1 := [random(100) for i in 1..10000]; l2 := [random(100) for i in 1..10000];

                                                           Type: List Integer
                         Time: 0.01 (IN) + 14.66 (EV) + 0.25 (GC) = 14.92 sec
(2) -> [l1.i + l2.i for i in 1..2000];

                                                           Type: List Integer
                                       Time: 1.16 (EV) + 0.45 (GC) = 1.61 sec
(3) -> [l1.i + l2.i for i in 1..3000];

                                                           Type: List Integer
                                       Time: 2.47 (EV) + 0.88 (GC) = 3.35 sec

\start
Date: Tue, 4 Jul 2006 23:46:54 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Why is Axiom so slow?

Martin,

On Tuesday, July 04, 2006 5:35 PM you wrote:
>
> I am just submitting my article about guessing formulas. One
> important aspect of this article is that I am - contrary to
> the other packages - using fast algorithms.
>
> So, I wanted to do a speed comparison. I must say, I am
> shocked. Even though I used certainly the best algorithms
> available, they are still *much* slower than the na=EFve
> versions in Mathematica or Maple.

I have to admit that Maple (and Mathematica?) is faster than
Axiom for some things. For example my Maple version of

http://wiki.axiom-developer.org/SandBoxCategoricalRelativity

is at least 10 times faster than the Axiom version above. In
this case I think it has something to do with the implementation
of the AlgebraicNumber domain.

But in your case I do not think you are comparing equivalent
computations.

>
> I just did another test:
>
> In[2]:= Timing[Table[Random[Integer, 100]+Random[Integer,
> 100], {i,1,10000}]][[1]]
>
> Out[2]= 0.1 Second
>
> In[3]:= Timing[Table[Random[Integer, 100]+Random[Integer,
> 100], {i,1,100000}]][[1]]
>
> Out[3]= 1.01 Second
>

As a data structure 'Table' in Mathematica is not the same as
'List' in Axiom.

> (1) -> )se me au of
> (1) -> )time on
> (1) -> l1 := [random(100) for i in 1..10000];
>        l2 := [random(100) for i in 1..10000];
>
>        Type: List Integer
>    Time: 0.01 (IN) + 14.66 (EV) + 0.25 (GC) = 14.92 sec
>...
> Any suggestions?

I think it takes Axiom a long time to build a list this large.
An array data structure can be accessed much more rapidly.
Try something like this instead:

(1) -> l1:=new(10000,0)$ARRAY1(INT); =
map!(x+->random(100)+random(100),l1);

          Type: OneDimensionalArray Integer
    Time: 0.20 (EV) + 0.08 (GC) = 0.28 sec

\start
Date: 05 Jul 2006 08:43:40 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Why is Axiom so slow?

Dear Bill & William,

I admit that my comparison was stupid. However, the real issues are simply too
complex to describe here. In any case, I'm facing a factor 100 between
Mathematica and Axiom... It seems that I'm in big trouble: how can I write that
I'm using advanced algorithms and then have a program that is so extremely
slow?

In any case, I'll install it today on MathAction...

\start
Date: 05 Jul 2006 08:57:02 +0200
From: Martin Rubey
To: Antoine Hersen
Subject: Preliminary fixes for issue 301

--=-=-=

Unfortunately, this is only part of the cure.

There are two big problems with seriesSolve:

* it crashes regularly

* it requires that the expression is linear in the highest derivative.

Antoine, do you think you could write a simple but working replacement?

Martin


--=-=-=

*** exprode.spad	2006-07-05 08:52:04.000000000 +0200
--- /pusers/rubey/axiom/mnt/linux/src/algebra/exprode.spad	2006-05-26 14:06:29.000000000 +0200
***************
*** 118,124 ****
      --opex  := operator("exquo"::Symbol)$OP
      opex  := operator("fixedPointExquo"::Symbol)$OP
      opint := operator("integer"::Symbol)$OP
-     opmon := operator("mymonomial"::Symbol)$OP
  
      Rint? := R has IntegerNumberSystem
  
--- 118,123 ----
***************
*** 171,177 ****
        for i in 2..n repeat
          l  := concat(retract(f := differentiate(f, x))@K, l)
          lv := concat(opelt(sy, localInteger(m := m + 1)), lv)
!       div2exquo subst(subst(diffRhs(differentiate(f, x), diffeq), l, lv), x::F=opmon(1))
  
      checkSystem(diffeq, yx, lv) ==
        for k in kernels diffeq repeat
--- 170,176 ----
        for i in 2..n repeat
          l  := concat(retract(f := differentiate(f, x))@K, l)
          lv := concat(opelt(sy, localInteger(m := m + 1)), lv)
!       div2exquo subst(diffRhs(differentiate(f, x), diffeq), l, lv)
  
      checkSystem(diffeq, yx, lv) ==
        for k in kernels diffeq repeat

--=-=-=

*** utsode.spad	2006-07-04 08:28:49.000000000 +0200
--- /pusers/rubey/axiom/mnt/linux/src/algebra/utsode.spad	2006-05-26 14:06:38.000000000 +0200
***************
*** 64,71 ****
      fixedPointExquo: (UTS,UTS) -> UTS
        ++ fixedPointExquo(f,g) computes the exact quotient of \spad{f} and
        ++ \spad{g} using a fixed point computation.
-     mymonomial: PositiveInteger -> UTS
-       ++ returns the variable as UTS
      ode1: ((UTS -> UTS),Coef) -> UTS
        ++ ode1(f,c) is the solution to \spad{y' = f(y)}
        ++ such that \spad{y(a) = c}.
--- 64,69 ----
***************
*** 105,113 ****
        rhy case "failed" => error "stream division:no reciprocal"
        divloop(hx,tx,rhy::Coef,ty)
  
!     fixedPointExquo(f, g) == series sdiv(coefficients f, coefficients g)
! 
!     mymonomial k == monomial(1,k)
  
  -- first order
  
--- 103,109 ----
        rhy case "failed" => error "stream division:no reciprocal"
        divloop(hx,tx,rhy::Coef,ty)
  
!     fixedPointExquo(f,g) == series sdiv(coefficients f,coefficients g)
  
  -- first order
  
\start
Date: Wed, 05 Jul 2006 04:28:27 -0400
From: William Sit
To: Bill Page
Subject: Re: Why is Axiom so slow?

Hi Bill:

Wow, you are good with Axiom! (and everything else, of course).

> An array data structure can be accessed much more rapidly.
> Try something like this instead:
>
> (1) -> l1:=new(10000,0)$ARRAY1(INT); map!(x+->random(100)+random(100),l1);
>
>           Type: OneDimensionalArray Integer
>     Time: 0.20 (EV) + 0.08 (GC) = 0.28 sec
>

Axiom can even do 100000 in about 1.35 secs. Still about 7 times as long
as the best try in Mathematica.

In[85]:=
Timing[Table[Random[Integer,100]+Random[Integer,100],{i,1,100000}]][[1]]

Out[85]=
0.203 Second

So, the reason for the difference is that List in Axiom is really a
singly linked list and hence has pointer overhead (both time and space),
right? Indeed most of the time is spent that way (or so it seems):

(12) -> l2:=[0 for i in 1..10000]$List(INT);

                                                               Type:
List Any
                           Time: 0.03 (IN) + 3.92 (EV) + 0.02 (OT) =
3.97 sec
(13) -> map!(x+->random(100)+random(100),l2);

                                                               Type:
List Any
                                                                  Time:
0 sec
(Don't know why the type was List Any! Is this a bug?)

Oops,
(14) -> l2
 [157]
                                                                  Type:
List Any
                                                                  Time:
0 sec

Why is Axiom so counter-intuitive? Is this another bug? (the doc says
map! for both ARRAY1 and LIST came from HomogeneousAggregate).

Question: if List in Axiom is that much more inefficient than Array, why
does the Interpreter use List as the default?

Thanks,

William
PS Please change my email address to William Sit.

\start
Date: Wed, 5 Jul 2006 09:44:01 -0400
From: Bill Page
To: William Sit
Subject: axiom-developer subscription email address

William,

You wrote:

> PS Please change my email address to William Sit.

I have enabled submissions to the axiom-developer list from your
new email address (which is all I can do as a list administrator).
This will let you submit messages but the email will still be sent
to your old address.

For security reasons, changing your subscription is something that
you must do yourself. To do that click here:

http://lists.nongnu.org/mailman/options/axiom-developer

and enter your old address and password, then click Login to
change your email address and/or other list options.

To subscribe a new email address go here:

http://lists.nongnu.org/mailman/listinfo/axiom-developer

\start
Date: Wed, 05 Jul 2006 17:22:51 -0400
From: William Sit
To: Bill Page
Subject: Re: axiom-developer subscription email address

Dear Bill:

Thanks for the set up. I have made the changes to my subscription and
this is a test.

\start
Date: Wed, 5 Jul 2006 17:24:49 -0400
From: Bill Page
To: William Sit
Subject: RE: Why is Axiom so slow?

William,

On Wednesday, July 05, 2006 4:28 AM you wrote:
>
> Wow, you are good with Axiom! (and everything else, of course).
>

Well, thank you! <bows> ;-)

> > An array data structure can be accessed much more rapidly.
> > Try something like this instead:
> >
> > (1) -> l1:=new(10000,0)$ARRAY1(INT); _
> >        map!(x+->random(100)+random(100),l1);
> >
> >           Type: OneDimensionalArray Integer
> >     Time: 0.20 (EV) + 0.08 (GC) = 0.28 sec
> >
>
> Axiom can even do 100000 in about 1.35 secs. Still about 7
> times as long as the best try in Mathematica.
>
> In[85]:=
> Timing[Table[Random[Integer,100]+Random[Integer,100],{i,1,1000
> 00}]][[1]]
>
> Out[85]=
> 0.203 Second
>

It seems that Axiom can perform about the same as Mathematica
if we are careful to compile the initialization function before
calling it.

See http://wiki.axiom-developer.org/SandBoxArray

  init1(x:Integer):Integer == random(100)-random(100)
  l1:PRIMARR(INT):=new(100000,0); map!(init1,l1);

This only takes about 0.15 seconds on the AxiomWiki server.

This also shows that overhead for using map! is not very
high (almost not measurable) provided the function is
compiled.

\start
Date: Sun, 9 Jul 2006 00:31:00 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Start of a new axiom.bib file

Hi all.  Since it's been a little quiet, I thought I would mention that
I have figured out how to produce an annotated bibliography for Axiom,
at least insofar as getting the available solutions to function for
this particular case.  An example is here:

http://portal.axiom-developer.org/Members/starseeker/test1.pdf/download

The interesting parts are the example annotation, on page 5, and the
hyperlink to the arXiv site, on page 8.

Still some work to do, and the latter trick requires the eprint.sty
file from the ToC folks, but all in all it looks like it might prove
useful.

\start
Date: Sun, 9 Jul 2006 08:01:00 -0500
From: Tim Daly
To: Cliff Yapp
Subject: axiom bibliography


> Hi all.  Since it's been a little quiet, I thought I would mention that
> I have figured out how to produce an annotated bibliography for Axiom,
> at least insofar as getting the available solutions to function for
> this particular case.  An example is here:
> 
> http://portal.axiom-developer.org/Members/starseeker/test1.pdf/download
> 
> The interesting parts are the example annotation, on page 5, and the
> hyperlink to the arXiv site, on page 8.
> 
> Still some work to do, and the latter trick requires the eprint.sty
> file from the ToC folks, but all in all it looks like it might prove
> useful.

excellent.
i'm overseas at the ISSAC conference for the next week.
i'll look at it further when i return.

\start
Date: Sun, 9 Jul 2006 08:25:24 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: axiom bibliography

I have no idea how useful this might in the future (it might be that
this is useful only for the "bootstrapping" of the bibliography file)
but I'll document what was done anyway just in case we ever have to do
this again.  

>From the directory axiom-patch##-cvs:

grep -r \\author{ */*/*.pamphlet > completelist.txt
grep -r \\author{ */*/*/*.pamphlet >> completelist.txt

Now create a file called "temp1.awk" with the following content: 

 { FS = ":" }
 { sub(/\}/, "") }
 { gsub(/\,/, " and ") }
 { sub(/\\author\{/, "") }
 { namestrng = $1 }
 { titlestrng = $1 }
 { sub(/.pamphlet/,"",titlestrng) }
 { sub(/\_/,"\\_",$1) }
 { print "@PAMPHLET{"namestrng",\n  author={"$2"},\n 
title={"titlestrng"},\n  howpublished = {Axiom},\n 
url={src/algebra/"$1"},\n  owner={user},\n  timestamp =
{2006.06.11},\n}\n" }

(the print line is all on one line in my file, in case the email
clients mess with it)

and run the following command:

gawk -f temp1.awk completelist.txt > axiomtest.bib

Then insert this command at the end of axiomtest.bib (for jabref)

@comment{jabref-entrytype: Pamphlet: req[]
opt[author;title;abstract;howpublished;url;annotate]}

It's extremely crude (especially the grep extraction of info) but it
worked.

Then I edited the DeveloperNotes entry so it appears as follows:

@PAMPHLET{int/doc/DeveloperNotes.pamphlet,
  author = {Timothy Daly},
  title = {int/doc/DeveloperNotes},
  abstract = {This file contains a random collection of facts about
Axiom intended
	for developers. It talks about directory structure, internal
representations,
	debugging tools, and gives a cookbook for using CVS. There is nothing
	of interest for the end user.},
  howpublished = {Axiom},
  url = {src/algebra/int/doc/DeveloperNotes.pamphlet},
  annote = {A general collection of notes intended to assist developers
who are
	new to Axiom, based on a variety of discussions between current
developers.
	Recommended, even though it still needs to be organized into a more
	coherent structure.},
  owner = {user},
  timestamp = {2006.06.11},
}

and added this entry:

@ARTICLE{Duff:2002,
  author = {M J Duff and L B Okun and G Veneziano},
  title = {Trialogue on the number of fundamental constants},
  year = {2002},
  volume = {0203},
  pages = {023},
  pdf = {http://www.arxiv.org/PS_cache/physics/pdf/0110/0110060.pdf},
  eprint = {arxiv:physics/0110060},
  owner = {user},
  timestamp = {2006.07.09},
}

in order to test both aspects of the "advanced" bib behavior.  I then
combined (using kompare, which is quite nice, but the tool choice is
irrelevant) the annotation modifications found on the internet for bst
files with the ToC bst file (the changes in the ToC are much more
extensive).  I suppose we should put together an axiom.bst file as a
literate document, but that's beyond my current resources (the bibtex
language used for bst files is a bit odd, and I am no expert).  I think
I have a file that is usable, and perhaps we can start minimally and
work up.

There is a file here http://www.jasonokane.com/latex/anncat.sty which
combines the annotation stuff with a categorization field.  I think it
would be interesting to adopt the MSC2000 categories and use this
feature or one like it to organize (optionally anyway) our
bibliography.  I have some more experimentation to do to find out if
this makes sense, and more to figure out how to do it "right", but if
it does work it is something we will want to incorporate from the
beginning.  My hunch is that organizing both Axiom pamphlets and the
bibliography via MSC will prove to be the most coherent thing to do in
the long term both for us and for the mathematical community as a
whole.

\start
Date: Thu, 13 Jul 2006 20:15:13 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Axiom Bibliography, round two

I have been able, with the help of awk, bibtool, and a few other
assorted tools to take a single bibtex file and create a book type
structure organized according to the MSC2000 system.

http://portal.axiom-developer.org/Members/starseeker/axiombibliography.pdf/download

I had to parse the html from the AMS website into a reasonable text
file, then use awk to sort and clean up.  Then I used that file,
bibtool, and some key entries in the bibtex entries themselves to split
the big file up into many smaller, topic specific bib files.  Then the
latex package bibtopic comes into play, and awk again turns the msc2000
converted text into latex, pruning at the subsection level so as to not
create a huge document without need.

Hopefully this is an acceptable use of the AMS web content - should we
contact them and check?  I could parse the pdf eventually, but it is
more difficult and raises the same basic issues.  I also intend to add
the PACS system for phyics to this (it seems to cover a couple other
subjects as well - I spotted geochemistry in there) which will be
considerably easier since they already have a nice neat text file (and
xml if needed) on their website.  Not needed yet, of course, which is
the reason for the MSC2000 focus, but eventually it can be added on as
a Part 2.

I know this looks massive, and it is, but I can't think of anything
else that has a realistic chance of coherently organizing all of the
references Axiom can and should refer to as its coverage of the
mathematical world grows.  Given enough literate programs on enough
topics and it is quite conceivable that our bib file could contain many
thousands of entries varying across the entire world of mathematical
subjects.  The merit to this is that it can be automated - the edges
are (very) rough yet since I'm just trying to get something to work,
but clearly it can be done - this would have been a VERY long task by
hand.  Processing a large bib file could take hours (at least at the
moment - it can probably be done more quickly with smarter coding, and
maybe even in lisp by someone who's better at lisp than me) but it does
seem to have some promise.

Oh, annotations and linking seem to be at least partially functional. 
There are a couple scattered in there with links, and most have a "put
me somewhere already!" message as an annotation.

\start
Date: Sat, 15 Jul 2006 18:12:31 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Bibliography with preliminary PACS inclusion

It looks like PACS is viable.  I haven't gotten proper pruning in place
yet, so this is rather larger than it should be, but it does seem to be
workable.

I removed the previous version to save space, and this version is
compressed (apparently 6Megs is a bit much for the portal, which is no
surprise.)

\start
Date: Sun, 16 Jul 2006 06:29:56 -0400
From: Tim Daly
To: Renaud Rioboo
Subject: -l Xpm

fixed. available in next release --t


=================================================================

   Tried to build GoldenAxiom from 
   arch@axiom-developer.org--axiom/axiom--main--1--patch-49
   under Ubuntu/dapper

   Could not find libXpm.a which is assumed to be under /usr/X11R6/lib,
   but is actually in /usr/lib

   The following modifications helped (these let the linker find it)

   antalk@neurophysa:~/p/axiom/axiom-src/axiom-current/GoldenAxiom$ tla file-diffs src/graph/view2D/Makefile.pamphlet
   --- orig/src/graph/view2D/Makefile.pamphlet
   +++ mod/src/graph/view2D/Makefile.pamphlet
   @@ -283,7 +283,7 @@
    ${OUT}/view2D: ${VIEW2D_OBJS} ${GDRAW_OBJS} ${LIBFILES}
	   @ echo 34 linking ${OUT}/view2D
	   @ ${CC} ${VIEW2D_OBJS} ${GDRAW_OBJS} ${LIBFILES} \
   -        -o ${OUT}/view2D ${XLIB}/libXpm.a $(LDFLAGS)
   +        -o ${OUT}/view2D -L${XLIB} -lXpm $(LDFLAGS)

    @
    \section{axiom.sty}



   antalk@neurophysa:~/p/axiom/axiom-src/axiom-current/GoldenAxiom$ tla file-diffs src/hyper/Makefile.pamphlet
   --- orig/src/hyper/Makefile.pamphlet
   +++ mod/src/hyper/Makefile.pamphlet
   @@ -1058,7 +1058,7 @@
	    (cd ${OUT} ; \
	    ${CC} -g ${HYPER_OBJS} -o ${OUT}/hypertex ${LIB}/sockio-c.o \
	      ${LIB}/pixmap.o ${LIB}/spadcolors.o ${LIB}/util.o \
   -           ${LIB}/bsdsignal.o ${LDFLAGS} ${XLIB}/libXpm.a -lX11 -lm -L${LIB} )
   +           ${LIB}/bsdsignal.o ${LDFLAGS} -L${XLIB} -lXpm -lX11 -lm -L${LIB} )

    @
    \section{htsearch binary}

\start
Date: 16 Jul 2006 16:55:58 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: -l Xpm
Cc: Renaud Rioboo

Tim Daly writes:

| fixed. available in next release --t

Tim, I did not see a commit to the silver branch; please could apply
it there too?

\start
Date: Sun, 16 Jul 2006 17:55:24 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Copyright?
Cc: Nic Doye

Ralf,

Earlier in an email you asked:

> ...
> Depending on what publishing really means, I think that 
> copyright actually forbid it to put the file onto an axiom
> server.
>
> Have you contacted Doye?
> ...

On July 16, 2006 3:10 PM I replied:
> ... 
> I did not try to contact Doye before uploading his thesis to
> axiom-developer. Given the content of the thesis and the intent
> of our website I did not think there was any serious risk of a
> copyright issue. Of course if he (or anyone else) asked me to,
> I would certainly be prepared to remove it from the site.
>

Actually, my brain is a seive and if it weren't for this archive
I would probably not remember my own name! In fact I did ask Nic
if it was ok to put a copy of his thesis online. See:

http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00134.html
 
This reminds me that someday real-soon-now I still hope to spend
some time looking at OBJ:

http://cseclassic.ucsd.edu/~goguen/sys/obj.html
http://www.cse.ucsd.edu/users/goguen

and how it might related to Axiom. More specifically, I was thinking
of installing some version of OBJ on the axiom server and making it
accessible via the wiki. This might be one (more) way of starting to
mix automated theorem proving with computer algebra. Do you think
anyone else would be interested in this?

Apparently there is/was? a version of OBJ3 that uses/used? GCL:

"There is a new release (from June 2000) of OBJ3, version 2.06; it is
a cleaned-up version OBJ3 version 2.04 (from 1992), engineered by Joseph
Kiniry and Sula Ma, and built and supported by Joseph Kiniry; it runs
under GCL 2.2.2, and has modern open source documentation."

but I have not been able to locate the source code yet since the links
seem to be out of date.

Perhaps I should consider using cafeOBJ?

http://www.ldl.jaist.ac.jp/cafeobj

which appears to be newer and apparently also can be compiled using
GCL.

Or for the adventuresome, there is BOBJ - a Java-based version of
OBJ. I think BOBJ is very interesting because

"BOBJ is used in the Tatami project, which is developing the Kumo
proof assistant and proof website generator."

http://www.cs.ucsd.edu/groups/tatami
http://www.cse.ucsd.edu/groups/tatami/kumo
http://www.cse.ucsd.edu/groups/tatami/bobj

\start
Date: Sun, 16 Jul 2006 16:20:20 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Bib update - PACS working now - close to ready

At the risk of spamming the list, I can now report that the PACS
scripts are working.  They prune the PACS entries down to chapters with
sections present only if content is also present.  The MSC is still at
subsection pruning - it will be a bit tricky to intelligently prune
sections, and I'm undecided if it is worthwhile or not.  (It probably
is, but if anyone has any good ideas on how to conditionalize it I
would appreciate it.)

The new example/test is here:
http://portal.axiom-developer.org/Members/starseeker/axiombibliography.pdf/download

I've also gone ahead and uploaded the scripts that I'm using to
generate this -
http://portal.axiom-developer.org/Members/starseeker/axiombibliographysystem.tar.gz/download

On a unix system with standard tools (gawk, sort, grep, bash, latex,
etc) and bibtool (might have to install that one, link is here: 
http://www.gerd-neugebauer.de/software/TeX/BibTool.en.html) one goes
into the bibliography dir and types ./generatebibliography.sh to run
the machinery.  The MSC html files and the PACs text file are in there
for convenience, along with an example file called test.bib.  To clean
up after latex run ./cleanup.sh and to REALLY clean up use the
__reset__.sh file. 

It's rough, but it appears to work.  If this is to go into Axiom I
suppose it needs to be made into a literate document, but first we need
to decide IF it's worth putting into Axiom ;-).  Both code and bibtex
style documentation will be needed to do this correctly, so if the word
is go I'll get started putting those together.  I think with this in
place we can proceed to start building our axiom.bib file and turn our
pamphlets into real academic papers, citations and all.

\start
Date: Mon, 17 Jul 2006 11:57:14 -0400
From: Tim Daly
To: Scott Collison
Subject: Axiom information

Your website contains completely incorrect information about Axiom.

                           You say:                         Fact:
Project started:        2 years ago            1971, open in 2000
Active Developers:                0                     approx 15
Main Language                 C/C++                   Common Lisp
Codebase                  2,260 LOC                 approx 1M LOC
Avg Salary                 $55/Year                       $0/Year
Total                       $25,894                       (what?)
License                        None                  Modified BSD
Factoid    large number of comments All source is literate documents
Factoid    no recent contributions  Last contribution on 7/15/06 (2 days)

\start
Date: Mon, 17 Jul 2006 13:48:43 -0400
From: Bill Page
To: Tim Daly
Subject: ISSAC and CAFE meetings?

Tim,

I believe that you were recently in Europe for the subject meetings
and that you may have discussed open source Aldor with Steven Watt
and others while at the meeting.

Is there any progress to report on making Aldor available as open
source and/or as an integral part of the Axiom project?

Did you distribute the DoyenCD while at the conference? If so was
there much interest in this format?

Do you have any other comments about the meetings that might be
relevant to Axiom?

Did anyone else on this list attend?

\start
Date: Mon, 17 Jul 2006 14:52:04 -0400
From: Tim Daly
To: Bill Page
Subject: ISSAC and CAFE trip report
Cc: Wilken Rivera

> I believe that you were recently in Europe for the subject meetings
> and that you may have discussed open source Aldor with Steven Watt
> and others while at the meeting.
>
> Is there any progress to report on making Aldor available as open
> source and/or as an integral part of the Axiom project?

Yep. Stephen and Mike Dewar are discussing the license details.
Stephen has been away in a series of conferences and had not yet
returned home so there was no progress in the last 2 weeks. But
conversations are happening.

> Did you distribute the DoyenCD while at the conference? If so was
> there much interest in this format?

I gave out 100 copies of the CD as well as 10 copies of the
tutorial. And I had long, detailed conversations with virtually
everyone I knew at the conference (roughly 20 people, all the old
timers) and some I didn't know. Mostly pushing literate programming.

I want the next ISSAC CD to be a Doyen CD. I helped to make the ISSAC
CD for the last three years. I think we need to get a demo version
running by december if we're to have a hope of replacing the static
ISSAC CDs.

Several points arose. I claim that this isn't a science if we cannot
build on each other's work. In computational math it is not sufficient
to show an algorithm in a paper. In that case I have to write a program
to implement your algorithm before I can modify it to improve it. Thus
I'm forced to start from nothing rather than build on your work.

Plus I don't feel that complexity proofs are valid without the code.
People argue things like "my algorithm is O(n^2) over the Integers".
But my computer does not have Integers, it has fixnums and bignums.
If the coefficients become bignums then an O(n^2) algorithm becomes
at least O(n^3) or worse.

And, of course, this literate programming solution to keeping the
research and the code together got a lot of voice-time. 

I had a conversation with Carlo Traverso, head of the math dept at
Univ. of Pisa. He gave a talk at Calculemus the day before detailing
literate programs being submitted to an "Active Journal". He gave me
all of his implementation source code and slides which I'll be adding
to the Doyen CD. Carlo is working to create an Active Journal for
this field so people can submit their literate research for review.

I also picked up some information about how to get a drag-and-drop
interrupt in javascript. Now I have to make a demonstration page.

I met Ralf Hemmecke and he showed me the details of his ALLPROSE
work. Very nice. We should certainly follow his lead for doing
literate programming his way. And he showed it to Emil, the ACM
contact, so Ralf could get some mileage out of a paper that could
be presented next year.

Renaud gave me some patches for Fedora Core 5 and I rebuilt and
tested Axiom. 

Xin Li could potentially rewrite the Axiom Tutorial into Chinese.

Xin Li has an FFT implementation which I'll be adding to the system
in the near future. Mark Moreno Maza (his advisor) is a major
advocate of Axiom at ORCCA (Ontario Research Center in Computer
Algebra, in Canada).

I took another step in documenting the algebra code and a little
more study in the proviso area.

We might finally have permission to use Manuel Bronstein's algebra
code. There is only one step left and it should complete shortly
(in principle). This will mean a lot of work for me but it's the
only way to keep Manuel's work alive.

I spoke to some people from Maplesoft about including Maple code
on the Doyen CD so drag-and-drop would work.

ISSAC used to have a track about systems but I didn't see any
system presentations this year. This is computational math but
I only see Maple at the conference. Prior years would have shown
many systems.

Barry Trager worked with someone who had a Groebner basis issue
that neither Maple nor Singular could sufficiently solve. He
showed that Axiom could do the problem in a reasonable amount
of time.

William Sit has done some work with a person from Rutgers that
looks very interesting.

I spoke to a person who has worked with Bertfried Fauser on 
Clifford Algebra and Hopf Algebra. He would like to see the
algorithms in Axiom.


> 
> Do you have any other comments about the meetings that might be
> relevant to Axiom?

I saw an interesting input format (a matrix written with elided
entries that you see in textbooks). There was a paper that showed
how to handle that format. I think Axiom could handle this input
format easily.

I want to work with Sage/GAP/Singular/CoCoA on the Doyen front. We
need to expand Doyen (and probably the Axiom Wiki) to handle these
systems.

There were a lot of algorithms presented by I'm never going to
get them implemented. It would take too long.

> 
> Did anyone else on this list attend?
> 

Ralf and Renaud were there. Possibly others but not that I remember.
But I have a very bad memory.

\start
Date: Mon, 17 Jul 2006 13:50:12 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Bill Page
Subject: Re: ISSAC and CAFE trip report
Cc: Wilken Rivera

--- Tim Daly wrote:

> Yep. Stephen and Mike Dewar are discussing the license details.
> Stephen has been away in a series of conferences and had not yet
> returned home so there was no progress in the last 2 weeks. But
> conversations are happening.

Yay!  Fingers crossed...

By the way, has anyone tried building the Aldor stuff with the silver
branch?  I hit a couple of snags (which are probably my fault) but I
was curious if it was a one-off issue with my machine or if others have
had trouble.

> > Did you distribute the DoyenCD while at the conference? If so was
> > there much interest in this format?
> 
> I gave out 100 copies of the CD as well as 10 copies of the
> tutorial. And I had long, detailed conversations with virtually
> everyone I knew at the conference (roughly 20 people, all the old
> timers) and some I didn't know. Mostly pushing literate programming.

Thank you Tim (I think I can safely say from all of us) for your
investment of time and materials in promoting Axiom.

> I want the next ISSAC CD to be a Doyen CD. I helped to make the ISSAC
> CD for the last three years. I think we need to get a demo version
> running by december if we're to have a hope of replacing the static
> ISSAC CDs.

That's a neat idea - what can we do to help?

> Several points arose. I claim that this isn't a science if we cannot
> build on each other's work. In computational math it is not
> sufficient to show an algorithm in a paper. In that case I have to
> write a program to implement your algorithm before I can modify it
> to improve it. Thus I'm forced to start from nothing rather than
> build on your work.

Yes and no.  It might be argued that programming the algorithm yourself
is similar to a physical scientist having to duplicate the equipment in
the lab needed to run an experiment.  (I'm sure you heard all the
arguments at ISSAC ;-).  I would tend to view it as follows - since
computation math cannot realistically be separated from the computer,
and the "apparatus" can be duplicated for very low cost (compared to an
XRD analysis system, for example) it is inefficient to force
researchers to spend time duplicating a setup already available to
them.  (The catch, of course, being that it is only available if the
license/cost permits it to be available, or sometimes the software is
in-house only at the university and never released.)  One thing about
different programmed implementations is that they can identify problems
with the experimental setup originally used (e.g. the CAS) but I think
the way forward there is to incorporate and interface with proof
systems if a particular result needs to be verified correct with a high
degree of certainty - this effectively "tests" the functioning of the
CAS by putting its result up for review by pure logic systems, which
(if they do THEIR job) will provide a high degree of confidence in the
answer.  (Of course, you might suspect the proof software, but then
human reviewers aren't perfect either, so SOMETHING has to be trusted.)

Anyway.  Pardon the rant - I'm sure everyone here is more fluent in
such matters than I am. (setf *deliver-sermon* nil) ;-)
 
> Plus I don't feel that complexity proofs are valid without the code.
> People argue things like "my algorithm is O(n^2) over the Integers".
> But my computer does not have Integers, it has fixnums and bignums.
> If the coefficients become bignums then an O(n^2) algorithm becomes
> at least O(n^3) or worse.

I think I would put it that a complexity proof in an ideal environment
is of limited utility when it comes to application of the algorithm in
question.  I have always thought it would be a useful (and difficult)
exercise to build "successive complexity analysis" into the design of
an OS and compiler - that way you can find out what the real overhead
is at all levels in the system, from core OS bootstrapping and
processing routines on up through integration algorithms.  I suppose
that's not possible practically though, unless we re-create a new
super-lisp machine from the circuits on up.  

It has always bothered me that people are capable of writing more
efficient assembler routines than a compiler - what are they seeing
that the compiler isn't?  Why can't a compiler see it?  I suppose it's
a question of how much time you want to spend compiling but given how
long some binaries are run in commercial applications (and how many
systems will run them every day) I would think there would be some
benefit.  

> And, of course, this literate programming solution to keeping the
> research and the code together got a lot of voice-time. 

Was it well recieved, on the whole?

> I had a conversation with Carlo Traverso, head of the math dept at
> Univ. of Pisa. He gave a talk at Calculemus the day before detailing
> literate programs being submitted to an "Active Journal". He gave me
> all of his implementation source code and slides which I'll be adding
> to the Doyen CD. Carlo is working to create an Active Journal for
> this field so people can submit their literate research for review.

I guess the trick is getting peer review and reputation established. 
Is his presentation available online anywhere?

> We might finally have permission to use Manuel Bronstein's algebra
> code. There is only one step left and it should complete shortly
> (in principle). This will mean a lot of work for me but it's the
> only way to keep Manuel's work alive.

Excellent!  Can we help you with the work?

\start
Date: Tue, 18 Jul 2006 01:55:04 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: Sandbox20

Hi,

May I know why the name "Sandbox" has been modified to "Sanbox20" ?

\start
Date: Mon, 17 Jul 2006 21:33:59 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Sandbox20

Greg,

On July 17, 2006 7:55 PM you asked:
> 
> May I know why the name "Sandbox" has been modified to "Sanbox20" ?
> 
> Just curious.
> 

Apparently someone identifying themselves as 'scvblwxq' issued a
rename of 'SandBox' to 'SandBox20' ... probably just a simple
mistake. Perhaps they did not understand the instructions about
how to create new pages. Or maybe they were just experimenting and
did not understand the consequences of their actions: When you
change the name of a page, all the links to the original page
located in other pages will be updated with the new name and
messages get generated for each such change. Maybe this is a bad
design choice for the wiki that should be corrected. For example
we could make changing links in other pages an option of the
rename and default this option to 'no'. On the other hand it
seems this kind of error does not happen very often.

We are also having a few problems lately with changes made to the
status of issues in IssueTracker. In this case, so far as I can
tell from the web site logs someone connected to an ISP in Japan
is occasionally running some kind of rogue robot program that is
triggering these changes - this in spite of the fact that changing
the status already requires that the use identify themselves before
making changes. Of course this can be very easily spoofed by someone
who knows a little about how these things work and there are a few
people out there who are willing to exploit and abuse almost any
openly accessible system. We can try to put blocks in the way of
this kind of abuse or simply tolerate it.

The current philosophy is that all (almost all) changes are allowed
by anyone who is willing to identify themselves by setting wiki
'preferences' but any changes made to the wiki (except for 'SandBox'
pages) will result in email notices being sent to the Axiom Wiki
subscribers. Although this might be annoying to some Axiom Wiki
subscribers, the result is someone is likely to notice any incorrect
changes and use the 'diff' menu option to revert the change. The
intent of this open access policy is suppose to be to encourage
the use of the wiki and also to encourage those people who do
use the wiki to feel some sense of "ownership" and responsibility
for the content.

This open access policy (more or less) in keeping with the original
WikiWiki concept and quite at odds with the traditional way of
implementing online collaborative interactive systems. Some people
have suggested that we should adopt a more controlled access
approach for the Axiom Wiki, but so far I have resisted this
temptation because we already have a more controlled access mode
of operation in the Axiom portal and my observation is that for
the most part this greatly limits the number of people willing
to contribute to this part of MathAction.

In the present case of the change from SandBox to SandBox20 I just
used the Zope Management Interface (ZMI) to revert all of these
changes with a single 'Undo' request - that is one of the really
nice features of having the wiki based on Zope. Right now, besides
myself, there are only two other Axiom developers who have access
to the ZMI level of Axiom Wiki and Axiom Portal (aka MathAction).
ZMI access is limited to a small number of well motivated people
because it requires a good knowledge of how to use Zope and like
with any "management" interface it is possible to do both great
good and great evil. :)

To prevent this sort of error in the future and because the SandBox
page is an important feature of this system, I have also set the
security options for this page to allow renaming only by users
with ZMI access.

Sorry for the overly long "explanation" ;) As usual your opinions
about design changes in the Axiom wiki are most welcome.

\start
Date: Tue, 18 Jul 2006 05:31:48 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: MathLang

Just saw an announcement on the Isabelle list
(http://www.macs.hw.ac.uk/~jbw/phd-student-ad.html) which referenced
this:
http://www.macs.hw.ac.uk/~fairouz/talks/talks2005/mathlang-general-talk.pdf

I may be wrong, but it sounds like the problems they are looking at
there are a bit similar to the ones B-sharp is intended to address.

Position sounds interesting, although they don't seem to be interested
in Axiom as such.

\start
Date: Tue, 18 Jul 2006 14:44:18 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Sandbox20

> Greg,
>
> On July 17, 2006 7:55 PM you asked:
> >
> > May I know why the name "Sandbox" has been modified to "Sanbox20" ?
> >
> > Just curious.
> >
>
> Apparently someone identifying themselves as 'scvblwxq' issued a
> rename of 'SandBox' to 'SandBox20' ... probably just a simple
> mistake. Perhaps they did not understand the instructions about
> how to create new pages. Or maybe they were just experimenting and
> did not understand the consequences of their actions: When you
> change the name of a page, all the links to the original page
> located in other pages will be updated with the new name and
> messages get generated for each such change. Maybe this is a bad
> design choice for the wiki that should be corrected. For example
> we could make changing links in other pages an option of the
> rename and default this option to 'no'. On the other hand it
> seems this kind of error does not happen very often.

Humm... I thought the person who renamed the Sandbox page was known (but
I admit that the 'cvb' letter sequence (for example) is relatively
strange).

\start
Date: Tue, 18 Jul 2006 17:14:46 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: MathLang

On Tuesday, July 18, 2006 8:32 AM C Y wrote:
>
> Just saw an announcement on the Isabelle list
> (http://www.macs.hw.ac.uk/~jbw/phd-student-ad.html) which
> referenced this:
>
http://www.macs.hw.ac.uk/~fairouz/talks/talks2005/mathlang-general-talk.
pdf
>
> I may be wrong, but it sounds like the problems they are
> looking at there are a bit similar to the ones B-sharp is
> intended to address.

It seems to me that goals of MathLang go way beyond BNatural
(B# or B-sharp if you prefer). BNatural is a single-typed input
language intended to replace or suppliment the existing Axiom
interpreter, especially for new users of Axiom. MathLang on
the other hand is apparently intended as a semi-formal middle
ground between published mathematical text and a formal input
language (such as BNatural, the Axiom Interpreter or an automated
theorem proving system). Maybe some day this will be a possible
input language for computer algebra systems, but it seems to me
that having just learned to crawl, we should first set our sites
on learning to walk before we try to run ... :)

\start
Date: Mon, 17 Jul 2006 13:35:27 -0700
From: Scott Collison
To: Tim Daly
Subject: Re: Axiom information
Cc: Scott Collison

Hi Tim,

I have forwarded this to one of our developers. He will get back to  
you soon. Thanks for taking the time to provide us feedback.

Best regards,

--Scott

On Jul 17, 2006, at 8:57 AM, root wrote:

> Your website contains completely incorrect information about Axiom.
>
>                            You say:                         Fact:
> Project started:        2 years ago            1971, open in 2000
> Active Developers:                0                     approx 15
> Main Language                 C/C++                   Common Lisp
> Codebase                  2,260 LOC                 approx 1M LOC
> Avg Salary                 $55/Year                       $0/Year
> Total                       $25,894                       (what?)
> License                        None                  Modified BSD
> Factoid    large number of comments All source is literate documents
> Factoid    no recent contributions  Last contribution on 7/15/06 (2  
> days)

\start
Date: Tue, 18 Jul 2006 22:05:33 -0400
From: Bill Page
To: Ivan Savov
Subject: RE: LatexWiki
Cc: Bob McElrath

Dear "Ivan pretending-to-do-reseach-student-of-physics Savov",

On Thursday, July 13, 2006 2:37 PM you wrote:
> ...
> I am VERY impressed with the Plone/Zope site you are running and
> the smooth support for Latex in it. Being able to manipulate latex
> on the web has been a dream of mine for quite some time and I
> thought it was finally a reality when I saw your page.

You should really be talking with Bob McElrath who is/was the once
(now irregular) maintainer of LatexWiki:

http://mcelrath.org/Notes/LatexWiki

on which the stuff I developed

http://wiki.axiom-developer.org and
http://portal.axiom-developer.org

is based.

>
> I am a debian user myself and I have been learning about Zope for
> the last couple of months.  I tried the Zope+Plone that come with
> Debian stable but I got mixed results.

We also run the Axiom Wiki and Axiom Portal on a Debian mirror at

http://axiom.risc.uni-linz.ac.at

running Debian sarge currently with kernel 2.6.8-3-686.

>
> Then I decided to start from scratch following this video:
> http://www.archive.org/details/SeanKellyGettingYourFeetWetwithPlone
> I compiled Python 2.4.3 with zlib, also Zope 2.9.3, and finally
> LatexWiki 0.42 over ZWiki 0.42 which is recommended in the
> LatexWiki docs. Then I had to put-in some PIL libraries after
> but in the end nothing really works!!!

Pity. Sometimes getting this all to work is a bit of work... ;)
especially using newer versions, as you appear to be trying to do.
I think your Zope version is "too new" but in principle with a
few tweaks it should be possible to make this work.

If you really want to use the newest versions of things, you might
want to try the branch of LatexWiki derived by Simon Michael (the
developer of ZWiki) at:

http://zwiki.org/DarcsRepos
http://zwiki.org/repos/latexwiki (browse)
    LatexWiki pared down and updated for latest Zwiki

If you go this route, please let me know how it works out.

>
> I was hoping you can tell me a few words about what is running
> on portal.axiom-developer.org so that I can try to mimic your
> installation.
> Which version of Python are you using?

On the Debian system mentioned above we are running:

Zope 2.7.5-final
Python Version 2.4.2
GCC 4.0.3 20051111

> Which version of LatexWiki are you using? Which version of ZWiki?

The versions of both LatexWiki and ZWiki we are using are hacks of
old ones which I wish I had time to update. You can get a version
close to what we are currently running at:

http://wiki.axiom-developer.org/MathActionRepository

If you are strongly motivated to run the *same* version, then you
might actually be able to push me into updating the repository. :-)

> Were there any modifications necessary or did the code work
> out of the box?

You might be interested in the detailed information presented here

http://wiki.axiom-developer.org/DoyenCD

about building a version of MathAction for distribution on CD
although in this case the developer was using Fedora linux.

>
> My setup: (some things may not be running right now...)
> stremi.mine.nu:8080/research/    <-- Plone
> stremi.mine.nu:8080/research2/   <--wiki alone
> stremi.mine.nu:80/Music/   <-- my music collection... check
> out Full Albums/
> (the line is a sympatico DSL in Montreal with decent upstream
> speeds...)
>
>
> Thank you very much for your time,
>    Ivan pretending-to-do-reseach-student-of-physics Savov
>
> PS:
> My real goal is to create a research-and-writing-portal for
> scientists based on Zope and Plone.

Talk to Bob. :)

> The first step it to create something useful for my own research
> so that I can organize ideas. I think of it as an annotated
> bibliography: links interleaved with my comments (in Latex) so
> that I know what is important and what isn't.

Sounds familiar. You should feel free to try what you like at

http://portal.axiom-developer.org

if that is any use to you.

>
> PS2: The grand scheme of things
> In the long run, I want to build a super-duper-mega research
> portal that will allow discussion and cooperation on any research
> topic. The idea is to organize and structurize different ressources
> like wikipedia, arXiv.org and other people's personal weblogs.
> There will be folderish objects for Physics with a subfolded
> Quantum Mechanics and a subfolder Quantum Informaiton Theory. Then
> different people can add links to papers in QIT with their own
> personal comments. A newcomer to the field should then be able to
> immediately see what the important papers in the field are and know
> what to read first... something a stupid text search can't really
> provide.
>

Well, that is rather grand... ;) But I predict that any effort
like this is doomed to failure by a very simple fact: The ratio of
the number people who read a wiki web site, to the number of people
who will actually contribute to it, is a very big number - maybe
as high as 10,000 or even 100,000 to 1 - a fact that is sadly
born-out by the monthly web statistics for the Axiom Wiki. The only
reason why a project like wikipedia succeeds is that it's goals are
even grander than yours. Like Computer Algebra, Physics is just to
"small" a subject.

\start
Date: Tue, 18 Jul 2006 19:46:38 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: LatexWiki
Cc: Ivan Savov

Page, Bill [Bill Page] wrote:
> Dear "Ivan pretending-to-do-reseach-student-of-physics Savov",
[...]
> > PS:
> > My real goal is to create a research-and-writing-portal for
> > scientists based on Zope and Plone.
> 
> Talk to Bob. :)

Yeah, me too!  :)  But I have so little time these days...

> > The first step it to create something useful for my own research
> > so that I can organize ideas. I think of it as an annotated
> > bibliography: links interleaved with my comments (in Latex) so
> > that I know what is important and what isn't.
> 
> Sounds familiar. You should feel free to try what you like at

For personal use, I think tiddlywiki is fantastic, and I've made a latex
addition for it:
    http://bob.mcelrath.org/tiddlyjsmath-2.0.3.html
This is what I have been using in the time since I basically abandoned
latexwiki.  I use the "ziddlywiki" backend.

> > PS2: The grand scheme of things
> > In the long run, I want to build a super-duper-mega research
> > portal that will allow discussion and cooperation on any research
> > topic. The idea is to organize and structurize different ressources
> > like wikipedia, arXiv.org and other people's personal weblogs.
> > There will be folderish objects for Physics with a subfolded
> > Quantum Mechanics and a subfolder Quantum Informaiton Theory. Then
> > different people can add links to papers in QIT with their own
> > personal comments. A newcomer to the field should then be able to
> > immediately see what the important papers in the field are and know
> > what to read first... something a stupid text search can't really
> > provide.
> 
> Well, that is rather grand... ;) But I predict that any effort
> like this is doomed to failure by a very simple fact: The ratio of
> the number people who read a wiki web site, to the number of people
> who will actually contribute to it, is a very big number - maybe
> as high as 10,000 or even 100,000 to 1 - a fact that is sadly
> born-out by the monthly web statistics for the Axiom Wiki. The only
> reason why a project like wikipedia succeeds is that it's goals are
> even grander than yours. Like Computer Algebra, Physics is just to
> "small" a subject.

I like your idea and have had many similar ideas myself.  At a
conference in March at fermilab, it was widely discussed that such a
thing would be a great thing to have.  Grand plans were made.  I spent a
weekend or two hacking Plone.  Another post-doc who is far less picky
than me set up a MediaWiki. (http://www-theory.lbl.gov/toolswiki/ and a
separate discussion forum http://www-theory.lbl.gov/tools/)  Despite the
wide consensus that this was a good idea, it's not being used.  I think
people in academia tend to spend their time writing papers, and can't
seem to justify time spent editing a wiki.  (That's true for me anyway)
It's a "critical mass" problem.  I have ideas how to solve it, but I'm
not excited about the sites above...

I still think this is a worthwhile goal, and if you want to devote time
to this I would love to discuss further.  I have some code here you
might be interested in as well.  e.g. an XHTML+MathML+SVG version of
Plone and a python tool like itex2MML which can convert tex to MathML.
I also wanted an integrated discussion/mailing list, and was sorely
disappointed in the options for Plone.  A lot of work, a lot of promise,
and nothing currently usable.  (Plone seems to be a wasteland of
half-finished projects)  I also looked hard at ATBibliography, so that I
can put \arxiv{hep-ph/1234567} and have it automatically generate a
bibliography reference by retrieving the data from the web.  The folks
at SPIRES (http://www.slac.stanford.edu/spires/) were even kind enough
to offer their database for this use.  You mention wikipedia and weblogs
as well...from a professional physicist's standpoint these are kind of
the equivalent of a sixth-grader's book report and the bathroom wall,
respectively.  The real resources are on the arxiv and in journals.
Links to blogs which *discuss* a specific paper would be interesting
though, but blogs are not useful as a primary source of anything at all.

Anyway, lots of ideas, lots of interesting things to do.  I'd be happy
to discuss further.

P.S. Hello from Vancouver.  ;)  I'm on your turf at a conference until
Friday.

\start
Date: Tue, 18 Jul 2006 20:47:32 -0700 (PDT)
From: Cliff Yapp
To: Bob McElrath, Bill Page
Subject: re: LatexWiki
Cc: Ivan Savov

Bob, have you had a chance to look at the axiom bibliography stuff I
put up?  Would it be at least compatible with your web based ideas?

\start
Date: Tue, 18 Jul 2006 23:22:00 -0700
From: Bob McElrath
To: Cliff Yapp
Subject: re: LatexWiki
Cc: Ivan Savov

C Y [Cliff Yapp] wrote:
> Bob, have you had a chance to look at the axiom bibliography stuff I
> put up?  Would it be at least compatible with your web based ideas?

I noticed it but didn't have a chance to look closely.  Looking now, I
don't really understand what you're trying to do.  You've done some
transformations on axiom.bib?

Why can't you just use latex and bibtex as usual on a literate document?
All it should require is to run noweb, latex, bibtex, latex in that
order.  Am I being dense?

=46rom my perspective, the axiom.bib is not of any interest by itself,
except as it can cause citations[1] to show up in documents.  As such,
axiom.bib should ideally contain every document ever written.  Bibtex
ignores unused bibliography entries.  Why do you want to process
axiom.bib?  I think the processing you're interested in could be
accomplished with a .bst file.  If one wants to store annotations about
a paper, that's an interesting thing to do.  But I don't think a
bibliography is the place to do it.  (It makes sense though if I
envision the .bib file as a generalized database that will be processed
in different ways)

[1] Somebody F. Important, Journal of Important Results, v2, p483, 2006

\start
Date: Wed, 19 Jul 2006 03:19:48 -0700 (PDT)
From: Cliff Yapp
To: Bob McElrath
Subject: re: LatexWiki
Cc: Ivan Savov

> C Y [Cliff Yapp] wrote:
> > Bob, have you had a chance to look at the axiom bibliography stuff
> > I put up?  Would it be at least compatible with your web based 
> > ideas?
> 
> I noticed it but didn't have a chance to look closely.  Looking now,
> I don't really understand what you're trying to do.  You've done some
> transformations on axiom.bib?

Yes.  In essence, I want to be able to view the entire contents of the
bib file in the context of mathematical coverage - i.e. in that
bibliography, what are the papers that pertain to a given topic?  It's
a measure of whether Axiom has considered a particular topic before,
and a good way to check on the "depth" of the coverage we have.

> Why can't you just use latex and bibtex as usual on a literate
> document?

I would prefer to keep axiom.bib as a valid bibliography file, rather
than a literate document, for simplicity in processing.  Bibtex is
after all a type of TeX, and I don't see any particular advantage to
the literate programming structure for a bibliography - the annotation
field can contain our comments, and other than that the only content in
the document is the bibliography entries themselves.  This way, all we
have to do is put new, more or less standard entries into axiom.bib,
and annotate them if we have anything to say about them.

> All it should require is to run noweb, latex, bibtex, latex in that
> order.  Am I being dense?

For pamphlet files, yes.  I want to go one step beyond that - I want
the bibliography itself to become an organized volume.  So axiom.bib
will work as normal for pamphlets - the one difference being the
axiom.bst file (which, with the help of eprint.sty can produce pdfs
linking to arXiv, for example.)  But I don't want the bibliography to
just show up in individual pamphlets, although that is its primary
function - I want it to be organized as a whole.

> From my perspective, the axiom.bib is not of any interest by itself,
> except as it can cause citations[1] to show up in documents.  As
> such, axiom.bib should ideally contain every document ever written.

Agreed that is its primary function.  However, to me the axiom.bib file
is of interest in and of itself.  Perhaps that's just me?

> Bibtex ignores unused bibliography entries.  Why do you want to
> process axiom.bib?

Because it is the best way I am aware of for someone to evaluate the
quality of the background work put into various subjects in Axiom - as
we turn more and more pamphlets into real literate programs we should
build up a bibliography file containing all the significant works in
the particular sub-disiciplines.  Someone could look at the
Bibliography volume in the MSC subject [foo], and point out relevant or
important work we haven't yet considered.  That's a bit difficult just
by looking at individual pamphlet files - there could be a lot of them
covering individual aspects of a subject.  I sort of expect many
subjects will have a "core" file with the basics and then subsequent
pamphlets with more advanced/newer research as time goes by.

>  I think the processing you're interested in could be
> accomplished with a .bst file.  If one wants to store annotations
> about a paper, that's an interesting thing to do.  But I don't think 
> a bibliography is the place to do it.  (It makes sense though if I
> envision the .bib file as a generalized database that will be
> processed in different ways)

Exactly.  That's how I think of the bib file.  If we use something like
bibtool we can do a lot of transformations on the (very large) main bib
file to get useful answers - say, for example, we want to know how many
papers by author X have been used in Axiom.  That's a one-liner with
bibtool, if I understand the technology correctly, and the output is
itself a valid bib file.  The annote field defined in the bst file to
me is the preferable way to go - that way axiom.bib is always a valid
bibtex file and can be easily cited in other work. Personally I'd
rather generate the latex framework to house the bibliography according
to msc2000 and pacs and sort the bibliography into it, than stick
everything into a pamphlet.  If we do a pamphlet file and still want to
use msc2000, then we have to put things in the correct places by hand. 
I'd rather just append new entries to axiom.bib for immediate use and
let the computer sort it out when the time comes, but that' s just me. 

\start
Date: Thu, 20 Jul 2006 12:42:16 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [Aldor-l] exports and constants
Cc: Christian Aistleitner

Ralf,

Thanks for continuing your discussion on the list. I hope
my comments below further the discussion and do not appear
overly "final". I admit that thinking deeply and correctly
about Aldor's (and Axiom's) type system is quite difficult
and I may well still be making some errors below. Please
bare with me while I try to give my current understanding
below. :)

On Thursday, July 20, 2006 7:12 AM you wrote:
>
> Sorry, but Christian and me started that discussion in German,
> but we now think that it might be interesting for all other
> Aldor people.
>
> So let me start with a little program that shows some strange
> behavior.
>
> ---BEGIN aaa.as
> #include "aldor"
> import from String, TextWriter, Character;
>
> define CatA: Category == with { }
> define CatB: Category == with { }
> define SomeCat: Category == with { CatA; CatB; }
> Dom: SomeCat == Integer add;
>
> A == Dom;
> B: CatA == Dom;
> H: CatA == Dom add;
>
> stdout << "A has CatA: " << ( A has CatA ) << newline;
> stdout << "A has CatB: " << ( A has CatB ) << newline;
> stdout << "B has CatA: " << ( B has CatA ) << newline;
> stdout << "B has CatB: " << ( B has CatB ) << newline;
> stdout << "H has CatA: " << ( H has CatA ) << newline;
> stdout << "H has CatB: " << ( H has CatB ) << newline;
> ---END aaa.as
>
> You get...
>  >aldor -grun -laldor xxx.as
> A has CatA: T
> A has CatB: T
> B has CatA: T
> B has CatB: T
> H has CatA: T
> H has CatB: F
>
> In particular, that "B has CatB" is a bit surprising, isn't it?
>

I think you are dealing here with two separate but related issues:
1) *static* typing, and 2) inheritance rules. All types in Aldor
are static (or at least *nearly static*) meaning that they must be
resolved during the compilation phase.

Aldor has some rather complex inheritance rules because domains
and categories follow very different rules (the first involves
abstract set "membership" while the second involves "sub-types"
of abstract subsets.

> Has someone found a description in the Aldor UG of whether this
> is intended to be so or this should be considered a bug in the
> compiler?

No, I don't think it is a bug. This is all rather well (although
perhaps too tersely explained in the Aldor Users Guide, under
the heading of "Type Satisfaction", see section 7.7.

Unfortunately http://www.aldor.org is inaccessible :( again! ):
but you can get it from Google's cache:

http://72.14.207.104/search?q=cache:tXXWE6iGeLEJ:www.aldor.org

/docs/HTML/chap7.html+aldor+users+guide+type+satisfaction
&hl=en&gl=ca&ct=clnk&cd=1nces.

or from one of the other pdf versions:

www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/documentation/axlugII.pdf

We have also discussed this a little before:

http://lists.gnu.org/archive/html/axiom-developer/2006-03/msg00140.html

and on static types in:

http://lists.gnu.org/archive/html/axiom-developer/2006-02/msg00065.html

>
> Let me go on with answering Christian's mail...
>
> On 07/20/2006 11:05 AM, Christian Aistleitner wrote:
> > On Wed, 19 Jul 2006 11:20:06 +0200, Ralf Hemmecke
> Ralf Hemmecke wrote:
> >
> >>> i: Integer == 1;
> >>>  und
> >>>  i: Integer == 2;
> >>>  nicht gleich sind.
> >>
> >> Naja, hier mu=DF man nur wissen, da=DF die Symbole 0 und 1
> >> Ausnahmen in Aldor sind. Die kann man n=E4mlich als Bezeichner
> >> verwenden, w=E4hrend das bei 2 nicht geht. Weil das einfach
> >> ein Symbol ist, das wie eine ganze Zahl aussieht, aber
> >> niemals ein Bezeichner sein kann. (Letzteres ist eigentlich
> >> auch eine Einschr=E4nkung, sonst k=F6nnte man "PowerSet(S)"
> >> ganz einfach als "2^S" implementieren. OK, dann w=E4re der
> >> Bezeichner allerdings "2^"... naja.
> >
> > Sorry that was a bad example. What I wanted to point out is
> > that from a user perspective,
> >
> >   identifier: type == value
> >
> > should always refer to the same language construct. So
> >
> >   i: Integer == 2;
> >
> > and
> >
> >   i: Integer == 3;
> >
> > should be the same language construct,
>
> Where do you see a difference?
>
>  > just as
> >
> >   Ident: Category == Domain;
> >
> > and
> >
> >   Ident: Category == Domain add;
> >
> > . Of course, "Domain" and "Domain add" are different things.
> > No doubt about that. However, this difference should be the
> > only difference.

"add" forms a "add expression". See especially sections 7.8 and
8.10.

The more I read (and re-read) the Aldor Users Guide, I am
beginning to believe that the entire definition of Aldor
is in fact very succinctly and consistently given here. But
I have never been able to read and appreciate it in just a
few linear readings of the text.

>
> There is a difference in the semantic, but I cannot
> remember that I have found a proper explanation of what
> "Ident: SomeType == Dom" actually means (no "add" here).

In the above the value of 'Ident' *is* 'Dom' whereas in the
previous case 'Ident' is the name of a new domain whose
"parent domain" is 'Dom' - like the difference between



>
> >> One cannot, however write something like
> >>
> >> CatC: Category == with { }
> >> H: CatC == Dom;
> >
> > Of Course not, because Dom does not provide CatC.
>
> >> Different from
> >>
> >> A: CatA == Dom add;
> >>
> >> the construct
> >>
> >> H: CatA == Dom;
> >>
> >> just means that H provides *at least* the exports of CatA,
> >> and the compiler can tell, if Dom provides less.

In the first case you are defining a new domain A which
satisfies only CatA. In the second case you are saying
that H is identical to Dom, but the compiler knows that
is not true.

> >
> > You can interpret both kinds as "provides at least".

No, I don't think that is true.

> > But the first statement does not give you any more than
> > CatA.

In the first case A is a member of CatA, in the second case
you are saying that type of Dom is a subtype of the type
of H (CatA).

>
> >> It is going to be interesting.
> >>
> >> Take for example
> >>
> >> A: Join(CatA, CatX) == add {...}
> >> B: Join(CatB, CatX) == add {...}
> >> X: CatX == if odd? random() then A else B;
> >>
> >> It is clear that X cannot export more than CatX. In such
> >> constructions the additional exports of A and B cannot be
> >> seen.
> >
> > I am a bit puzzled right now. The line
> >
> >> X: CatX == if odd? random() then A else B;
> >
> > causes problems and does not compile. Furthermore, for
> >
> >> X: CatX == A
> >
> > X has both CatA and CatX, as expected ... Could you detail
> > on that problem.
>
> Sorry, I have not tested that line and I also cannot compile it.

The reason of course is because the expression 'odd? random()'
is not static - it does not have a well-defined value at the
time that the source is compiled. It is only later when the
code is run that we can know if the condition is true or false
in a particular instance. The Aldor compiler is not able to
compile *types* of this kind.

This might seem like a severe restriction, but section 7.8
ends with an example of a "conditional definition" in Zmod
where such static typing is still interesting. I think
understanding in what sense this is "static" (in comparison
to your "dynamic" typing example above) is very important
to understand Aldor's type system as a whole.

>
> ---BEGIN aaa2.as
> #include "aldor"
> import from String, TextWriter, Character;
>
> define CatA: Category == with;
> define CatB: Category == with;
> define CatX: Category == with;
>
> A: CatX with { CatA } == add;
> B: CatX with { CatB } == add;
>
> X: CatX == if true then (A add) else (B add); -- (*)
>
> stdout << "X has CatA: " << ( X has CatA ) << newline;
> stdout << "X has CatB: " << ( X has CatB ) << newline;
> stdout << "X has CatX: " << ( X has CatX ) << newline;
> ---END aaa2.as
>
> aldor -grun -laldor aaa2.as
> X has CatA: F
> X has CatB: F
> X has CatX: T
>
> That is clear, but why does the compiler reject the program
> without the "add" in line (*)?
>

It is because the types of A and B are not a subtypes of CatX.
But X can be a member of CatX defined by (A add) or (B add).

> >
> >> R: GcdDomain == if iWantRationals? then Fraction Integer
> >>                                    else Integer;
> >> computation()$MyPackage(R);
> >>
> >> Und in MyPackage haben wir sowas
> >>
> >> gcd(a: R, b: R): R == {
> >>    if R has Field then {
> >>        ... kann nur 0 oder 1 sein
> >>    } else {
> >>       ... implement Euclidean Algorithm
> >>    }
> >> }
> >>
> >> und computation() benutzt intern diesen gcd. Selbst wenn
> >> iWantRationals? = true
> >> wird nicht der einfachere K=F6rperfall genommen. MyPackage
> >> sieht also die zus=E4tzlichen Exports nicht mehr. Bl=F6d, was?
> >
> > This puzzles me even more, because it works properly for me:
> >
> > #include "algebra"
> > import from String, TextWriter, Character;
> > import from MachineInteger;
> >
> > #if FIELD
> > firstIsField? == true;
> > #else
> > firstIsField? == false;
> > #endif
> > R: GcdDomain == if firstIsField? then (Fraction
> Integer@GcdDomain) else
> > (Integer@GcdDomain);
> >
> > stdout << ( R has GcdDomain ) << newline;
> > stdout << ( R has Field ) << newline;
>
> I am actually a bit amazed that your program runs and gives
> expected results. But what about...

Its static typing again!

>
> ---BEGIN aaa3.as
> #include "aldor"
> import from String, TextWriter, Character, MachineInteger;
>
> define CatA: Category == with;
> define CatB: Category == with;
> define CatX: Category == with;
>
> A: Join(CatX, CatA) == add;
> B: Join(CatX, CatB) == add;
>
> MyPkg(X: CatX): with {isA?: () -> Boolean} == add {
> 	isA?(): Boolean == X has CatA;
> }
> main(): () == {
> 	import from CommandLine, Array String;
> 	X: CatX == if zero? #arguments then (A add) else (B add);
> 	stdout << isA?()$MyPkg(X) << zero? #arguments << newline;
> }
> main();
> ---END aaa3.as
>
>  >aldor -fx -laldor aaa3.as
>  >aaa3
> FT
>  >aaa3 1
> FF
>

Static type again: the value of 'isA()' is determined at
compile time and does not depend on #arguments.

> It is clear with the "add" in the definition of X that we will
> always see a F in the first column of the output. Can someone
> find a "nice" construction where X is defined by a similar "if"
> construction and the first F would turn into T?

This is not possible because as a domain X must be static.

>
> Of course it would be easy to write
>
> main(): () == {
> 	import from CommandLine, Array String;
> 	b: Boolean := zero? #arguments;
> 	stdout << (if b then isA?()$MyPkg(A) else isA?()$MyPkg(B));
> 	stdout << zero? #arguments << newline;
> }
>
> and obtain TT and FF, but that is not a "nice" solution.
>
> Imagine there were another 2 domains R and S that would take
> a domain of type CatX as input and return a domain whose exports
> depend on the input. (A polynomial construction Dense/Sparse
> (for R and S) over some coefficient domain (for A and B) would
> be a common example.)

This is possible because as types domains are static in Aldor.

>
> It's soon becoming quite cumbersome and unreadable if it is
> done in the way the last main() function demonstrates.
>

This is an argument for dynamic types, which certainly is
possible (e.g. Lisp), but efficient compilation is much more
difficult to achieve. One of the beautiful things about Aldor
is that it seems to do so much in spite of it's static
type system.

\start
Date: Fri, 21 Jul 2006 02:12:17 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner,

Hello Bill,

Thank you for your comments, but I don't seem to agree with everything.

Let's keep this programm since I'll refer to its output.

>> ---BEGIN aaa.as
>> #include "aldor"
>> import from String, TextWriter, Character;
>>
>> define CatA: Category == with { }
>> define CatB: Category == with { }
>> define SomeCat: Category == with { CatA; CatB; }
>> Dom: SomeCat == Integer add;
>>
>> A == Dom;
>> B: CatA == Dom;
>> H: CatA == Dom add;
>>
>> stdout << "A has CatA: " << ( A has CatA ) << newline;
>> stdout << "A has CatB: " << ( A has CatB ) << newline;
>> stdout << "B has CatA: " << ( B has CatA ) << newline;
>> stdout << "B has CatB: " << ( B has CatB ) << newline;
>> stdout << "H has CatA: " << ( H has CatA ) << newline;
>> stdout << "H has CatB: " << ( H has CatB ) << newline;
>> ---END aaa.as
>>
>> You get...
>>  >aldor -grun -laldor xxx.as
>> A has CatA: T
>> A has CatB: T
>> B has CatA: T
>> B has CatB: T
>> H has CatA: T
>> H has CatB: F
>>
>> In particular, that "B has CatB" is a bit surprising, isn't it?

> I think you are dealing here with two separate but related issues:
> 1) *static* typing, and 2) inheritance rules. All types in Aldor
> are static (or at least *nearly static*) meaning that they must be
> resolved during the compilation phase.

The "B has CatB" result is not about static or dynamic. If you read the 
code above. Would you immediately be able to tell that the Type of B is 
NOT CatA (as "H: CatA" might suggest), but the same as the type of Dom?

>> Has someone found a description in the Aldor UG of whether this
>> is intended to be so or this should be considered a bug in the
>> compiler?

> No, I don't think it is a bug. This is all rather well (although
> perhaps too tersely explained in the Aldor Users Guide, under
> the heading of "Type Satisfaction", see section 7.7.

I know that the html version of the user guide at aldor.org is a little 
different from the .pdf version, but it seems 7.7 and 7.8 are OK.
Looking at the pdf version, I cannot find good explanations of what

H: CatA == Dom;

actually means.

The constant assignment

H == Dom;

is clear, though. H inherits type and value of Dom.

>> There is a difference in the semantic, but I cannot
>> remember that I have found a proper explanation of what
>> "Ident: SomeType == Dom" actually means (no "add" here).

> In the above the value of 'Ident' *is* 'Dom' whereas in the
> previous case 'Ident' is the name of a new domain whose
> "parent domain" is 'Dom' - like the difference between

If Ident *is* Dom then what do you think the ": SomeType" is for?

>>>> One cannot, however write something like
>>>>
>>>> CatC: Category == with { }
>>>> H: CatC == Dom;
>>> Of Course not, because Dom does not provide CatC.
>>>> Different from
>>>>
>>>> A: CatA == Dom add;
>>>>
>>>> the construct
>>>>
>>>> H: CatA == Dom;
>>>>
>>>> just means that H provides *at least* the exports of CatA, 
>>>> and the compiler can tell, if Dom provides less.

> In the first case you are defining a new domain A which
> satisfies only CatA. In the second case you are saying
> that H is identical to Dom, but the compiler knows that
> is not true.

First and second is not so clear to me now. Can you repeat your 
statement. In particular I don't understand your last sentence.

>>> You can interpret both kinds as "provides at least".

> No, I don't think that is true.

Well, the compiler behaves according to "provides at least" if you write

H: CatA == Dom;

That would compile, whereas

H: CatC == Dom;

would not.

>>>> It is going to be interesting.
>>>>
>>>> Take for example
>>>>
>>>> A: Join(CatA, CatX) == add {...}
>>>> B: Join(CatB, CatX) == add {...}
>>>> X: CatX == if odd? random() then A else B;
>>>>
>>>> It is clear that X cannot export more than CatX. In such 
>>>> constructions the additional exports of A and B cannot be
>>>> seen.
>>> I am a bit puzzled right now. The line
>>>
>>>> X: CatX == if odd? random() then A else B;
>>> causes problems and does not compile. Furthermore, for
>>>
>>>> X: CatX == A
>>> X has both CatA and CatX, as expected ... Could you detail 
>>> on that problem.
>> Sorry, I have not tested that line and I also cannot compile it.

> The reason of course is because the expression 'odd? random()'
> is not static - it does not have a well-defined value at the
> time that the source is compiled. It is only later when the
> code is run that we can know if the condition is true or false
> in a particular instance. The Aldor compiler is not able to
> compile *types* of this kind.

Bill you should have tried the following piece of code.

---BEGIN aaa5.as
#include "aldor"
define CatA: Category == with;
define CatB: Category == with;
define CatX: Category == with;

A: Join(CatX, CatA) == add;
B: Join(CatX, CatB) == add;
#if ADD
import from MachineInteger;
X: CatX == if odd? random(10) then (A add) else (B add);
#else
X: CatX == if true then A else B;
#endif
---END aaa5.as

 >aldor -fx -laldor -DADD aaa5.as

compiles without any complaints. Now try without the ADD assertion.

 >aldor -fx -laldor aaa5.as
"aaa5.as", line 14: X: CatX == if true then A else B;
                     ...........^
[L14 C12] #1 (Error) Have determined 0 possible types for the expression.
   Subexpression `A':
	Meaning 1:
                 Join(CatX, CatA) with
                     ==...
   Subexpression `B':
	Meaning 1:
                 Join(CatX, CatB) with
                     ==...
   The context requires an expression of type CatX.


Are you now a bit more puzzled?

Random things are not the problem. Obviously "A" and "A add" are not 
(treated) identical by the compiler.

Now if we assume that

X: CatX == if true then A else B;

yield an X of the type of the domain on the right hand side then the 
compiler has to match the types of A and B (they have to be equal).
Try to replace B by A in the code above and the compiler will not 
complain anymore.

And to make you even more happy...

---BEGIN aaa6.as
#include "aldor"
#include "aldorio"
macro I == MachineInteger;
define CatX: Category == with {foo: () -> I}
A: CatX == add {foo(): I == 0;}
B: CatX == add {foo(): I == 1;}

import from MachineInteger;
X: CatX == if odd? random(10) then A else B;

main(): () == {
	import from X;
	stdout << foo() << newline;
}
main();
---END aaa6.as

woodpecker:~>aldor -fx -laldor aaa6.as
woodpecker:~>aaa6
0
woodpecker:~>aaa6
0
woodpecker:~>aaa6
0
woodpecker:~>aaa6
0
woodpecker:~>aaa6
0
woodpecker:~>aaa6
1
woodpecker:~>aaa6
1

It's only the type of X that must be clear at compile time. But maybe 
even that is just a current restriction of the compiler. Categories are 
first class values and they should be computable at runtime. But I won't 
go into detail since there are certain problems that occur if categories 
are truly "first class".

The interesting part of aaa6.as is that now if one writes

X: CatX == if odd? random(10) then (A add) else (B add);

(with the "add"), the program does not compile anymore in contrast to 
aaa5.as above.

 >aldor -fx -laldor aaa6.as
"aaa6.as", line 13:         stdout << foo() << newline;
                     ..................^
[L13 C19] #1 (Error) There are no suitable meanings for the operator `foo'.


>> ---BEGIN aaa2.as
>> #include "aldor"
>> import from String, TextWriter, Character;
>>
>> define CatA: Category == with;
>> define CatB: Category == with;
>> define CatX: Category == with;
>>
>> A: CatX with { CatA } == add;
>> B: CatX with { CatB } == add;
>>
>> X: CatX == if true then (A add) else (B add); -- (*)
>>
>> stdout << "X has CatA: " << ( X has CatA ) << newline;
>> stdout << "X has CatB: " << ( X has CatB ) << newline;
>> stdout << "X has CatX: " << ( X has CatX ) << newline;
>> ---END aaa2.as
>>
>> aldor -grun -laldor aaa2.as
>> X has CatA: F
>> X has CatB: F
>> X has CatX: T
>>
>> That is clear, but why does the compiler reject the program 
>> without the "add" in line (*)?

> It is because the types of A and B are not a subtypes of CatX.
> But X can be a member of CatX defined by (A add) or (B add).

I don't understand.
A is of type Join(CatX, CatA) and you are saying that this is not a 
subtype of CatX??? Similar for B.

>> ---BEGIN aaa3.as
>> #include "aldor"
>> import from String, TextWriter, Character, MachineInteger;
>>
>> define CatA: Category == with;
>> define CatB: Category == with;
>> define CatX: Category == with;
>>
>> A: Join(CatX, CatA) == add;
>> B: Join(CatX, CatB) == add;
>>
>> MyPkg(X: CatX): with {isA?: () -> Boolean} == add {
>> 	isA?(): Boolean == X has CatA;
>> }
>> main(): () == {
>> 	import from CommandLine, Array String;
>> 	X: CatX == if zero? #arguments then (A add) else (B add);
>> 	stdout << isA?()$MyPkg(X) << zero? #arguments << newline;
>> }
>> main();
>> ---END aaa3.as
>>
>>  >aldor -fx -laldor aaa3.as
>>  >aaa3
>> FT
>>  >aaa3 1
>> FF

> Static type again: the value of 'isA()' is determined at
> compile time and does not depend on #arguments.

That is completely wrong. If "isA?()" would be computed at compile time,
I would be really amazed. X is a parameter to MyPkg. How should the 
compiler be able to evaluate "X has CatA" at all?

>> Of course it would be easy to write
>>
>> main(): () == {
>> 	import from CommandLine, Array String;
>> 	b: Boolean := zero? #arguments;
>> 	stdout << (if b then isA?()$MyPkg(A) else isA?()$MyPkg(B));
>> 	stdout << zero? #arguments << newline;
>> }
>>
>> and obtain TT and FF, but that is not a "nice" solution.
>>
>> Imagine there were another 2 domains R and S that would take 
>> a domain of type CatX as input and return a domain whose exports
>> depend on the input. (A polynomial construction Dense/Sparse
>> (for R and S) over some coefficient domain (for A and B) would
>> be a common example.)
> 
> This is possible because as types domains are static in Aldor.
> 
>> It's soon becoming quite cumbersome and unreadable if it is 
>> done in the way the last main() function demonstrates.
>>
> 
> This is an argument for dynamic types, which certainly is
> possible (e.g. Lisp), but efficient compilation is much more
> difficult to achieve. One of the beautiful things about Aldor
> is that it seems to do so much in spite of it's static
> type system.

Maybe I don't quite understand your "static", but I believe that what I 
have demonstrated above shows that Aldor just requires that types are 
constant in a certain context, but otherwise one can do quite a lot with 
them.

My feeling is that categories are not really "first class" in Aldor 
(which is certainly another issue). I haven't seen any reasonable 
program that computes a category and then creates a domain that belongs 
to that category. That the compiler cannot handle computed categories, I 
can understand, but I don't even know whether it would be useful to 
treat categories as "first class citizens".

\start
Date: Fri, 21 Jul 2006 07:58:42 +0200 (CEST)
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

Dear all,

I made yet another experiment (on SandBox7, no ssh here), and tested
whether in the code below H would have SomeCat. It does not. B has,
though.

On Fr, 21.07.2006, 02:12, Ralf Hemmecke wrote:
> ---BEGIN aaa.as
> #include "aldor"
> import from String, TextWriter, Character;
>
> define CatA: Category == with { }
> define CatB: Category == with { }
> define SomeCat: Category == with { CatA; CatB; }
> Dom: SomeCat == Integer add;
>
> A == Dom;
> B: CatA == Dom;
> H: CatA == Dom add;

In any case, it would be good to have *one* example program, that
demonstrates as many possibilities as we can think of...

\start
Date: Fri, 21 Jul 2006 09:47:11 +0200
From: Christian Aistleitner
To: Ralf Hemmecke, Bill Page
Subject: Re: [Aldor-l] exports and constants

Hello,

On Fri, 21 Jul 2006 02:12:17 +0200, Ralf Hemmecke wro=
te:

>>> There is a difference in the semantic, but I cannot
>>> remember that I have found a proper explanation of what
>>> "Ident: SomeType == Dom" actually means (no "add" here).
>
>> In the above the value of 'Ident' *is* 'Dom' whereas in the
>> previous case 'Ident' is the name of a new domain whose
>> "parent domain" is 'Dom' - like the difference between
>
> If Ident *is* Dom then what do you think the ": SomeType" is for?

May it's syntactic sugar (maybe I should drop the "syntactic").
You can use it to restrict the static type.
Example:


#include "aldor"
import from String, TextWriter, Character;

define CatA: Category == with { }
define CatB: Category == with { }
define SomeCat: Category == with { CatA; CatB; }
Dom: SomeCat == Integer add;

B: CatA == Dom;

stdout << "B has CatA: " << ( B has CatA ) << newline;
stdout << "B has CatB: " << ( B has CatB ) << newline;

func( DomParam: CatB ):() == { stdout << "called func" << newline; }=



C_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx =
 =

-lalgebra -laldor -D IFCLAUSE test2.as && ./test2
cc1: note: -fwritable-strings is deprecated; see documentation for detai=
ls
cc1: note: -fwritable-strings is deprecated; see documentation for detai=
ls
B has CatA: T
B has CatB: T


We see B's dynamic type has bath CatA and CatB.
However,
func( B )
complains about B being only CatA and not also CatB.
func( Dom )
works.

What about the following:

Universe of the compiler before B: CatA == DOM:

Dom ( StaticType: SomeCat; Implementation at memory location 123456 )

After the B: CatA == Dom:

Dom ( StaticType: SomeCat; Implementation at memory location 123456 )
B   ( StaticType: CatA;    Implementation at memory location 123456 )


> ---BEGIN aaa5.as
> #include "aldor"
> define CatA: Category == with;
> define CatB: Category == with;
> define CatX: Category == with;
>
> A: Join(CatX, CatA) == add;
> B: Join(CatX, CatB) == add;
> #if ADD
> import from MachineInteger;
> X: CatX == if odd? random(10) then (A add) else (B add);
> #else
> X: CatX == if true then A else B;
> #endif
> ---END aaa5.as
>
>  >aldor -fx -laldor -DADD aaa5.as
>
> compiles without any complaints. Now try without the ADD assertion.
>
>  >aldor -fx -laldor aaa5.as
> "aaa5.as", line 14: X: CatX == if true then A else B;
>                      ...........^
> [L14 C12] #1 (Error) Have determined 0 possible types for the expressi=
on.
>    Subexpression `A':
> 	Meaning 1:
>                  Join(CatX, CatA) with
>                      ==...
>    Subexpression `B':
> 	Meaning 1:
>                  Join(CatX, CatB) with
>                      ==...
>    The context requires an expression of type CatX.
>
>
> Are you now a bit more puzzled?
>
> Random things are not the problem. Obviously "A" and "A add" are not
> (treated) identical by the compiler.

It's getting tricky to put my thoughts into correct words, but I guess:
Once the value of "A" and "A add" are established, they are treated  =

equally. But these expressions give different values. "A add" gives an  =

expression of type CatX. "A" gives an expression of type Join( CatX, Cat=
A  =

). And the compiler cannot infer properly, that Join( CatX, CatA )  =

provides CatX.

> Now if we assume that
>
> X: CatX == if true then A else B;
>
> yield an X of the type of the domain on the right hand side then the
> compiler has to match the types of A and B (they have to be equal).
> Try to replace B by A in the code above and the compiler will not
> complain anymore.

Not true for me--I still get the corresponding errors:

#include "aldor"
define CatA: Category == with;
define CatB: Category == with;
define CatX: Category == with;

A: Join(CatX, CatA) == add;
B: Join(CatX, CatB) == add;

X: CatX == if true then B else A;



LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx=
  =

-lalgebra -laldor  test2.as && ./test2
"test2.as", line 34: X: CatX == if true then B else A;
                      ...........^
[L34 C12] #1 (Error) Have determined 0 possible types for the expression=
.
   Subexpression `B':
         Meaning 1:
                 Join(CatX, CatB) with
                     ==  add ()

   Subexpression `A':
         Meaning 1:
                 Join(CatX, CatA) with
                     ==  add ()

   The context requires an expression of type CatX.




> ---BEGIN aaa6.as
> #include "aldor"
> #include "aldorio"
> macro I == MachineInteger;
> define CatX: Category == with {foo: () -> I}
> A: CatX == add {foo(): I == 0;}
> B: CatX == add {foo(): I == 1;}
>
> import from MachineInteger;
> X: CatX == if odd? random(10) then A else B;
>
> main(): () == {
> 	import from X;
> 	stdout << foo() << newline;
> }
> main();
> ---END aaa6.as
>
> [ ... ]
>
> The interesting part of aaa6.as is that now if one writes
>
> X: CatX == if odd? random(10) then (A add) else (B add);
>
> (with the "add"), the program does not compile anymore in contrast to
> aaa5.as above.
>
>  >aldor -fx -laldor aaa6.as
> "aaa6.as", line 13:         stdout << foo() << newline;
>                      ..................^
> [L13 C19] #1 (Error) There are no suitable meanings for the operator  =

> `foo'.

But I guess, that's a different issue, as X has the foo function and  =

allows to call it, as demonstrated by

#include "aldor"
#include "aldorio"
macro I == MachineInteger;
define CatX: Category == with {foo: () -> I}
A: CatX == add {foo(): I == 0;}
B: CatX == add {foo(): I == 1;}
import from MachineInteger;
X: CatX == if odd? random(10) then (A add) else (B add);
main(): () == {
	import from X;

	stdout << (X has with{ foo:() -> I }) << newline;
	stdout << ((foo$X)()) << newline;
}
main();

LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx=
  =

-lalgebra -laldor  test2.as && ./test2 && sleep 1 && ./test2
cc1: note: -fwritable-strings is deprecated; see documentation for detai=
ls
cc1: note: -fwritable-strings is deprecated; see documentation for detai=
ls
T
1
T
0

\start
Date: Fri, 21 Jul 2006 09:47:16 +0200
From: Christian Aistleitner
To: Bill Page, Ralf Hemmecke
Subject: Re: [Aldor-l] exports and constants

Hello,


>> > You can interpret both kinds as "provides at least".
>
> No, I don't think that is true.

Can you provide an example where you cannot interprete it as "provides a=
t  =

least"?

>> >> Take for example
>> >>
>> >> A: Join(CatA, CatX) == add {...}
>> >> B: Join(CatB, CatX) == add {...}
>> >> X: CatX == if odd? random() then A else B;
>
> The reason of course is because the expression 'odd? random()'
> is not static - it does not have a well-defined value at the
> time that the source is compiled. It is only later when the
> code is run that we can know if the condition is true or false
> in a particular instance. The Aldor compiler is not able to
> compile *types* of this kind.

I see, that the compiler is not able to compile this. We all agree on  =

that. But I cannot see mhy the "odd? random()" is the problem. From my  =

point of view, the "if" is the problem. Ralf already provided an example=
,  =

where

   X: CatX == if true then (A add) else (B add);

worked, while

   X: CatX == if true then A else B;

did not. In this example "true" takes the place of "odd? random()". "tru=
e"  =

is static as could be and still the problem remains. Therefore I doubt  =

that "odd? random()" is the problem. Type inference across the "if"  =

statement is the problem. As I showed in
http://www.aldor.org/pipermail/aldor-l/2006-July/000228.html
, hinting the comiler by "@" works perfectly well.

\start
Date: Fri, 21 Jul 2006 10:37:30 +0200
From: Ralf Hemmecke
To: Christian Aistleitner
Subject: Re: [Aldor-l] exports and constants

Hello Christian,

On 07/21/2006 09:47 AM, Christian Aistleitner wrote:
[...]
> #include "aldor"
> import from String, TextWriter, Character;
> 
> define CatA: Category == with { }
> define CatB: Category == with { }
> define SomeCat: Category == with { CatA; CatB; }
> Dom: SomeCat == Integer add;
> 
> B: CatA == Dom;
> 
> stdout << "B has CatA: " << ( B has CatA ) << newline;
> stdout << "B has CatB: " << ( B has CatB ) << newline;
> 
> func( DomParam: CatB ):() == { stdout << "called func" << newline; }
> 
> 
> C_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx 
> -lalgebra -laldor -D IFCLAUSE test2.as && ./test2
> cc1: note: -fwritable-strings is deprecated; see documentation for details
> cc1: note: -fwritable-strings is deprecated; see documentation for details
> B has CatA: T
> B has CatB: T
> 
> 
> We see B's dynamic type has bath CatA and CatB.
> However,
> func( B )
> complains about B being only CatA and not also CatB.
> func( Dom )
> works.

I don't see what you mean.

> What about the following:
> 
> Universe of the compiler before B: CatA == DOM:
> 
> Dom ( StaticType: SomeCat; Implementation at memory location 123456 )
> 
> After the B: CatA == Dom:
> 
> Dom ( StaticType: SomeCat; Implementation at memory location 123456 )
> B   ( StaticType: CatA;    Implementation at memory location 123456 )

That would be OK for me, but currently the last line probably reads

B   ( StaticType: SomeCat; Implementation at memory location 123456 )

since the ": CatA" has no influence on the type of B. (That's what the 
compiler says. I am not sure what the language defines in that case.)

>> ---BEGIN aaa5.as
>> #include "aldor"
>> define CatA: Category == with;
>> define CatB: Category == with;
>> define CatX: Category == with;
>>
>> A: Join(CatX, CatA) == add;
>> B: Join(CatX, CatB) == add;
>> #if ADD
>> import from MachineInteger;
>> X: CatX == if odd? random(10) then (A add) else (B add);
>> #else
>> X: CatX == if true then A else B;
>> #endif
>> ---END aaa5.as
>>
>>  >aldor -fx -laldor -DADD aaa5.as
>>
>> compiles without any complaints. Now try without the ADD assertion.
>>
>>  >aldor -fx -laldor aaa5.as
>> "aaa5.as", line 14: X: CatX == if true then A else B;
>>                      ...........^
>> [L14 C12] #1 (Error) Have determined 0 possible types for the expression.
>>    Subexpression `A':
>>     Meaning 1:
>>                  Join(CatX, CatA) with
>>                      ==...
>>    Subexpression `B':
>>     Meaning 1:
>>                  Join(CatX, CatB) with
>>                      ==...
>>    The context requires an expression of type CatX.
>>
>>
>> Are you now a bit more puzzled?
>>
>> Random things are not the problem. Obviously "A" and "A add" are not
>> (treated) identical by the compiler.
> 
> It's getting tricky to put my thoughts into correct words, but I guess:
> Once the value of "A" and "A add" are established, they are treated 
> equally. But these expressions give different values. "A add" gives an 
> expression of type CatX. "A" gives an expression of type Join( CatX, 
> CatA ). And the compiler cannot infer properly, that Join( CatX, CatA ) 
> provides CatX.

I think I should try a little piece of code here to claim that "A add" 
cannot just give something of type CatX. We all know that it is a 
perfect value in Aldor and thus must have a type of its own. The only 
type I can think of for "A add" is that of "A" so it would be 
Join(CatX,CatA). But then some miracles happen if you say

X: CatX == A add;

That simply forgets the CatA exports.

Now let's make things a bit more complicated. Would you be able to guess 
the output of the following program?

---BEGIN aaa7.as
#include "aldor"
#include "aldorio"

define CatA: Category == with;
define CatX: Category == with;

A: Join(CatX, CatA) == add;
X: CatX == A add;  stdout << (X has CatA) << newline;
Y: CatX == A;      stdout << (Y has CatA) << newline;
#if WITHZ
Z: CatA == Y;      stdout << (Z has CatA) << newline;
#endif
---END aaa7.as

Right.

 >aldor -grun -laldor aaa7.as
F
T

 >aldor -DWITHZ -grun -laldor aaa7.as
"aaa7.as", line 11: Z: CatA == Y;      stdout << (Z has CatA) << newline;
                     ...........^
[L11 C12] #1 (Error) There are 0 meanings for `Y' in this context.
The possible types were:
	  Y: CatX, a local
   The context requires an expression of type CatA.

So the compiler now thinks that the type of Y is just CatX. OK, but then 
why can the program print "T" in the previous compilation?

If that is not to be considered a bug then I don't know what to say.

>> Now if we assume that
>>
>> X: CatX == if true then A else B;
>>
>> yield an X of the type of the domain on the right hand side then the
>> compiler has to match the types of A and B (they have to be equal).
>> Try to replace B by A in the code above and the compiler will not
>> complain anymore.
> 
> Not true for me--I still get the corresponding errors:
> 
> #include "aldor"
> define CatA: Category == with;
> define CatB: Category == with;
> define CatX: Category == with;
> 
> A: Join(CatX, CatA) == add;
> B: Join(CatX, CatB) == add;
> 
> X: CatX == if true then B else A;

Sorry, I meant

X: CatX == if true then A else A;

(no B anymore).

>> ---BEGIN aaa6.as
>> #include "aldor"
>> #include "aldorio"
>> macro I == MachineInteger;
>> define CatX: Category == with {foo: () -> I}
>> A: CatX == add {foo(): I == 0;}
>> B: CatX == add {foo(): I == 1;}
>>
>> import from MachineInteger;
>> X: CatX == if odd? random(10) then A else B;
>>
>> main(): () == {
>>     import from X;
>>     stdout << foo() << newline;
>> }
>> main();
>> ---END aaa6.as
>>
>> [ ... ]
>>
>> The interesting part of aaa6.as is that now if one writes
>>
>> X: CatX == if odd? random(10) then (A add) else (B add);
>>
>> (with the "add"), the program does not compile anymore in contrast to
>> aaa5.as above.
>>
>>  >aldor -fx -laldor aaa6.as
>> "aaa6.as", line 13:         stdout << foo() << newline;
>>                      ..................^
>> [L13 C19] #1 (Error) There are no suitable meanings for the operator 
>> `foo'.
> 
> But I guess, that's a different issue, as X has the foo function and 
> allows to call it, as demonstrated by
> 
> #include "aldor"
> #include "aldorio"
> macro I == MachineInteger;
> define CatX: Category == with {foo: () -> I}
> A: CatX == add {foo(): I == 0;}
> B: CatX == add {foo(): I == 1;}
> import from MachineInteger;
> X: CatX == if odd? random(10) then (A add) else (B add);
> main(): () == {
>     import from X;
> 
>     stdout << (X has with{ foo:() -> I }) << newline;
>     stdout << ((foo$X)()) << newline;
> }
> main();
> 
> LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx 
> -lalgebra -laldor  test2.as && ./test2 && sleep 1 && ./test2
> cc1: note: -fwritable-strings is deprecated; see documentation for details
> cc1: note: -fwritable-strings is deprecated; see documentation for details
> T
> 1
> T
> 0

I am amazed. I had also tried foo()$X but the compiler still complained.

\start
Date: Fri, 21 Jul 2006 13:06:26 +0200
From: Ralf Hemmecke
To: list
Subject: semantics of categories

Last night I was referring to some problems with categories as first 
class values. I remember that I have read something about it.

http://www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/discussion/define.pdf

I've already put a copy of this and the other papers in that directory to

http://portal.axiom-developer.org/refs/articles/

\start
Date: Fri, 21 Jul 2006 13:48:47 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

On 07/21/2006 07:58 AM, Martin Rubey wrote:
> Dear all,
> 
> I made yet another experiment (on SandBox7, no ssh here), and tested
> whether in the code below H would have SomeCat. It does not. B has,
> though.

http://wiki.axiom-developer.org/SandBox7

mainHB and mainHS return false is totally clear. You define a *new* 
domain H and declare its type to be just CatA. What else would you expect?

\start
Date: Fri, 21 Jul 2006 15:41:38 +0200 (CEST)
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: semantics of categories

On Fr, 21.07.2006, 13:06, Ralf Hemmecke wrote:
> Last night I was referring to some problems with categories as first
> class values. I remember that I have read something about it.
>
> http://www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/discussion/define.pdf

Funny that they would say in the appendix

 Perhaps there is some mind-bending way that domains
 could be constructed as a resul to userinput, but I cannot think of
 one off the top of myhead.

since I guess that this is exactly what we were doing in our version of
combinat -- i.e., the parser I wrote, that takes a string and returns a
combinatorial class.

\start
Date: Fri, 21 Jul 2006 07:09:54 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Axiom bibliography - questions to consider

Hi everybody:

   Concerning the Axiom bibliography, Bob made the point that perhaps
we shouldn't worry about organization of the bibliography as a whole,
since its primary purpose is to serve as a repository for bib
references used in pamphlets.  I may have gotten a false impression
from earlier discussions, so before I go further maybe we should decide
definitely a couple of things:

a)  Do we want to include annotations as part of the bibliography?

   Personally, my feeling on this is that we should, and I believe it
is something Tim suggested we should do.  Virtually all of Axiom is in
the form of literate documents ala pamphlet files, which I approve of. 
In the one, specific case of the bibtex bibliography data however, I
believe a pamphlet (or at least a .bib.pamphlet file) is not the
correct way to make it "literate".  The document content (in whatever
eventual form) will be bibtex paper entries and our comments (if any)
about that paper.  This means that a pamphlet file would consist of
large amounts of "code" (the bibtex syntax) and then our annotations
about the paper in question, which are often likely to be fairly
minimal.  Given this, the thing that makes the most sense to me is to
not introduce the extra overhead of the pamphlet structure, but take
advantage of the fact that bibtex is already structured.  If we want to
"see" the bibliography as a whole (more on this later), we can include
it in a "bibliography" latex document which could provide the
"pamphlet" part of the system.  I like Bob's description of axiom.bib
as a database, as opposed to a document - I think that's a good way to
look at it.

   Next question - what do we want to "do" with the annotations?  Do we
want them to simply be attached to the bibliography as a note for
people who want to find notes about the paper?  Do we include the
annotation in each pamphlet's LaTeX output?  
   My thoughts on this, which I expect will not be universal, are 1) 
We should not include the annotations in pamphlet-level output by
default, to avoid possibly undesirable length of the document.  2) 
Rather we should have a link available to an entry in an ouput document
which does have the annotation available, if the user wants that.  3) a
build time option of including or not including annotations in pamphlet
files might be a good idea - this can be accomplished by changing which
bst file is used (presumably there is a way to do something like copy
axiom-plain.bst to axiom.bst prior to compiling the pamphlet files). 
The bst files will need to become literate documents.

a)  What do we want to do about the "complete bibliography as a volume"
idea?

   Number 2 above suggests one of the reasons I favor having a complete
document containing all bibliography entries - that complete document
will include the annotations for each entry.  Another reason I have
touched on earlier - with this document organized according to MSC2000
and PACS, it will be possible for a researcher to quickly access the
level of coverage Axiom has attained in a particular research subfield.
 It will also provide a mechanism for classifying Axiom pamphlets
according to subject, which I believe was of some interest earlier.  If
we view the axiom.bib file as a database, many interesting
transformations become possible - assembling mini-bibliographies for a
single subject, assembling a bibliography of pamphlets only, finding
all papers in all subjects from a particular journal, etc. etc. etc.
  Plus, if we are to publish Axiom someday as "volumes", we might be
able to provide a mechanism where the "global" bibliography volume
could group papers by subject with an indication of which pamphlets
they are cited by.  This might actually be possible with existing tools
(http://www.tug.org/pipermail/macostex-archives/2004-June/006647.html),
and if there is interest I will look into it further.  In this fashion,
we are more or less building a roadmap to the Axiom system via
mathematical subject.  It allows someone to ask the question "I wonder
if Axiom implements this idea from this paper?"  They can then check
the bibliography by subject looking for that paper, and if it exists
check the pamphlets referenced by it.
  Naturally, the latex document(s) needed for this must be generated at
real time based on the bibliography (and possibly the pamphlets
themselves).  Right now I'm using unix system tools.  Probably the way
to eventually do it would be to move the logic into Lisp and streamline
it, but while I'm not yet up to that I can at least get something
working which can eventually be transferred to Lisp. (We will probably
also want things like CL-PPCRE, which I'm not sure works under GCL -
particularly non ANSI GCL.)

   I think it will become very important, as we move forward, to have
some kind of system that is consistent, comprehensive, and agreed upon.
 While Axiom is now technically composed of literate documents, most of
those consist almost completely of source code.  The real work of
turning them into complete, properly referenced papers is still ahead
of us, so now is the time (IMHO) to put something in place which will
scale up as far as might be needed in the future.  Since this is a
decision and a convention that would have widespread results, I invite
comment and discussion.

\start
Date: Fri, 21 Jul 2006 17:12:33 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Axiom bibliography - questions to consider

Hello Cliff,

> a)  Do we want to include annotations as part of the bibliography?

I think yes. But as for you, a .bib file for me is a database format.
Turning it into a .bib.pamphlet does not gain much if the text between 
the bibentries could also be written inside an annote filed of the 
bibentry. In a pamphlet file, the latex text between the "code chunks" 
(bib-entries) would even be less accessible to different views.

Assume I want to have a nice document that annotates references related 
to some area that I am interested in. Then I think it is better, one 
starts a program and generates such a document from a database (be it a 
.bib file or something else). I don't think it makes much sense to write 
up a fixed view on the bibliographic data as ONE .bib.pamphlet would be.

> a)  What do we want to do about the "complete bibliography as a volume"
> idea?

I rather think that should be just digitally accessible with links and 
everything. In book form it only has half the value.

\start
Date: Fri, 21 Jul 2006 10:08:22 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Axiom bibliography - questions to consider

--- Ralf Hemmecke wrote:

> Hello Cliff,
> 
> > a)  Do we want to include annotations as part of the bibliography?
> 
> I think yes. But as for you, a .bib file for me is a database format.
> Turning it into a .bib.pamphlet does not gain much if the text
> between the bibentries could also be written inside an annote filed
> of the bibentry. In a pamphlet file, the latex text between the "code
> chunks" (bib-entries) would even be less accessible to different
> views.

Agreed.
 
> Assume I want to have a nice document that annotates references
> related to some area that I am interested in. Then I think it is
> better, one starts a program and generates such a document from a
> database (be it a .bib file or something else). I don't think it
> makes much sense to write up a fixed view on the bibliographic data
> as ONE .bib.pamphlet would be.

Maybe a good idea would be to do a lisp version of bibtool.  I'll have
to look into that.

Sounds like we are on the same page :-).

> > a)  What do we want to do about the "complete bibliography as a
> volume" idea?
> 
> I rather think that should be just digitally accessible with links
> and everything. In book form it only has half the value.

Oh, certainly I would agree that digital access with hyperlinking would
be the most useful (and most common) method.  The two shouldn't be
mutually exclusive though.  In fact, maybe we can use latex2html for
this, since it doesn't rely on images... Hmm... I'll have to do some
tests.  Searching would probably be more difficult... Hmm.

I'm hopeful that someday Axiom will be one of those things like the
Oxford Unabridged Dictionary that all academic libraries will want to
have on their shelves as worth preserving for the ages.  Of course
electronic copies are more useful, but for reading I often prefer a
book.  If Axiom does exist as 10 or 20 printed volumes, I think being
able to print the entire bibliography is probably of some interest, for
the sake of completeness.  But that shouldn't interfere with more
mundane and practical uses :-).

\start
Date: Fri, 21 Jul 2006 15:38:40 -0400
From: Alfredo Portes
To: list
Subject: Doyen Wiki

Hi everyone,

Mr. Bill Page has point out in many occasions the importance of
improving the content of the Doyen Wiki included in the Live CD. I
have setup a LatexWiki server for this purpose:
http://doyen.sytes.net/Doyen

Here, anybody can add content that you consider important, especially
using information from axiom-developer. This content will be the same
to be included in the Live CD.

It can also be used to develop/test the idea of the drag and drop
engine and future algebra systems to work in the Wiki.

If you have any problem accessing it, please let me know.

\start
Date: Sat, 22 Jul 2006 08:33:43 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Order of loading of lisp files?

Is there some way to identify the order in which lisp, boot, and spad
files are loaded into the lisp environment once gcl is built?  I'm
trying to figure out how to attempt a sbcl build and I'm not quite sure
how to "plug in" sbcl instead of the axiom copy of gcl.

\start
Date: Sat, 22 Jul 2006 16:19:43 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Order of loading of lisp files?

On July 22, 2006 11:34 AM you wrote:
> 
> Is there some way to identify the order in which lisp, boot,
> and spad files are loaded into the lisp environment once gcl
> is built?  I'm trying to figure out how to attempt a sbcl build
> and I'm not quite sure how to "plug in" sbcl instead of the
> axiom copy of gcl.
>

That you ask the question in this way suggests that you have
a lot to learn about the way Axiom is built! But then I have
always admired the way you seem to be willing to ask these
questions. :-) Seriously. If more people asked for things on
this list, we would be getting a lot further than we have in
the number of possible Axiom developers.

The short answer to your question of course is that you must
look at the Makefile.pamplet, or rather the set of makefiles
in each of the root, boot, interp and algebra directories.
The order is given there both explicitly and to lesser extent
implicitly, in the manner allowed by make.

The longer answer is that the current Axiom build process is
not really organized in a manner that would allow you to just
"plug in" a different lisp. It might be easier for you to work
with the Debian version of the build which does not build the
lisp system from scratch. Another thing that you might look at
is the CMUCL build of Axiom that was done by Juergen Weiss
about 3 years ago. See the most recent reference to this here:

http://lists.nongnu.org/archive/html/axiom-developer/2005-11/msg00373.html

There is one statement that Juergen made here in this email
that has really stuck in my mind. In reply to Tim Daly Jr.
question regarding the common lisp port:

> ...
>> And, if it's been done, how come people are still talking
>> about getting it done?
>

He wrote:

>  "because people do not listen ;-)..."

Well, I am certainly listening, but unfortunately we have not
heard anything more from either of them since that exchange. :(

\start
Date: Sat, 22 Jul 2006 17:01:44 -0400
From: Tim Daly
To: Camm Maguire
Subject: compile failure

Camm 

While building the latest version of Axiom on GCL-2.6.8pre I get
the attached failure. Is GCL-2.6.8 ready for use?

Tim

=======================================================================

gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/tmp/axiom49/lsp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
fat_string.c:229: parse error before `bfd_combined_table_update'
fat_string.c:229: warning: return type defaults to `int'
fat_string.c: In function `fSset_up_combined':
fat_string.c:301: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
fat_string.c:308: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
make[4]: *** [fat_string.o] Error 1
make[4]: Leaving directory `/tmp/axiom49/lsp/gcl-2.6.8pre/o'
make[3]: *** [unixport/saved_pre_gcl] Error 2
make[3]: Leaving directory `/tmp/axiom49/lsp/gcl-2.6.8pre'
/bin/sh: unixport/saved_gcl: No such file or directory
make[2]: *** [gcldir] Error 127
make[2]: Leaving directory `/tmp/axiom49/lsp'
make[1]: *** [lspdir] Error 2
make[1]: Leaving directory `/tmp/axiom49'
make: *** [all] Error 2

\start
Date: Sun, 23 Jul 2006 02:00:56 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [Aldor-l] exports and constants
Cc: Christian Aistleitner

Ralf,

On July 20, 2006 8:12 PM you wrote:
> 
> Thank you for your comments, but I don't seem to agree with 
> everything.

That is probably a good thing! :)

> 
> Let's keep this program since I'll refer to its output.
> 

Omitted for brevity. Please refer to:

http://wiki.axiom-developer.org/SandBoxAldorSemantics

> >>
> >> In particular, that "B has CatB" is a bit surprising, isn't it?
> 
> > I think you are dealing here with two separate but related
> > issues:
> > 1) *static* typing, and 2) inheritance rules. All types in Aldor
> > are static (or at least *nearly static*) meaning that they must
> > be resolved during the compilation phase.
> 
> The "B has CatB" result is not about static or dynamic. If you
> read the code above. Would you immediately be able to tell that
> the Type of B is NOT CatA (as "H: CatA" might suggest), but the
> same as the type of Dom?

You are right, this example has only to do with inheritance
(Other cases you mentioned involved static vs. dynamic types).

You say: "the Type of B is NOT CatA", ??? But what I see is that
the type of both B and H *is* CatA just as the code says it must
be if this program is going to compile (and it does)!

Perhaps your question really is: If B is of type CatA, how can it
also satisfy CatB? To understand this you must understand that
SomeCat is a subtype of both CatA and CatB and therefore a domain
that is a member of SomeCat is also a member of both CatA and CatB.

Refer especially to section 7.5 of the Aldor User's Guide:

  "Inheritance for domains from categories is analogous to class
  membership and inheritance between categories is analogous to
  class containment."

> 
> >> Has someone found a description in the Aldor UG of whether this
> >> is intended to be so or this should be considered a bug in the
> >> compiler?
> 
> > No, I don't think it is a bug. This is all rather well (although
> > perhaps too tersely explained in the Aldor Users Guide, under
> > the heading of "Type Satisfaction", see section 7.7.
> 
> I know that the html version of the user guide at aldor.org 
> is a little 
> different from the .pdf version, but it seems 7.7 and 7.8 are OK.
> Looking at the pdf version, I cannot find good explanations of what
> 
> H: CatA == Dom;
> 
> actually means.
> 
> The constant assignment
> 
> H == Dom;
> 
> is clear, though. H inherits type and value of Dom.

But this is very fundamental. H:CatA is a declaration of the type
of H. That is true no matter in what context this appears.

In Aldor := is an assignment and is processed at run-time, while
== is a definition and is processed by the compiler. See section 5.3
of the Users Guide:

  "The general syntax for a constant definition is:

      x : T == E

  x is an identifier giving the name of the constant.

  T is an expression giving the type of the constant. The type
  declaration is optional. If the type is declared, then the type
  of E must satisfy it. Otherwise the type is inferred from the
  type of the expression E."

> 
> >> There is a difference in the semantic, but I cannot
> >> remember that I have found a proper explanation of what
> >> "Ident: SomeType == Dom" actually means (no "add" here).
> 
> > In the above the value of 'Ident' *is* 'Dom' whereas in the
> > previous case 'Ident' is the name of a new domain whose
> > "parent domain" is 'Dom' - like the difference between
> 
> If Ident *is* Dom then what do you think the ": SomeType" is for?
> 
> >>>> One cannot, however write something like
> >>>>
> >>>> CatC: Category == with { }
> >>>> H: CatC == Dom;
> >>> Of Course not, because Dom does not provide CatC.
> >>>> Different from
> >>>>
> >>>> A: CatA == Dom add;
> >>>>
> >>>> the construct
> >>>>
> >>>> H: CatA == Dom;
> >>>>
> >>>> just means that H provides *at least* the exports of CatA, 
> >>>> and the compiler can tell, if Dom provides less.
> 
> > In the first case you are defining a new domain A which
> > satisfies only CatA. In the second case you are saying
> > that H is identical to Dom, but the compiler knows that
> > is not true.
> 
> First and second is not so clear to me now. Can you repeat your 
> statement. In particular I don't understand your last sentence.
> 
> >>> You can interpret both kinds as "provides at least".
> 
> > No, I don't think that is true.

As stated in section 5.3

  H: CatA == Dom

means that the type of Dom must satisfy CatA, i.e. 'Dom has CatA'
must be true, which is just another way to say that it "provides
*at least* the exports of CatA". Provided that the compiler can
determine that this is true, then H is a constant that denotes
exactly Dom.

On the other hand if we write

  A: CatA == Dom add

section 5.3 still applies. (So in that sense you are right.)

The difference is that now Dom is the parent domain of a new
domain: "which specifies a domain from which any or all of the
exports of the add can be inherited". (Ref: Section 7.8).

So 'Dom add' is a new domain which inherits from Dom, but now
we need to take into account the rule about the "Visibility of
inherited operations":

  "whenever an expression 'A add B' appears in a context requiring
  a domain whose type is the category C, then any operations
  required by C which are not defined in B are taken from the
  domain A.

So here the expression 'Dom add' appears in a context requiring a
domain whose type is CatA, so all operations (and by implication,
*only* those operations) required by CatA are taken from Dom.

> ...
> Bill Page wrote:
>> The reason of course is because the expression 'odd? random()'
>> is not static - it does not have a well-defined value at the
>> time that the source is compiled. It is only later when the
>> code is run that we can know if the condition is true or false
>> in a particular instance. The Aldor compiler is not able to
>> compile *types* of this kind.
> 
> Bill you should have tried the following piece of code.
> 
> ---BEGIN aaa5.as
> #include "aldor"
> define CatA: Category == with;
> define CatB: Category == with;
> define CatX: Category == with;
> 
> A: Join(CatX, CatA) == add;
> B: Join(CatX, CatB) == add;
> #if ADD
> import from MachineInteger;
> X: CatX == if odd? random(10) then (A add) else (B add);
> #else
> X: CatX == if true then A else B;
> #endif
> ---END aaa5.as
> 
>  >aldor -fx -laldor -DADD aaa5.as
> 
> compiles without any complaints. Now try without the ADD assertion.
> 
>  >aldor -fx -laldor aaa5.as
> "aaa5.as", line 14: X: CatX == if true then A else B;
>                      ...........^
> [L14 C12] #1 (Error) Have determined 0 possible types for the 
> expression.
>    Subexpression `A':
> 	Meaning 1:
>                  Join(CatX, CatA) with
>                      ==...
>    Subexpression `B':
> 	Meaning 1:
>                  Join(CatX, CatB) with
>                      ==...
>    The context requires an expression of type CatX.
> 
> 
> Are you now a bit more puzzled?

No. That makes perfectly good sense according to the Aldor Users
Guide. You can compile:

  define CatA: Category == with;
  define CatB: Category == with;
  define CatX: Category == with {CatA; CatB;}
  A: Join(CatX, CatA) == add;
  B: Join(CatX, CatB) == add;
  import from Integer;
  X: CatX == if odd? random(10) then A else B;

Maybe it is surprising that the compiler does not complain about

> X: CatX == if odd? random(10) then (A add) else (B add);

but then both A and B satisfy CatX in a vacuous sense: none of
these categories have any exports and so X is still a constant.

But suppose we try a little harder:

  import from Integer;
  define CatA: Category == with {n:Integer};
  define CatB: Category == with {n:Integer};
  define CatX: Category == with {n:Integer};
  A: Join(CatX, CatA) == add { n:Integer==1 };
  B: Join(CatX, CatB) == add { n:Integer==2 };
  X: CatX == if odd? random(10) then (A add) else (B add);

where n is a "category-valued constant" as described in section
7.9. Again (surprise!) Aldor compiles this with no errors. But
what output do we expect? Will evaluating n$X yield different
results each time it is called?

What we see at runtime in fact is that n$X is a constant just
as required. See the example at

http://wiki.axiom-developer.org/SandBoxAldorSemantics

Should we conclude that it is the compiler that evaluates the
expression 'odd? random(10)' at compile time? Or perhaps that
fact that n must be a constant is resolved in some other way?

> 
> Random things are not the problem. Obviously "A" and "A add" are
> not (treated) identical by the compiler.

I agree that "A" and "A add" are not treated identically but the
difference is more subtle then your example implies.

> ... 
> And to make you even more happy...
> 
> ---BEGIN aaa6.as
> #include "aldor"
> #include "aldorio"
> macro I == MachineInteger;
> define CatX: Category == with {foo: () -> I}
> A: CatX == add {foo(): I == 0;}
> B: CatX == add {foo(): I == 1;}
> 
> import from MachineInteger;
> X: CatX == if odd? random(10) then A else B;
> 
> main(): () == {
> 	import from X;
> 	stdout << foo() << newline;
> }
> main();
> ---END aaa6.as
> 
> woodpecker:~>aldor -fx -laldor aaa6.as
> woodpecker:~>aaa6
> 0
> woodpecker:~>aaa6
> 0
> woodpecker:~>aaa6
> 0
> woodpecker:~>aaa6
> 0
> woodpecker:~>aaa6
> 0
> woodpecker:~>aaa6
> 1
> woodpecker:~>aaa6
> 1
> 
> It's only the type of X that must be clear at compile time.

I agree that it is the type of X must be clear. But something
very strange is going on here. I do not get this result in my
example running Aldor inside Axiom. See again:

http://wiki.axiom-developer.org/SandBoxAldorSemantics

If you write:

  main(): () == {
  	import from X;
  	stdout << foo() << newline;
  	stdout << foo() << newline;
  	stdout << foo() << newline;
  	stdout << foo() << newline;
  	stdout << foo() << newline;
  	stdout << foo() << newline;
  }
  main();

You will see that each time you run the program you will only
get one *constant* result (all 0's or all 1's). But if you run
the same program repeatedly (as you did above), then sometimes
you get one result and sometimes the other! Within a given
runtime of the program, the result is constant and not variable
as you might be expecting.

My conclusion is that Aldor must be sort of "faking" the
compilation of the constants in the sense that they are not
fully resolved at compile-time, yet they are indeed constant
within any run of the program. There must be some kind of
dynamic initialization phase at the start of the program.

> But maybe even that is just a current restriction of the compiler. 
> Categories are first class values and they should be computable
> at runtime.

I do not know of any examples where categories are computed at
runtime in Aldor except in the case of dependent types where
static type checking is still possible.
 
> But I won't go into detail since there are certain problems that
> occur if categories are truly "first class".

The devil is in the details and that is what we are discussing!
:)

> ... 
> >> ---BEGIN aaa2.as
> >> #include "aldor"
> >> import from String, TextWriter, Character;
> >>
> >> define CatA: Category == with;
> >> define CatB: Category == with;
> >> define CatX: Category == with;
> >>
> >> A: CatX with { CatA } == add;
> >> B: CatX with { CatB } == add;
> >>
> >> X: CatX == if true then (A add) else (B add); -- (*)
> >>
> >> stdout << "X has CatA: " << ( X has CatA ) << newline;
> >> stdout << "X has CatB: " << ( X has CatB ) << newline;
> >> stdout << "X has CatX: " << ( X has CatX ) << newline;
> >> ---END aaa2.as
> >>
> >> aldor -grun -laldor aaa2.as
> >> X has CatA: F
> >> X has CatB: F
> >> X has CatX: T
> >>
> >> That is clear, but why does the compiler reject the program 
> >> without the "add" in line (*)?
> 
> > It is because the types of A and B are not a subtypes of CatX.
> > But X can be a member of CatX defined by (A add) or (B add).
> 
> I don't understand.
> A is of type Join(CatX, CatA) and you are saying that this is not a 
> subtype of CatX??? Similar for B.
>

No, in the above program A is not of type Join(CatX, CatA), it is
just CatX. And CatA does not satisfy CatX.

 
> >> ---BEGIN aaa3.as
> >> #include "aldor"
> >> import from String, TextWriter, Character, MachineInteger;
> >>
> >> define CatA: Category == with;
> >> define CatB: Category == with;
> >> define CatX: Category == with;
> >>
> >> A: Join(CatX, CatA) == add;
> >> B: Join(CatX, CatB) == add;
> >>
> >> MyPkg(X: CatX): with {isA?: () -> Boolean} == add {
> >> 	isA?(): Boolean == X has CatA;
> >> }
> >> main(): () == {
> >> 	import from CommandLine, Array String;
> >> 	X: CatX == if zero? #arguments then (A add) else (B add);
> >> 	stdout << isA?()$MyPkg(X) << zero? #arguments << newline;
> >> }
> >> main();
> >> ---END aaa3.as
> >>
> >>  >aldor -fx -laldor aaa3.as
> >>  >aaa3
> >> FT
> >>  >aaa3 1
> >> FF
> 
> > Static type again: the value of 'isA()' is determined at
> > compile time and does not depend on #arguments.
> 
> That is completely wrong. If "isA?()" would be computed at 
> compile time, I would be really amazed. X is a parameter to
> MyPkg. How should the compiler be able to evaluate "X has CatA"
> at all?
>

X is a domain of type CatX, thus X has CatA is always false.

> ... 
> Maybe I don't quite understand your "static", but I believe 
> that what I have demonstrated above shows that Aldor just
> requires that types are constant in a certain context, but
> otherwise one can do quite a lot with them.

By "static" I just mean that in Aldor the type-correctness of a
program can be checked entirely at compile-time. Because Aldor's
type system is quite complex, including the possibility of
dependent types, then you are right that this does not mean
that all types in Aldor are constant. But so far I don't think
you have given an example where this is not the case.

> 
> My feeling is that categories are not really "first class" in
> Aldor (which is certainly another issue). I haven't seen any
> reasonable program that computes a category and then creates
> a domain that belongs to that category. That the compiler cannot
> handle computed categories, I can understand, but I don't even
> know whether it would be useful to treat categories as "first
> class citizens".
> 

I would look at the situation of dependent types.

\start
Date: Sun, 23 Jul 2006 05:17:45 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Order of loading of lisp files?

--- Bill Page wrote:

> CY,
> 
> On July 22, 2006 11:34 AM you wrote:
> > 
> > Is there some way to identify the order in which lisp, boot,
> > and spad files are loaded into the lisp environment once gcl
> > is built?  I'm trying to figure out how to attempt a sbcl build
> > and I'm not quite sure how to "plug in" sbcl instead of the
> > axiom copy of gcl.
> 
> That you ask the question in this way suggests that you have
> a lot to learn about the way Axiom is built! But then I have
> always admired the way you seem to be willing to ask these
> questions. :-)

Well, I guess idiocy has some virtue after all ;-).

> Seriously. If more people asked for things on
> this list, we would be getting a lot further than we have in
> the number of possible Axiom developers.

At a guess, I think we're all still waiting to see if the Aldor
situation sorts itself out.  However, since all the neat toys in the
lisp world seem to run on the more ANSI lisp implementations out there,
a lot of experimentation won't be able to happen until we can join them
there.

> The short answer to your question of course is that you must
> look at the Makefile.pamplet, or rather the set of makefiles
> in each of the root, boot, interp and algebra directories.
> The order is given there both explicitly and to lesser extent
> implicitly, in the manner allowed by make.

I have started trying to do that (it was more involved than I had
guessed - I had to follow several levels of make file down to the src
dir level before I even identified what I needed).  Unfortunately,
while that of course gives me the broad outlines of what I need, there
still seem to be a few gotchas I haven't ironed out.  To say nothing of
trying to tweak the lisp to load in sbcl.  For example, the boot make
file didn't indicate that I need interp/utils.lisp loaded before I
could do boottocl on a file (I'm sure that logic was somewhere but I
missed it the first time around).

> The longer answer is that the current Axiom build process is
> not really organized in a manner that would allow you to just
> "plug in" a different lisp. It might be easier for you to work
> with the Debian version of the build which does not build the
> lisp system from scratch. 

That's a good idea.

> Another thing that you might look at
> is the CMUCL build of Axiom that was done by Juergen Weiss
> about 3 years ago. See the most recent reference to this here:

I took a look at that, but I see I didn't look closely enough.  I
couldn't figure out how to build it, but I now see the Make files are
hidden in the tree.  That's far and away the most promising, since a
lot of the fixes for CMUCL are likely to apply to sbcl as well. 

> There is one statement that Juergen made here in this email
> that has really stuck in my mind. In reply to Tim Daly Jr.
> question regarding the common lisp port:
> 
> > ...
> >> And, if it's been done, how come people are still talking
> >> about getting it done?
> >
> 
> He wrote:
> 
> >  "because people do not listen ;-)..."

Well, I'm embarassed to admit I did download it but couldn't figure out
how to load it. I think I'm making more progress now, although it is
clear 3 years has resulted in enough changes in CMU to need some
updating.

In the interest of listening, does Tim Daly Jr. in fact have an asdf
file for Axiom, however incomplete?  Eventually we will want to be
looking at one if we do things the "lispish" way (and I think that
would be a very good idea - the make files are good for bootstrapping
and managing external requirements, but once we hit the lisp level asdf
is the way to go).  If one is already started I would very much prefer
to work with that than start from scratch ;-)
 
> Well, I am certainly listening, but unfortunately we have not
> heard anything more from either of them since that exchange. :(

I think it has gone no further because no annotated diff has been
prepared for Tim yet ;-).

I'll see if I can run the CMUCL version.

\start
Date: Sun, 23 Jul 2006 09:15:31 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Order of loading of lisp files?

see src/interp/debugsys.lisp.pamphlet for the load order.
axiom actually loads the .o files but debugsys is interpreted
and loads the lisp versions.

\start
Date: Sun, 23 Jul 2006 10:55:07 -0400
From: Tim Daly
To: Scott Collison
Subject: axiom entry

Gentlemen,

The information you have posted about Axiom is wildly incorrect.
I sent correct information a while ago yet the wrong information persists.

It is important that the public information for Axiom is correct and
you are causing damage by posting information which is wrong. Soon the
search engines will catalog your version and it will never go away.

Please remove Axiom from your site.

\start
Date: 23 Jul 2006 19:13:04 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: compile failure
Cc: Camm Maguire

Tim Daly writes:

| Camm 
| 
| While building the latest version of Axiom on GCL-2.6.8pre I get
| the attached failure. Is GCL-2.6.8 ready for use?
| 
| Tim
| 
| =======================================================================
| 
| gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  -I/tmp/axiom49/lsp/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
| fat_string.c:229: parse error before `bfd_combined_table_update'
| fat_string.c:229: warning: return type defaults to `int'
| fat_string.c: In function `fSset_up_combined':
| fat_string.c:301: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
| fat_string.c:308: warning: passing arg 2 of `bfd_link_hash_traverse' from incompatible pointer type
| make[4]: *** [fat_string.o] Error 1
| make[4]: Leaving directory `/tmp/axiom49/lsp/gcl-2.6.8pre/o'
| make[3]: *** [unixport/saved_pre_gcl] Error 2
| make[3]: Leaving directory `/tmp/axiom49/lsp/gcl-2.6.8pre'
| /bin/sh: unixport/saved_gcl: No such file or directory
| make[2]: *** [gcldir] Error 127
| make[2]: Leaving directory `/tmp/axiom49/lsp'
| make[1]: *** [lspdir] Error 2
| make[1]: Leaving directory `/tmp/axiom49'
| make: *** [all] Error 2


Tim --

   That might be another aspect of a bug reported here

   http://lists.gnu.org/archive/html/gcl-devel/2006-07/msg00004.html

Can you try

   http://lists.gnu.org/archive/html/gcl-devel/2006-07/msg00007.html

?

\start
Date: Sun, 23 Jul 2006 13:36:01 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: compile failure
Cc: Camm Maguire

that fixed it. the breakage has moved elsewhere. thanks. --t

\start
Date: Sun, 23 Jul 2006 16:16:01 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Translation of the interp to lisp

After fooling around this weekend trying to get something running on
sbcl, I can see Tim why you decided to scrap boot and get everything
below SPAD/Aldor into Lisp.  Yikes.

Two questions:

1.  Where is the most current work on that translation?  Is it in the
silver/gold branches?  Or one of the tla archives?  (Sorry if I missed
this in my archive hunt - there were a lot of emails on the general
subject).

2.  I noticed a lot of implementation specific code having to do with
things like (system:getenv $AXIOM) - is the plan to write some generic
macros to handle these operations and get all of the implementation
specific logic into one file?

Not trying to restart the boot vs. lisp wars, just want to know how
best to help here.  I could start going over the #+gcl type entries in
the files and putting together a "rosetta" file for various
implementations, if that's of any interest.  Also, I would be
interested in helping with an asdf file if that is on the program -
I've tried with the boot based codebase but didn't even get to first
base.  The multiple images used in the bootstrapping process (something
I gather would be rendered unnecessary by the lisp conversion?) tend to
complicate things.

\start
Date: Sun, 23 Jul 2006 18:47:34 -0400
From: Tim Daly
To: list
Subject: Correctness/Provability/Compiling

Functional Pearl, A Type-correct, stack-safe, provably correct
expression compiler in Epigram.
http://www.cs.nott.ac.uk/~jjw/papers/Compiler_Pearl/Compiler_Pearl.pdf


I've mentioned before that it is a long term goal of Axiom to 
enhance the compiler to prove properties of Categores and Domains.
This is of interest because of that goal. I'd like to be able to
do things like decorate the Categories and Domains with mathematical
axioms (e.g. Group) and prove properties like commutative rather
than just assert them. 

\start
Date: 24 Jul 2006 01:53:00 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Correctness/Provability/Compiling

Tim Daly writes:

| Functional Pearl, A Type-correct, stack-safe, provably correct
| expression compiler in Epigram.
| http://www.cs.nott.ac.uk/~jjw/papers/Compiler_Pearl/Compiler_Pearl.pdf
| 
| 
| I've mentioned before that it is a long term goal of Axiom to 
| enhance the compiler to prove properties of Categores and Domains.

We need a clear formulation of the type system for that.  
Adn we also need a clear grammar.

| This is of interest because of that goal. I'd like to be able to
| do things like decorate the Categories and Domains with mathematical
| axioms (e.g. Group) and prove properties like commutative rather
| than just assert them. 

Funny, you should mention that.  In our design for "C++ concepts", we
have provision for that -- though it is not enforced in the typpe
system directtly, but can be used for auxiliary tools.

\start
Date: Sun, 23 Jul 2006 19:47:50 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Translation of the interp to lisp

> 1.  Where is the most current work on that translation?  Is it in the
> silver/gold branches?  Or one of the tla archives?  (Sorry if I missed
> this in my archive hunt - there were a lot of emails on the general
> subject).

the current work is on my local disk. the first fruits are in 
bookvol5.pamphlet. i'm currently working on decoding the interface
between the parser and the rest of the system (ptrees, pf2sex). 
this is the place where the input syntax gets turned into s-expressions
and will give us a clue about how to modify the input language.

> 2.  I noticed a lot of implementation specific code having to do with
> things like (system:getenv $AXIOM) - is the plan to write some generic
> macros to handle these operations and get all of the implementation
> specific logic into one file?

yes, there are a lot of #+ and #- blocks of code laying around.
these are gradually being collected into bookvol5 and generalized.

it appears that you are trying to get axiom running in ansi (say,
sbcl).  one possible path is to use the debugsys.lisp file and try
loading it into sbcl. for each failure, modify the original pamphlet
file. eventually you'll have an set of lisp files that load. at that
point you can try running some of the input files thru the ansi image.
if they succeed you can diff the pamphlet files and post the patches.

once we have an idea of the ansi differences the next task will be
to either try to get it running in GCL again or move the system onto
sbcl.

\start
Date: Sun, 23 Jul 2006 17:29:34 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Translation of the interp to lisp

--- Tim Daly wrote:

> > 1.  Where is the most current work on that translation?  Is it in
> > the silver/gold branches?  Or one of the tla archives?  (Sorry if
> > I missed this in my archive hunt - there were a lot of emails on
> > the general subject).
> 
> the current work is on my local disk. the first fruits are in 
> bookvol5.pamphlet. i'm currently working on decoding the interface
> between the parser and the rest of the system (ptrees, pf2sex). 
> this is the place where the input syntax gets turned into
> s-expressions and will give us a clue about how to modify the input
> language.

OK, thanks.
 
> > 2.  I noticed a lot of implementation specific code having to do
> > with things like (system:getenv $AXIOM) - is the plan to write
> > some generic macros to handle these operations and get all of the
> > implementation specific logic into one file?
> 
> yes, there are a lot of #+ and #- blocks of code laying around.
> these are gradually being collected into bookvol5 and generalized.

OK.  Those blocks will be important for portability - sbcl, for
example, is quite different on the system interface than GCL (sbcl
doesn't even have a system package - the relevant logic appears in
sb-posix.)  I would suggest hiding that logic behind macros collected
into a single section/chapter/whatever, and then when someone tries to
port it to a new platform they can start be defining all the macro
logic for their own platform.  

> it appears that you are trying to get axiom running in ansi (say,
> sbcl).

Well, let's say I was experimenting to see how difficult it would be. 
It would be very nice to have the lisp logic contained in an asdf file,
and avoid the need for separate make logic for the lisp files.  I think
such a file could probably be constructed from the debugsys file, but
for a good job of it I would like to break things up into modules and
other logical units, which requires a deeper understanding than I have
achieved as yet.

> one possible path is to use the debugsys.lisp file and try
> loading it into sbcl. for each failure, modify the original pamphlet
> file. eventually you'll have an set of lisp files that load. at that
> point you can try running some of the input files thru the ansi
> image.

Yes, that looks like the quickest approach.  If I were to do this
though, it could result in a disconnect with the boot.pamphlet files -
changes I make at a lisp level might be hard to map back into the
original logic.  I guess it could be done, but it might be a slow cycle
- I'd have to change the boot file, then recompile everying to
re-generate the lisp files and see if the change was the correct one. 
If I use the int files, that is - I tried taking a run at the main src
tree and ran into the problems with bootstrapping boot.  One of the
things that will definitely need to be changed, right off the bat, is
things like the LISP and USER packages -> CL and CL-USER.

One question Tim - if I'm reading the doc correctly, the build process
actually creates three lisp images - the bootstrap image, the defsys
image, and then the final one.  Is this because the bootstrap code
can't live in the same image with the final code due to conflicts?

> if they succeed you can diff the pamphlet files and post the patches.

OK.  Should this be targeted at the boot level (when we get the basic
lisp files loaded) or the boot code?

> once we have an idea of the ansi differences the next task will be
> to either try to get it running in GCL again or move the system onto
> sbcl.

I think we will want to be able to run on GCL - it's probably the best
deployment target for Windows at the moment.  What we might do instead,
though, is shift from the Ctl2 image to the ANSI image.  I know GCL
isn't all the way to ANSI yet, but maybe our moving there will help
that process along :-).

\start
Date: Sun, 23 Jul 2006 20:56:34 -0400
From: Tim Daly
To: Emil Volcheck
Subject: SELinux vs Lisp

Emil,

I mentioned the fact that in FC3 and FC4, GNU Common Lisp does not
build properly when SELinux is enabled.

I recently started porting Axiom to FC5 and the only way to get 
GCL (and thus Axiom) to build is to completely turn off SELinux
processing. 

The problem occurs because Lisp saves images and then tries to execute
them which, if SELinux is enabled, results in a segmentation
violation. Apparently it is no longer enough to just disable
randomize_va_space. Now it seems I must do:
  
  /usr/sbin/setenforce 0

I'm not sure what the technical problem is but there is clearly a
complete misunderstanding by the SELinux people about what is
reasonable program behavior.

The problem is not confined to GCL. I see that Steel Bank Common
Lisp (SBCL) has also struggled with the same problems.

Please pass along, rather more emphatically, that SELinux should
not break fundamental computing technology like lisp systems. If
they cannot build GCL they should not promote the SELinux change.

\start
Date: Sun, 23 Jul 2006 22:01:25 -0400
From: Bill Page
To: Christian Aistleitner
Subject: RE: [Aldor-l] exports and constants

On July 21, 2006 2:38 AM Christian Aistleitner wrote:
> ...
> Ralf wrote:
> >
> > X: CatX == if true then (A add) else (B add); -- (*)
> > ...
> > That is clear, but why does the compiler reject the program 
> > without the "add" in line (*)?
> 
> I'd consider that a bug in comparison of exports. Replacing 
> your (*) line by
> 
>    X: CatX == if true then (A@CatX) else (B@CatX);
> 
> gives a working program with output
> 
>    X has CatA: T
>    X has CatB: F
>    X has CatX: T
> 

Wow! Nice. And

   X: CatX == if false then (A@CatX) else (B@CatX);
 
gives

   X has CatA: F
   X has CatB: T
   X has CatX: T

That's excellent.

> So the problem (wild guess) is that the compiler Has problems
> with seeing that the if statement gives CatX in both branches
> of the if statement. Mainly because the types of A and B aro
> not equal. However, you can hint the compiler. My code is telling
> him "The if part gives CatX and the else part gives CatX". Then
> the compiler can infer, that the whole  "if" statement gives
> CatX. And it is at least the type of X (which is CatX). So it
> matches.
>

I accept your argument and withdraw (most) of my comments about
static types in my previous message.
 
> ...
> > But what about...
> >
> > ---BEGIN aaa3.as
> > #include "aldor"
> > import from String, TextWriter, Character, MachineInteger;
> >
> > define CatA: Category == with;
> > define CatB: Category == with;
> > define CatX: Category == with;
> >
> > A: Join(CatX, CatA) == add;
> > B: Join(CatX, CatB) == add;
> >
> > MyPkg(X: CatX): with {isA?: () -> Boolean} == add {
> > 	isA?(): Boolean == X has CatA;
> > }
> > main(): () == {
> > 	import from CommandLine, Array String;
> > 	X: CatX == if zero? #arguments then (A add) else (B add);
> > 	stdout << isA?()$MyPkg(X) << zero? #arguments << newline;
> > }
> > main();
> > ---END aaa3.as
> >
> >  >aldor -fx -laldor aaa3.as
> >  >aaa3
> > FT
> >  >aaa3 1
> > FF
> >
> > It is clear with the "add" in the definition of X that we 
> > will always see a F in the first column of the output. Can
> > someone find a "nice" construction where X is defined by a
> > similar "if" construction and the first F would turn into T?
> 
> Of course. Again, be nice to the compiler. He is old. He is 
> buggy. He is a bit rusty on the edges. And he is locked in,
> in a jail of non-free source code.

Hear, hear! Please, let's find a way to free him! :-)

> But help him. Do not force him to do extra work. Tell 
> him what you know, if he needs to be told.
> 
> X: CatX == if zero? #arguments then (A@CatX) else (B@CatX);
> 
> does the trick for me:
> 
> LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32
> -Fx -lalgebra -laldor aaa3.as && ./aaa3 && ./aaa3 xx
> cc1: note: -fwritable-strings is deprecated; see 
> documentation for details
> cc1: note: -fwritable-strings is deprecated; see 
> documentation for details
> TT
> FF
>

That is quite fantastic to me. It means that the value of the
"constant" X is not determined at compile time. I did not expect
this to be possible. This variant also works is even better:

  main4(n:Integer): Boolean == {
	X: CatX == if zero? n then (A@CatX) else (B@CatX);
	isA?()$MyPkg(X);
  }

  main4(0)
  main4(1)

But then I must realize that X is local to main4, so in the
dynamic invocation context of main4 X is still "constant".

http://wiki.axiom-developer.org/SandBoxAldorSemantics

> ... 
> I hope we both deem my solution to be "nice" :)
>

\start
Date: Mon, 24 Jul 2006 08:32:11 +0200
From: Christian Aistleitner
To: Ralf Hemmecke
Subject: Re: [Aldor-l] exports and constants

Hello,

On Fri, 21 Jul 2006 10:37:30 +0200, Ralf Hemmecke wro=
te:

> Hello Christian,
>
> On 07/21/2006 09:47 AM, Christian Aistleitner wrote:
> [...]
>> #include "aldor"
>> import from String, TextWriter, Character;
>>
>> define CatA: Category == with { }
>> define CatB: Category == with { }
>> define SomeCat: Category == with { CatA; CatB; }
>> Dom: SomeCat == Integer add;
>>
>> B: CatA == Dom;
>>
>> stdout << "B has CatA: " << ( B has CatA ) << newline;
>> stdout << "B has CatB: " << ( B has CatB ) << newline;
>>
>> func( DomParam: CatB ):() == { stdout << "called func" << newline=
; }
>>
>>
>> C_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -=
Fx
>> -lalgebra -laldor -D IFCLAUSE test2.as && ./test2
>> cc1: note: -fwritable-strings is deprecated; see documentation for  =

>> details
>> cc1: note: -fwritable-strings is deprecated; see documentation for  =

>> details
>> B has CatA: T
>> B has CatB: T
>>
>>
>> We see B's dynamic type has bath CatA and CatB.
>> However,
>> func( B )
>> complains about B being only CatA and not also CatB.
>> func( Dom )
>> works.
>
> I don't see what you mean.

I wanted to elaborate on the possible uses for ": SomeType" in statement=
s  =

like "SomeIdent: SomeType == SomeThing". Indeed I explained that in =
the  =

part you chopped off when quoting:

>>> If Ident *is* Dom then what do you think the ": SomeType" is for?
>>May it's syntactic sugar (maybe I should drop the "syntactic").
>> You can use it to restrict the static type.

The above code shows, how to get an equivalent ( B ) for a domain ( Dom =
)  =

having a different static type ( SomeCat opposed to CatA ).
Dom has static type SomeCat and dynomic type SomeCat.
B has static type CatA and dynamic type SomeCat.

>> What about the following:
>>
>> Universe of the compiler before B: CatA == DOM:
>>
>> Dom ( StaticType: SomeCat; Implementation at memory location 123456 )=

>>
>> After the B: CatA == Dom:
>>
>> Dom ( StaticType: SomeCat; Implementation at memory location 123456 )=

>> B   ( StaticType: CatA;    Implementation at memory location 123456 )=

>
> That would be OK for me, but currently the last line probably reads
>
> B   ( StaticType: SomeCat; Implementation at memory location 123456 )
>
> since the ": CatA" has no influence on the type of B. (That's what the=

> compiler says. I am not sure what the language defines in that case.)

Could you underpin that with code? Because from my point of view, B does=
  =

not have static type SomeCat. B has static type CatA and dynamic type  =

SomeCat. I wanted to indicate this dynamic type by "implementation at  =

memory location 123456). In the above piece of code, you cannot use B  =

where CatB is expected (func( B )). Hence, B cannot have SomeCat.

>>> ---BEGIN aaa5.as
>>> #include "aldor"
>>> define CatA: Category == with;
>>> define CatB: Category == with;
>>> define CatX: Category == with;
>>>
>>> A: Join(CatX, CatA) == add;
>>> B: Join(CatX, CatB) == add;
>>> #if ADD
>>> import from MachineInteger;
>>> X: CatX == if odd? random(10) then (A add) else (B add);
>>> #else
>>> X: CatX == if true then A else B;
>>> #endif
>>> ---END aaa5.as
>>>
>>>  >aldor -fx -laldor -DADD aaa5.as
>>>
>>> compiles without any complaints. Now try without the ADD assertion.
>>>
>>>  >aldor -fx -laldor aaa5.as
>>> "aaa5.as", line 14: X: CatX == if true then A else B;
>>>                      ...........^
>>> [L14 C12] #1 (Error) Have determined 0 possible types for the  =

>>> expression.
>>>    Subexpression `A':
>>>     Meaning 1:
>>>                  Join(CatX, CatA) with
>>>                      ==...
>>>    Subexpression `B':
>>>     Meaning 1:
>>>                  Join(CatX, CatB) with
>>>                      ==...
>>>    The context requires an expression of type CatX.
>>>
>>>
>>> Are you now a bit more puzzled?
>>>
>>> Random things are not the problem. Obviously "A" and "A add" are not=

>>> (treated) identical by the compiler.
>>
>> It's getting tricky to put my thoughts into correct words, but I gues=
s:
>> Once the value of "A" and "A add" are established, they are treated
>> equally. But these expressions give different values. "A add" gives a=
n
>> expression of type CatX. "A" gives an expression of type Join( CatX,
>> CatA ). And the compiler cannot infer properly, that Join( CatX, CatA=
 )
>> provides CatX.
>
> I think I should try a little piece of code here to claim that "A add"=

> cannot just give something of type CatX. We all know that it is a
> perfect value in Aldor and thus must have a type of its own. The only
> type I can think of for "A add" is that of "A" so it would be
> Join(CatX,CatA). But then some miracles happen if you say
>
> X: CatX == A add;
>
> That simply forgets the CatA exports.

That's no miracle to me. Consider the statement

A: B == C add D

The "add" cuts off (mostly) all things of C such that the type of the cu=
t  =

C and D meet B.
So in your example the "add" may cut off all fields of A that are not  =

needed by CatX.


> Now let's make things a bit more complicated. Would you be able to gue=
ss
> the output of the following program?
>
> ---BEGIN aaa7.as
> #include "aldor"
> #include "aldorio"
>
> define CatA: Category == with;
> define CatX: Category == with;
>
> A: Join(CatX, CatA) == add;
> X: CatX == A add;  stdout << (X has CatA) << newline;
> Y: CatX == A;      stdout << (Y has CatA) << newline;
> #if WITHZ
> Z: CatA == Y;      stdout << (Z has CatA) << newline;
> #endif
> ---END aaa7.as
>
> Right.
>
>  >aldor -grun -laldor aaa7.as
> F
> T
>
>  >aldor -DWITHZ -grun -laldor aaa7.as
> "aaa7.as", line 11: Z: CatA == Y;      stdout << (Z has CatA) << n=
ewline;
>                      ...........^
> [L11 C12] #1 (Error) There are 0 meanings for `Y' in this context.
> The possible types were:
> 	  Y: CatX, a local
>    The context requires an expression of type CatA.
>
> So the compiler now thinks that the type of Y is just CatX. OK, but th=
en
> why can the program print "T" in the previous compilation?

Because Y has static type CatX and dynamic type with{ CatA; CatX; }.
The compiler uses the static type to check if Y can be used in "Z: CatA =
==  =

Y".
The "has" checks the dynamic type.

> If that is not to be considered a bug then I don't know what to say.

No bug for me ;)

>>> Now if we assume that
>>>
>>> X: CatX == if true then A else B;
>>>
>>> yield an X of the type of the domain on the right hand side then the=

>>> compiler has to match the types of A and B (they have to be equal).

No. Their least common type has to be at least CatX. But we saw that Ald=
or  =

is not too good when working out types across conditional statements ;(

>>> Try to replace B by A in the code above and the compiler will not
>>> complain anymore.
>> Not true for me--I still get the corresponding errors:
> Sorry, I meant
> X: CatX == if true then A else A;
> (no B anymore).

Then it's obvious. The compiler can infer the proper types. In both  =

branches, the type is TypeOfA (whatever this value was).  Then inference=
  =

is easier, as the least common type is again TypeOfA.

>>> ---BEGIN aaa6.as
>>> #include "aldor"
>>> #include "aldorio"
>>> macro I == MachineInteger;
>>> define CatX: Category == with {foo: () -> I}
>>> A: CatX == add {foo(): I == 0;}
>>> B: CatX == add {foo(): I == 1;}
>>>
>>> import from MachineInteger;
>>> X: CatX == if odd? random(10) then A else B;
>>>
>>> main(): () == {
>>>     import from X;
>>>     stdout << foo() << newline;
>>> }
>>> main();
>>> ---END aaa6.as
>>>
>>> [ ... ]
>>>
>>> The interesting part of aaa6.as is that now if one writes
>>>
>>> X: CatX == if odd? random(10) then (A add) else (B add);
>>>
>>> (with the "add"), the program does not compile anymore in contrast t=
o
>>> aaa5.as above.
>>>
>>>  >aldor -fx -laldor aaa6.as
>>> "aaa6.as", line 13:         stdout << foo() << newline;
>>>                      ..................^
>>> [L13 C19] #1 (Error) There are no suitable meanings for the operator=

>>> `foo'.
>>
>> But I guess, that's a different issue, as X has the foo function and
>> allows to call it, as demonstrated by
>>
>> #include "aldor"
>> #include "aldorio"
>> macro I == MachineInteger;
>> define CatX: Category == with {foo: () -> I}
>> A: CatX == add {foo(): I == 0;}
>> B: CatX == add {foo(): I == 1;}
>> import from MachineInteger;
>> X: CatX == if odd? random(10) then (A add) else (B add);
>> main(): () == {
>>     import from X;
>>
>>     stdout << (X has with{ foo:() -> I }) << newline;
>>     stdout << ((foo$X)()) << newline;
>> }
>> main();
>>
>> LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 =
-Fx
>> -lalgebra -laldor  test2.as && ./test2 && sleep 1 && ./test2
>> cc1: note: -fwritable-strings is deprecated; see documentation for  =

>> details
>> cc1: note: -fwritable-strings is deprecated; see documentation for  =

>> details
>> T
>> 1
>> T
>> 0
>
> I am amazed. I had also tried foo()$X but the compiler still complaine=
d.

So the code I gave does not compile at your place?

\start
Date: Mon, 24 Jul 2006 09:11:54 +0200
From: Christian Aistleitner
To: Ralf Hemmecke, Martin Rubey
Subject: Re: [Aldor-l] Re:  exports and constants

Hello,

On Fri, 21 Jul 2006 13:48:47 +0200, Ralf Hemmecke wrote:

> On 07/21/2006 07:58 AM, Martin Rubey wrote:
>> Dear all,
>>
>> I made yet another experiment (on SandBox7, no ssh here), and tested
>> whether in the code below H would have SomeCat. It does not. B has,
>> though.
>
> http://wiki.axiom-developer.org/SandBox7

That link gives some Polynomials and integrate stuff. Is this really the  
correct link?

\start
Date: Mon, 24 Jul 2006 09:37:52 +0200
From: Christian Aistleitner
To: Bill Page, Ralf Hemmecke
Subject: Re: [Aldor-l] exports and constants

Hello,

On Sun, 23 Jul 2006 08:00:56 +0200, Bill Page  =

Bill Page wrote:

>> ---BEGIN aaa6.as
>> #include "aldor"
>> #include "aldorio"
>> macro I == MachineInteger;
>> define CatX: Category == with {foo: () -> I}
>> A: CatX == add {foo(): I == 0;}
>> B: CatX == add {foo(): I == 1;}
>>
>> import from MachineInteger;
>> X: CatX == if odd? random(10) then A else B;
>>
>> main(): () == {
>> 	import from X;
>> 	stdout << foo() << newline;
>> }
>> main();
>> ---END aaa6.as
>>
>> woodpecker:~>aldor -fx -laldor aaa6.as
>> woodpecker:~>aaa6
>> 0
>> woodpecker:~>aaa6
>> 0
>> woodpecker:~>aaa6
>> 0
>> woodpecker:~>aaa6
>> 0
>> woodpecker:~>aaa6
>> 0
>> woodpecker:~>aaa6
>> 1
>> woodpecker:~>aaa6
>> 1
>>
>> [...]
> [...]
>   main(): () == {
>   	import from X;
>   	stdout << foo() << newline;
>   	stdout << foo() << newline;
>   	stdout << foo() << newline;
>   	stdout << foo() << newline;
>   	stdout << foo() << newline;
>   	stdout << foo() << newline;
>   }
>   main();
>
> You will see that each time you run the program you will only
> get one *constant* result (all 0's or all 1's). But if you run
> the same program repeatedly (as you did above), then sometimes
> you get one result and sometimes the other! Within a given
> runtime of the program, the result is constant and not variable
> as you might be expecting.

I'd strongly expect it to be constant at runtime! "==" gives a const=
ant.  =

So it should be constant.
What kind of concept is a modifyable constant?
Maybe you want to refer to a macro instead of a constant?

A assume that each time you start the program, odd? random(10) is  =

evaluated exactly once.
Of course, your whole main function accounts for exactly one program sta=
rt.

> My conclusion is that Aldor must be sort of "faking" the
> compilation of the constants in the sense that they are not
> fully resolved at compile-time, yet they are indeed constant
> within any run of the program. There must be some kind of
> dynamic initialization phase at the start of the program.

I doubt that. The constant X is compiled to "if odd? random(10) then A  =

else B;" and neither A nor B. That's not faking, that's just what's in t=
he  =

.as file. However, the value of a constant is (typically) determined onl=
y  =

once, hence for the whole program execution X acts like either A or B.

\start
Date: Mon, 24 Jul 2006 11:05:18 -0400
From: Bill Page
To: Christian Aistleitner
Subject: RE: [Aldor-l] Re:  exports and constants

On July 24, 2006 3:12 AM Christian Aistleitner wrote:
> On 07/21/2006 07:58 AM, Martin Rubey wrote:
>>
>> I made yet another experiment (on SandBox7, no ssh here), 
>> and tested whether in the code below H would have SomeCat.
>> It does not. B has,though.
>>
>> http://wiki.axiom-developer.org/SandBox7
> 
> That link gives some Polynomials and integrate stuff. Is this 
> really the correct link?
> 

I moved Martin's code to

http://wiki.axiom-developer.org/SandBoxAldorSemantics

modified it a little and added some of the more recent examples.

Everyone: Please feel free to add explanatory text and more
examples there.

\start
Date: Mon, 24 Jul 2006 11:14:04 -0400
From: Bill Page
To: Christian Aistleitner
Subject: RE: [Aldor-l] exports and constants

On July 24, 2006 3:38 AM Christian Aistleitner
> On Sun, 23 Jul 2006 08:00:56 +0200, Bill Page wrote:
> ...
> >> X: CatX == if odd? random(10) then A else B;
> ...
> > ...
> >   main(): () == {
> >   	import from X;
> >   	stdout << foo() << newline;
> >   	stdout << foo() << newline;
> >   	stdout << foo() << newline;
> >   	stdout << foo() << newline;
> >   	stdout << foo() << newline;
> >   	stdout << foo() << newline;
> >   }
> >   main();
> >
> > You will see that each time you run the program you will only
> > get one *constant* result (all 0's or all 1's). But if you run
> > the same program repeatedly (as you did above), then sometimes
> > you get one result and sometimes the other! Within a given
> > runtime of the program, the result is constant and not variable
> > as you might be expecting.
> 
> I'd strongly expect it to be constant at runtime! "==" gives 
> a constant. So it should be constant. What kind of concept is a
> modifyable constant? Maybe you want to refer to a macro instead
> of a constant?

I agree with you and that was precisely my point. Perhaps I did
not explain myself clearly.

> 
> I assume that each time you start the program, odd? random(10)
> is evaluated exactly once. Of course, your whole main function
> accounts for exactly one program start.

Yes, howerver originally I believed that Aldor could resolve all
constant values at compile time. In retrospect that does not make
much sense and so it seems that (as in most other languages) the
values of constants in Aldor are initialized at run time.

> 
> > My conclusion is that Aldor must be sort of "faking" the
> > compilation of the constants in the sense that they are not
> > fully resolved at compile-time, yet they are indeed constant
> > within any run of the program. There must be some kind of
> > dynamic initialization phase at the start of the program.
> 
> I doubt that.

You doubt that?? Perhaps I should not have used the word "faking"
because in fact as you say below this is exactly what most
programming languages do.

> The constant X is compiled to "if odd? random(10) then A  
> else B;" and neither A nor B. That's not faking, that's just 
> what's in the .as file. However, the value of a constant is
> (typically) determined only once, hence for the whole program
> execution X acts like either A or B.
> 

I agree.

\start
Date: Mon, 24 Jul 2006 11:39:31 -0400
From: Tim Daly
To: Bill Page
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

you can see what Aldor is doing by asking it to print the
generated lisp code.

\start
Date: Mon, 24 Jul 2006 12:00:50 -0400
From: Bill Page
To: Tim Daly
Subject: RE: [Aldor-l] exports and constants
Cc: Christian Aistleitner

On July 24, 2006 11:40 AM Tim Daly wrote:
> 
> you can see what Aldor is doing by asking it to print the
> generated lisp code.

Of course one can try to analyze the generated code, but if the
definition of the language is adequate there should never be a
need to do this. Better, one might review the internal source
code of the compiler, but this also might only be a "last resort"
due to the complexity of that code. Much better is if the
documentation is clear, unambiguous and illustrated with proper
examples. I would claim that for the most part the Aldor Users
Guide meets this goal, but I admit that it bears reading more
than once... :)

BTW, most of these examples are run without generating any lisp
code.

\start
Date: 24 Jul 2006 18:09:28 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

Bill Page writes:

| On July 24, 2006 11:40 AM Tim Daly wrote:
| > 
| > you can see what Aldor is doing by asking it to print the
| > generated lisp code.
| 
| Of course one can try to analyze the generated code, but if the
| definition of the language is adequate there should never be a
| need to do this.

Strongly agreed.

We should be at the point where, we have the definition of the
language on one hand, what the compiler does on the other hand, and
check whether it is the language that is defined that way or whether
the compiler has a bug. 

\start
Date: Mon, 24 Jul 2006 19:15:02 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

On 07/24/2006 06:09 PM, Gabriel Dos Reis wrote:
> Bill Page writes:
> 
> | On July 24, 2006 11:40 AM Tim Daly wrote:
> | > 
> | > you can see what Aldor is doing by asking it to print the
> | > generated lisp code.
> | 
> | Of course one can try to analyze the generated code, but if the
> | definition of the language is adequate there should never be a
> | need to do this.
> 
> Strongly agreed.
> 
> We should be at the point where, we have the definition of the
> language on one hand, what the compiler does on the other hand, and
> check whether it is the language that is defined that way or whether
> the compiler has a bug. 
> 
> -- Gaby

I also strongly agree. Clear language definition + a compiler 
implementation that meets that specification.

I hope there will be more discussions about Aldor semantics in places 
where it seems not to be clear enough. I for my part have read the AUG 
several times and there are still a few things unclear to me. Maybe I 
don't remember things well, but for things like

X: CatX == Dom;
X: CatX == Dom add;

they are described at several pages in the AUG, but it would be nice to 
add a few more pages that explain "common pitfalls".

For example

---BEGIN aaa8.as
#include "aldor"
#include "aldorio"

define CatA: Category == with;
A: CatA == add;

stdout << ((A add {foo(): () == {}}) has CatA) << newline;
stdout << ((A add {foo(): () == {}}) has with{foo:()->()}) << newline;
---END aaa8.as

Is somebody able to guess the output of that program?

Well, it is as simple as this: The program does not compile.

 >aldor -grun -laldor aaa8.as
"aaa8.as", line 7: stdout << ((A add {foo(): () == {}}) has CatA) << 
newline;
                    ..............^
[L7 C15] #1 (Error) The domain is missing some exports.

I consider this a bug.

The AUG says in section 7.8 "Domains":

   The value of the expression "A add B" is a domain which exports
   those symbols exported by "A" and those exports defined in "B".

So the type of "A add {foo(): () == {}}" would be

CatA with {foo: () -> ()}

Now, replace the output lines with

stdout << ( A      has CatA) << newline;
stdout << ((A add) has CatA) << newline;

It still does not compile. But it should. Both A and "A add" are domains 
of type CatA.

What I wanted to demonstrate is that "A add {...}" has a type and is a 
value of its own.

But if used in a context like "X: CatX == ... " it does matter whether 
there is an "add" *explicitly* appearing on the right hand side. That is 
not just an ordinary assignment of constants, i.e.

constName: SomeType == somevalue;

I can live with that, and it is probably a good thing, but I think to 
figure out the difference of

X: CatX == Dom;
and
X: CatX == Dom add;

is not something obvious. Be honest, who has read the AUG and could have 
   explained the difference? There is certainly need for more documentation.

But that brings me to another question. In order to figure out what the 
Aldor language actually is, there is only the AUG to consult. If that is 
imprecise, who is going to have the last word if it comes to implement 
the details in the compiler? We certainly do not want different versions 
of the Aldor language.

\start
Date: Mon, 24 Jul 2006 13:25:01 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

> But that brings me to another question. In order to figure out what the 
> Aldor language actually is, there is only the AUG to consult. If that is 
> imprecise, who is going to have the last word if it comes to implement 
> the details in the compiler? We certainly do not want different versions 
> of the Aldor language.

Ask Stephen Watt (Stephen Watt)

\start
Date: Mon, 24 Jul 2006 14:12:23 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [Aldor-l] exports and constants
Cc: Christian Aistleitner

On July 24, 2006 1:15 PM Ralf Hemmecke wrote:
> ...
> What I wanted to demonstrate is that "A add {...}" has a type
> and is a value of its own.

Hmmm... in Aldor values do not have types. "A add {...}" is
an "add expression".

>
> But if used in a context like "X: CatX == ... " it does
> matter whether there is an "add" *explicitly* appearing on
> the right hand side. That is not just an ordinary assignment
> of constants, i.e.
>
> constName: SomeType == somevalue;
>
> I can live with that, and it is probably a good thing, but
> I think to figure out the difference of
>
> X: CatX == Dom;
> and
> X: CatX == Dom add;
>
> is not something obvious. Be honest, who has read the AUG and
> could have explained the difference?

The concept of inheritance in Aldor is obviously very important.
In an add-expression the domain appearing to the left of 'add'
is called the parent domain. This is described in the users
guide.

> There is certainly need for more documentation.

I do agree with that!

I was wondering: If we put the current Aldor Users guide up on the
Axiom Wiki, would there be any people willing to review, extend
and update it? After all, that kind of collaboration is what wikis
are supposed to especially good for, right?

>
> But that brings me to another question. In order to figure
> out what the Aldor language actually is, there is only the AUG
> to consult. If that is imprecise, who is going to have the last
> word if it comes to implement the details in the compiler? We
> certainly do not want different versions of the Aldor language.
>

>From this site:

http://hopl.murdoch.edu.au/showlanguage.prx?exp=1777

I found a reference to the following document:

S.M. Watt, A# Language Reference, V 0.35, IBM Research Report 19530,
1994

It is also referenced here [24] in:

A First Report on the A# Compiler

http://www.csd.uwo.ca/~watt/pub/reprints/1994-ibmtr-asharp.pdf
http://portal.acm.org/ft_gateway.cfm?id=190356&type=pdf&coll=portal=
&dl=ACM&C
FID=15151515&CFTOKEN=6184618

Unfortunately I have not been able to find a copy of this anywhere
on the web.

If someone has an electronic version or a copy of this in their
paper files would you be prepared to scan it and upload it for us?

\start
Date: Mon, 24 Jul 2006 22:35:31 +0200
From: Antoine Hersen
To: Tim Daly
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

------=_Part_18768_6649610.1153773331082

On Aldor type system discussion :

No all parameter of a type are equivalent( see program at the end) :

MyVecCat( 10) == MyVecCat( 20)
but
MyListCat( Int ) != MyListCat( String)

Even if the argument is not use in the category definition.

Also "type as value" is something unusual for me, try this :

---------------------------------
#include "aldor"
#include "aldorio"

import from  Boolean , MachineInteger;

define MyListCat( t:PrimitiveType ): Category
== with {
    size: () -> Integer; }

MyList(t: PrimitiveType): MyListCat( t )
== add { size(): Integer == 1 }

Mytype:PrimitiveType == String ;
Mytype2: PrimitiveType ==  Integer ;

MyRandomType: PrimitiveType ==
if odd? random(2) then Mytype else Mytype2 ;

stdout << (MyList( MyRandomType)   has MyListCat( String)) << newline ;
-----------------------

So type are static but not determined at compile time.

It is why you are allow to use only '==' and no ':=' but if you use
destructive function on one of your type argument you have found a sure way
to crash any program.

Also I do not know much about dependent type, but I think it is a run time
feature only contrary to polymorphic type.

So how much optimization can we hope to do ? For example can I do unboxing
for my polynomial if I am not sure that they will be over machine integer at
compile time ? Do we have to use dynamic language trick ?

Also about the user guide. It is what the title say a user guide not a
language reference manual.
I am personally quite confuse with the Type description.

I think it is important to have a more formal Aldor semantic.

The type system is quite unique and has some resemblance to modern typed
language, for example aldor "Category", from far, look like Haskell "class
type".
But from my limited knowledge, type as first class value and dependent type
his quite unique.

There is a paper about the aldor type system on aldor.com I have not taken
the time to read it completely but it could be a start even if it only
represent a subset of Aldor.

Chapter 18: Recomendation is very interesting.

I will support the adition of algebraic datatype and I think any addition or
modification that make Aldor closer to the popular modern functionall
languages will be welcome.

Also some question that come in my mind :

Do we need a "type system" for the type definition( think Haskell "kind") ?

What about "pretend" is it really needed ? and the special place of Rep, rep
and per ?

Is it possible to implement type inferrence ?

Are any modification needed to make it even more suited for programming
computer algebra ?

This only my personal, not very well informed, impression but the Aldor type
system seem to have been created out of practical need, I will say trying to
formalize a bit the SPAD one but still lack solid theorethical fundation.
( My bias as an ML enthousiast is that sound theoretical fundation is a must
have )

I know there is a lot of hope that the Aldor compiler will become open
source.
But a very large piece of un documented C code will not be very ususefull if
nobody with a good knowledge of it is willing and able to spend a lot of
time on cleaning( I think it does not compile under recent version of gcc),
writing documentation and debugging( optimization above O1 does not seem to
preserve semantic).

Maybe we should "audit" aldor source code and decide if we should write a
new implementation ?

Something not to forget is the tools around a language, we need a good
debugger, profiler and co.

For example Ralf Allprose and Christiant Unit testing should be part of the
upcoming open Aldor realase and their usage covered in the user
documentation to be sure every one use them as much a possible.

Regards
Antoine Hersen

-- No all type are equal
#include "aldor"
#include "aldorio"

import from  Boolean , Integer;

define MyVecCat( i:Integer ): Category
== with {
    size: () -> Integer; }

MyVector(i:Integer): MyVecCat( i )
== add {
    size(): Integer == i
}

stdout << (MyVector( 1)  has MyVecCat( 1)) << newline ;
stdout << (MyVector( 1)  has MyVecCat( 2)) << newline ;

define MyListCat( t:PrimitiveType ): Category
== with {
    size: () -> Integer; }

MyList(t: PrimitiveType): MyListCat( t )
== add {
    size(): Integer == 1
}

stdout << (MyList( String)   has MyListCat( String)) << newline ;
stdout << (MyList( Integer)  has MyListCat( String)) << newline ;

\start
Date: Mon, 24 Jul 2006 22:48:28 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

>   Has expressions
> 
>   A ``has'' expression has the following form:
> 
>       dom has cat
> 
>   where dom is a domain-valued expression, and cat is a category-valued
>   expression. A ``has'' expression may be used in any part of a program,
>   but is most often used to conditionalize domains and categories. The
>   result of the expression is a Boolean value which will be true if dom
>   can be shown to **satisfy** the category, and false otherwise.
>   ...
>   The evaluation of this expression is made at run-time, ...
> 
> ** my emphasis. Type satisfaction is defined in section 7.7: 
> 
>   "We say that a type S satisfies the type T if any value of type S can
>   be used in any context which requires a value of type T."

The compiler seems to have problems with that specification. I had a 
discussion about this with Antoine Hersen today.

---BEGIN aaa9.as
#include "aldor"
#include "aldorio"
define CatA(s: String): Category == with;
A(s: String): CatA(s) == add;
stdout << (A("x") has CatA("x")) << newline;
stdout << (A("y") has CatA("x")) << newline;
---END aaa9.as

 >aldor -grun -laldor aaa9.as
T
T

Now let's replace
String <-- PrimitiveType
"x"    <-- String
"y"    <-- Integer

---BEGIN aaa10.as
#include "aldor"
#include "aldorio"
define CatA(s: PrimitiveType): Category == with;
A(s: PrimitiveType): CatA(s) == add;
stdout << (A(String)  has CatA(String)) << newline;
stdout << (A(Integer) has CatA(String)) << newline;
---END aaa10.as

 >aldor -grun -laldor aaa10.as
T
F

I hope that someone agrees with me that this is a bit confusing.

We had a similar thing when we discussed about "Dom has Monoid(*, 1)".

\start
Date: Mon, 24 Jul 2006 16:59:01 -0400
From: Bill Page
To: Ralf Hemmecke, Antoine Hersen
Subject: RE: [Aldor-l] exports and constants
Cc: Christian Aistleitner

On July 24, 2006 4:36 PM Antoine Hersen wrote:

> On Aldor type system discussion :
>
> Not all parameter of a type are equivalent (see program at
> the end) :
>
> MyVecCat( 10) == MyVecCat( 20)
> but
> MyListCat( Int ) != MyListCat( String)
> ...

On July 24, 2006 4:48 PM Ralf Hemmecke wrote:
> ... 
> We had a similar thing when we discussed about
> "Dom has Monoid(*, 1)".
> 

Yes. In my opinion this is a serious bug in the current
implementation. This bug will affect the conversion of
significant parts of the Axiom library from SPAD to Aldor.
See for example DirectProduct.

\start
Date: 24 Jul 2006 23:25:21 +0200
From: Gabriel Dos Reis
To: Antoine Hersen
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

"Antoine Hersen" Antoine Hersen writes:

[...]

| Also I do not know much about dependent type, but I think it is a run time
| feature only contrary to polymorphic type.

http://portal.acm.org/citation.cfm?id=292560&coll=Portal&dl=GUIDE&CFI=
D=2132016&CFTOKEN=35552809

http://portal.acm.org/citation.cfm?id=289451&dl=GUIDE&coll=Portal&CFI=
D=2132016&CFTOKEN=35552809

| So how much optimization can we hope to do ? For example can I do unboxing
| for my polynomial if I am not sure that they will be over machine integer=
 at
| compile time ? Do we have to use dynamic language trick ?

for real word programs, this is still a reaserch topic.
So far, from experience, I can tell you that existing technologies are
good at exploiting invariant known at *compile-time*.  This is why
people still loves C or Haskell :-/

[...]

| The type system is quite unique and has some resemblance to modern typed
| language, for example aldor "Category", from far, look like Haskell "class
| type".

only on the surface.

| But from my limited knowledge, type as first class value and dependent ty=
pe
| his quite unique.

not really.  See above and chase references in there.

| There is a paper about the aldor type system on aldor.com I have not taken
| the time to read it completely but it could be a start even if it only
| represent a subset of Aldor.
|
| Chapter 18: Recomendation is very interesting.
|
| I will support the adition of algebraic datatype and I think any addition=
 or
| modification that make Aldor closer to the popular modern functionall
| languages will be welcome.

This is a major addition.  One that I have been thinking of the last
two months.  I just don't know how to do it properly.  And I lack
a precise language description.
Algebraic datatype and "true" pattern matching help write very
readable codes.  Pattern matching is what makes Boot so enjoyable to
read.

| Also some question that come in my mind :
|
| Do we need a "type system" for the type definition( think Haskell "kind")=
 ?

Yes, we do.

| What about "pretend" is it really needed ? and the special place of Rep, =
rep
| and per ?

For any serious program yes.  Even, Haskell has unsafe stuff.

| Is it possible to implement type inferrence ?

We need to have type inference for Aldor (or Axiom if we can wait that
long).  The explicit polymorphism =E0 la System F is just unbearable by
moment.

| Are any modification needed to make it even more suited for programming
| computer algebra ?

We need way to "reflect" objects -- I'm awaiting Tim's work on pf2sex.
That should bring us a handle on way to better support generic
programming in Axiom.

[...]

| But a very large piece of un documented C code will not be very ususefull=
 if
| nobody with a good knowledge of it is willing and able to spend a lot of
| time on cleaning( I think it does not compile under recent version of gcc=
),
| writing documentation and debugging( optimization above O1 does not seem =
to
| preserve semantic).

The same is true for any language, especially Lisp, Boot, or SPAD.

\start
Date: Mon, 24 Jul 2006 23:57:29 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

On 07/24/2006 08:12 PM, Bill Page wrote:
> On July 24, 2006 1:15 PM Ralf Hemmecke wrote:
>> ... 
>> What I wanted to demonstrate is that "A add {...}" has a type 
>> and is a value of its own.
> 
> Hmmm... in Aldor values do not have types. "A add {...}" is
> an "add expression".

OK, maybe my formulation was a bit misleading. I agree that if you look 
at the memory location where a value is stored Aldor does not store type 
information, but still the _compiler_ should know about the type of that 
value. Same for "A add {...}". Of course that is a value since I can 
assign it to a constant (or maybe even to a variable--have not tried 
this), so the compiler should know its type. There are no things in 
Aldor without type.

>> X: CatX == Dom;
>> and
>> X: CatX == Dom add;

> The concept of inheritance in Aldor is obviously very important.
> In an add-expression the domain appearing to the left of 'add'
> is called the parent domain. This is described in the users
> guide.

---BEGIN aaa12.as
#include "aldor"
#include "aldorio"

define CatA: Category == with;
define CatB: Category == with;
define CatC: Category == with;
define CatAB : Category == Join(CatA,  CatB);
define CatABC: Category == Join(CatAB, CatC);
ABC: CatABC == add;
X: CatA ==  ABC     @CatAB;
Y: CatA == (ABC add);
Z: CatA == (ABC add)@CatAB;
W: CatA == (ABC add)@CatABC;

stdout << (X has CatABC) << newline;
stdout << (Y has CatABC) << newline;
stdout << (Z has CatABC) << newline;
stdout << (W has CatABC) << newline;
---END aaa12.as

I am sure you can guess the output of the above program.
But in order to have it recorded in the mailing list, I give the output 
here.

 >aldor -grun -laldor aaa12.as
T
F
F
T

Please take some time to understand why for Y the answer is false but 
for Z it is true. Compare that to the output for X. Is the output for W 
clear?

\start
Date: Tue, 25 Jul 2006 00:38:24 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

> Omitted for brevity. Please refer to:
> 
> http://wiki.axiom-developer.org/SandBoxAldorSemantics

 > See section 5.3 of the Users Guide:
> 
>   "The general syntax for a constant definition is:
> 
>       x : T == E
> 
>   x is an identifier giving the name of the constant.
> 
>   T is an expression giving the type of the constant. The type
>   declaration is optional. If the type is declared, then the type
>   of E must satisfy it. Otherwise the type is inferred from the
>   type of the expression E."

OK. That explains the "E must at least be of type T" which I said in a 
previous post in this thread. But it still does not explain why

#include "aldor"
#include "aldorio"

define CatA: Category == with;
define CatX: Category == with;

A: Join(CatX, CatA) == add;
X: CatX == A;

MyPkg(X: CatX): with {isA?: () -> Boolean} == add {
	isA?(): Boolean == X has CatA;
}
main(): () == {	stdout << isA?()$MyPkg(X) << newline; }
main();

outputs "T". Or does it?

> On the other hand if we write
> 
>   A: CatA == Dom add
> 
> section 5.3 still applies. (So in that sense you are right.)
> 
> The difference is that now Dom is the parent domain of a new
> domain: "which specifies a domain from which any or all of the
> exports of the add can be inherited". (Ref: Section 7.8).
> 
> So 'Dom add' is a new domain which inherits from Dom, but now
> we need to take into account the rule about the "Visibility of
> inherited operations":
> 
>   "whenever an expression 'A add B' appears in a context requiring
>   a domain whose type is the category C, then any operations
>   required by C which are not defined in B are taken from the
>   domain A.
> 
> So here the expression 'Dom add' appears in a context requiring a
> domain whose type is CatA, so all operations (and by implication,
> *only* those operations) required by CatA are taken from Dom.

To my understanding, that paragraph from the AUG tells nothing about 
what happens with operations that are not exported through C. In 
particular it says nothing about the type of A that will be seen via an 
"has" expression.


>> ---BEGIN aaa6.as
>> #include "aldor"
>> #include "aldorio"
>> macro I == MachineInteger;
>> define CatX: Category == with {foo: () -> I}
>> A: CatX == add {foo(): I == 0;}
>> B: CatX == add {foo(): I == 1;}
>>
>> import from MachineInteger;
>> X: CatX == if odd? random(10) then A else B;
>>
>> main(): () == {
>> 	import from X;
>> 	stdout << foo() << newline;
>> }
>> main();
>> ---END aaa6.as
>>
>> woodpecker:~>aldor -fx -laldor aaa6.as
>> woodpecker:~>aaa6
>> 0
>> woodpecker:~>aaa6
>> 0
>> woodpecker:~>aaa6
>> 0
>> woodpecker:~>aaa6
>> 0
>> woodpecker:~>aaa6
>> 0
>> woodpecker:~>aaa6
>> 1
>> woodpecker:~>aaa6
>> 1

>> It's only the type of X that must be clear at compile time.

> I agree that it is the type of X must be clear. But something
> very strange is going on here. I do not get this result in my
> example running Aldor inside Axiom. See again:
> 
> http://wiki.axiom-developer.org/SandBoxAldorSemantics
> 
> If you write:
> 
>   main(): () == {
>   	import from X;
>   	stdout << foo() << newline;
>   	stdout << foo() << newline;
>   	stdout << foo() << newline;
>   	stdout << foo() << newline;
>   	stdout << foo() << newline;
>   	stdout << foo() << newline;
>   }
>   main();
> 
> You will see that each time you run the program you will only
> get one *constant* result (all 0's or all 1's). But if you run
> the same program repeatedly (as you did above), then sometimes
> you get one result and sometimes the other! Within a given
> runtime of the program, the result is constant and not variable
> as you might be expecting.

I was not expecting any variable behaviour. I declared X to be a 
constant and it was a constant. And, by the way, constant always mean 
"constant in a certain scope". Of course you can define a function

foo(i: Integer): () == {
   k: Integer == i;
   ...
}

So k is constant, but not necessarily constant during the runtime of a 
whole program that uses "foo". It's just constant during execution of 
"foo". So that

   for i in 1..10 repeat foo(i);

is perfectly fine.

\start
Date: Tue, 25 Jul 2006 00:50:33 +0200
From: Ralf Hemmecke
To: Christian Aistleitner
Subject: Re: [Aldor-l] exports and constants

>> Now let's make things a bit more complicated. Would you be able to guess
>> the output of the following program?
>>
>> ---BEGIN aaa7.as
>> #include "aldor"
>> #include "aldorio"
>>
>> define CatA: Category == with;
>> define CatX: Category == with;
>>
>> A: Join(CatX, CatA) == add;
>> X: CatX == A add;  stdout << (X has CatA) << newline;
>> Y: CatX == A;      stdout << (Y has CatA) << newline;
>> #if WITHZ
>> Z: CatA == Y;      stdout << (Z has CatA) << newline;
>> #endif
>> ---END aaa7.as
>>
>> Right.
>>
>>  >aldor -grun -laldor aaa7.as
>> F
>> T
>>
>>  >aldor -DWITHZ -grun -laldor aaa7.as
>> "aaa7.as", line 11: Z: CatA == Y;      stdout << (Z has CatA) << newline;
>>                      ...........^
>> [L11 C12] #1 (Error) There are 0 meanings for `Y' in this context.
>> The possible types were:
>>       Y: CatX, a local
>>    The context requires an expression of type CatA.
>>
>> So the compiler now thinks that the type of Y is just CatX. OK, but then
>> why can the program print "T" in the previous compilation?

> Because Y has static type CatX and dynamic type with{ CatA; CatX; }.
> The compiler uses the static type to check if Y can be used in "Z: CatA 
> == Y".

OK. If the static type is used for type satisfactions, I can live with that.

> The "has" checks the dynamic type.

So "has" is in fact a weak way to reflect about domains. But surely, we 
need true reflections.

\start
Date: 25 Jul 2006 01:18:38 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

Ralf Hemmecke writes:

[...]

| So "has" is in fact a weak way to reflect about domains.

Yes.


Personnally, I don't find it a very general, useful feature to
structure codes.

| But surely, we need true reflections.

\start
Date: Mon, 24 Jul 2006 20:41:03 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

On July 24, 2006 7:19 PM Gabriel Dos Reis wrote:
> 
> Ralf Hemmecke writes:
> [...]
>> | So "has" is in fact a weak way to reflect about domains.
> 
> Yes.
>

I would also answer emphatically "yes".
 
> 
> Personnally, I don't find it a very general, useful feature to
> structure codes.
> 
> | But surely, we need true reflections.
> 

The most immediate application of reflection in Aldor, it seems
to me, is an essential part of implementing an interpreter
(such as B#).

But perhaps "has" is not so weak. What other applications of
reflection are there other then conditional ones?

\start
Date: 25 Jul 2006 03:10:12 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [Aldor-l] Re:  exports and constants
Cc: Christian Aistleitner

Bill Page writes:

[...]

| But perhaps "has" is not so weak. What other applications of
| reflection are there other then conditional ones?

Support for generic programming.

  http://haskell.org/th/
  http://www.iai.uni-bonn.de/~loeh/ExploringGH.pdf


BTW, the deadline for LCSD'06 is soon.  I hope to see contributions
from the Axiom community there...

\start
Date: Mon, 24 Jul 2006 21:11:29 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [Aldor-l] exports and constants
Cc: Christian Aistleitner

Ralf,

On July 24, 2006 5:57 PM you wrote:
> On 07/24/2006 08:12 PM, Bill Page wrote:
> > ...
> > Hmmm... in Aldor values do not have types. "A add {...}" is
> > an "add expression".
>
> OK, maybe my formulation was a bit misleading. I agree that
> if you look at the memory location where a value is stored
> Aldor does not store type information, but still the _compiler_
> should know about the type of that value. Same for "A add {...}".
> Of course that is a value since I can assign it to a constant
> (or maybe even to a variable--have not tried this), so the
> compiler should know its type.

I disagree. What we are talking about is "type inference" and such
inferences can depend on context.

> There are no things in Aldor without type.

Well, it might be better to say that "type" is not an intrinsic
property of a value or even of certain expressions (such as add
expressions), but rather that the type depends on the context.

> ...
> ---BEGIN aaa12.as
> #include "aldor"
> #include "aldorio"
>
> define CatA: Category == with;
> define CatB: Category == with;
> define CatC: Category == with;
> define CatAB : Category == Join(CatA,  CatB);
> define CatABC: Category == Join(CatAB, CatC);
> ABC: CatABC == add;
> X: CatA ==  ABC     @CatAB;
> Y: CatA == (ABC add);
> Z: CatA == (ABC add)@CatAB;
> W: CatA == (ABC add)@CatABC;
>
> stdout << (X has CatABC) << newline;
> stdout << (Y has CatABC) << newline;
> stdout << (Z has CatABC) << newline;
> stdout << (W has CatABC) << newline;
> ---END aaa12.as
>
> I am sure you can guess the output of the above program.
> But in order to have it recorded in the mailing list, I give
> the output
> here.
>
>  >aldor -grun -laldor aaa12.as
> T
> F
> F
> T
>
> Please take some time to understand why for Y the answer is
> false but for Z it is true. Compare that to the output for X.
> Is the output for W clear?
>

The result for Z is false. Maybe you meant "why for Y the
answer is false but for X it is true"?

I think these results make sense if you think of @CatAB as providing
"hints" to Aldor's type inference process. This is described in some
detail here:

A First Report on the A# Compiler

http://www.csd.uwo.ca/~watt/pub/reprints/1994-ibmtr-asharp.pdf
http://portal.axiom-developer.org/refs/articles/axiom-aldor-a-sharp.pdf/v=
iew

It is false for Y because the "visibility rule" that I mentioned
earlier and which I claim is not so clear (I admit that it is not
sufficiently explicit.)

It is true for X because in spite of the hint @CatAB, the context
here is not an add expression.

And the output for W seems entirely satisfactory to me.

\start
Date: 25 Jul 2006 03:19:59 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom trunk failure

Gabriel Dos Reis writes:

[...]

| Sourceforge has a compile farm for various platforms.  We should take
| advantage of that so that the silver branch get testing, not just by
| its developers but also by other means out there.  I'm no Axiom
| administrator, so please could you request a nightly build of the
| silver branch on the various platforms they offer and have the results
| sent to say, axiom-testresults@list.sourceforge.org? -- that list would
| need to be created.  Please could you ask for that list too?
| Yes, that may involve writing a script for sending the build output
| but if they accept the requests then I volunteer to write the
| script.  Thanks!


Bill, Tim --

  Please could any one of you request the creation of the list

    axiom-testresults@list.sourceforge.org

?

(I'm pretty sure I have sent a similar request earlier but I can't
find it right now).

I've some cron jobs sending results of nightly builds of Axiom on
i686 and x86_64 systems to this list but I think they have been blocked.

\start
Date: Mon, 24 Jul 2006 21:23:10 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re:  exports and constants
Cc: Christian Aistleitner

On July 24, 2006 9:10 PM Gaby wrote:
> 
> Bill Page writes:
> [...]
> | But perhaps "has" is not so weak. What other applications of
> | reflection are there other then conditional ones?
> 
> Support for generic programming.
> 
>   http://haskell.org/th/
>   http://www.iai.uni-bonn.de/~loeh/ExploringGH.pdf
>

It is clear isn't it, that one of the primary motivations for Aldor
(at least in the context of Axiom) is to provide exactly this sort
of "generic programming"? It seems to me that this is done using
only "has" and polymorphic types.

In Andres Loh's thesis it says:

"The possibility to define functions by analysis of the structure
of datatypes is what we call generic programming in the context of
this thesis."

How would more general forms of reflection within Aldor help to
achieve this?

> ...

\start
Date: Mon, 24 Jul 2006 21:23:45 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: Axiom trunk failure

done. it will take 8-24 hours --t

\start
Date: 25 Jul 2006 03:41:02 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Bill Page writes:

| On July 24, 2006 9:10 PM Gaby wrote:
| > 
| > Bill Page writes:
| > [...]
| > | But perhaps "has" is not so weak. What other applications of
| > | reflection are there other then conditional ones?
| > 
| > Support for generic programming.
| > 
| >   http://haskell.org/th/
| >   http://www.iai.uni-bonn.de/~loeh/ExploringGH.pdf
| >
| 
| It is clear isn't it, that one of the primary motivations for Aldor
| (at least in the context of Axiom) is to provide exactly this sort
| of "generic programming"? It seems to me that this is done using
| only "has" and polymorphic types.

I have programmed a bit in Generic Haskell to assert that, no Aldor's
"has" is no substitute.  You can try to simulate, but you will not be
there. 

| In Andres Loh's thesis it says:
| 
| "The possibility to define functions by analysis of the structure
| of datatypes is what we call generic programming in the context of
| this thesis."
| 
| How would more general forms of reflection within Aldor help to
| achieve this?

Please, download Generic Haskell and do some experiment by yourself.
Look at the resulting codes in each case.



(On performance side, last month, a colleague of mine and I did some
experiments by writing a small Computer Algebra library in Haskell 98
and Generic Haskell.  Disappointingly, there is a slowdown factor
between 7 and 10 when going from Haskell to Generic Haskell.  We don't
know yet which part can be credited to the maturity of the compiler
and which part is inherent to the approach.  Anyway, it was an
interesting experience). 

\start
Date: 25 Jul 2006 03:45:29 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom trunk failure

Tim Daly writes:

| done. it will take 8-24 hours --t

\start
Date: Mon, 24 Jul 2006 23:14:03 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: [Aldor-l] Re:  exports and constants

Gaby,

On July 24, 2006 9:41 PM you wrote:
> | > Bill Page writes:
> | ... 
> | How would more general forms of reflection within Aldor help
> | to achieve this?
> 
> Please, download Generic Haskell and do some experiment by
> yourself. Look at the resulting codes in each case.
> 

I have the Coral release from 

  http://www.cs.uu.nl/research/projects/generic-haskell/compiler.html

and also the paper "Dependency-style Generic Haskell" from

  http://www.cs.uu.nl/~johanj/publications/GHTypeSystem.pdf

But I am having some difficulty getting started with any real
generic code. Can you suggest where I might find a "quick start"
tutorial at the level of, say the SortPackage example in section
11.8 of the Axiom book?

\start
Date: 25 Jul 2006 05:50:29 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [Aldor-l] Re:  exports and constants

Bill Page writes:

| Gaby,
| 
| On July 24, 2006 9:41 PM you wrote:
| > | > Bill Page writes:
| > | ... 
| > | How would more general forms of reflection within Aldor help
| > | to achieve this?
| > 
| > Please, download Generic Haskell and do some experiment by
| > yourself. Look at the resulting codes in each case.
| > 
| 
| I have the Coral release from 
| 
|   http://www.cs.uu.nl/research/projects/generic-haskell/compiler.html
| 
| and also the paper "Dependency-style Generic Haskell" from
| 
|   http://www.cs.uu.nl/~johanj/publications/GHTypeSystem.pdf
| 
| But I am having some difficulty getting started with any real
| generic code. Can you suggest where I might find a "quick start"
| tutorial at the level of, say the SortPackage example in section
| 11.8 of the Axiom book?

Hmm, that is a good question.

Hmm.

I would suggest starting to implement yourself generic 'eq', generic
'map' without looking at the library.  If you get stuck, you can have
a look there.  That should give you a quick start I guess.
If you have any further question, please don't hesitate to ask.

I'll probably send you a draft of a paper discussing our little
experience in case be interested.

Generic Haskell is well-suited for problems that depend only on the
structures of types, like serialization, parsing, generation of
combinatorial structures, etc.


I'll be thinking about your question and attempt to come up with a
mini-tutorial as you suggested.

\start
Date: Tue, 25 Jul 2006 07:01:45 +0200
From: Christian Aistleitner
To: Bill Page
Subject: Re:  exports and constants

Hello,

On Mon, 24 Jul 2006 17:05:18 +0200, Bill Page  
Bill Page wrote:

> On July 24, 2006 3:12 AM Christian Aistleitner wrote:
>> On 07/21/2006 07:58 AM, Martin Rubey wrote:
>>>
>>> http://wiki.axiom-developer.org/SandBox7
> I moved Martin's code to
>
> http://wiki.axiom-developer.org/SandBoxAldorSemantics
>
> modified it a little and added some of the more recent examples.

Thank you for the new link--it's working now.

\start
Date: Tue, 25 Jul 2006 07:04:45 +0200
From: Christian Aistleitner
To: Bill Page
Subject: Re: [Aldor-l] exports and constants

Hello,

>> > My conclusion is that Aldor must be sort of "faking" the
>> > compilation of the constants in the sense that they are not
>> > fully resolved at compile-time, yet they are indeed constant
>> > within any run of the program. There must be some kind of
>> > dynamic initialization phase at the start of the program.
>>
>> I doubt that.
>
> You doubt that?? Perhaps I should not have used the word "faking"
> because in fact as you say below this is exactly what most
> programming languages do.

Ok. The word "faking" is the problem for me. I probably read it in a  
different way than you wanted me to. But I see we agree.

\start
Date: Tue, 25 Jul 2006 07:16:26 +0200
From: Christian Aistleitner
To: Ralf Hemmecke, Gabriel Dos Reis
Subject: Re: [Aldor-l] exports and constants

Hello


> stdout << ( A      has CatA) << newline;
> stdout << ((A add) has CatA) << newline;
>
> It still does not compile. But it should. Both A and "A add" are domains
> of type CatA.

Why should (A add) be of static type CatA? (I assume you meant static type  
although has checks the dynamic type, which of course is something  
different. The Aldor compiler complains about the static type of "A add".)

If (A add) had static type with {} in this context, it would be perfectly  
fine for me. Nevertheless, it is a bug. Once a again a bug, where the add  
statement cannot determine which static type it has to satisfy. If you  
hint the compiler, it should work.

> What I wanted to demonstrate is that "A add {...}" has a type and is a
> value of its own.
>
> But if used in a context like "X: CatX == ... " it does matter whether
> there is an "add" *explicitly* appearing on the right hand side. That is
> not just an ordinary assignment of constants, i.e.
>
> constName: SomeType == somevalue;

Why not? It's just a different "somevalue".  I have not seen any code
that cannot be explained by the "add is allowed to cut off fields"
principle or the "add cannot determine the type it has to fulfill"
bug.

\start
Date: Tue, 25 Jul 2006 10:16:07 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

> But perhaps "has" is not so weak. What other applications of
> reflection are there other then conditional ones?

Yes "has" is quite weak. One has to give the type you are trying to test 
on the right hand side of "has". But if you don't know that might be 
difficult. In particular for an interpreter or debugger the "has" is not 
overly useful.

One can write out the name of a domain by using the Trace package.

#include "aldor"
#include "aldorio"

main(): () == {
     stdout << name(Integer)$Trace << newline;
     stdout << name(String)$Trace << newline;
     stdout << name(List String)$Trace << newline;
     stdout << name(List List String)$Trace << newline;

     stdout << shortName(Integer)$Trace << newline;
     stdout << shortName(String)$Trace << newline;
     stdout << shortName(List String)$Trace << newline;
     stdout << shortName(List List String)$Trace << newline;
}
main();

 >aldor -grun -laldor aaa.as
AldorInteger
String
List(String)
List(List(String))
AldorInteger
String
List(*)
List(*)

But that is all I know.

\start
Date: Tue, 25 Jul 2006 11:19:50 +0200
From: Ralf Hemmecke
To: Christian Aistleitner
Subject: Re: [Aldor-l] exports and constants

On 07/25/2006 07:16 AM, Christian Aistleitner wrote:
> Hello
> 
> 
>> stdout << ( A      has CatA) << newline;
>> stdout << ((A add) has CatA) << newline;
>>
>> It still does not compile. But it should. Both A and "A add" are domains
>> of type CatA.
> 
> Why should (A add) be of static type CatA? (I assume you meant static 
> type although has checks the dynamic type, which of course is something 
> different. The Aldor compiler complains about the static type of "A add".)

If I read Section 7,8 of the AUG

http://www.aldor.org/docs/HTML/chap7.html#8

I would say the type of "A add" is CatA (the same as for "A").

 From the AUG 7.8:
    The type of the expression A add B is

          C with { x1: T1; ...; xn: Tn }

    here C is the type of A, and x1,...,xn are the symbols defined
    (using ==) in B, whose types are T1,...,Tn, respectively.

\start
Date: Tue, 25 Jul 2006 11:28:45 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Aldor-l] exports and constants
Cc: Christian Aistleitner

>> Y: CatA == (ABC add);
>> W: CatA == (ABC add)@CatABC;

> The result for Z is false. Maybe you meant "why for Y the
> answer is false but for X it is true"?

Well that was an error on my side. My code changed while I was writing 
the email.

It should be clear by now that Y has static and dynamic type CatA while 
W has static type CatA and dynamic type CatABC. It basically says that 
the  "(...)@CatABC" hides the "add" inside the parentheses. The whole 
construction for W is not an add-expression.

\start
Date: Tue, 25 Jul 2006 10:59:05 -0400
From: Jacques Carette
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] Re:  exports and constants
Cc: Christian Aistleitner

If you want a better experience with metaprogramming, I definitely 
recommend MetaOCaml (http://www.metaocaml.org).  Unlike Template 
Haskell, it is fully typed; TH only types the result of the generation, 
not the generator itself [though SimonPJ assures me they are working on 
that too].

Gabriel Dos Reis wrote:
> (On performance side, last month, a colleague of mine and I did some
> experiments by writing a small Computer Algebra library in Haskell 98
> and Generic Haskell.  Disappointingly, there is a slowdown factor
> between 7 and 10 when going from Haskell to Generic Haskell.  We don't
> know yet which part can be credited to the maturity of the compiler
> and which part is inherent to the approach.  Anyway, it was an
> interesting experience). 
>   
Is this experiment available?  I would be quite interested in looking at 
the details.

<ShamelessPlugWarning>
Getting efficiency from meta-programs seems to be quite difficult, and 
even more so in a typeful system.  Enough has been said about C++ 
template programming to assure everyone that a) it is hard, and b) it's 
not *really* typed.  But it *is* possible to get both genericity and 
efficiency.  As a side effect, one can also get much better code 
organization as well!  See the paper
"Multi-stage programming with functors and monads: eliminating 
abstraction overhead from generic code" by Carette & Kiselyov
(paper, code, tests, etc at http://www.cas.mcmaster.ca/~carette/metamonads/)
published at GPCE05 (http://dx.doi.org/10.1007/11561347_18)
as well as  http://metaocaml.org/examples/gausselim/
which contains all the extras for an earlier paper published (later!) in
Science of Computer Programming 
(http://dx.doi.org/10.1016/j.scico.2005.10.012).

You will see, especially in the GPCE05 work, code organization which is 
explicitly influenced by Axiom/Aldor.  The principal reason that this 
work was done in MetaOCaml was that a) the type system is completely 
described (and proven to 'work') in published papers and b) the compiler 
sources are open [which was needed, not just nice-to-have].

Our basic thesis is that, given the right infrastructure, you can 
structure code like it ought to be structured (which is already what 
Axiom/Aldor strives for) and, without relying on the cleverness of 
compiler writers, get optimal efficiency.  For linear algebra, this 
works.  In separate work, it was shown that this works for FFT as well.  
We are currently extending the work to handle (numeric) solving of LODEs.
</ShamelessPlugWarning>

Jacques

PS: MetaOCaml has no introspection features at _all_, by design.  No 
'has' of anything like it.  That makes things extra-challenging, yet 
still feasible, which was not clear at all when the work was begun.

\start
Date: Tue, 25 Jul 2006 17:25:27 +0200
From: Frederic Lehobey
To: list
Subject: SAGE software

Hi,

I have recently discovered this software (not yet tried it):

  http://modular.math.washington.edu/sage/

Has any Axiom developper heard about it?  I have noticed it provides a
binding for Maxima.  Maybe is also possible with Axiom?  (I do not
have the resources to work on such a thing in the near future.)

\start
Date: 25 Jul 2006 17:34:53 +0200
From: Gabriel Dos Reis
To: Jacques Carette
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Jacques Carette writes:

| If you want a better experience with metaprogramming, I definitely
| recommend MetaOCaml (http://www.metaocaml.org).  Unlike Template
| Haskell, it is fully typed; TH only types the result of the
| generation, not the generator itself [though SimonPJ assures me they
| are working on that too].

I worked also with MetaOcaml -- mostly practically after reading your
paper on Guassian elimination, since earlier encounters were only
through papers.  Though I did Template Haskell (and I continue to do
so) before that, coming from a C++ brackground.  For some reasons, I
still prefer coding in Template Haskell -- I do appreciate MetaOcaml though.

| 
| Gabriel Dos Reis wrote:
| > (On performance side, last month, a colleague of mine and I did some
| > experiments by writing a small Computer Algebra library in Haskell 98
| > and Generic Haskell.  Disappointingly, there is a slowdown factor
| > between 7 and 10 when going from Haskell to Generic Haskell.  We don't
| > know yet which part can be credited to the maturity of the compiler
| > and which part is inherent to the approach.  Anyway, it was an
| > interesting experience).
| Is this experiment available?  I would be quite interested in looking
| at the details.

We do hope to make it publically available very soon.

[...]

| Our basic thesis is that, given the right infrastructure, you can
| structure code like it ought to be structured

yup; and I've been holding that from practical experience for over a
decade of metaprogramming in C++.

| (which is already what
| Axiom/Aldor strives for) and, without relying on the cleverness of
| compiler writers, get optimal efficiency.  For linear algebra, this
| works.  In separate work, it was shown that this works for FFT as
| well.  We are currently extending the work to handle (numeric) solving
| of LODEs.

I'm awaiting to read it -- looking very interesting!

\start
Date: Tue, 25 Jul 2006 11:48:12 -0400
From: Alfredo Portes
To: Bill Page
Subject: Doyen content

Hi Bill,

I started merging the content of axiom-developer into Doyen:
http://doyen.sytes.net

This is just a start, basically to keep the links relevant to Doyen
and Axiom. I would like to know how can I add a general stylesheet to
the wiki using Zope. Also, I would like to eliminate the subtopics.

Anybody can feel free to modify / improve the content on the Wiki.

Regards,

\start
Date: Tue, 25 Jul 2006 17:20:02 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: sbcl and Axiom

Question.  I've managed so far to get the boottocl command more or less
working (e.g. most of the boot dir code).  It occurrs to me that this
might be a waste of time, particularly if the interp directory code
contains all of the functionality in boot aside from translating boot
code to cl.  I think this is the case but before I throw out my current
work - is the boot directory in fact entirely redundant functionality
wise?

\start
Date: Tue, 25 Jul 2006 20:38:04 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: sbcl and Axiom

On Tuesday, July 25, 2006 8:20 PM C Y asked:
>
> Question.  I've managed so far to get the boottocl command
> more or less working (e.g. most of the boot dir code).

Good work!

> It occurrs to me that this might be a waste of time,
> particularly if the interp directory code contains all of
> the functionality in boot aside from translating boot code
> to cl.  I think this is the case but before I throw out my
> current work - is the boot directory in fact entirely
> redundant functionality wise?
>

Gee, what could have given you that idea??

No the boot directory is not redundant.

Yes you need to compile boot first before you can compile
anything from interp.

No the interp directory code does not contain all of the
functionality of boot (nor any of the functionality of boot
for that matter).

No what you have been doing so far is not a waste of time.
However, I think you should be using the make process as
defined in the current Axiom makefiles first before trying
to change things in a radical manner.

\start
Date: Tue, 25 Jul 2006 18:30:57 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: sbcl and Axiom

--- Bill Page wrote:

> On Tuesday, July 25, 2006 8:20 PM C Y asked:
> > 
> > Question.  I've managed so far to get the boottocl command 
> > more or less working (e.g. most of the boot dir code).
> 
> Good work!

Thanks.

> > It occurrs to me that this might be a waste of time,
> > particularly if the interp directory code contains all of
> > the functionality in boot aside from translating boot code
> > to cl.  I think this is the case but before I throw out my
> > current work - is the boot directory in fact entirely
> > redundant functionality wise?
> > 
> 
> Gee, what could have given you that idea??

The axiom_cmu.tgz archive does not contain the boot directory.  Also,
when trying to load src-pkg.lisp, there appear to be exports which are
in conflict with definitions made in the boot files - I'm not
completely sure about that but some of the errors make me wonder.

> No the boot directory is not redundant.
> 
> Yes you need to compile boot first before you can compile
> anything from interp.

There is however a second option - take the intermediate lisp files
produced in the current "normal" build, and build those directly
without first generating them from the boot files.  I was reluctant to
do that until Axiom formally makes the switch, but the boot translator
appears to do a few non-ANSI things and it will take some digging to
change that.  I can load the boot-strap lisp files in boot (after some
tweaking) but I have not as yet attempted to repeat the cycle by
loading the clisp files produced from that process.  For that cycle to
work automatically, changes at the boot->lisp level are necessary.

> No the interp directory code does not contain all of the
> functionality of boot (nor any of the functionality of boot
> for that matter).

Hmm.  OK :-).

> No what you have been doing so far is not a waste of time.
> However, I think you should be using the make process as
> defined in the current Axiom makefiles first before trying
> to change things in a radical manner.

Since I'm not familiar with make as a tool, I'm trying to keep
everything as much as possible in lisp.  Theoretically the build order
is the key point, at least once I figure out the technical reason for
using multiple images.  Also, once the changes needed to run in sbcl
are made, those pamphlet files should just plug right into the make
process.  During development though, I find asdf a bit more convenient
for lisp loading - I can easily load, for example, the boot subsystem
defined in the boot dir without the rest of the compile proceeding,
then incrementally attempt loading each file from the next step. 
(Currently I'm a bit stalled on interp/sys-pkg.lisp - VMLISP and BOOT
exports appear to be causing a bit of confusion, although it may be I
haven't sorted out what's really going on yet.)  I'm using both the
Makefiles and debugsys.lisp for file orders, so they're definitely
playing a role, and the files themselves should just plug back into
their old spots, once they're working.

\start
Date: Wed, 26 Jul 2006 03:41:47 +0200
From: Gregory Vanuxem
To: Cliff Yapp
Subject: Re: sbcl and Axiom

Le mardi 25 juillet 2006 =E0 17:20 -0700, C Y a =E9crit :
> Question.  I've managed so far to get the boottocl command more or less
> working (e.g. most of the boot dir code).  It occurrs to me that this
> might be a waste of time, particularly if the interp directory code
> contains all of the functionality in boot aside from translating boot
> code to cl.

Please, explain (and document) what are your difficulties here. I think
your work is an important thing in the history of the building procedure
of Axiom. It's relatively difficult to understand how Axiom is built.

Anyway, yes, there are a lot of "redundant functionality" in the boot
code and in the code of the interpreter. This represents an important
work to remove all of theses redondancies in the boot or in the
interpreter code (from my point of view it's a pain and I want to say
you "good luck !"). So please explain what you are doing and what
difficulties you encounter.


PS : I'm not a specialist of the interpreter but I wanted to say you
"good luck !!" if you intend to clean up this code.

Greg

> I think this is the case but before I throw out my current
> work - is the boot directory in fact entirely redundant functionality
> wise?

\start
Date: Tue, 25 Jul 2006 21:46:20 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Doyen content

On Tuesday, July 25, 2006 11:48 AM Alfredo Portes wrote:
>
> I started merging the content of axiom-developer into Doyen:
> http://doyen.sytes.net
>

Great.

The web site above does not seem to be responding right now:

  The connection has timed out
  The server at 24.44.150.177 is taking too long to respond.

But I will try again later to look at it.

> This is just a start, basically to keep the links relevant to
> Doyen and Axiom.

Yes, I think that is the right approach.

> I would like to know how can I add a general stylesheet to
> the wiki using Zope.

The stylesheet used by LatexWiki is a DTML Method file in the wiki
root folder called

  stylesheet.css

You can see the one currently used on http://wiki.axiom-developer.org
by clicking

http://wiki.axiom-developer.org/stylesheet.css

There are general details about stylesheets in ZWiki here:

http://zwiki.org/CustomizingAppearance#customizing-the-style-sheet

> Also, I would like to eliminate the subtopics.

This is controlled by specifying a property on the root
folder of the wiki called

  show_subtopics

This is described on the ZWiki site here:

http://zwiki.org/Configuring#subtopics

See also

http://zwiki.org/CustomizingAppearance#customizing-the-subtopics

Or for a more general quick reference:

http://zwiki.org/QuickReference

You might have noticed that I modified the subtopics on

http://wiki.axiom-developer.org

to appear as a left-side bar in order to provide a new way
of navigating the site. I think it works quite well but I
have not received any commments from anyone yet about these
changes.

This required modifications to the 'wikipage' page template
and the 'wikipage_macros' which is described here:

http://zwiki.org/CustomizingAppearance#customizing-skin-templates

If you want to attempt a modification like this for Doyen
please let me know and I can send you the files or tell you
how to access them on the axiom-developer website.

>
> Anybody can feel free to modify / improve the content on the
> Wiki.
>

I would like to re-iterate Alfredo's invitation to other
people to contribute to the design of the wiki content on
the DoyenCD. I think this DoyenCD is an excellent way to
introduce people to Axiom.

http://wiki.axiom-developer.org/DoyenCD

\start
Date: Wed, 26 Jul 2006 00:19:24 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: sbcl and Axiom

CY,

============================================================
BUILD ORDER

Axiom runs a tree of Makefiles, starting with the root Makefile.
Each subdirectory contains a Makefile.pamphlet. The system does
a recursive walk of the Makefile tree by subdirectory.

In a subdirectory running a Makefile that Makefile has the
responsibility to set up global conditions for all of the Makefiles
in each child subdirectory. 
  For each subdirectory
    set up global conditions (eg directories)
    notangle the Makefile.pamphlet ==> Makefile
    ( cd subdir ; make )


You can see what the build will do by recording the console
output of a system build. The exact sequence necessary to build
the system is laid out in linear form during system build. Every
make stanza outputs a line that says what it is doing. Each line
that is output has a unique number (for the subdirectory) as a
prefix to the line. So you'll see things like:

32 making /tmp/axiom49/obj/linux/graph/view2D/write2d.o from /tmp/axiom49/int/graph/view2D/write2d.c

Notice the '32' prefix which gives a clue about which make stanza it is.
This line is output from the Makefile running in the 
  src/graph/view2D
subdirectory. If you look at the src/graph/view2D/Makefile.pamphlet and
search for 'echo 32' you will see the stanza:

${MIDOBJ}/write2d.o: ${MIDINT}/write2d.c ${LINC}/write.h ${HEADERS}
	@ echo 32 making ${MIDOBJ}/write2d.o from ${MIDINT}/write2d.c
	@ ( cd ${MIDOBJ} ; ${CC} -c ${CFLAGS} ${MIDINT}/write2d.c )

This stanza says: 

  if you need to build  ${MIDOBJ}/write2d.o
  then you must first build
     ${MIDINT}/write2d.c 
     ${LINC}/write.h 
     ${HEADERS}
  once these have been built it echos the '32' line and then
  it builds ${MIDOBJ}/write2d.o 


============================================================
BUILD-TIME DIRECTORY STRUCTURE


There are 4 top-level directories 
 ${SRC} -- the source tree (human written)
 ${INT} -- the intermediate (machine independent, machine generated)
 ${OBJ} -- the object files (machine dependent, machine generated)
 ${MNT} -- the final ship tree
and within each Makefile combinations of these make local variables.

The system is set up so that it is possible to copy the SRC and INT
directory to another system and restart the build. Historically this
was important because it used to take 3 weeks to build a system from
scratch (well, not scratch but from a previous system).

The makefiles are designed so you could mount NFS disk space on
multiple systems and build them all in parallel. Axiom used to build
on PCs, Symbolics, AIX, Solaris, and VM/370 all from the same 
SRC and INT. The target system is named by the ${SYS} variable,
these days usually just linux. The target system is determined from
the $AXIOM variable so:

export AXIOM=/tmp/axiom/mnt/linux
                            ^^^^^
                             the target

and you could build others by NFS mounting the source directory and
setting the AXIOM variable such as:

export AXIOM=/tmp/axiom/mnt/solaris
export AXIOM=/tmp/axiom/mnt/freebsd
export AXIOM=/tmp/axiom/mnt/symbolics
export AXIOM=/tmp/axiom/mnt/aix
etc...


So the basic idea is that you start from the sources ${SRC},
  cache a lot of machine independent work in ${INT},
    use ${OBJ} as a machine specific temp area (.o files, etc),
      and create a machine-specific "ship" system in ${MNT}.

Once the machine-specific directory exists (${MNT}/linux, ${MNT}/aix, 
etc) you can throw away everything else, including the sources.



============================================================
BUILD-TIME INTERMEDIATE IMAGES


We need to build lisp images for specific purposes. 

Initially we need a lisp image that contains our patches.
That is machine-specific, machine-generated code so it logically
belongs in the OBJ directory (see above). And since it is system
dependent it lives under the SYS subdirectory. In this case we get
${OBJ}/${SYS} == obj/linux

If we look in obj/linux we see

lisp
bootsys
depsys
interpsys
debugsys

So the key steps that use these images amount to:

step 0: build noweb

step 1: build a lisp with our patches ==> lisp
  if we had a fully patched lisp (or did not depend on any 
  special features) we could just copy a lisp rather than build one.


step 2: build a lisp with the boot translator ==> bootsys
  extract the boot translator clisp files from the boot files into INT
  load the boot translator into the lisp image
  save it as bootsys

step 3: translate (use bootsys)
  translate the boot files into clisp files using bootsys
  after this point bootsys is useless and we abandon the image

step 4: build a lisp image with all the macros ==> depsys
  we use lisp macros which are needed at compile time but not runtime
  we load those macros into a lisp image and save it as depsys
 
step 5: compile lisp (use depsys)
  we use depsys to compile the clisp/lisp/lsp files 
    clisp is boot-generated code
    lisp is lisp-original code
    lsp is GCL generated code

step 6: build a lisp image that contains the interpreter/compiler ==> interpsys
  we load all the compile files into lisp
  we can preload some algebra code for efficiency
  and save it as interpsys (eventually copied as AXIOMsys into ${MNT}/${SYS}

step 7: autoloads (use depsys)
  we have a set of files that are used in special cases but are not needed
  we use depsys to compile these into the autoload subdirectory.  

step 8: algebra (use interpsys)
  using interpsys, compile the algebra 

step 9: we may have to do deep debugging ==> debugsys
  this is purely for my use. sometimes the only way to find a 
  bug is to run the interpreted lisp code. 

Just to add to the pain each of the source files are documents so
we have to extract the required sources at each and every step.




==============================================================
BOOT HISTORY


Boot is necessary to translate the boot files to clisp files.

It is not normally used in a running system. However, boottocl
is a command line tool that allows you to dynamically translate
a boot file to a clisp file. This is a way of making dynamic
changes to the sources (it's lisp, after all). The system used to
be built on top of an existing system. Our style of working was
to keep modifying the system while it was running. Thus the boot
code was changing while we worked. Eventually this led to a system
that could no longer be built from scratch but required a running
system to build. Boot is one example of this problem. The boot
compiler is written in boot. In order to start the process we now
cache the generated lisp files in the original documents. Hacking the
boot compiler would require re-generating and re-caching these files.

The boot code is slowly disappearing from the sources.  Once that
happens the boot subdirectory is no longer necessary and boottocl will
disappear. As you can see from the steps above boot adds complexity
we don't need.

As mentioned previously in these mailing lists Dick Jenks did work
in languages. He created a Meta language to describe the boot syntax
and then a boot language.  This is one of the early attempts to build a
paren-free version of lisp (\begin{religion} similar to python and 
many other failed attempts, past and future \end{religion})

Note that not everyone agrees that boot should die as they like 
the language. Since there is nothing axiom-specific about the boot
language it would be perfectly possible to fork off a boot language
project and let it live elsewhere. 


==============================================================
FUTURE DIRECTION

I'm rewriting and documenting the system internals into straight
common lisp. At the moment I'm working on the interpreter which
will eventually become the 5th volume of the axiom series (hence,
src/interp/bookvol5.pamphlet). This fully documented interpreter
will mirror the existing system. Once it is documented we can
modify it to suit future needs.

My ultimate aim is to make the system a literate lisp program that
only needs to be compiled and run in a single pass on any ansi
standard lisp. The lisp ASDF facility will allow us to remove the
makefiles and the autoconf/autoload machinery. Boot will disappear
as will the many lisp images, intermediate directories, etc. Lisp
will be extended with native notangle/noweave so you can just
load or compile literate files.

The next version of axiom will consist of a set of volumes that are
literate documents, fully explaining the code. The compiler will be
its own volume and can be replaced by a different compiler.  The
interpreter will be its own volume and can also be replaced (possibly
by an aldor standalone version).  The algebra will be organized (in
some fashion) as volumes that fully document that algebra. Axiom will
sit on top of an ansi common lisp literate base (or aldor standalone 
base if we go there).

The build process should involve just a drag-and-drop of the volumes
and any literate papers containing algorithms you might want to use.

\start
Date: Wed, 26 Jul 2006 01:36:10 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: sbcl and Axiom

On Tuesday, July 25, 2006 9:31 PM C Y wrote:
> ...
> The axiom_cmu.tgz archive does not contain the boot directory.

I have to admit that I had not previously looked deeply at the
axiom_cmu build but it seems to me that it is based on a different
version of boot then the one built by the standard distribution
of Axiom (i.e. Tim's). Although I do see '#+:tpd' in the util.lisp
file...

Apparently in axiom_cmu boot is compiled as part of the
/interp/Makefile. See especially the clisp "bootstrap boot files"
in the inter/lisp subdirectory. These are similar to but different
from the clisp boot bootstrap files embedded in the *.pamphlet
files in the boot directory of the standard distribution. If
you look for 'BOOTTOCL' for example you will see that it is
implemented in ptyout.boot.pamphlet in the standard distribution
but in interp/util.lisp in the axiom_cmu version.

I do believe that there was an "old" and a "new" boot compiler
so it could be that axiom_cmu is using an older version.

I suppose that only Tim Daly and/or Juergen Weiss will be able
to sort all this out for us... :(

> Also, when trying to load src-pkg.lisp, there appear to be
> exports which are in conflict with definitions made in the boot
> files - I'm not completely sure about that but some of the
> errors make me wonder.
>
> > No the boot directory is not redundant.
> >
> > Yes you need to compile boot first before you can compile
> > anything from interp.
>
> There is however a second option - take the intermediate lisp files
> produced in the current "normal" build, and build those directly
> without first generating them from the boot files.  I was reluctant
> to do that until Axiom formally makes the switch, but the boot
> translator appears to do a few non-ANSI things and it will take
> some digging to change that.

I think there are some changes in the axiom_cmu source specifically
for this. In

http://lists.nongnu.org/archive/html/axiom-developer/2005-11/msg00373.ht
ml

Juergen Weiss wrote:

> ... there is the quoted function stuff and some minor
> changes (a few macros and one or two places in the algebra
> code) for string-char, both of which I already have taken care
> of in my cmucl port 2 years ago.

So I guess you should look specifically for the ':cmu' specific
code in vmlisp.lisp (i.e. macros). A diff between int/interp/
vmlisp.lisp file from the standard distribution and this file
shows a lot of cmu specific changes (including changing :cmulisp
to :cmu). There are other changes but in some cases it is rather
hard to tell if these are applicable or regressions due to a
differences in the base version of vmlisp.lisp.

Maybe

+#+:cmu
+(defmacro define-function (f v)
+  `(eval-when (eval load compile)
+     (setf (symbol-function ,f) ,v)
+     #+(or :akcl :cmu)
+     (define-compiler-macro ,(cadr f) (&rest args)
+         `(,',(cadr v) ,@args))
+   ))

is the "quoted function stuff" referred to by Weiss?

Anyway, such is the difficulty that is cut out for you in this
task... :) I hope you can attract the help of others more
knowledgeable.

> I can load the boot-strap lisp files in boot (after some
> tweaking) but I have not as yet attempted to repeat the cycle
> by loading the clisp files produced from that process.  For
> that cycle to work automatically, changes at the boot->lisp
> level are necessary.

Could you give some examples of the "tweaking"?

>
> > No the interp directory code does not contain all of the
> > functionality of boot (nor any of the functionality of boot
> > for that matter).
>
> Hmm.  OK :-).
>
> > No what you have been doing so far is not a waste of time.
> > However, I think you should be using the make process as
> > defined in the current Axiom makefiles first before trying
> > to change things in a radical manner.
>
> Since I'm not familiar with make as a tool, I'm trying to keep
> everything as much as possible in lisp.

Good luck! make is fundamental to almost all open source (with
some lisp code and some python code as the only exceptions that
I know about). I really recommend taking a look at the gnu make
documentation.

> Theoretically the build order is the key point, at least once
> I figure out the technical reason for using multiple images.
> Also, once the changes needed to run in sbcl are made, those
> pamphlet files should just plug right into the make process.

Could you explain a little more about how you see this working?
It seems to me that more than build order is important.

> During development though, I find asdf a bit more convenient
> for lisp loading - I can easily load, for example, the boot
> subsystem defined in the boot dir without the rest of the
> compile proceeding, then incrementally attempt loading each
> file from the next step.

I suppose it is possible to integrate asdf into parts of the
current build process. You will end up using both make and
asdf.

> (Currently I'm a bit stalled on interp/sys-pkg.lisp - VMLISP
> and BOOT exports appear to be causing a bit of confusion,
> although it may be I haven't sorted out what's really going
> on yet.)

Are you trying to build interp starting with the boot image?
I think that is not the way the current build works. Even the
axiom_cmu Makefile builds two separate images (depsys and
interpsys).

> I'm using both the Makefiles and debugsys.lisp for file orders,
> so they're definitely playing a role, and the files themselves
> should just plug back into their old spots, once they're working.
>

We are here to try to help ... :)

\start
Date: Wed, 26 Jul 2006 07:53:40 +0200
From: Christian Aistleitner
To: Bill Page, Gabriel Dos Reis
Subject: Re:  exports and constants

Hello,

> But perhaps "has" is not so weak. What other applications of
> reflection are there other then conditional ones?

I do not know if you'd consider that to be reflection or not...
I'd need a generator for all the fields of a domain.
I'd need a way to determine the type of a field.
I'd need a way to generate all Domains (or functions mapping to domains)  
in the top-level scope.
I'd need a way instanciate a Domain completely at runtime.
...

Basically, just take a look at Java's reflection framework
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Field.html
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Method.html
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html
...

\start
Date: Wed, 26 Jul 2006 07:57:06 +0200
From: Christian Aistleitner
To: Ralf Hemmecke
Subject: Re: [Aldor-l] exports and constants

Hello,

On Tue, 25 Jul 2006 11:19:50 +0200, Ralf Hemmecke wrote:

> On 07/25/2006 07:16 AM, Christian Aistleitner wrote:
>
>>> stdout << ( A      has CatA) << newline;
>>> stdout << ((A add) has CatA) << newline;
>>>
>>> It still does not compile. But it should. Both A and "A add" are  
>>> domains
>>> of type CatA.
>>
>> Why should (A add) be of static type CatA? (I assume you meant static
>> type although has checks the dynamic type, which of course is something
>> different. The Aldor compiler complains about the static type of "A  
>> add".)
>
> If I read Section 7,8 of the AUG
> [...]

Sorry. I thought you meant current compiler behaviour.
If you refer to the AUG, (A add) should have CatA. You are right.

However, I hope it will never be implemented that way.

\start
Date: Wed, 26 Jul 2006 10:04:20 +0200
From: Ralf Hemmecke
To: Christian Aistleitner
Subject: Re:  exports and constants

On 07/26/2006 07:53 AM, Christian Aistleitner wrote:

>> But perhaps "has" is not so weak. What other applications of
>> reflection are there other then conditional ones?

> I do not know if you'd consider that to be reflection or not...
> I'd need a generator for all the fields of a domain.
> I'd need a way to determine the type of a field.
> I'd need a way to generate all Domains (or functions mapping to domains) 
> in the top-level scope.
> I'd need a way instanciate a Domain completely at runtime.

Christian, I think that you should have said that reflection would be 
just perfect for your AldorUnit

http://www.risc.uni-linz.ac.at/software/aldor/aldorunit

Currently one has to add a few shell scripts in order to make working 
with AldorUnit convenient. It would be just perfect if (at least for 
AldorUnit) it is possible to say

MyTestDomain: TestCaseType with {
   testMult1: () -> ();
   testMult2: () -> ();
   ...
} == add { ... }

and AldorUnit could provide a function

runTest(T: TestCaseType): () == ...

and inside "runTest" it would figure out which "test...: ()->()" 
functions the given domain T provides. Then it would call all those 
functions. Of course, here a restricted reflection would suffice and 
calling a function of type "()->()" should not be a big problem with the 
type system.

I am somehow reluctant to allow reflections in general, but for certain 
types of problems (like AldorUnit) it would be quite advantagous. OR the 
Aldor compiler would support AldorUnit and several other tools (relying 
on reflections) that people come up with in the future, then reflections 
are not so important in my eyes.

\start
Date: Wed, 26 Jul 2006 10:28:52 +0200
From: Juergen Weiss
To: Bill Page, Cliff Yapp
Subject: RE: sbcl and Axiom

The SPAD parser is actually able to translate boot to lisp. So
you do not need the bootsys image. You can build the depsys
image immediately (as Bill noted you need a few pretranslated
files from the interpreter directory). 

The quoted function stuff refers to the usage of for example
map('car, ....) in the sources (lisp and boot). I had to 
change it to map(function car, .. ) in boot and map(#'car .. ) in
lisp. Not a big deal but distributed all over the sources.
This change should be made for gcl as well.

Regards

Juergen Weiss

Juergen Weiss	  | Universitaet Mainz, Zentrum fuer Datenverarbeitung,
Juergen Weiss| 55099 Mainz, Tel: +49(6131)39-26361, FAX:
+49(6131)39-26407


> -----Original Message-----
> From: axiom-developer-bounces+weiss=uni-mainz.de@nongnu.org
>  On Behalf Of Page, Bill
> Sent: Wednesday, July 26, 2006 7:36 AM
> To: C Y
> Cc: list
> Subject: RE: sbcl and Axiom
>
> On Tuesday, July 25, 2006 9:31 PM C Y wrote:
> > ...
> > The axiom_cmu.tgz archive does not contain the boot directory.
>
> I have to admit that I had not previously looked deeply at the
> axiom_cmu build but it seems to me that it is based on a different
> version of boot then the one built by the standard distribution
> of Axiom (i.e. Tim's). Although I do see '#+:tpd' in the util.lisp
> file...
>
> Apparently in axiom_cmu boot is compiled as part of the
> /interp/Makefile. See especially the clisp "bootstrap boot files"
> in the inter/lisp subdirectory. These are similar to but different
> from the clisp boot bootstrap files embedded in the *.pamphlet
> files in the boot directory of the standard distribution. If
> you look for 'BOOTTOCL' for example you will see that it is
> implemented in ptyout.boot.pamphlet in the standard distribution
> but in interp/util.lisp in the axiom_cmu version.
>
> I do believe that there was an "old" and a "new" boot compiler
> so it could be that axiom_cmu is using an older version.
>
> I suppose that only Tim Daly and/or Juergen Weiss will be able
> to sort all this out for us... :(
>
> > Also, when trying to load src-pkg.lisp, there appear to be
> > exports which are in conflict with definitions made in the boot
> > files - I'm not completely sure about that but some of the
> > errors make me wonder.
> >
> > > No the boot directory is not redundant.
> > >
> > > Yes you need to compile boot first before you can compile
> > > anything from interp.
> >
> > There is however a second option - take the intermediate lisp files
> > produced in the current "normal" build, and build those directly
> > without first generating them from the boot files.  I was reluctant
> > to do that until Axiom formally makes the switch, but the boot
> > translator appears to do a few non-ANSI things and it will take
> > some digging to change that.
>
> I think there are some changes in the axiom_cmu source specifically
> for this. In
>
> http://lists.nongnu.org/archive/html/axiom-developer/2005-11/m
sg00373.ht
> ml
>
> Juergen Weiss wrote:
>
> > ... there is the quoted function stuff and some minor
> > changes (a few macros and one or two places in the algebra
> > code) for string-char, both of which I already have taken care
> > of in my cmucl port 2 years ago.
>
> So I guess you should look specifically for the ':cmu' specific
> code in vmlisp.lisp (i.e. macros). A diff between int/interp/
> vmlisp.lisp file from the standard distribution and this file
> shows a lot of cmu specific changes (including changing :cmulisp
> to :cmu). There are other changes but in some cases it is rather
> hard to tell if these are applicable or regressions due to a
> differences in the base version of vmlisp.lisp.
>
> Maybe
>
> +#+:cmu
> +(defmacro define-function (f v)
> +  `(eval-when (eval load compile)
> +     (setf (symbol-function ,f) ,v)
> +     #+(or :akcl :cmu)
> +     (define-compiler-macro ,(cadr f) (&rest args)
> +         `(,',(cadr v) ,@args))
> +   ))
>
> is the "quoted function stuff" referred to by Weiss?
>
> Anyway, such is the difficulty that is cut out for you in this
> task... :) I hope you can attract the help of others more
> knowledgeable.
>
> > I can load the boot-strap lisp files in boot (after some
> > tweaking) but I have not as yet attempted to repeat the cycle
> > by loading the clisp files produced from that process.  For
> > that cycle to work automatically, changes at the boot->lisp
> > level are necessary.
>
> Could you give some examples of the "tweaking"?
>
> >
> > > No the interp directory code does not contain all of the
> > > functionality of boot (nor any of the functionality of boot
> > > for that matter).
> >
> > Hmm.  OK :-).
> >
> > > No what you have been doing so far is not a waste of time.
> > > However, I think you should be using the make process as
> > > defined in the current Axiom makefiles first before trying
> > > to change things in a radical manner.
> >
> > Since I'm not familiar with make as a tool, I'm trying to keep
> > everything as much as possible in lisp.
>
> Good luck! make is fundamental to almost all open source (with
> some lisp code and some python code as the only exceptions that
> I know about). I really recommend taking a look at the gnu make
> documentation.
>
> > Theoretically the build order is the key point, at least once
> > I figure out the technical reason for using multiple images.
> > Also, once the changes needed to run in sbcl are made, those
> > pamphlet files should just plug right into the make process.
>
> Could you explain a little more about how you see this working?
> It seems to me that more than build order is important.
>
> > During development though, I find asdf a bit more convenient
> > for lisp loading - I can easily load, for example, the boot
> > subsystem defined in the boot dir without the rest of the
> > compile proceeding, then incrementally attempt loading each
> > file from the next step.
>
> I suppose it is possible to integrate asdf into parts of the
> current build process. You will end up using both make and
> asdf.
>
> > (Currently I'm a bit stalled on interp/sys-pkg.lisp - VMLISP
> > and BOOT exports appear to be causing a bit of confusion,
> > although it may be I haven't sorted out what's really going
> > on yet.)
>
> Are you trying to build interp starting with the boot image?
> I think that is not the way the current build works. Even the
> axiom_cmu Makefile builds two separate images (depsys and
> interpsys).
>
> > I'm using both the Makefiles and debugsys.lisp for file orders,
> > so they're definitely playing a role, and the files themselves
> > should just plug back into their old spots, once they're working.
> >
>
> We are here to try to help ... :)

\start
Date: Wed, 26 Jul 2006 03:48:39 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: sbcl and Axiom

--- Tim Daly wrote:

> CY,
> 
> ============================================================
> BUILD ORDER

> Notice the '32' prefix which gives a clue about which make stanza it
> is. This line is output from the Makefile running in the 
>   src/graph/view2D
> subdirectory. If you look at the src/graph/view2D/Makefile.pamphlet
> and search for 'echo 32' you will see the stanza:
> 
> ${MIDOBJ}/write2d.o: ${MIDINT}/write2d.c ${LINC}/write.h ${HEADERS}
> 	@ echo 32 making ${MIDOBJ}/write2d.o from ${MIDINT}/write2d.c
> 	@ ( cd ${MIDOBJ} ; ${CC} -c ${CFLAGS} ${MIDINT}/write2d.c )
> 
> This stanza says: 
> 
>   if you need to build  ${MIDOBJ}/write2d.o
>   then you must first build
>      ${MIDINT}/write2d.c 
>      ${LINC}/write.h 
>      ${HEADERS}
>   once these have been built it echos the '32' line and then
>   it builds ${MIDOBJ}/write2d.o 

Ah!  Thanks!  That makes sense :).


> ============================================================
> BUILD-TIME DIRECTORY STRUCTURE
> 
> 
> There are 4 top-level directories 
>  ${SRC} -- the source tree (human written)
>  ${INT} -- the intermediate (machine independent, machine generated)
>  ${OBJ} -- the object files (machine dependent, machine generated)
>  ${MNT} -- the final ship tree
> and within each Makefile combinations of these make local variables.
> 
> The system is set up so that it is possible to copy the SRC and INT
> directory to another system and restart the build. Historically this
> was important because it used to take 3 weeks to build a system from
> scratch (well, not scratch but from a previous system).

Yikes.

> The makefiles are designed so you could mount NFS disk space on
> multiple systems and build them all in parallel. Axiom used to build
> on PCs, Symbolics, AIX, Solaris, and VM/370 all from the same 
> SRC and INT. The target system is named by the ${SYS} variable,
> these days usually just linux. The target system is determined from
> the $AXIOM variable so:
> 
> export AXIOM=/tmp/axiom/mnt/linux
>                             ^^^^^
>                              the target
> 
> and you could build others by NFS mounting the source directory and
> setting the AXIOM variable such as:

Is this still a desirable feature, to be able to compile OS targets
from a single copy of the source tree?  I must confess I've never run
into such a situation - each machine I've ever installed on gets it own
copy of the source - but I suppose that is rather inefficient.  Most
lisp programs seem to compile their binary files alongside the source
files, although come to think of it Garnet also moved things around
somewhat.  I'll have to find out if asdf supports moving the output
files into another directory.

> export AXIOM=/tmp/axiom/mnt/solaris
> export AXIOM=/tmp/axiom/mnt/freebsd
> export AXIOM=/tmp/axiom/mnt/symbolics
> export AXIOM=/tmp/axiom/mnt/aix
> etc...
> 
> 
> So the basic idea is that you start from the sources ${SRC},
>   cache a lot of machine independent work in ${INT},
>     use ${OBJ} as a machine specific temp area (.o files, etc),
>       and create a machine-specific "ship" system in ${MNT}.

OK.  So fasl files (the sbcl compiled file) should be targeted to
${OBJ}.  

> Once the machine-specific directory exists (${MNT}/linux, ${MNT}/aix,
> etc) you can throw away everything else, including the sources.

Got it.

> ============================================================
> BUILD-TIME INTERMEDIATE IMAGES
>
> So the key steps that use these images amount to:
> 
> step 0: build noweb

OK.
 
> step 1: build a lisp with our patches ==> lisp
>   if we had a fully patched lisp (or did not depend on any 
>   special features) we could just copy a lisp rather than build one.

I'm hopeful that we won't need to recompile sbcl et. al., but I admit
I'm not nearly expert enough to tell for sure yet.

> step 2: build a lisp with the boot translator ==> bootsys
>   extract the boot translator clisp files from the boot files into
>   INT
>   load the boot translator into the lisp image
>   save it as bootsys

OK.  So step one is accomplished using the lisp code contained in the
bootdir boot.pamphlet files, which allows the lisp to then translate
the bootdir boot code into clisp files?  (e.g. the "bootstrap" step?)
 
> step 3: translate (use bootsys)
>   translate the boot files into clisp files using bootsys
>   after this point bootsys is useless and we abandon the image

Is there any reason not to just use the same image and delete the boot
and boottran packages?  (I suppose from the make standpoint it's six of
one, half a dozen of the other.)

> step 4: build a lisp image with all the macros ==> depsys
>   we use lisp macros which are needed at compile time but not runtime
>   we load those macros into a lisp image and save it as depsys

Is eliminating these macros from the final image done to save memory?

> step 5: compile lisp (use depsys)
>   we use depsys to compile the clisp/lisp/lsp files 
>     clisp is boot-generated code
>     lisp is lisp-original code
>     lsp is GCL generated code

Ah ha!  Thanks.  I hadn't made the connection between lsp and GCL.

> step 6: build a lisp image that contains the interpreter/compiler ==>
> interpsys
>   we load all the compile files into lisp
>   we can preload some algebra code for efficiency
>   and save it as interpsys (eventually copied as AXIOMsys into
> ${MNT}/${SYS}
> 
> step 7: autoloads (use depsys)
>   we have a set of files that are used in special cases but are not
> needed
>   we use depsys to compile these into the autoload subdirectory.  

OK.  It's starting to make sense now.  Since we don't want to hold the
whole Axiom system in memory, we dump the build image and create a
smaller, less hefty image and use the autoload system to get what is
needed.

> step 8: algebra (use interpsys)
>   using interpsys, compile the algebra 

OK.  I take it this part should be the least sensitive to
cross-platform issues, given a properly running interp?
 
> step 9: we may have to do deep debugging ==> debugsys
>   this is purely for my use. sometimes the only way to find a 
>   bug is to run the interpreted lisp code. 

OK.

> Just to add to the pain each of the source files are documents so
> we have to extract the required sources at each and every step.

Indeed.  I set up a convenience feature where I just run notangle in
advance on all pamphlet files in a directory before I start working on
it (so asdf has lisp files to work with), but that's probably not the
best idea.

> ==============================================================
> BOOT HISTORY
> 
> 
> Boot is necessary to translate the boot files to clisp files.
> 
> It is not normally used in a running system. However, boottocl
> is a command line tool that allows you to dynamically translate
> a boot file to a clisp file. This is a way of making dynamic
> changes to the sources (it's lisp, after all). The system used to
> be built on top of an existing system. Our style of working was
> to keep modifying the system while it was running. Thus the boot
> code was changing while we worked. Eventually this led to a system
> that could no longer be built from scratch but required a running
> system to build. Boot is one example of this problem. The boot
> compiler is written in boot. In order to start the process we now
> cache the generated lisp files in the original documents. Hacking the
> boot compiler would require re-generating and re-caching these files.

OK.  I thought so.

> The boot code is slowly disappearing from the sources.  Once that
> happens the boot subdirectory is no longer necessary and boottocl
> will disappear. As you can see from the steps above boot adds
> complexity we don't need.

Amen.

> FUTURE DIRECTION
>
> I'm rewriting and documenting the system internals into straight
> common lisp. At the moment I'm working on the interpreter which
> will eventually become the 5th volume of the axiom series (hence,
> src/interp/bookvol5.pamphlet). This fully documented interpreter
> will mirror the existing system. Once it is documented we can
> modify it to suit future needs.

OK.  So trying to monkey with this level of code at this stage sounds
like a Bad Idea.  I take it when the transition is complete the entire
interp system will be in bookvol5.pamphlet and the others will go away?

> My ultimate aim is to make the system a literate lisp program that
> only needs to be compiled and run in a single pass on any ansi
> standard lisp.

Ah, OK.  Having gone just far enough to begin to appreciate the
gargantuan nature of this task, I salute you.  I'm beginning to suspect
there is little we can do to help you here, but if someone wanted to
try what task(s) would be most useful to your effort that are still
doable by others?  If the first version of bootvol5 will mirror the
current system is it pretty much a strict "clean up and document the
generated Lisp" process?

> The lisp ASDF facility will allow us to remove the
> makefiles and the autoconf/autoload machinery. Boot will disappear
> as will the many lisp images, intermediate directories, etc. Lisp
> will be extended with native notangle/noweave so you can just
> load or compile literate files.

OK, cool.  

> The next version of axiom will consist of a set of volumes that are
> literate documents, fully explaining the code. The compiler will be
> its own volume and can be replaced by a different compiler.  The
> interpreter will be its own volume and can also be replaced (possibly
> by an aldor standalone version).  The algebra will be organized (in
> some fashion) as volumes that fully document that algebra. Axiom will
> sit on top of an ansi common lisp literate base (or aldor standalone 
> base if we go there).

Personally I would hate to see us move completely away from lisp
(although I guess I should wait to see how aldor looks).  IIRC, the
Aldor compiler is written in C?  (arrgh.)

> The build process should involve just a drag-and-drop of the volumes
> and any literate papers containing algorithms you might want to use.

Sounds good!  If there is anything I can do which will help you with
this Tim, please don't hesitate to ask.  

\start
Date: Wed, 26 Jul 2006 04:10:37 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: sbcl and Axiom

--- Bill Page wrote:
 
> Anyway, such is the difficulty that is cut out for you in this
> task... :) I hope you can attract the help of others more
> knowledgeable.

It sounds like Tim is on top of the situation.  
 
> > I can load the boot-strap lisp files in boot (after some
> > tweaking) but I have not as yet attempted to repeat the cycle
> > by loading the clisp files produced from that process.  For
> > that cycle to work automatically, changes at the boot->lisp
> > level are necessary.
> 
> Could you give some examples of the "tweaking"?

Sure.  Package names needed to be fixed, for example:

"LISP" -> :cl
"USER" -> :cl-user
"SYSTEM" -> for cases where it is needed in sbcl, like getenv,
:sb-posix
"COMPILER" -> no match found yet in sbcl

(in-package 'BOOTTRAN) type entries -> (in-package :BOOTTRAN)

Logic like (make-package "FOO") (in-package "FOO") <use other packages>
was replaced with a single defpackage statement.

I could dig up a couple more I think, but I think with Tim translating
and cleaning up this code having me work on it is a bit like running
Windows 3.1 to back up a Unix server.

Maybe an idea would be to have Tim post a "files to be cleaned up" list
so we could go to work on the ones he hasn't already delt or is dealing
with - at least clean up the code so it loads elsewhere, even if we
don't know what exactly it's doing.  Although given some of that
autogenerated code, I think the refactoring will be major enough that a
lot of those changes will be of minimal utilty anyway :-/.

> > Since I'm not familiar with make as a tool, I'm trying to keep
> > everything as much as possible in lisp.
> 
> Good luck! make is fundamental to almost all open source (with
> some lisp code and some python code as the only exceptions that
> I know about). I really recommend taking a look at the gnu make
> documentation.

I guess I should.
 
> > Theoretically the build order is the key point, at least once
> > I figure out the technical reason for using multiple images.
> > Also, once the changes needed to run in sbcl are made, those
> > pamphlet files should just plug right into the make process.
> 
> Could you explain a little more about how you see this working?
> It seems to me that more than build order is important.

I think Tim covered it, but basically with lisp files the trick is to
make sure for each file you load and compile any definitions it uses
from other files are already loaded.  That's most of what asdf does -
manange those inter-connections.

> > During development though, I find asdf a bit more convenient
> > for lisp loading - I can easily load, for example, the boot
> > subsystem defined in the boot dir without the rest of the
> > compile proceeding, then incrementally attempt loading each
> > file from the next step. 
> 
> I suppose it is possible to integrate asdf into parts of the
> current build process. You will end up using both make and
> asdf.

Currently, yes.

> > (Currently I'm a bit stalled on interp/sys-pkg.lisp - VMLISP
> > and BOOT exports appear to be causing a bit of confusion,
> > although it may be I haven't sorted out what's really going
> > on yet.)
> 
> Are you trying to build interp starting with the boot image?
> I think that is not the way the current build works. Even the
> axiom_cmu Makefile builds two separate images (depsys and
> interpsys).

Yes, but I don't like the necessity of that.  Tim seems to agree that
the eventual goal is a single pass with a lisp system, although how far
away we are from that being workable I couldn't say.

> > I'm using both the Makefiles and debugsys.lisp for file orders,
> > so they're definitely playing a role, and the files themselves
> > should just plug back into their old spots, once they're working.
> 
> We are here to try to help ... :)

Thanks! :-).  I'm more or less poking around where more skilled folks
are busy, but since most of the new lisp goodies around (CFFI, McCLIM,
scigraph, cl-plplot, etc. etc.) don't run on GCL I was kind of hoping I
could wedge it into sbcl.  However, after having looked at some of the
code I can safely say just getting it on sbcl won't do much.

\start
Date: Wed, 26 Jul 2006 08:34:23 -0400
From: Jeremy Siek
To: list
Subject: Library-Centric Software Design 2006, Second Call for Papers


                 LIBRARY-CENTRIC SOFTWARE DESIGN - LCSD'06

                       http://lcsd.cs.tamu.edu/2006

                Workshop, on October 22nd, 2006 at the
           OOPSLA'06 conference in Portland, Oregon,
           October 22-26, 2006

CALL FOR PAPERS

Libraries are central to all major scientific, engineering, and
business areas, yet the design, implementation, and use of libraries
are underdeveloped arts. This workshop is one of the first steps in
the process of placing all aspects of libraries on a sound technical
and scientific basis through research into fundamental issues and
documentation of best practices.

A software library is an organized collection of code with associated
tools supporting programming in general or in specific domains,
usually united by a specified set of principles and conventions. Most
libraries are aimed for use by several people and in different
environments. The areas of software library research include

       * Design and implementation of libraries
       * Program and system design based on libraries
       * Libraries supporting specific application domains, such as
         biology or banking
       * Evolution, refactoring, and maintenance of libraries
       * Empirical studies of library use
       * Performance of libraries, including benchmarking and
         library-based optimizations
       * Design of language facilities and tools in support of library
         definition and use
       * Validation, debugging, and testing of libraries
       * Extensibility, parameterization, and customization
       * Distribution of libraries
       * Specification of libraries and their semantics
       * Usability for library users and developers
       * Assessing quality of libraries
       * Documentation and teaching of libraries
       * Creating and supporting communities of library users
       * Using several libraries in combination

We invite the submission of extended abstracts on software library
research, including, but not limited to, the above list of topics.
The extended abstracts should address issues important to libraries as
a field, i.e., describe ideas or techniques that can be reused for
libraries across problem domains and/or languages; they should refrain
from merely describing a particular library, no matter how novel the
choice of domain. As an additional criterion, the extended abstracts
are reviewed against suitability for a journal publication of the
corresponding full paper.

For uniformity, authors should use the latest ACM SIGS conference
style file (option 1) at
http://www.acm.org/sigs/pubs/proceed/template.html. Submissions should
be limited to 10 pages in this style.

Accepted extended abstracts will be posted on the workshop's Web site
prior to the workshop, and collected in a proceedings published as a
Rensselaer Polytechnic Institute tech report. Authors of selected
papers will be invited to submit a full paper for a special issue of a
journal, to be announced later.

IMPORTANT DATES

Aug 11    Submission of extended abstracts
Sep 12    Notification of acceptance
Oct 10    Submission of final versions of the extended abstracts
Oct 15    Final version posted on Workshop web pages
Oct 22 or 23 Workshop

SUBMISSION PROCEDURE

For details of the electronic submission procedure, see the workshop's
Web site, http://lcsd.cs.tamu.edu/2006.

ORGANIZERS

       *  Josh Bloch, Google Inc.
       *  David Musser, Rensselaer Polytechnic Institute
       *  Jaakko Jarvi, Texas A&M University
       *  Sibylle Schupp, Chalmers University of Technology
       *  Jeremy Siek, Rice University

PROGRAM COMMITTEE

       *  Dave Abrahams, Boost Consulting
       *  Olav Beckman, Imperial College London
       *  Herv=C8 Br=88nnimann, Polytechnic University
       *  Cristina Gacek, University of Newcastle upon Tyne
       *  Douglas Gregor, Indiana University
       *  Doug Lea, State University of New York at Oswego
       *  Andrew Lumsdaine, Indiana University
       *  Erik Meijer, Microsoft Research
       *  Tim Peierls, Prior Artisans LLC
       *  Doug Schmidt, Vanderbilt University
       *  Anthony Simons, University of Sheffield
       *  Bjarne Stroustrup, Texas A&M University and AT&T Labs
       *  Todd Veldhuizen, University of Waterloo

In addition, the organizers will serve as program committee members,
with Jaakko Jarvi and Josh Bloch as program co-chairs.

Primarily, the email address lcsd06@cs.tamu.edu should be used for
questions addressed to the organizers.

KEYNOTE ADDRESS

There will be an invited talk by Sean Parent, Adobe Inc.

WORKSHOP GOALS AND ACTIVITIES

The workshop is a scientific forum for presenting original
research in the design, implementation, and evaluation of software
libraries. Other major activities include the identification of open
questions specific to library research and the discussion of a
strategic plan for establishing library research as a field. The
outcome of the workshop is a combination of research contributions and
specific next steps for improving the infrastructure for library
research.

Participants are expected to read the accepted submissions beforehand.
The technical presentations, although based on the accepted papers,
should not provide mere summaries of the papers. Instead, authors are
encouraged to use their presentation slots (20 + 10 mins) to bring up
topics for discussion.

The technical presentations are mixed with scientific and
organizational discussions. The discussions aim at furthering the
topics of the presentations, thus their agenda will be publicly
discussed among the participants and then posted on the website of the
workshop. All participants are expected to come prepared with their
tentative answers or thoughts.

The full-day workshop starts with a keynote talk for the stimulation
of discussion and concludes with a plenary discussion that decides the
specific next steps for improving the infrastructure for library
research.

FOR MORE INFORMATION AND UPDATES please visit
the workshop's Web site, http://lcsd.cs.tamu.edu/2006

\start
Date: Wed, 26 Jul 2006 09:56:26 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Ralf, Gaby,

If you generate lisp from Aldor and parse the result you will
have complete reflection information. This can be done dynamically
by an aldor domain since you can invoke the compiler and get the
result. A 'refection' domain could have functions to access all
of the information available.

\start
Date: Wed, 26 Jul 2006 16:34:33 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re:  exports and constants
Cc: Christian Aistleitner

On 07/26/2006 03:56 PM, root wrote:
> Ralf, Gaby,

> If you generate lisp from Aldor and parse the result you will have 
> complete reflection information.

Well, you are always assuming that the target language is LISP.
The aldor compiler is able to target other languages, too. So I would
prefer a solution that is independent of the target system.
A runtime library would be perfectly OK.

The Trace package in libaldor provides a very limited reflection

http://lists.nongnu.org/archive/html/axiom-developer/2006-07/msg00106.html

If an extension of this package could be provided with the aldor
compiler as a runtime support, that would be better than going the lisp way.

> This can be done dynamically by an aldor domain since you can invoke
> the compiler and get the result. A 'refection' domain could have
> functions to access all of the information available.

Assume you distribute a standalone executable. That will normally not 
have the compiler living inside it. So your solution does not work in 
that case.

I believe reflections are not too complicated once we know how the 
internal datastructures for domains are. (Yes, yes, we must look inside 
the compiler sources, or does anybody already have a description of how 
domains are represented in memory?)

It would be a bit more complicated to figure out how functions could be 
called with the appropriate type. The latter is inherently type-unsafe 
and I am certainly not proposing it, but there are cases (like 
AldorUnit) where reflection and calling () -> () functions makes sense.

To make it clear, I am only in favour of reflections in order to be able 
to write nice programming support tools.

For ordinary users I cannot see an advantage of reflections.
Does anybody else have reasonable use-cases?

\start
Date: Wed, 26 Jul 2006 10:47:46 -0400
From: Bill Page
To: list
Subject: RE: sbcl and Axiom

On Wednesday, July 26, 2006 4:29 AM Juergen Weiss wrote:
>
> The SPAD parser is actually able to translate boot to lisp.
> So you do not need the bootsys image. You can build the
> depsys image immediately (as Bill noted you need a few
> pretranslated files from the interpreter directory).

Now that I have looked more closely at the axiom_cmu build
I am amazed at how much shorter and simpler it is than the
current Axiom build process (of course there are still a
few steps missing).

As Juergen implies, building depsys from bootstrap Clisp
files is really no different than the way that Boot itself
is bootstrapped. Since SPAD can process boot files it seems
bootsys is completely unnecessary. This makes it even more
clear that spending time working to eliminate code written
in boot is a gross waste of time unless we were also planning
to eliminate the SPAD compiler itself and this certainly
wont happen until/unless we have an open source version
of Aldor.

Just like the algebra code written in SPAD and Aldor, boot
code is translated to Lisp. Reverting that code back to
Lisp is a retrogressive step that does not make any sense.

In the quest to simplify the build process and make it more
easily understandable and therefore maintainable, it does
make sense I think to eliminate the first two steps in the
process that Tim Daly outlined in a previous email. Already
the Debian build eliminates the first step. Using the method
implemented by Juergen Weiss for axiom_cmu it is also possible
to also eliminate the 2nd step.

>
> The quoted function stuff refers to the usage of for example
> map('car, ....) in the sources (lisp and boot). I had to 
> change it to map(function car, .. ) in boot and map(#'car .. )
> in lisp. Not a big deal but distributed all over the sources.
> This change should be made for gcl as well.
>

Time spent converting the existing Lisp code and the generated
Lisp code to conform to the common lisp standard is obviously
time well spent, as are efforts to port Axiom to other lisp
platforms besides GCL. But seems really unfortunate to me that
we are still in the situation where we have only one active
Axiom developer working in Lisp (Tim Daly).

Although I do believe that Lisp is a beautiful programming
language, from an objective point of view it seems clear to me
that it is Lisp itself that is the problem. In spite of having
advertised repeatedly over the last two years in the Lisp
community for help with Axiom, no one knowledgeable and
experienced in Lisp programmers have stepped forward. On the
other hand we have had numerous and ongoing discussions about
Aldor, SPAD, and other high level languages like Haskell and
ML. It might be a sad thing but these days Lisp is just not
sexy enough. And it does not attract a significant portion
of the available open source programming resources. It seems
there is nothing that we can do in promoting Axiom as open
source that is likely to change this.

Languages like Boot, SPAD, and Aldor on the other hand are all
precursors to languages that are currently undergoing rapid
development, e.g. Python, Ruby, Haskell, Ocaml and several
others. They seem to have significant appeal to a majority
of open source developers and are being rapidly adopted for
many large and significant projects. In my opinion we should
be actively promoting this aspect of the Axiom project and
*not* attempting to eliminate it. As far as I can see, this is
the only way that we have any chance of increasing the number
of active Axiom developers.

I know Tim has proposed Axiom as a long term project with a
(rolling?) 30 year horizon, but I have worked fairly aggressively
on the Axiom project now for nearly 3 years and I am frankly
quite disappointed at how little progress we have made. :(
Even new and innovative projects like Sage:

http://modular.math.washington.edu/sage/

  (Thanks for the reference Fr=E9d=E9ric Lehobey.)

have choosen to implement an interface to Maxima first before
seriously considering Axiom. And the situation is similar with
TeXmacs - the other major open source project that integrates
a large number of open source computer algebra tools. The Maxima
interface for TeXmacs is greatly superior to the current Axiom
interface.

And on the mathematics front I seems we aren't doing much better.
In spite of a lot of apparent interest, we still have not
collected nor have there been initiated more than just a few
(two or three) projects involving Axiom.

Is there nothing we can do to improve this situation?

\start
Date: 26 Jul 2006 17:30:14 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Ralf Hemmecke writes:

| On 07/26/2006 03:56 PM, root wrote:
| > Ralf, Gaby,
| 
| > If you generate lisp from Aldor and parse the result you will have 
| > complete reflection information.
| 
| Well, you are always assuming that the target language is LISP.
| The aldor compiler is able to target other languages, too. So I would
| prefer a solution that is independent of the target system.

I believe it might be easier to start with LISP, provided SEX is OK or
enhanced.  But long term should be to have something typed.

[...]

| I believe reflections are not too complicated once we know how the 
| internal datastructures for domains are.

so says you :-)

\start
Date: Wed, 26 Jul 2006 11:36:34 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re:  exports and constants
Cc: Christian Aistleitner

On Wednesday, July 26, 2006 10:35 AM Ralf Hemmecke wrote:
> ...
> I believe reflections are not too complicated once we know
> how the internal datastructures for domains are. (Yes, yes,
> we must look inside the compiler sources, or does anybody
> already have a description of how domains are represented
> in memory?)
> ...

I think the documentation that you need for this is Aldor's
abstract machine layer called FOAM. This is where implementation
details such as you describe are specified. This abstract
machine is implemented in Lisp, Scheme, and in a C runtime
system. I believe that the program code that is generated by
Aldor before being converted to real machine code is accessible
in the .asy and .ao files. If we had to parse the output of the
compiler in order to know what it was doing, then it seems to
me that this a better and fully portable place to look rather
Lisp or intermediate C code.

To fully implement reflects in Aldor it might be necessary to
provide some new operations at the FOAM level and in particular
in the RunTime support library (which is written in Adlor).

Here is a useful introduction:

http://www.orcca.on.ca/~ldragan/aldor/fp/fp.html

Apparently there is a detailed reference

[6]: Stephen M. Watt and Peter A. Broadbery and Pietro Iglio
and Scott C. Morrison and Jonathan M. Steinbach,
FOAM: First Oder Abstract Machine

which is referenced here

www.csd.uwo.ca/~watt/pub/reprints/2005-mc-towers.pdf

but I have not been able to find it online anywhere.

But even without extending the RunTime support it may be possible
to use the approach discussed in the Aldor Users Guide to make
"data self-identifying". See section 7.1:

"Aldor, on the other hand, adopts the ``Types on Variables''
approach, and values are not normally self-identifying....
For example, self-identifying data may obtained by incorporating
types in the values."

By this I presume is meant something like this:

-----------
MyDom: with
  describe:Generator Category
  add2:(MyDom,MyDom) -> MyDom
  sub2:(MyDom,MyDom) -> MyDom
  neg: MyDom -> MyDom
 == add
  import from Integer
  Rep == Integer

  describe:Generator Category == generate
    yield with {add2:(MyDom,MyDom)->MyDom}
    yield with {sub2:(MyDom,MyDom)->MyDom}
    yield with {neg:MyDom->MyDom}

  add2(x:%,y:%):% == per(rep(x) + rep(y))
  sub2(x:%,y:%):% == per(rep(x) - rep(y))
  neg(x:%):% == per(-rep(x))

----------

Unfortunately this code causes a compile error in the current
version of the Aldor compiler.

It also raises the question of how reflected information
should be represented in Aldor. Perhaps a List would be
better than a generator? Unfortunately although the above
code using List does compile, it does not seem to work as
expected at runtime. See

http://wiki.axiom-developer.org/SandBoxAldorSemantics#msg20060726062837-
0500@wiki.axiom-developer.org

But in principle this would allow one to write something like

  for s in describe$MyDom repeat
    if MyDom2 has s then
      ...
      etc.

and maybe (with some extension to the syntax) even to instantiate
new domains from categories defined like this:

  with { s for s in describe$MyDom where MyDom2 has s }

\start
Date: Wed, 26 Jul 2006 08:54:07 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: sbcl and Axiom

--- Bill Page wrote:

> As Juergen implies, building depsys from bootstrap Clisp
> files is really no different than the way that Boot itself
> is bootstrapped. Since SPAD can process boot files it seems
> bootsys is completely unnecessary. This makes it even more
> clear that spending time working to eliminate code written
> in boot is a gross waste of time unless we were also planning
> to eliminate the SPAD compiler itself and this certainly
> wont happen until/unless we have an open source version
> of Aldor.

Of course, until the interp files become lisp in the standard tree we
will still need the bootdir.

Now that I understand what's going on with the bootsys -> depsys image
process, sys-pkg.lisp presents much less of a problem.  It seems I just
spent two days getting bootstrapping the boot code (sort of) working
under sbcl, when the axiom_cmu approach indicated that this wasn't
necessary except in the case where no clisp files are available for the
interp dir (the situation Tim was originally faced with, but not a
current limitation).  Oh well.  I'll probably keep poking at this just
for the fun/learning experience - I'm curious how much further I can go
without major changes to the source code :-).

> Just like the algebra code written in SPAD and Aldor, boot
> code is translated to Lisp. Reverting that code back to
> Lisp is a retrogressive step that does not make any sense.
> 
> In the quest to simplify the build process and make it more
> easily understandable and therefore maintainable, it does
> make sense I think to eliminate the first two steps in the
> process that Tim Daly outlined in a previous email. Already
> the Debian build eliminates the first step. Using the method
> implemented by Juergen Weiss for axiom_cmu it is also possible
> to also eliminate the 2nd step.

In essence, at least enough of the interp code has to be in lisp to get
a functional compiler for boot/SPAD/etc. The "bootstrapping" code is
basically in interp in that case.

> Time spent converting the existing Lisp code and the generated
> Lisp code to conform to the common lisp standard is obviously
> time well spent, as are efforts to port Axiom to other lisp
> platforms besides GCL. But seems really unfortunate to me that
> we are still in the situation where we have only one active
> Axiom developer working in Lisp (Tim Daly).

Agreed.  But moving the generated Lisp code to ANSI is only of use if
one never plans to generate the code again.  It seems this is indeed
the plan for the boot level code.  However, the SPAD compiler will have
to be adjusted to output ANSI lisp, unless we get a Free aldor first. 
If there is overlap between the SPAD abilities and the BOOT abilities,
perhaps a "tweaked-to-ANSI" boot compiler would be of some user after
all for patching the SPAD code.

> Although I do believe that Lisp is a beautiful programming
> language, from an objective point of view it seems clear to me
> that it is Lisp itself that is the problem. In spite of having
> advertised repeatedly over the last two years in the Lisp
> community for help with Axiom, no one knowledgeable and
> experienced in Lisp programmers have stepped forward.

I can tell you that most of the open source lisp coders out there are
not likely to want to go wading through the old lisp code in Axiom -
they won't have the background to understand it properly, and cleaning
up old code to ANSI isn't the most thrilling programming.

> On the other hand we have had numerous and ongoing discussions about
> Aldor, SPAD, and other high level languages like Haskell and
> ML. It might be a sad thing but these days Lisp is just not
> sexy enough. And it does not attract a significant portion
> of the available open source programming resources. It seems
> there is nothing that we can do in promoting Axiom as open
> source that is likely to change this.

I think making Axiom behavior more like a "normal" lisp program - ANSI,
asdf, etc - will go a ways to changing that.

> Languages like Boot, SPAD, and Aldor on the other hand are all
> precursors to languages that are currently undergoing rapid
> development, e.g. Python, Ruby, Haskell, Ocaml and several
> others. They seem to have significant appeal to a majority
> of open source developers and are being rapidly adopted for
> many large and significant projects. In my opinion we should
> be actively promoting this aspect of the Axiom project and
> *not* attempting to eliminate it. As far as I can see, this is
> the only way that we have any chance of increasing the number
> of active Axiom developers.

The interp type of programming isn't going to appeal to many people no
matter what language it's written in, IMHO.  There's nothing really
"new" there, just framework building.  It's a bit like programming a
word processor - very useful, but not very exciting to a lot of
programmers (particularly of the more academic sort - you don't often
publish papers about revitalizing old interperter code).  It's utility
is what it makes possible, and there is a certain satisfaction in a
well designed framework, but I doubt those will be big draws.  

I am hoping the interperter will be one of those sections of the code
that will eventually be "finished."  Maybe not the compiler part, but
the more mundane parts at least.

> I know Tim has proposed Axiom as a long term project with a
> (rolling?) 30 year horizon, but I have worked fairly aggressively
> on the Axiom project now for nearly 3 years and I am frankly
> quite disappointed at how little progress we have made. :(

I think it's equal parts non-Standard Lisp, non-Free Aldor, and Really
Tough Subjects ;-).  People won't commit to Aldor until it is free
software, and the lisp guys aren't likely to enjoy weeks of fixing old
code and trying to figure out what it is doing.

> Even new and innovative projects like Sage:
> 
> http://modular.math.washington.edu/sage/
> 
>   (Thanks for the reference Frdric Lehobey.)
> 
> have choosen to implement an interface to Maxima first before
> seriously considering Axiom.

Maxima has a couple years head start on Axiom in the mindshare
department, and its name is more widely known.  Maxima had the
advantage of stepping into a virtual vacuum in terms of heavy-duty
open-source CAS - there were a few, but none very strong in the
symbolic side.  Maxima has also gone through a lot of trouble to make
itself easier to interface with - check the archives for some of the
history on that, particularly the prompts work.  Then too, Maxima
compiles and builds on ANSI lisp platforms.

More fundamentally, I think Maxima appeals to the Mathematica types by
not worrying about strong typing et. al., but just going for the
answer.  It's "easier" in some sense to deal with.  I know for myself
my first impression of Axiom was rather overwhelming.  I think now that
Axiom has more long term potential and its ideas are more likely to
scale, which makes it worth the effort, but folks not looking for such
broad ambitions and potential will be able to get started with Maxima
more quickly.

> And the situation is similar with
> TeXmacs - the other major open source project that integrates
> a large number of open source computer algebra tools. The Maxima
> interface for TeXmacs is greatly superior to the current Axiom
> interface.

IIRC there is really one one major developer for the CAS<->TeXmacs
interfaces (aside from the main developer of TeXmacs).  

I haven't tried the TeXmacs-Axiom link in a while - what are its
limitations?  I seem to remember some comments on the problems with
interfacing with Axiom sometime in the past - not sure where though.

> And on the mathematics front I seems we aren't doing much better.
> In spite of a lot of apparent interest, we still have not
> collected nor have there been initiated more than just a few
> (two or three) projects involving Axiom.

Since we are targeting our major language at the mathematics level to
be Aldor, and Aldor is not yet free, this doesn't surprise me much.

> Is there nothing we can do to improve this situation?

I think we need to await developments on the Aldor front.  A robust,
unquestionably free framework will attract more people, I think, than
the current situation.  Even if we are forced to stick with SPAD and
try to fix it, that at least is a concrete direction forward - an
answer one way or the other will be a big help.

Clear directions and tasks I think are always a help in keeping a
project like this moving - the circumstances currently prevent this
from being the case, for the most part.

\start
Date: 26 Jul 2006 17:54:31 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: sbcl and Axiom

Bill Page writes:

[...]

| Languages like Boot, SPAD, and Aldor on the other hand are all
| precursors to languages that are currently undergoing rapid
| development, e.g. Python, Ruby, Haskell, Ocaml and several
| others. They seem to have significant appeal to a majority
| of open source developers and are being rapidly adopted for
| many large and significant projects. In my opinion we should
| be actively promoting this aspect of the Axiom project and
| *not* attempting to eliminate it. As far as I can see, this is
| the only way that we have any chance of increasing the number
| of active Axiom developers.

Indeed; I would prefer to promote the "pattern" aspect of boot --
though it really is rustic -- that to demonize Boot.  I don't clearly
like its layout rule.  Clearly.  Boot with real type system will start
looking like Haskell :-)

\start
Date: Wed, 26 Jul 2006 12:05:37 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: sbcl and Axiom

There are many volumes planned for axiom so there are many places to play.

One key subgoal that is completely independent is to figure out how to
draw a line on the screen using SBCL or CLISP and the new lisp-based GUI
work. planet.lisp.org has had several discussions about this. A lisp-based
GUI for graphics would be much more portable.

As I look around the local swamp I have several projects "in process".
Each one is running in a locally modified version of Axiom and is not
ready for merging into the main branch.

I have a project to redo HyperDoc using javascript and XMLHttpRequest.
This uses a browser as the front end for the hyperdoc pages and uses
an axiom back end to service requests for actions. Eventually this will
go into the Doyen Wiki. I've rewritten a couple dozen pages so far and
am working test examples.

I have a project to document the integration routines in axiom. I have
several sources of text (Trager's thesis, Bronstein's thesis, etc) as
well as 4800 integrals that came from the Maple test suite (reported
on elsewhere in this mailing list). I've modified axiom to tell me
where each integral resolves and am classifying the various integrals
into sets of examples. That way each of the 40ish 'integrate' routines
will have example input associated with it.

I have a project to port axiom to the MAC. The key issue is getting GCL
to build on the MAC. Since MACs are based on BSD the include file chain
is completely different from linux and so things resolve poorly. Plus
I find the MAC impossible to use (my ability to use a system is 
inversely proportional to its "ease of use").

I have a project to document the interpreter and reduce it to a book
(volume 5). Currently I'm reverse engineering and documenting the
ptree and pf2sex structures and functions. This is the primary 
seam between the parser and the axiom internals.

I have a project to write a literate program for drag-and-drop.
This involves figuring out how to handle drag-and-drop in a browser
(there is a drag-and-drop event in javascript) as well as choosing
a technical paper that will be simple enough to illustrate the idea.
Two papers are competing for that, one is "Primes is in P" and the
other is on denesting radicals.

I have a project to add the numeric libraries back into Axiom.  Axiom
is now a member of the Numerical Mathematics Consortium.  As a side
effect, I'm rewriting the routines into literate form, finding
research papers explaining the theory, such as convergence and
sensitivity, and adding that to the documentation. I'm currently
making the BLAS library literate.

I have a research effort to rewrite the algebra using provisos.
This uses the idea of generalized intervals to contain conditional
statements that constrain the validity of computations.


There are many, many other projects that could be done. For instance,

 * choose one of the book volumes and work on it

    - vol 2 is on programming. lately there has been a lot of discussion
      about programming in aldor. some of the same questions apply to
      spad code. there needs to be a lot of work given to explaining
      how to code algebra for axiom. i wrote a tutorial for how to
      develop a simple domain in aldor (it might be on the aldor site).
      this could be adapted to spad code and put into volume 2 as a
      chapter.

    - vol 3 is a reference guide. there are hundreds of hours of work
      here, following the example of the original Jenks book. Each 
      domain needs an explanation, a coverage of its exported functions,
      and example code. The explanations would also fit into the source
      files for the domain and the examples could be added to the input
      test suite.

    - vol 4 is the developer's guide. there are a large number of
      ideas cached in this mailing list that need explaining. there
      needs to be a step-by-step explanation of the make process
      (and the makefile.pamphlets can use the same text).

    - vol 6 is the compiler. Start with the )compile command and
      figure out how it works. Document it. Rewrite it. Package it
      as a volume.

    - vol 7 is the hyperdoc browser. This needs to be documented,
      rewritten, and packaged. Ideally it would be rewritten using one
      of the lisp GUI tools.

    - vol 8 is the graphics. Again, this needs to be documented,
      rewritten, and packaged. Ideally it would be rewritten using one
      of the lisp GUI tools.

    - vol 9 is the algebra. There is a whole wonderland of problems here.
      We can't even graph the lattice of the algebra reasonably. Pick
      any domain, document its purpose, functions, and give example code.
      Rewrite it so it can be drag-and-dropped. 

Volume 1, the tutorial, needs to be translated to other languages.

Axiom needs an example domain-specific literate book, like linear
algebra or signal processing, or music that can be an example of a
drag-and-drop domain expertise.

The database design in Axiom is old. It uses random access files which
follow VM/370 LispVM design. These databases should be redone using a
better overall design.

The NRLIB design needs rework. This is a copy of the LispVM compile
structure and should go away.

The NRLIB/code.lsp file has a large number of conventions. These need
to be defined and explained. There should be a low-level browser for
these files. 

How does Axiom generate Latex? Can we use the same mechanism to 
generate MathML?

The input directory should go away and the input tests should be
merged with their corresponding algebra source files. The machinery
now exists and has a couple examples. The input examples should be 
explained and made comprehensive.

There is a book "CRC Standard Curves and Surfaces" which contains
hundreds of worked-out examples of equations and their curves. This
should be made into a test suite (I have a start on this effort in
the CATS (Computer Algebra Test Suite) effort). We need to ensure that
Axiom's graphing routines generate the correct output and we need a
comprehensive test suite.

Axiom needs updated Groebner basis work (although the current routines
performed quite well at ISSAC 2006 when compared to singular and maple)

Axiom needs higher functions in the algebra, for instance, polylogs.

Axiom needs Symbolic Summation (extensions of Gosper's work)

Axiom needs much stronger algorithms in group theory.

Axiom needs generalization of its input format. For instance you should
pbe able to do:
   x := [ a_1, a_2, ..., a_n ] 
(in general for vectors or matrices). You should be able to ask for
the ith element of x, e.g. get(x,5) => x_5

Axiom needs to be able to do higher-order expressions like:
   x := p^n * 3*p^m + 2
   y := q^r * 6*q^s - 3
what is the j'th term of x*y? Well, since the we don't know the
exponents (n, m, r, or s) we have to construct a function that
will return the k'th component of x, the i'th component of y and
a final function that gives the result of x*y as a function of
the component functions. f(x(k),y(i)). Nobody does this yet to 
my knowledge.

If X is an 2x2 matrix what is X^p? If x is NxM what is X^p?
What is the i,j'th entry?

Can we construct a Maple parser that will generate Axiom internal
S-expressions? This would allow us to replace the Axiom input language
with a Maple input language. Is this useful? Is this better than B#?

If we decorate the Categories with their mathematical axioms can
we prove anything about them? Can we do it automatically using ACL2?
Can we extend the compiler to do the proof while it compiles?

Can we define a "problem graph" semantic network that will sit at the
heart of the crystal? What is the subsumption rule and is it theoretically
sound and stable?

Axiom should be attached to a Computer Aided Design program to 
model the stresses and strains and theoretical failure points.

Axiom should be integrated into a game like Bridge Builder
(http://www.bridgebuilder-game.com/pfx-info.php
to attempt to predict when a bridge might fail by computing the
result and then checking the simulation.

Axiom does not use threads or multiple processors but this is 
clearly the future direction of hardware. We need to find algorithms
that can be done in parallel and work up an example that gives linear
speedups based on the number of processors.

And that's just the short list off the top of my head.

\start
Date: Wed, 26 Jul 2006 12:16:45 -0400
From: Tim Daly
To: Bill Page
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Can anyone consider writing up a good tutorial-style summary of
this thread? Can you diagram the relationships? I think that the
points made here would be very valuable when presented in an 
incremental, logical, tutorial fashion. 

\start
Date: Wed, 26 Jul 2006 12:48:02 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: sbcl and Axiom

On Wednesday, July 26, 2006 11:54 AM C Y wrote:

> --- Bill Page wrote:
> ...
> > Time spent converting the existing Lisp code and the generated
> > Lisp code to conform to the common lisp standard is obviously
> > time well spent, as are efforts to port Axiom to other lisp
> > platforms besides GCL. But seems really unfortunate to me that
> > we are still in the situation where we have only one active
> > Axiom developer working in Lisp (Tim Daly).
>
> Agreed. But moving the generated Lisp code to ANSI is only of
> use if one never plans to generate the code again.

What I meant to write what modifying the programs that generate
lisp code so that they generate ANSI common lisp compliant code.

> It seems this is indeed the plan for the boot level code.
> However, the SPAD compiler will have to be adjusted to output
> ANSI lisp, unless we get a Free aldor first.

Agreed, however I think it should be done asap anyway.

> If there is overlap between the SPAD abilities and the BOOT
> abilities, perhaps a "tweaked-to-ANSI" boot compiler would be
> of some user after all for patching the SPAD code.

I don't see any point since as you originally surmised,
there is a complete overlap between the BOOT compiler and
the SPAD compiler - all we need is the bootstrapped SPAD
compiler.

> ...
> > Even new and innovative projects like Sage:
> >
> > http://modular.math.washington.edu/sage/
> >
> >   (Thanks for the reference Fr=E9d=E9ric Lehobey.)
> >
> > have choosen to implement an interface to Maxima first
> > before seriously considering Axiom.
>

I found some emails on the Sage website where one of the
authors briefly considered Axiom but decided on Maxima
because it already ran on Clisp and he anticipated (quite
correctly!) that Maxima would be easier to build on many
different platforms.

BTW, Sage already has a Javascript/AJAX web-based notebook
interface and their code is fully available under GPL. It
even includes LaTeX and graphics (gnuplot) output. If
someone is thinking of extending Tim Daly's work on this
sort of user interface for Axiom, I think Sage would be a
great place to look first.

\start
Date: Wed, 26 Jul 2006 14:19:58 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: sbcl and Axiom

On Tuesday, July 25, 2006 9:31 PM C Y wrote:
> ...
> > > It occurrs to me that this might be a waste of time,
> > > particularly if the interp directory code contains all of
> > > the functionality in boot aside from translating boot code
> > > to cl.  I think this is the case but before I throw out my
> > > current work - is the boot directory in fact entirely
> > > redundant functionality wise?
> > >
> > Bill Page wrote:
> > Gee, what could have given you that idea??
>
> The axiom_cmu.tgz archive does not contain the boot directory.

Thank you for continuing to look into this.

> ...
> Bill Page wrote: 
> > No the boot directory is not redundant.
> >

I was wrong.

> Bill Page wrote:
> > Yes you need to compile boot first before you can compile
> > anything from interp.
>

I was wrong again.

> Bill Page wrote:
> > No the interp directory code does not contain all of the
> > functionality of boot (nor any of the functionality of boot
> > for that matter).
>
> Hmm.  OK :-).

You are so nice, but I was wrong again...

> Bill Page wrote:
> > No what you have been doing so far is not a waste of time.
> > However, I think you should be using the make process as
> > defined in the current Axiom makefiles first before trying
> > to change things in a radical manner.
>

Yes, I admit it. Even this was rather bad advice.

\start
Date: 26 Jul 2006 22:29:47 +0200
From: Martin Rubey
To: list
Subject: Poster at Mathinfo 06

Dear all,

I am quite happy to announce that I will have a poster at Mathinfo 06,

"Fourth Colloquium on Mathematics and Computer Science,
Algorithms, Trees, Combinatorics and Probabilities"

http://mathinfo06.iecn.u-nancy.fr/

where I will present my axiom package for guessing formulas. *

Thus, I slightly disagree with the following:

> And on the mathematics front I seems we aren't doing much better.  In spite
> of a lot of apparent interest, we still have not collected nor have there
> been initiated more than just a few (two or three) projects involving Axiom.

It is probably true that we have only two or three projects involving Axiom,
but at least Combinat by Ralf et al. and the implementation of GFUN by Antoine
are very promising, if they happen. (and I sure hope they will!)

I think it is not sooo important to have many projects. I'd rather have one or
two "killer applications".

If I'm very lucky, I'll by able to convince Neil Sloane to replace his bunch of
programs by mine :-)

> Is there nothing we can do to improve this situation?

No, there is a lot we can do. From *my* perspective, the following are the
"most important tasks":

* free Aldor and/or start writing an Aldor interpreter or maybe modify the
  current spad interpreter to understand Aldor. The main features missing are:
  dependent types and extend, maybe generators.

* free the Algebra and SumIt sources. 

* write a replacement for HyperDoc and MathAction that uses AllProse. Note that
  AllProse is able to produce html, mathml etc., whatever you want. The main
  feature missing is the "HyperDoc browse" facility. Step zero: make AllProse
  use axiom, then in a first step, one could transform the existing pamphlet
  files into AllProse. If one restricts oneself to the few commands understood
  by HyperDoc between \begin{+++} and \end{+++}, this won't break HyperDoc.

* implement the summation algorithms from RISC, i.e., sigma.

* implement a nice domain for differentially algebraic power series in
  cooperation with Antoine.

Finally:

> I have a project to document the integration routines in axiom. I have
> several sources of text (Trager's thesis, Bronstein's thesis, etc) as
> well as 4800 integrals that came from the Maple test suite (reported
> on elsewhere in this mailing list). I've modified axiom to tell me
> where each integral resolves and am classifying the various integrals
> into sets of examples. That way each of the 40ish 'integrate' routines
> will have example input associated with it.


> I have a project to add the numeric libraries back into Axiom.  Axiom
> is now a member of the Numerical Mathematics Consortium.  As a side
> effect, I'm rewriting the routines into literate form, finding
> research papers explaining the theory, such as convergence and
> sensitivity, and adding that to the documentation. I'm currently
> making the BLAS library literate.

 
> I have a research effort to rewrite the algebra using provisos.
> This uses the idea of generalized intervals to contain conditional
> statements that constrain the validity of computations.

seem very sensible to me too. Although I'm a bit doubtful with respect to the
last item. I think, it is a quite complicated thing and one should note that
axiom rather takes a different approach to these things: an integer in Axiom
really is an integer. A polynomial really is a polynomial. So, what is the
domain of "generic" integers, "generic" polynomials? I don't think that there
will be an easy answer to this.

Martin

PS: I will certainly promote Axiom there a little. :-)

\start
Date: Thu, 27 Jul 2006 01:06:18 +0200
From: Antoine Hersen
To: Tim Daly
Subject: Re: sbcl and Axiom

Hello,


One key subgoal that is completely independent is to figure out how to
> draw a line on the screen using SBCL or CLISP and the new lisp-based GUI
> work. planet.lisp.org has had several discussions about this. A lisp-based
> GUI for graphics would be much more portable.


Do you mean just for plotting or a complete user interface ?

I have a project to redo HyperDoc using javascript and XMLHttpRequest.
> This uses a browser as the front end for the hyperdoc pages and uses
> an axiom back end to service requests for actions. Eventually this will
> go into the Doyen Wiki. I've rewritten a couple dozen pages so far and
> am working test examples.


Yes, HyperDoc show its age. Can you already generate static HTML ?
Why do you want to use XMLHttpRequest for ?

I have a project to document the integration routines in axiom. I have
> several sources of text (Trager's thesis, Bronstein's thesis, etc) as
> well as 4800 integrals that came from the Maple test suite (reported
> on elsewhere in this mailing list). I've modified axiom to tell me
> where each integral resolves and am classifying the various integrals
> into sets of examples. That way each of the 40ish 'integrate' routines
> will have example input associated with it.


My experience with Bronstein code is that there is not much comment and it
is very architectured. I have not try to read the Risch implementation. I
think Martin had a look at it.


I have a project to port axiom to the MAC. The key issue is getting GCL
> to build on the MAC. Since MACs are based on BSD the include file chain
> is completely different from linux and so things resolve poorly. Plus
> I find the MAC impossible to use (my ability to use a system is
> inversely proportional to its "ease of use").


Being a Mac user I think this should be the top most priority ;)
Each of my try was stopped by GCL too. It is more than BSD issue Darwin use
CMU microkernel and the way the stack is created is different from BSD or
Linux.

I am sorry you find the Mac difficult to use. Have you try Fink or
DarwinPort ?
I also recomend this Emac http://homepage.mac.com/zenitani/emacs-e.html.

I have a research effort to rewrite the algebra using provisos.
> This uses the idea of generalized intervals to contain conditional
> statements that constrain the validity of computations.


Will all domain  need to be made provisos aware ?
How will the conditional description be part of the type ?

The database design in Axiom is old. It uses random access files which
> follow VM/370 LispVM design. These databases should be redone using a
> better overall design.


What is this database ?

Axiom needs updated Groebner basis work (although the current routines
> performed quite well at ISSAC 2006 when compared to singular and maple)


I think the algebra need a good clean up. I have spend quite some time with
the polynomial univariate and multivariate and you can see they have been
done at the begining. I think that a lot of work form Aldor libAlgebra
should be included in Axiom.


Axiom needs Symbolic Summation (extensions of Gosper's work)


I am doing works in that direction.

Axiom needs to be able to do higher-order expressions like:
>    x := p^n * 3*p^m + 2
>    y := q^r * 6*q^s - 3
> what is the j'th term of x*y? Well, since the we don't know the
> exponents (n, m, r, or s) we have to construct a function that
> will return the k'th component of x, the i'th component of y and
> a final function that gives the result of x*y as a function of
> the component functions. f(x(k),y(i)). Nobody does this yet to
> my knowledge.


I need to check but I think work related to this as been show at last ISSAC
?

Also I have trouble with the Expression domain I dont really understand how
to use it. I will like an expression tree better.

If X is an 2x2 matrix what is X^p? If x is NxM what is X^p?


I think there is already a distinction between sqare and not sqare matrix ?

What is the i,j'th entry?


I dont understand this question.

Can we construct a Maple parser that will generate Axiom internal
> S-expressions? This would allow us to replace the Axiom input language
> with a Maple input language. Is this useful? Is this better than B#?


That look complicated.
My understanding of B#  is it will be a smart interpreter that can do as
much type guessing as possible. But if people want to specify type they
should be free to do so.

If we decorate the Categories with their mathematical axioms can
> we prove anything about them? Can we do it automatically using ACL2?
> Can we extend the compiler to do the proof while it compiles?


Very difficult.

Can we define a "problem graph" semantic network that will sit at the
> heart of the crystal? What is the subsumption rule and is it theoretically
> sound and stable?


I dont understand.

Axiom should be attached to a Computer Aided Design program to
> model the stresses and strains and theoretical failure points.


FEM analysis is traditionally more on the numeric computation side. But
people are working on mix symbolic numeric method(
http://www.sfb013.uni-linz.ac.at/ )

Axiom does not use threads or multiple processors but this is
> clearly the future direction of hardware. We need to find algorithms
> that can be done in parallel and work up an example that gives linear
> speedups based on the number of processors.


You need very good language support to make this practicable.
Also parallel algorithm tend to be significantly more complicated.


\start
Date: Wed, 26 Jul 2006 19:08:30 -0400
From: Tim Daly
To: Antoine Hersen
Subject: Re: sbcl and Axiom

> One key subgoal that is completely independent is to figure out how to
> > draw a line on the screen using SBCL or CLISP and the new lisp-based GUI
> > work. planet.lisp.org has had several discussions about this. A lisp-based
> > GUI for graphics would be much more portable.
> 
> 
> Do you mean just for plotting or a complete user interface ?

Ideally a complete user interface. A lisp-based user interface is
"in process" in the lisp community. If we can get that to work we
gain the portability we need. Additionally we could contribute the
graphics back to that effort.

\start
Date: Thu, 27 Jul 2006 01:20:52 +0200
From: Antoine Hersen
To: list
Subject: Front page esthetic

Hello,

I have just a comment about the front page.

In the right column all links start with "Axiom". Is there is a reason for
this ?

I know it is mostly about personal taste but I find it redundant and does
not help me find what I am looking for.

\start
Date: Wed, 26 Jul 2006 19:14:24 -0400
From: Tim Daly
To: Antoine Hersen
Subject: Re: sbcl and Axiom

> I have a project to redo HyperDoc using javascript and XMLHttpRequest.
> > This uses a browser as the front end for the hyperdoc pages and uses
> > an axiom back end to service requests for actions. Eventually this will
> > go into the Doyen Wiki. I've rewritten a couple dozen pages so far and
> > am working test examples.
> 
> 
> Yes, HyperDoc show its age. Can you already generate static HTML ?
> Why do you want to use XMLHttpRequest for ?

I'm looking at the issue of re-doing the work in javascript and HTML,
basically the AJAX model. AJAX is just javascript behind HTML that
can make an asynchronous call using XMLHttpRequest. You can set some
information in the XMLHttpRequest object, invoke the send method and
wait for a result. That way you don't change pages. This will be useful
because the Axiom browser can send requests off to Axiom and have it
execute. Using Bill and Jose's work we can get Axiom running completely
in a web page. This gives us the ability to generate output immediately,
effectively making the browser a complete front-end that is system
independent.

The Axiom graphics can generate postscript images immediately so it
would be possible to embed the graphics results directly into the
web page. Unfortunately they would be static.

\start
Date: Wed, 26 Jul 2006 19:32:01 -0400
From: Tim Daly
To: Antoine Hersen
Subject: Re: sbcl and Axiom

> I have a project to port axiom to the MAC. The key issue is getting GCL
> > to build on the MAC. Since MACs are based on BSD the include file chain
> > is completely different from linux and so things resolve poorly. Plus
> > I find the MAC impossible to use (my ability to use a system is
> > inversely proportional to its "ease of use").
> 
> 
> Being a Mac user I think this should be the top most priority ;)
> Each of my try was stopped by GCL too. It is more than BSD issue Darwin use
> CMU microkernel and the way the stack is created is different from BSD or
> Linux.

If you can get GCL to build it would be a big help.
It would be an even bigger help if you could get Axiom to build
as Axiom has "portable (guffaw) C code".

> I am sorry you find the Mac difficult to use. Have you try Fink or
> DarwinPort ?
> I also recomend this Emac http://homepage.mac.com/zenitani/emacs-e.html.

I'm using Fink. That isn't the problem. The problem is the same one
I'm having with the FreeBSD port. The C include files have a completely
different tree than the Linux files. 

\start
Date: Wed, 26 Jul 2006 20:01:39 -0400
From: Tim Daly
To: Antoine Hersen
Subject: Provisos

> I have a research effort to rewrite the algebra using provisos.
> > This uses the idea of generalized intervals to contain conditional
> > statements that constrain the validity of computations.
> 
> Will all domain  need to be made provisos aware ?
> How will the conditional description be part of the type ?

Provisos are fundamental. If you look at math books carefully
you'll see that quite a few expressions, results, and reasoned arguments
have provisos. Axiom has a way of carrying types but not provisos.

It's a rich research area with very few results.
This was my PhD research and has held my interest for years.

This involves a complete algebra rewrite from the ground-up.
Provisos are fundamental to the whole system. Each Category,
Domain, and object has provisos which limit the validity.

Computation involves reasoning "with" the provisos. That is,
computing with a proviso and an operation like *,

  (1/x provided x != 0) * (1/y provided y != 0)

and computing "in" the provisos which amounts to doing computation
in the "provided" section to combine the results. 

This has implications about forking and combining results so that
you can get answers which have multiple branches, e.g. f(x) can return
         
         --
         |
  f(x) = | x   provided x > 0
         |
         | 1   provided x = 0
         |
         | 1/x provided x < 0
         |
         --

where the proviso-based computation automatically forked into 
multiple branches.

This also has interestng implications for multi-thread or 
multi-process work since you can compute a branch of the 
proviso in parallel and independent of other branches in 
some cases.

Since the provisos can be anything, a whole host of issues
arises. For instance, suppose the proviso reads:

   x provided P in [0,1]

where P is a polynomial? Well, types show up quickly. Is
[0,1] an interval over the reals? Domain matching becomes
an issue since 

   provided P in y

means that 'in' has a type on either side, essentially in(P,y)
and the types have to match. Which raises the issue of conversion
and coercion, which brings us to the Fortenbacher type work.

Handling infinities also arises which brings in the work of
Hansen and Walster on csets.

Handling "indefinites" like 

  x provided x is PositiveInteger

covers the assume facilities in most other systems. You might
be able to compute the type of something but not its value.

And just for excitement the compiler has to know about provisos
so it can decorate the resulting code properly.

This is how I waste my weekends :-)

\start
Date: Wed, 26 Jul 2006 20:05:15 -0400
From: Tim Daly
To: Antoine Hersen
Subject: Re: sbcl and Axiom

> The database design in Axiom is old. It uses random access files which
> > follow VM/370 LispVM design. These databases should be redone using a
> > better overall design.
> 
> 
> What is this database ?

There are several databases, you can see them loaded when the system
starts. These include information that the interpreter uses to run
the system.

They are random access files (a concept that seems to have been lost
from computer science :-) ). The first number in the file is the
number of bytes into the file to find the index, which is an association
list of (item . index). You can look up an item in the association list
and then the returned number is the byte index into the file for the value.

It's very efficient in terms of disk I/O which was a concern way back when
I was a lad but it would make more sense to keep these in memory as they
are relatively small. Such a change would probably speed up the system
quite a bit.

\start
Date: Wed, 26 Jul 2006 20:13:49 -0400
From: Bill Page
To: Antoine Hersen
Subject: RE: Front page esthetic

Antoine,

Thank you very much for the comment. I have made some
changes and look forward to further suggestions.

Regards,
Bill Page.

On Wednesday, July 26, 2006 7:21 PM you wrote:

> I have just a comment about the front page.
> In the right column all links start with "Axiom".
> Is there is a reason for this ?
>
> I know it is mostly about personal taste but I find it
> redundant and does not help me find what I am looking for.

\start
Date: Wed, 26 Jul 2006 20:22:32 -0400
From: Bill Page
To: Tim Daly
Subject: RE: sbcl and Axiom

Tim,

On Wednesday, July 26, 2006 7:14 PM you wrote:
>
> > I have a project to redo HyperDoc using javascript and
> > XMLHttpRequest. This uses a browser as the front end for
> > the hyperdoc pages and uses an axiom back end to service
> > requests for actions. Eventually this will go into the
> > Doyen Wiki. I've rewritten a couple dozen pages so far and
> > am working test examples.
> >
> >
> > Yes, HyperDoc show its age. Can you already generate static
> > HTML ? Why do you want to use XMLHttpRequest for ?
>
> I'm looking at the issue of re-doing the work in javascript
> and HTML, basically the AJAX model. AJAX is just javascript
> behind HTML that can make an asynchronous call using XMLHttpRequest.
> You can set some information in the XMLHttpRequest object, invoke
> the send method and wait for a result. That way you don't change
> pages. This will be useful because the Axiom browser can send
> requests off to Axiom and have it execute. Using Bill and Jose's
> work we can get Axiom running completely in a web page. This
> gives us the ability to generate output immediately, effectively
> making the browser a complete front-end that is system independent.
>
> The Axiom graphics can generate postscript images immediately so
> it would be possible to embed the graphics results directly into
> the web page. Unfortunately they would be static.
>

Please take a look at the Sage Notebook Interface.

It seems to have most (all?) of the feature that you describe
with interfaces to several open source computer algebra systems
including Gap, Magma, GP/PARI and Maxima.

http://modular.math.washington.edu/sage/doc/html/ref/node6.html
http://modular.math.washington.edu/sage/doc/html/ref/module-sage.server.
notebook.notebook.html

I am quite sure we could interest some Sage users in an
interface to Axiom.

\start
Date: 27 Jul 2006 02:26:55 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Front page esthetic

Bill,

  I wanted to add more information to

   http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers

but it asked for a zope identifier and password, which I don't have.

I do have a account with the "portal" though -- I don't know how they
realte.  All these identifiers and passwords... 

\start
Date: Thu, 27 Jul 2006 02:38:31 +0200
From: Antoine Hersen
To: Tim Daly
Subject: Re: sbcl and Axiom

> > The database design in Axiom is old. It uses random access files which
> > > follow VM/370 LispVM design. These databases should be redone using a
> > > better overall design.
> >
> >
> > What is this database ?
>
> There are several databases, you can see them loaded when the system
> starts. These include information that the interpreter uses to run
> the system.


What kind of information ?

They are random access files (a concept that seems to have been lost
> from computer science :-) ). The first number in the file is the
> number of bytes into the file to find the index, which is an association
> list of (item . index). You can look up an item in the association list
> and then the returned number is the byte index into the file for the
> value.


We still learn that dont worry.

It's very efficient in terms of disk I/O which was a concern way back when
> I was a lad but it would make more sense to keep these in memory as they
> are relatively small. Such a change would probably speed up the system
> quite a bit.


Yes the trade of between doing disk I/O and using memory space are reversed.

\start
Date: Wed, 26 Jul 2006 20:46:41 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Front page esthetic

Gaby,

On Wednesday, July 26, 2006 8:27 PM you wrote:
>
>   I wanted to add more information to
>
>    http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers
>
> but it asked for a zope identifier and password, which
> I don't have.

Perhaps you did not bother to read the next page after
the prompt which explains that you must provide reason
for the change unless you have administrator access?
This is a recent change intended to reduce the incidence
of spam edits. I agree that it might be a little confusing
to be first confronted by a a log in box before being
given the explanation but this is a result of the rather
quick hack I made to implement the edit check.

To make your changes to the SandBoxActiveAxiomDevelopers
just make sure that you enter some simple explanatory text
in the reason box before you click Save. Let me know if
you still have problems.

I think it might be a lot better if I used a javascript edit
check instead of depending on the awkward server interaction.
I will try that when I next get a chance.

>
> I do have a account with the "portal" though -- I don't
> know how they realte.  All these identifiers and passwords...
>

Yes, it is a real pain... mostly forced on us by those
malicious freeloaders who insist on defacing our precious
content. It is still my intention to keep the Axiom Wiki
site as open access as possible, but it is getting harder
and harder to keep it clean.

We have a few select pages (such the FrontPage) that are
protected from one acess since this page is a favourite one
of the spammers but it's consistent content is very important
to us. In order to modify these pages you must have Zope
Management user id. Only three people have that kind of
access to the Axiom web site right now. If you want to be
one of them I am sure we would all be glad to share the
responsibility with you. :)

The Axiom portal site is a different story. It runs Plone
and is intended from the start to be a more controlled access
environment where people can create the own work privately
and then share it with others as and when they wish in a
controlled manner. It does also provide users with their
own private wiki pages that can run Axiom and Reduce programs
in the same way as the public Axiom Wiki. And there are a
few other portal-based services such as the bibliograhies,
news, events and calendar.

I used to think this was pretty neat and some people have
said that they like the "feel" of the web page layout
better than the less structured (and less complex) wiki
environment, but unfortunately it does not really seem to
gotten much use yet.

Before getting access to the Axiom portal, users must
register but this is an easy process that basically just
confirms the validity of the users email address.

\start
Date: 27 Jul 2006 02:58:59 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Front page esthetic

Bill Page writes:

| Gaby, 
| 
| On Wednesday, July 26, 2006 8:27 PM you wrote:
| > 
| >   I wanted to add more information to
| > 
| >    http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers
| > 
| > but it asked for a zope identifier and password, which
| > I don't have.
| 
| Perhaps you did not bother to read the next page after
| the prompt which explains that you must provide reason
| for the change unless you have administrator access?

that must be it -- I have nearly a zone of navigator windows open and
I must confess I'm buried :-(


| This is a recent change intended to reduce the incidence
| of spam edits. I agree that it might be a little confusing
| to be first confronted by a a log in box before being
| given the explanation but this is a result of the rather
| quick hack I made to implement the edit check.
| 
| To make your changes to the SandBoxActiveAxiomDevelopers
| just make sure that you enter some simple explanatory text
| in the reason box before you click Save.

Many thanks; I'll give it a try.

\start
Date: Wed, 26 Jul 2006 21:19:57 -0400
From: Tim Daly
To: Antoine Hersen
Subject: Re: sbcl and Axiom

> Axiom needs to be able to do higher-order expressions like:
> >    x := p^n * 3*p^m + 2
> >    y := q^r * 6*q^s - 3
> > what is the j'th term of x*y? Well, since the we don't know the
> > exponents (n, m, r, or s) we have to construct a function that
> > will return the k'th component of x, the i'th component of y and
> > a final function that gives the result of x*y as a function of
> > the component functions. f(x(k),y(i)). Nobody does this yet to
> > my knowledge.
> 
> 
> I need to check but I think work related to this as been show at last ISSAC
> ?

Actually, it was. But the scheme given there is overly complicated in
my opinion. He measures the distance between the various entries and
computes a graph over the matrix.

In Axiom you could simply construct lists to represent the input so:

   [ a_1 ... a_n   ]
   [ a_2 .   a_n+1 ]
   [ .    .  .     ]
   [ .     . .     ]
   [ a_m ... a_n+m ]

could simply be represented as a list of lists with the dots as
list elements:

   ( ( a_1 ldots a_n ) (a_2 ldots a_n+1) hdots

kinds of a data structure. Then you could compute any given
element dynamically. It seems like an easier approach.

\start
Date: 27 Jul 2006 03:43:48 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Front page esthetic

Bill Page writes:

[...]

| To make your changes to the SandBoxActiveAxiomDevelopers
| just make sure that you enter some simple explanatory text
| in the reason box before you click Save. Let me know if
| you still have problems.

I just tried, it did not work :-(

\start
Date: Wed, 26 Jul 2006 21:59:17 -0400
From: Tim Daly
To: Antoine Hersen
Subject: Re: sbcl and Axiom

> Can we construct a Maple parser that will generate Axiom internal
> > S-expressions? This would allow us to replace the Axiom input language
> > with a Maple input language. Is this useful? Is this better than B#?
> 
> 
> That look complicated.
> My understanding of B#  is it will be a smart interpreter that can do as
> much type guessing as possible. But if people want to specify type they
> should be free to do so.

Well, as long as we're talking about changing the input language
so that it is type-free, one thing to consider would be to mimic 
the Maple language. That would give us a large test suite of 
programs and examples. It also might be fairly enlightening about
the issues, both for us and for Maple.

\start
Date: Wed, 26 Jul 2006 22:08:27 -0400
From: Tim Daly
To: Antoine Hersen
Subject: Re: sbcl and Axiom

> If we decorate the Categories with their mathematical axioms can
> > we prove anything about them? Can we do it automatically using ACL2?
> > Can we extend the compiler to do the proof while it compiles?
> 
> 
> Very difficult.

Clearly but I think that this is one of the most interesting areas
of research. Axiom has an advantage over other systems like Maple
and Mathematica because of our structure. In the long term it is
important that we are able to trust the results of computations,
especially when the results are beyond checking by hand. The only 
way to build trust will be proving the programs correct. Unlike
random programs, computer algebra programs have a good theory behind
them. I think it is vital that we develop a theory and a mechanism
for proof of computer algebra programs. It's the old Legendre vs
Gauss argument... we can't just assert that our programs are right,
we need to prove it. Otherwise it hardly qualifies as a science.

Also of interest is that computational math is not quite the same
as math. Axiom has some categories, such as RNG, which don't seem
to match those of regular math. One question is whether this is 
just a design flaw or does it expose a new computational object
that we need to examine theoretically.

The same issue arises in proofs. I often see statements that some
algorithm works "over the integers" and is of order O(n^2) or
some such. However, my computer does not have integers. It has
fixnums and bignums. The algorithm may be O(n^2) for fixnums but
become O(n^3) for bignum values. The standard methods of statements
based "on the integers" often don't take this into account.

Yeah, it's difficult but that's what makes it fun.

\start
Date: Wed, 26 Jul 2006 22:21:12 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Front page esthetic

Gaby,

On Wednesday, July 26, 2006 9:44 PM you wrote:

> Bill Pagewrites:
>
> [...]
>
> | To make your changes to the SandBoxActiveAxiomDevelopers
> | just make sure that you enter some simple explanatory text
> | in the reason box before you click Save. Let me know if
> | you still have problems.
>
> I just tried, it did not work :-(
>

You got the following message:

  "Please check your comments or changes for unauthorized content."

In nice bright friendly red letters, right?

Ok, sorry I should have tried this before my previous long
explanation... Now I must subject you to another. :(

The reason this is being rejected is also do to another anti-spam
change to the Axiom Wiki system. A few weeks ago based on Bob
McElrath's suggestion a configured a feature of ZWiki that we had
not been previously using that provides for direct content filtering
of posted text. The idea is that it is possible to maintain a list
of words and links which are extremely unlikely to be part of any
valid post to the web site. I did this in response to about two or
three nasty spam emails that were getting through each day. But
these guys are devious and it turns out this requires rather
constant attention to make it keep working to filter out the bad
stuff. This is all based on simple regular expression pattern
matching. Nothing fancy.

What I was especially concerned about was the apparent large number
of robot programs that were being written specifically to target
wiki/ZWiki web sites like ours.

The short story is that I decided to disallow all HTML encoded
href links since that was the most common denomintator in all of
these spam attacks. This makes it a little harder to post a message
or a change to a web page if all you (usually a robot) know is how
to generate an HTML link. Fortunately our web site pages support a
shorter and fairly convenient idiom (called StructuredText) for
links that looks like this:

  "some text":http://xxx.com

which is translated by the ZWiki web page rendering as exactly

  <a href="http://xxx.com">some text</a>

No robot seems to have figured out how to do this translation
automatically yet probably because of the number of wiki sites
that support StructuredText is too small to be worth the cost
of the modifications to the code.

So, what you have to do now (what I will do right now for you)
is to back convert these HTML encoded links to the StructuredText
form. Then everything will be fine. Of course you will also have
to remember to use the StructuredText.

I hope all of this nasty inconvenient stuff does not put you
off from making the changes that you intended to do. ;)

If anyone has some good suggestions for how to deal with this
spam problem stuff (without involving a lot of my programming
time!), I would be glad to hear it. And if anyone is motivated
to help solve this kind of problem, them I am certainly motivated
to spend as much time as it takes working with them... but I am
getting too tired and cranky by having to continue to play with
web server stuff, while what I really want is to devote more time
to mathematics and physics, rather than continue fix this kind
of stuff on my own now... :)

\start
Date: Wed, 26 Jul 2006 23:13:37 -0400
From: Alfredo Portes
To: Bill Page
Subject: Re: sbcl and Axiom

This is the sage notebook test web page (similar to sandbox in
axiom-developer):

http://sage.math.washington.edu:8100/

Here you can test sage and the computer algebra systems it uses (Maxima...).

On 7/26/06, Page, Bill Bill Page wrote:
> Tim,
>
> On Wednesday, July 26, 2006 7:14 PM you wrote:
> >
> > > I have a project to redo HyperDoc using javascript and
> > > XMLHttpRequest. This uses a browser as the front end for
> > > the hyperdoc pages and uses an axiom back end to service
> > > requests for actions. Eventually this will go into the
> > > Doyen Wiki. I've rewritten a couple dozen pages so far and
> > > am working test examples.
> > >
> > >
> > > Yes, HyperDoc show its age. Can you already generate static
> > > HTML ? Why do you want to use XMLHttpRequest for ?
> >
> > I'm looking at the issue of re-doing the work in javascript
> > and HTML, basically the AJAX model. AJAX is just javascript
> > behind HTML that can make an asynchronous call using XMLHttpRequest.
> > You can set some information in the XMLHttpRequest object, invoke
> > the send method and wait for a result. That way you don't change
> > pages. This will be useful because the Axiom browser can send
> > requests off to Axiom and have it execute. Using Bill and Jose's
> > work we can get Axiom running completely in a web page. This
> > gives us the ability to generate output immediately, effectively
> > making the browser a complete front-end that is system independent.
> >
> > The Axiom graphics can generate postscript images immediately so
> > it would be possible to embed the graphics results directly into
> > the web page. Unfortunately they would be static.
> >
>
> Please take a look at the Sage Notebook Interface.
>
> It seems to have most (all?) of the feature that you describe
> with interfaces to several open source computer algebra systems
> including Gap, Magma, GP/PARI and Maxima.
>
> http://modular.math.washington.edu/sage/doc/html/ref/node6.html
> http://modular.math.washington.edu/sage/doc/html/ref/module-sage.server.
> notebook.notebook.html
>
> I am quite sure we could interest some Sage users in an
> interface to Axiom.

\start
Date: 27 Jul 2006 05:15:12 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: sbcl and Axiom

Tim Daly writes:

| > Can we construct a Maple parser that will generate Axiom internal
| > > S-expressions? This would allow us to replace the Axiom input language
| > > with a Maple input language. Is this useful? Is this better than B#?
| > 
| > 
| > That look complicated.
| > My understanding of B#  is it will be a smart interpreter that can do as
| > much type guessing as possible. But if people want to specify type they
| > should be free to do so.
| 
| Well, as long as we're talking about changing the input language
| so that it is type-free, one thing to consider would be to mimic 
| the Maple language. That would give us a large test suite of 
| programs and examples. It also might be fairly enlightening about
| the issues, both for us and for Maple.

I consider Maple language to be cripled, grown barnacle over the
year.  With hindsight, we must be very careful.  I thought that
B-natural was considerd to be the typeless language of choice for
Axiom?

\start
Date: 27 Jul 2006 05:31:12 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Front page esthetic

Bill Page writes:

[...]

| The short story is that I decided to disallow all HTML encoded
| href links since that was the most common denomintator in all of
| these spam attacks. This makes it a little harder to post a message
| or a change to a web page if all you (usually a robot) know is how
| to generate an HTML link. Fortunately our web site pages support a
| shorter and fairly convenient idiom (called StructuredText) for
| links that looks like this:
| 
|   "some text":http://xxx.com

That works much better.  Thanks!

Well, it looks like today I don't have much luck with automated verifiers...
I just tried to adjust my options for the list
axiom-testresults@lists.sf.net, but met with a fierce resistance.
So, enough for today. :-(

\start
Date: Thu, 27 Jul 2006 00:11:58 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: sbcl and Axiom

On Wednesday, July 26, 2006 11:15 PM  Gaby wrote:

> ...
> Tim Daly wrote:
> |
> | Well, as long as we're talking about changing the input
> | language so that it is type-free, one thing to consider
> | would be to mimic the Maple language. That would give us
> | a large test suite of programs and examples. It also might
> | be fairly enlightening about the issues, both for us and
> | for Maple.

I have been and continue to be a long term frequent user and
beta tester of new versions of Maple. I don't see much point
in mimicing the "Maple language" as an Axiom interface - at
least not from the point of view of the significant features
of Axiom. In fact my dissatifaction with Maple as a formal
mathematical environment and with the direction taken by
the MapleSoft developers a few years ago lead directly to
my current interest (dare I say fascination) in Axiom and
Aldor.

>
> I consider Maple language to be cripled, grown barnacle
> over the year.  With hindsight, we must be very careful.

I agree strongly with Gaby about this. I think we have to be
very careful. I know that Steven Watt and his research group
are quite actively involved with Maple developers and have
implemented several different interfaces of the kind that
Tim is suggesting. See for example:

A Framework for Using Aldor Libraries with Maple.
Cosmin Oancea, Stephen M. Watt.
www.csd.uwo.ca/~watt/pub/reprints/2004-eaca-mapal.pdf

Since Maple remains a properitary system in more or less direct
competition with Axiom in spite of the fact that Axiom is now
open source, I think this connection between Aldor and Maple
is potentially in conflict with Aldor becoming open source
and available for full integration with the Axiom open source
distribution.

Two thing might dissuade me from this negative opinion: One
is if Maple should move much more strongly towards making
Maple open source then in has in the last few years
(admittedly there has been *some* progress). The second is
if MapleSoft would agree to become an official corporate
sponsor of the Axiom project. (Don't scoff!) Seriously I
don't see any reason why MapleSoft and even Mathematica might
not want to do this - afterall what do they have to lose by
doing this? And how many promises of the good will of
mathematical researchers would it like buy for them?

Anyway, although a Maple or Mathematica-style input language
might have some initial appeal to users attempting to migrate
from one of these other environments to Axiom, I think that
in the long run this path for new users to Axiom is not
likely to be a very effective one for Axiom because it too
strongly de-emphasises the fundamental design distinctions
between Axiom and these other systems. In fact it could be
very misleading for new users to be introduced to Axiom this
way.

> I thought that B-natural was considerd to be the typeless
> language of choice for Axiom?
>

I think I would prefeer to describe B-natural as a singly-
typed language rather than a typeless language because of
the way it must interface with the very complex Axiom type
system. Form my point of view, as a candidate for a new user
input language for Axiom, B-natural remains the most "natural"
choice. :)

\start
Date: Thu, 27 Jul 2006 01:18:24 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: sbcl and Axiom

Alfredo,

On Wednesday, July 26, 2006 10:58 PM you wrote:
>
> This is the sage notebook test web page (similar to sandbox
> in axiom-developer):
>
> http://sage.math.washington.edu:8100/
>
> Here you can test sage and the computer algebra systems it
> uses (Maxima...).

Yes. Not bad, is it? :-)

I am very impressed about how aggressively William Stein and
David Joyner are about developing and promoting Sage. I only
wish we had even half this much energy and a quarter of these
resources to work on the Axiom project!

Have you had a chance to listen to any of the audio of their
"First annual mini-conference and workshop" that was held in
February last year?

http://modular.math.washington.edu/sage/days1/index.html

So far I have only listened to William Stein's introduction
but it is more than enough to make me very interested in the
rest of the two day meeting.

> I can see that they rely heavily on Python.  Programs like
> Maxima can be invoked using a wrapper function.

Yes. This is (more or less) the way Axiom and Reduce are
driven by the MathAction/LatexWiki software. But there is
a significant difference since Sage attempts to use Python
data structures themselves to implement a common underlying
computer algebra system. So data coming from Maxima is
recoded by the interface into internal Sage data structures
instead of just being printed out or converted to LaTeX.
Later these mathematical objects can be sent to some other
package such as GAP, or to gnuplot for display.

Of course it is not as easy as it sounds and I have some
serious doubts about to what degree this can be done in the
most general way possible (such as the stuff done by the
OpenMath people), but I expect that Sage solves most of
these sort of problems in more practical ways. And I suppose
users of Sage fairly quickly learn to avoid such problems
if they really do find it convenient to use more than one
package to solve a particular problem.

>
> It uses its own web server, which seems to be a Python
> client/server socket program (I think is part of Python
> libraries). Yes you are right.

Sage does however make use of some internal parts of Zope in
particular the Zope Database component to provide persistent
object storage. I doubt that this makes it fully compatible
with Zope but at least is speaking the same language in a
deep way. From what I can tell from the documentation it does
seem that Zope is installed as part of the Sage installation.
But it is not clear exactly what role it plays. I guess finding
this out will have to wait until I get a chance to actually
install this thing and look at how it runs inside.

>
> I wonder if the notebook engine can be used inside Zope/Wiki
> server.

Yes, I think this should be possible.

> I do not know how this can be useful for the work being done
> by Tim for the Axiom browser front-end.
>

I don't know exactly, but I am sure if Tim willing and able
to find the time to learn Python, then there is a lot of code
here which would not have to be re-designed for Axiom's
purposes. :) If he persists thinking that it is necessary to
write substantial portions of his code in Lisp, I would be
much less optimistic of a useful result.

Certainly it would not be too difficult to offer Sage as an
alternative user interface on the DoyenCD provided we can
solve the problem of writing a reasonable Python wrapper
function to interface Axiom with Sage. In principle this
should be no harder than the code that I wrote for MathAction
which as you know is really is very simple (even simplistic)
Probably only a few hundred line of Python at most with
some of it adapted from the MathAction python code.

I am thinking in particular about the way the NoteBook
interface makes use of AJAX. I have seen how this can work
to make user interaction much more efficient for typical
Google-style search engine interfaces, but to get AJAX to
a work smoothly as a "worksheet/notebook" style interface
is still rather much of a unknown art. Sage is the first
system I have ever seen that attempts to do this.

Last year I did have a lot of conversations with Kai Kaminski
about this. Kai was our Google-funded "Summer of Code" student
last year who developed the AxiomUI prototype. I had hopes
that this would evolve into a more complete AJAX solution,
but in the end there was not much time left after Kai dealt
with the problems of interfacing his Clisp-based interface
software to the Axiom interp/bootsys level. Maybe some of
this work would still be applicable to Tim's new user
interface project.

\start
Date: Thu, 27 Jul 2006 08:06:35 +0200
From: Christian Aistleitner
To: Ralf Hemmecke
Subject: Re:  exports and constants

Hello,

> Christian, I think that you should have said that reflection would be
> just perfect for your AldorUnit
>
> http://www.risc.uni-linz.ac.at/software/aldor/aldorunit

You are right, reflection would be wonderfull for AldorUnit. However,  
that's not all I have int mind for reflection.
For example, I wrote wrappers for Maple syntax and Mathematica's FullForm  
syntax.
My further code needs to determine at runtime, which syntax wrappers are  
available. Therefore, the syntax wrappers have to register themselves in a  
central repository. But this is a pain. With reflection, we could do  
without such a repository.

For serialzation, a reflection framework proves handy sometimes.

There are lots of further examples :)

> I am somehow reluctant to allow reflections in general, but for certain
> types of problems (like AldorUnit) it would be quite advantagous. OR the
> Aldor compiler would support AldorUnit and several other tools (relying
> on reflections) that people come up with in the future, then reflections
> are not so important in my eyes.

I agree that everything giving more reflection to Aldor is a step in the  
right direction. But I'd prefer to go for the full monty.

\start
Date: Thu, 27 Jul 2006 09:20:52 +0200
From: Christian Aistleitner
To: Bill Page, Ralf Hemmecke
Subject: Re: [Aldor-l] Re:  exports and constants

Hello,

On Wed, 26 Jul 2006 17:36:34 +0200, Page, Bill Bill Page  
wrote:

> On Wednesday, July 26, 2006 10:35 AM Ralf Hemmecke wrote:
>> ...
>> I believe reflections are not too complicated once we know
>> how the internal datastructures for domains are. (Yes, yes,
>> we must look inside the compiler sources, or does anybody
>> already have a description of how domains are represented
>> in memory?)
>> ...
>
> I think the documentation that you need for this is Aldor's
> abstract machine layer called FOAM. This is where implementation
> details such as you describe are specified. This abstract
> machine is implemented in Lisp, Scheme, and in a C runtime
> system. I believe that the program code that is generated by
> Aldor before being converted to real machine code is accessible
> in the .asy and .ao files. If we had to parse the output of the
> compiler in order to know what it was doing, then it seems to
> me that this a better and fully portable place to look rather
> Lisp or intermediate C code.

I agree, .asy or Foam is better than C or LISP, for what you are  
considering. But Ralf considered looking into the compiler sources. The  
discussion has now drifted towards "I do not need the sources; I simply  
compile to <some Language> and get the required information by mysolf".  
Thereby, I guess you are barking up the wrong tree.

Assume, you had a domain being able to parse the FOAM code and extract the  
relevant information.
You have to do lots of trickery to get the FOAM code in first place.
You need:
- the compiler
- sources of the object to query
- all necessary include files for the sources
- information where these necessary include files are in the file system
- all necessary library files for the sources
- information where these necessary library files are in the file system
- the correct order in which the libraries have to be passed to the  
compiler
- Knowledge what defines are necessary to get program compiled correctly
- Knowledge what plattform-specific options are necessary to get program  
compiled correctly

probably you'll also need to have the sources of all libraries. (Assume I  
wanted to ask what functions MachineInteger has)

The first of these items is rather trivial -- currently. I guess everybody  
using aldor is a developer and has the compiler at hand.

Would that be really worth the pain?

But assume you solve all these issues -- there is still the assumption  
that you had a domain being able to parse the FOAM code and extract the  
relevant information.
Lots of problems are lukring there as well. For example, if you use  
MachineInteger within the code of interest, the FOAM code would give you  
the declaration
       (GDecl Word "sal_int_AldorInteger_1013410656" -1 4 1 Foam)
You can read off that it's the domain AldorInteger with its magic number  
1013410656. You also know it is defined in sal_int. Assume you somehow  
know that sal_int is in the algebra library. How to guess the "src/arith"  
in the source's filename (src/arith/sal_int.as)? What about extensions of  
AldorInteger?

What you are discussing here is honorable. But its an amazingly huge  
effort.

If Aldor would be freed from it's proprietary trap, you'd be able to look  
up the data structures and work with them directly. Take a look at the  
sources (that came with the compiler some time ago) of the Trace package.  
It's slick. Maybe something similar is possible to achieve "more  
reflection"?
Or maybe even some hackery of the compiler/runtime is necessary?

However, I would hold my horses when it comes to do it with a closed  
compiler. Simply too much trouble.


> [ FOAM ]
> Apparently there is a detailed reference
>
> [6]: Stephen M. Watt and Peter A. Broadbery and Pietro Iglio
> and Scott C. Morrison and Jonathan M. Steinbach,
> FOAM: First Oder Abstract Machine

This repart is a detailed reference. Yes. But it doesn't tell you  
everything. Consider this line of FOAM code
   (Decl Word "TextWriter" -1 4)
. With the help of the paper you'll know that it's a declaration of what's  
called "TextWriter" in Aldor source code. It is of type "Word". But the  
numbers -1 and 4 are still shrouded in darkness (reserved and used by the  
compiler). You get some hints about the 4, if the type (Word) would be Rec  
or Arr. But it is not.

It does not look like it cannot be done, but the cost/benefit ratio is bad.

\start
Date: Thu, 27 Jul 2006 10:29:45 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: RNG vs. RING   was: Re: sbcl and Axiom

> Also of interest is that computational math is not quite the same
> as math. Axiom has some categories, such as RNG, which don't seem
> to match those of regular math. One question is whether this is 
> just a design flaw or does it expose a new computational object
> that we need to examine theoretically.

I like this example! Let's look to the sources in catdef.spad

Rng(): Category == Join(AbelianGroup,SemiGroup)
Ring(): Category == Join(Rng,Monoid,LeftModule(%)) with ...

So Ring has a multiplicative identity, Rng hasn't.

There is surely a difference between mathematics and computational 
mathematics. As a mathematician I would like to tell my computer
"Ring is a ring with identity" if this is appropriate for my context.
And in another context I would like to use Ring to denote a ring without 
identiy. That is what mathematicians do all the time. But if you use a 
computer, then Ring is predefined by the programmer and if you don't 
like it you have to use another name for what you like to be called 
"Ring". As long as the contexts never meet there is no problem with two 
different "Ring"s. But how can one map this into a CAS?

In Axiom/Aldor you cannot have both, because

Ring: Category == with { -- ring with identity }
Ring: Category == with { -- ring withoug identity }

are both of the same type (Category) and one cannot have two constants 
with the same name and type and different values.

But maybe all identifiers within the library should come with a uniqe 
prefix (for example, "Abc" and one would have an additional macro file 
that provides the standard names. So one would for example provide

macro Ring == AbcRing;
macro Rng  == AbcRng;

as standard and if a user is not happy with this naming scheme, s/he can 
simple modify the macro and all is fine.

\start
Date: Thu, 27 Jul 2006 12:37:29 +0200
From: Ralf Hemmecke
To: Antoine Hersen
Subject: Re: sbcl and Axiom

>     Axiom does not use threads or multiple processors but this is
>     clearly the future direction of hardware. We need to find algorithms
>     that can be done in parallel and work up an example that gives linear
>     speedups based on the number of processors. 
> 
> 
> You need very good language support to make this practicable.
> Also parallel algorithm tend to be significantly more complicated.

http://www.aldor.org/projects.html#compiler

Don't forget to look into Pi^it

http://www.inf.ethz.ch/personal/mannhart/publications/issac98posterabstract/index.html
http://www.inf.ethz.ch/personal/mannhart/piit/index.html

and ParAldor

http://www.ph.ed.ac.uk/~bj/paraldor/WWW/

\start
Date: Thu, 27 Jul 2006 12:43:30 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: Poster at Mathinfo 06

> A polynomial really is a polynomial.

Another difference between mathematics and computational mathematics...
If polynomials where just polynomials why then was there some clever guy 
who thought about implementing recursive and distributed multivariate 
polynomials? When it comes to efficiency, the datastructure matters.

\start
Date: Thu, 27 Jul 2006 08:21:03 -0400
From: Tim Daly
To: Christian Aistleitner
Subject: Re: [Aldor-l] Re:  exports and constants

> I agree, .asy or Foam is better than C or LISP, for what you are  
> considering. But Ralf considered looking into the compiler sources. The  
> discussion has now drifted towards "I do not need the sources; I simply  
> compile to <some Language> and get the required information by mysolf".  
> Thereby, I guess you are barking up the wrong tree.

I might mention that the lisp output would be significantly easier
to parse and maintain. Language manipulation and transformation is
the easiest thing to do in lisp (due to the fact that data and
program have the same syntax). Lisp's READ function is straightforward.
You could cover the reader with a complete Aldor package that could
extract any known piece of information on request (e.g. fetchSignatures).
Thus creating a complete reflection API only involves knowing the 
structure of the data in the output file.

\start
Date: Thu, 27 Jul 2006 15:10:13 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re:  exports and constants
Cc: Christian Aistleitner

> I might mention that the lisp output would be significantly easier
> to parse and maintain.

Are you saying that aldor should not be translated to C or Fortran or 
whatever other target there will be in the future?

I have no access to the LISP output at runtime of my program.

 > Language manipulation and transformation is
> the easiest thing to do in lisp (due to the fact that data and
> program have the same syntax). Lisp's READ function is straightforward.
> You could cover the reader with a complete Aldor package that could
> extract any known piece of information on request (e.g. fetchSignatures).
> Thus creating a complete reflection API only involves knowing the 
> structure of the data in the output file.

So what does that mean? If I want to use reflection for domains defined 
in libaldor. I would expect that

#include "aldor"
#include "aldorio"
import from Reflection;
l: List String := exports(PrimitiveType);
stdout << l << newline;

just prints something like

list(=, ~=);

How do you think that program would be compiled if there is some lisp 
stuff involved? Note that this is a standalone program.

\start
Date: Thu, 27 Jul 2006 09:50:51 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Ralf,

Reflection involves inspecting the internal details of a program.
A reflection domain would be able to look into other domains for details.
A reflection domain would export a set of methods like fetchSignatures.

So how would REFLECT get this information? Well, in aldor you can ask
the compiler to compile a domain and output it in several forms including
FOAM, C, and Lisp. So given a domain to reflect, the REFLECT domain could
ask the aldor compiler to recompile the domain with one of those outputs.

If the output is FOAM or C you need a parser and a grammar in order to
read the compiler output and find the signature information. You would
likely then write a call to the parser to read the C file and construct
a list of signatures to return as the result of fetchSignatures.

If the output is Lisp you don't need a grammar and the parser is a
simple aldor program to read list objects. Constructing a list of
signatures to return as the result of fetchSignatures is thus a much
easier task.

The difference between reading C and reading Lisp is enormous. Reading
C involves a grammar/parser; reading Lisp is an introductory computer
science homework exercise.

\start
Date: Thu, 27 Jul 2006 10:05:10 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re:  exports and constants
Cc: Christian Aistleitner

On Thursday, July 27, 2006 9:10 AM Ralf Hemmecke wrote:
> Tim Daly wrote:
> > I might mention that the lisp output would be significantly
> > easier to parse and maintain.
>
> Are you saying that aldor should not be translated to C or
> Fortran or whatever other target there will be in the future?
>
> I have no access to the LISP output at runtime of my program.
>

I think Tim is fixated on Lisp. I do not see any relevance
of Lisp to the subject of reflection in Aldor.

> > Language manipulation and transformation is the easiest
> > thing to do in lisp (due to the fact that data and
> > program have the same syntax). Lisp's READ function is
> > straightforward. You could cover the reader with a complete
> > Aldor package that could extract any known piece of
> > information on request (e.g. fetchSignatures). Thus
> > creating a complete reflection API only involves knowing
> > the structure of the data in the output file.

One would not need to resort to such low-level tactics
if reflection was designed into Adlor at the proper level.

>
> So what does that mean? If I want to use reflection for
> domains defined in libaldor. I would expect that
>
> #include "aldor"
> #include "aldorio"
> import from Reflection;
> l: List String := exports(PrimitiveType);
> stdout << l << newline;
>
> just prints something like
>
> list(=, ~=);
>

This example is a good one but I object to the use of
String as a representation for the output of Reflection
operators. In Aldor we can do much better than that. A
function like export should probably look something like
this:

  exports: Domain -> Generator Category

Yesterday I gave this example:

-----------
MyDom: with
  exports:Generator Category
  add2:(MyDom,MyDom) -> MyDom
  sub2:(MyDom,MyDom) -> MyDom
  neg: MyDom -> MyDom
 == add
  import from Integer
  Rep == Integer

  exports:Generator Category == generate
    yield with {add2:(MyDom,MyDom)->MyDom}
    yield with {sub2:(MyDom,MyDom)->MyDom}
    yield with {neg:MyDom->MyDom}

  add2(x:%,y:%):% == per(rep(x) + rep(y))
  sub2(x:%,y:%):% == per(rep(x) - rep(y))
  neg(x:%):% == per(-rep(x))

----------

Use like this:

  for s in exports$MyDom repeat
    if MyDom2 has s then
      ...
      etc

> How do you think that program would be compiled if there
> is some lisp stuff involved? Note that this is a standalone
> program.
>

Lisp is irrelevant to this. For that matter as Christian
Aistleitner pointed out in a recent email, so are the
actual internal details of Aldor such as FOAM, the contents
of the .asy and .ao files.

\start
Date: Thu, 27 Jul 2006 10:22:08 -0400
From: Bill Page
To: Tim Daly
Subject: Re:  exports and constants
Cc: Christian Aistleitner

On Thursday, July 27, 2006 9:51 AM Tim Daly wrote:
>
> Reflection involves inspecting the internal details of a
> program. A reflection domain would be able to look into other
> domains for details. A reflection domain would export a set
> of methods like fetchSignatures.
>
> So how would REFLECT get this information? ...

Well obviously the compiler has this information when it
compiles the program but it throws most of it away after the
compile is done. Since in Aldor types are first order objects
it is not necessary for the compiler to do this. All of the
data generated during the compile could in principle be
present and available as constants to the routine itself
and to other functions.

When I wrote:

-----------
MyDom: with
  exports:Generator Category
  add2:(MyDom,MyDom) -> MyDom
  sub2:(MyDom,MyDom) -> MyDom
  neg: MyDom -> MyDom
 == add
  import from Integer
  Rep == Integer

  exports:Generator Category == generate
    yield with {add2:(MyDom,MyDom)->MyDom}
    yield with {sub2:(MyDom,MyDom)->MyDom}
    yield with {neg:MyDom->MyDom}

...

the constant 'exports' contains a representation of this
routine's actual exports (minus the 'exports' constant it
self since that would lead to infinite recursion). As Aldor
exists right now - and apparently explicitly by the intention
of the language designers as implied in section 7.1 of the
Aldor Users Guide - it is necessary to add the "reflection"
information manually to the code. But of course the compiler
could very easily automatically generate these reflective
type constants.

One very simple thing that one could do without modifying the
Aldor compiler itself would be to use a simple source text
preprocessor to modify the Aldor source code a little before
compilation to insert this extra reflection information.

\start
Date: Thu, 27 Jul 2006 10:15:48 -0400
From: Tim Daly
To: Bill Page
Subject: Re:  exports and constants
Cc: Christian Aistleitner

> I think Tim is fixated on Lisp. I do not see any relevance
> of Lisp to the subject of reflection in Aldor.
> 
> Lisp is irrelevant to this. For that matter as Christian
> Aistleitner pointed out in a recent email, so are the
> actual internal details of Aldor such as FOAM, the contents
> of the .asy and .ao files.

I've proposed mechanism, you've proposed policy.
We're talking about two different things.

How will you implement your policy?
I understand what you want but not how you plan to achieve it.

\start
Date: Thu, 27 Jul 2006 16:40:53 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re:  exports and constants
Cc: Christian Aistleitner

On 07/27/2006 03:50 PM, root wrote:
 > Ralf,
 >
 > Reflection involves inspecting the internal details of a program.
 > A reflection domain would be able to look into other domains for details.
 > A reflection domain would export a set of methods like fetchSignatures.
 >
 > So how would REFLECT get this information?

Let me give you a part of the Trace package...

Trace: with {
	name: Type -> String;
	shortName: Type -> String;
} == add {
	-- from gf_rtime.
	macro DbgTypes == 'assign,entry,exit,dominit';
	macro I == MachineInteger;

	name(T:Type):String == { import from Boolean; name(T, false); }
	shortName(T:Type):String== {import from Boolean; name(T, true);}

	-- horrible hack to get the type name,
	-- at least this avoids linking with langx.as from axllib!
	macro DN == Record(tag:I, p:Pointer);
	local name(T:Type, abbr?:Boolean):String == {
		macro DV == Record(tag:I, namer:Type -> DN);
		macro Dom == Record(dispatcher:DV, domainRep:Type);
		import from DV, Dom;
		dom := T pretend Dom;
		dn := (dom.dispatcher.namer) (dom.domainRep);
		name(dn, abbr?);
	}

	local name(dn:DN, abbr?:Boolean):String == {
		import from List DN;
		dn.tag = 0 => string(dn.p);
		dn.tag = 1 => {
			ldn := (dn.p) pretend List DN;
			assert(~empty? ldn);
			s := string(first(ldn).p) + "(";
			empty?(ldn := rest ldn) => s + ")";
			t := { abbr? => "*"; name(first ldn, abbr?) };
			s := s + t;
			while ~empty?(ldn := rest ldn) repeat {
				s := s + ",";
				t := { abbr? => "*"; name(first ldn, abbr?) };
				s := s + t;
			}
			s + ")";
		}
		empty;
	}
}

The code says it itself... "horrible hack to get the type name".

This code is part of libaldor. And it should NOT be. It should belong to 
the runtime environment since whenever the compiler changes the 
representation of domains, the above code will most likely fail.

But suppose something like that would be runtime support.

Then I can simply write

   (name$Trace)(Character)

and get the String "Character" as a result.

\start
Date: Thu, 27 Jul 2006 17:25:44 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re:  exports and constants
Cc: Christian Aistleitner

>> #include "aldor"
>> #include "aldorio"
>> import from Reflection;
>> l: List String := exports(PrimitiveType);
>> stdout << l << newline;
>>
>> just prints something like
>>
>> list(=, ~=);
>>
> 
> This example is a good one but I object to the use of
> String as a representation for the output of Reflection
> operators.

Of course. But if you want to print out thinks you must be able to 
convert to something that you can put onto a screen. It was just a 
simple example, after all.

> In Aldor we can do much better than that. A
> function like export should probably look something like
> this:

>   exports: Domain -> Generator Category
> 
> Yesterday I gave this example:
> 
> -----------
> MyDom: with
>   exports:Generator Category
>   add2:(MyDom,MyDom) -> MyDom
>   sub2:(MyDom,MyDom) -> MyDom
>   neg: MyDom -> MyDom
>  == add
>   import from Integer
>   Rep == Integer
> 
>   exports:Generator Category == generate
>     yield with {add2:(MyDom,MyDom)->MyDom}
>     yield with {sub2:(MyDom,MyDom)->MyDom}
>     yield with {neg:MyDom->MyDom}
> 
>   add2(x:%,y:%):% == per(rep(x) + rep(y))
>   sub2(x:%,y:%):% == per(rep(x) - rep(y))
>   neg(x:%):% == per(-rep(x))

I liked your code, but in fact that does not use reflection at all and
I think it should even compile. You are not doing anything fancy.

BUT, in the "add" you list the exports explicitly. Note that it would be 
better if you just say

for s in exports(Mydomain) repeat ...

where exports would have type

   Type -> Generator Category

and would be implemented in a runtime support library.

\start
Date: Thu, 27 Jul 2006 17:28:47 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re:  exports and constants
Cc: Christian Aistleitner

>   with { s for s in describe$MyDom where MyDom2 has s }

I would be amazed if this is working some day.
Since everything in Aldor is first class, it should already work. ;-)

\start
Date: Thu, 27 Jul 2006 08:37:07 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke, Tim Daly
Subject: Aldor translations
Cc: Christian Aistleitner

--- Ralf Hemmecke wrote:

> > I might mention that the lisp output would be significantly easier
> > to parse and maintain.
> 
> Are you saying that aldor should not be translated to C or Fortran
> or whatever other target there will be in the future?

A point which is probably orthogonal to this discussion but is
something to consider is why we would want to target Aldor towards
something other than lisp, in the first place.

Axiom's core is currently based on Lisp, and I personally think this is
a Good Thing.  If we output Aldor to something other than Lisp, we face
the problem of communicating between the main Lisp environment and
whatever happens to the non-Lisp code Aldor has exported.  To me, this
seems to invite a world of compatibility issues, cross-platform
problems, FFI issues, etc.  Aren't we better off using other libraries
which have been developed specifically to solve numerical problems
quickly, and gradually working on optimizing our Lisp code?

Am I missing something?

\start
Date: Thu, 27 Jul 2006 12:26:09 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Ralf,

On Thursday, July 27, 2006 11:26 AM you wrote:
> > ...
> > This example is a good one but I object to the use of
> > String as a representation for the output of Reflection
> > operators.
>
> Of course. But if you want to print out things you must be
> able to convert to something that you can put onto a screen.

Yes you are right. In Axiom such output is a matter resolved
by providing (almost) every domain with a coercion function
to the OutputForm domain. Since in Axiom lisp underlies
everything, providing such a coercion is relatively easy.
In Aldor as a stand alone high level language I am not sure
exactly what the best solution is. Does it really make sense
that such a high level language should care about the name
that a particular programmer assigned to one of it's objects?
Maybe this behavior (of associating an actual name string
with an object) should be controlled by a debugging option
on the compiler the way the rest of the Trace system works.

> It was just a simple example, after all.

Understood.

>
> > In Aldor we can do much better than that. A function like
> > export should probably look something like this:
>
> >   exports: Domain -> Generator Category
> >
> > Yesterday I gave this example:
> >
> > -----------
> > MyDom: with
> >   exports:Generator Category
> >   add2:(MyDom,MyDom) -> MyDom
> >   sub2:(MyDom,MyDom) -> MyDom
> >   neg: MyDom -> MyDom
> >  == add
> >   import from Integer
> >   Rep == Integer
> >
> >   exports:Generator Category == generate
> >     yield with {add2:(MyDom,MyDom)->MyDom}
> >     yield with {sub2:(MyDom,MyDom)->MyDom}
> >     yield with {neg:MyDom->MyDom}
> >
> >   add2(x:%,y:%):% == per(rep(x) + rep(y))
> >   sub2(x:%,y:%):% == per(rep(x) - rep(y))
> >   neg(x:%):% == per(-rep(x))
>
> I liked your code, but in fact that does not use reflection
> at all and I think it should even compile. You are not doing
> anything fancy.

Why do you say that this does not use reflection? I suppose,
that as in the Aldor Users Guide this is better called
"self-identification", but really it seems to me that these
are the same things.

I agree that this is nothing "fancy". Actually, reflection is
not really such a "fancy" concept at all, its just that we have
got used to not having access to this sort of information in
non lisp-based programming without first-order types.

Yes, I agree that this should compile now. Obviously Aldor
does try to compile it but it fails for some obscure reason.
Here is the output:

> cat self2.as
--- BEGIN: self2.as
#include "aldor"
#include "aldorio"

#pile

MyDom: with
  exports: Generator Category
  add2:(MyDom,MyDom) -> MyDom
  sub2:(MyDom,MyDom) -> MyDom
  neg: MyDom -> MyDom
 == add
  import from Integer
  Rep == Integer

  exports:Generator Category == generate
    yield with {add2:(MyDom,MyDom)->MyDom}
    yield with {sub2:(MyDom,MyDom)->MyDom}
    yield with {neg:MyDom->MyDom}

  add2(x:%,y:%):% == per(rep(x) + rep(y))
  sub2(x:%,y:%):% == per(rep(x) - rep(y))
  neg(x:%):% == per(-rep(x))

-- I think this should compile but it doesn't. :(
--for sig in exports$MyDom repeat
--   stdout << (Integer has sig) << newline;
---END self2.as

> aldor -grun -laldor self2.as
"self2.as", line 17:     yield with {add2:(MyDom,MyDom)->MyDom}
                     ....^
[L17 C5] #1 (Fatal Error) Compiler bug: no exit list for terrorSequence
(ooops).

------------

I guess this means I should submit a bug report ... but until
Aldor is open source or we find some other way to deal with it
I am not too strongly motivated. Given the urgency (to us at
least!) of resolving the issue of the open source status of
Aldor, I am disappointed not to hear anything yet from Steven
Watt or Mike Dewar as Mike did state directly in an email to
me that they intended to discuss it during the recent meetings
in Europe... :( I am again impatient and thinking about drastic
alternatives.

Perhaps I will just create an issue report in the Axiom Wiki
issue tracker anyway at least to document it. Do you think it
is reasonable to assume that the Aldor developers (are there
really any?) are subscribed to the axiom-developer email list
and will receive such reports? Or is the proper procedure to
forward it specifically to aldor-l?

This same program using a List data structure instead of a
Generator compiles (almost):

> cat self1.as
--- BEGIN: self1.as
#include "aldor"
#include "aldorio"

#pile

MyDom: with
  exports:List Category
  add2:(MyDom,MyDom) -> MyDom
  sub2:(MyDom,MyDom) -> MyDom
  neg: MyDom -> MyDom
 == add
  import from Integer
  Rep == Integer

  exports:List Category ==
    [with {add2:(MyDom,MyDom)->MyDom},
     with {sub2:(MyDom,MyDom)->MyDom},
     with {neg:MyDom->MyDom}]

  add2(x:%,y:%):% == per(rep(x) + rep(y))
  sub2(x:%,y:%):% == per(rep(x) - rep(y))
  neg(x:%):% == per(-rep(x))

--This should work but doesn't
--for sig in exports$MyDom repeat
--   stdout << (Integer has sig) << newline;
---END self1.as

> aldor -grun -laldor self1.as
cc1: note: -fwritable-strings is deprecated; see documentation for
details
cc1: note: -fwritable-strings is deprecated; see documentation for
details

---------

Except that I can not seem to get the "has" expression to
work the way I expected it to. Maybe this is another bug?

Any ideas?

Note: This warning referring to the "-fwritable-strings" option
used by Aldor means that Aldor can not be used with newer versions
of gcc (starting with 4.x) since modifiable string constants are
no longer supported. This is one more example of something that
could probably be easily and quickly resolved if Aldor was open
source.

>
> BUT, in the "add" you list the exports explicitly. Note that
> it would be better if you just say
>
> for s in exports(Mydomain) repeat ...
>
> where exports would have type
>
>    Type -> Generator Category
>
> and would be implemented in a runtime support library.
>

But that would require that something somewhere actually store
the self-identifying information at run-time. Aldor avoids this
by explicit design (not withstanding that we have also been
talking about ways of getting around this design decision :).

Apparently (by reading "between" the lines in section 7.1 of
the AUG, see the quote in my email of yesterday) the designers
of Aldor intended that self-identifying information be explicitly
added by the programmer where it is needed.

I do not see any advantage of the syntax

> for s in exports(Mydomain) repeat ...

over my

  for s in exports$Mydomain repeat ...

which does not involve any explicit external function call.

\start
Date: 27 Jul 2006 18:37:59 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Ralf Hemmecke writes:

| > I might mention that the lisp output would be significantly easier
| > to parse and maintain.
| 
| Are you saying that aldor should not be translated to C or Fortran or
| whatever other target there will be in the future?

I'm not sure that is what is implied.

I share Tim's view that if this stuff has to be done not directly
within the compiler but by translating to an intermediate language,
then I think Lisp is a better choice.  However, I would see the
interface to be typed.  That does not preclude the use of Lisp as an
intermediate representation.

| I have no access to the LISP output at runtime of my program.

I suspect part of the suggestion is to have Aldor use Lisp as an
intermediate representation language.  Ideally, I would prefer to see
a Lisp-like language but with a more expressive type system.

\start
Date: 27 Jul 2006 18:41:31 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Bill Page writes:

| On Thursday, July 27, 2006 9:51 AM Tim Daly wrote:
| > 
| > Reflection involves inspecting the internal details of a
| > program. A reflection domain would be able to look into other
| > domains for details. A reflection domain would export a set
| > of methods like fetchSignatures.
| > 
| > So how would REFLECT get this information? ...
| 
| Well obviously the compiler has this information when it
| compiles the program but it throws most of it away after the
| compile is done.

Yes.

But, we should aim for an information-preserving compiler.  That
will be good not only for reflection, but also for debug purposes for
example.

\start
Date: 27 Jul 2006 18:44:27 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Bill Page writes:

| I do not see any relevance of Lisp to the subject of reflection in Aldor.

I suspect it comes from implementation experience.  Basically, it
boils down to manipulating things symbolically and Lisp is very good
at that.  Other languages can be used, but they are going to mimic
Lisp.

Unless, you have a way to implement this directly in the compiler.
See Template Haskell (in GHC sources) for the kind of thing that is
done. 

\start
Date: Thu, 27 Jul 2006 12:55:02 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re:  exports and constants
Cc: Christian Aistleitner

On July 27, 2006 12:44 PM Gaby wrote:

> ... Basically, it boils down to manipulating things
> symbolically and Lisp is very good at that.

I do not see that reflection has anything specifically
to do with symbolic manipulation.

> Other languages can be used, but they are going to
> mimic Lisp.

Well, yeeaasss ... to the extent that they support first
order types. I admit that it is easy to to this kind of
thing in Lisp in a less structured way - at least it used
to be in versions of lisp before types in lisp became
popular. I don't know enough about types in modern lisp
to know how this would work now in compiled lisp programs.

>
> Unless, you have a way to implement this directly in
> the compiler. See Template Haskell (in GHC sources) for
> the kind of thing that is done.
>

It is very very easy for the compiler to generate self-
identifying type constants either all the time or as a
compile-time option. This can even been done in a simple
pre-compilation step if necessary.

\start
Date: Thu, 27 Jul 2006 19:13:03 +0200
From: Antoine Hersen
To: Cliff Yapp
Subject: Re: Aldor translations
Cc: Christian Aistleitner

> > > I might mention that the lisp output would be significantly easier
> > > to parse and maintain.
> >
> > Are you saying that aldor should not be translated to C or Fortran
> > or whatever other target there will be in the future?
>
> A point which is probably orthogonal to this discussion but is
> something to consider is why we would want to target Aldor towards
> something other than lisp, in the first place.
>
> Axiom's core is currently based on Lisp, and I personally think this is
> a Good Thing.  If we output Aldor to something other than Lisp, we face
> the problem of communicating between the main Lisp environment and
> whatever happens to the non-Lisp code Aldor has exported.  To me, this
> seems to invite a world of compatibility issues, cross-platform
> problems, FFI issues, etc.  Aren't we better off using other libraries
> which have been developed specifically to solve numerical problems
> quickly, and gradually working on optimizing our Lisp code?
>
> Am I missing something?


Exporting to C is a good think, if Aldor can create library in C other
program could use it easily. I am not sure if maintaining a Fortran back end
is still relevant.

I do not see has a problem not to be able to mix C Aldor and Lisp Aldor.

And FFI functionality should be back end independent. For example I should
be able to use GMP in all cases.

\start
Date: Thu, 27 Jul 2006 13:11:27 -0400
From: Tim Daly
To: Antoine Hersen
Subject: Re: Aldor translations
Cc: Christian Aistleitner

wow, we've really wandered off the question. i thought we were discussing
the question of how to implement a reflection domain that could figure out
things about domains. --t

\start
Date: Thu, 27 Jul 2006 13:26:10 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Aldor translations
Cc: Christian Aistleitner

On July 27, 2006 11:37 AM C Y wrote:
>
> Axiom's core is currently based on Lisp, and I personally
> think this is a Good Thing.

I agree. I do not see any reason to want to replace the
current run-time environment of Axiom with anything else.
Axiom's algebra library depends strongly on the
S-expressions and other lisp data structures plus a
large number of operations that are provided very
naturally by Lisp, e.g. infinite precision Integers.

> If we output Aldor to something other than Lisp,

You mean if we use a different run-time environment?

When used inside Axiom (and as an option when running
stand alone) Aldor does generate Lisp as the intermediate
"object" code. In Axiom this is essential in order to
integrate with the rest of the Axiom library and the
interpreter. But even in Axiom the intermediate Lisp
code is subsequently converted to C and compiled into
actual machine object files.

When Aldor is run stand alone, one can opt to generate
C code directly for a much reduced "lisp-like" run-time
environment also written in C. It is (more or less) just
like a cut down mini-version of Lisp. In the distant
future it is conceivable that Axiom could be based on
this reduced C-based run-time environment rather than a
full Lisp. But personally I do not see many advantages to
attempting to do this other than the goal of overall
simplicity.

> ...
> Am I missing something?
>

Perhaps you are assuming something that is not the case?
:)

\start
Date: Thu, 27 Jul 2006 10:36:55 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Antoine Hersen
Subject: Re: Aldor translations
Cc: Christian Aistleitner

Sorry, my bad - I should have started a new thread.

--- Tim Daly wrote:

> wow, we've really wandered off the question. i thought we were
> discussing
> the question of how to implement a reflection domain that could
> figure out
> things about domains. --t

\start
Date: 27 Jul 2006 19:39:46 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Bill Page writes:

[...]

| > Unless, you have a way to implement this directly in
| > the compiler. See Template Haskell (in GHC sources) for
| > the kind of thing that is done. 
| > 
| 
| It is very very easy for the compiler to generate self-
| identifying type constants either all the time or as a
| compile-time option. This can even been done in a simple
| pre-compilation step if necessary.

Either we have a very different view of what "Reflection" is, or we
have a very different experience in the use and implementations of
that suff :-)  I don't find Template Haskell implementation "very very
very easy". Here is an overview of Template Haskell

    http://research.microsoft.com/~simonpj/Papers/meta-haskell/index.htm
    http://www.haskell.org/th/#papers

\start
Date: Thu, 27 Jul 2006 13:53:25 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Gaby,

On Thursday, July 27, 2006 1:40 PM you wrote:

> ...
> Bill Page writes:
> 
> | It is very very easy for the compiler to generate self-
> | identifying type constants either all the time or as a
> | compile-time option. This can even been done in a simple
> | pre-compilation step if necessary.
>
> Either we have a very different view of what "Reflection"
> is, or we have a very different experience in the use and
> implementations of that suff :-)

That is quite possible. Care to give a couple of simple
examples we can continue to discuss?

> I don't find Template Haskell implementation "very very
> very easy". Here is an overview of Template Haskell
>    
> http://research.microsoft.com/~simonpj/Papers/meta-haskell/index.htm
>     http://www.haskell.org/th/#papers
>

I have read some of these papers (you've referred to them
before) and I am inclined to agree. I have not actually tried
to code in Template Haskell yet, but do not find this extension
of Haskell particularly "comfortable" yet. It's true isn't it
that some of the goals of meta-programming go beyond what one
would normally associate with language features that support
reflect?

Perhaps the difference between Template Haskell and what seems
easy in Aldor (at least with respect to self-identification and
reflection) has to do with significant differences in the
underlying type system. Aldor is set apart from Haskell for
historical reasons. Perhaps Aldor has more in common with ML?
I guess also need to find some time to look at MetaOCaml.

\start
Date: 27 Jul 2006 20:37:01 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Bill Page writes:

| Gaby, 
| 
| On Thursday, July 27, 2006 1:40 PM you wrote:
| 
| > ...
| > Bill Page writes:
| >  
| > | It is very very easy for the compiler to generate self-
| > | identifying type constants either all the time or as a
| > | compile-time option. This can even been done in a simple
| > | pre-compilation step if necessary.
| > 
| > Either we have a very different view of what "Reflection"
| > is, or we have a very different experience in the use and
| > implementations of that suff :-)
| 
| That is quite possible. Care to give a couple of simple
| examples we can continue to discuss?

Well, first it is you make the claims that it is "very very easy" to
implement; I would say the burden of proof is upon you :-)

However, my starting example is getting right the Figure 1 of the
Template-Haskell paper.  Can you provide a proof-of-concept as to why
it is very very easy to do?

| > I don't find Template Haskell implementation "very very
| > very easy". Here is an overview of Template Haskell 
| >     
| > http://research.microsoft.com/~simonpj/Papers/meta-haskell/index.htm
| >     http://www.haskell.org/th/#papers
| > 
| 
| I have read some of these papers (you've referred to them
| before) and I am inclined to agree. I have not actually tried
| to code in Template Haskell yet, but do not find this extension
| of Haskell particularly "comfortable" yet. It's true isn't it
| that some of the goals of meta-programming go beyond what one
| would normally associate with language features that support
| reflect?

full-fledged meta-programming yes -- and Template Haskell is not there
yet.  But by "reflection" I imply the bare minimum currently provided
by Template Haskell for example. 

| Perhaps the difference between Template Haskell and what seems
| easy in Aldor (at least with respect to self-identification and
| reflection) has to do with significant differences in the
| underlying type system.

I'm not so sure.  Aldor's type system appears to me to be far more
complicated and intricate than that of Haskell.  Both share a good
deal of functional core, though.

|  Aldor is set apart from Haskell for
| historical reasons. Perhaps Aldor has more in common with ML?
| 

Hmm, in what aspects?

\start
Date: Thu, 27 Jul 2006 20:18:01 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re:  exports and constants
Cc: Christian Aistleitner

> Of course. But if you want to print out things you must be
>> able to convert to something that you can put onto a screen.
> 
> Yes you are right. In Axiom such output is a matter resolved
> by providing (almost) every domain with a coercion function
> to the OutputForm domain. Since in Axiom lisp underlies
> everything, providing such a coercion is relatively easy.
> In Aldor as a stand alone high level language I am not sure
> exactly what the best solution is. Does it really make sense
> that such a high level language should care about the name
> that a particular programmer assigned to one of it's objects?

As I said before I don't aim at an implementation of reflections as a 
tool for the general user. I only want to have reflections for a few 
exceptional cases like AldorUnit or perhaps a debugger that is written 
in Aldor. Both would need a way to print the name of a function.
(In general, of course the name is irrelevant. That is why I don't want 
reflections.)

>>> MyDom: with
>>>   exports:Generator Category
>>>   add2:(MyDom,MyDom) -> MyDom
>>>   sub2:(MyDom,MyDom) -> MyDom
>>>   neg: MyDom -> MyDom
>>>  == add
>>>   import from Integer
>>>   Rep == Integer
>>>
>>>   exports:Generator Category == generate
>>>     yield with {add2:(MyDom,MyDom)->MyDom}
>>>     yield with {sub2:(MyDom,MyDom)->MyDom}
>>>     yield with {neg:MyDom->MyDom}
>>>
>>>   add2(x:%,y:%):% == per(rep(x) + rep(y))
>>>   sub2(x:%,y:%):% == per(rep(x) - rep(y))
>>>   neg(x:%):% == per(-rep(x))
>> I liked your code, but in fact that does not use reflection
>> at all and I think it should even compile. You are not doing
>> anything fancy.
> 
> Why do you say that this does not use reflection?

Because you give the "exports" constant explicitly. Suppose you later say

extend MyDom: with {foo:()->()} == add {foo(): () == {}}

Then exports$MyDom does not reflect the true exports since "foo" would 
be missing.

You don't relect about "MyDom" you just give an explicit constant.

> I agree that this is nothing "fancy". Actually, reflection is
> not really such a "fancy" concept at all, its just that we have
> got used to not having access to this sort of information in
> non lisp-based programming without first-order types.

Right, I am not used to reflection. Is there a collection of nice 
examples where reflection is a "must have"? I can only think about 
AldorUnit, a debugger and a way to ask a library which functionality it 
provides.

> Yes, I agree that this should compile now. Obviously Aldor
> does try to compile it but it fails for some obscure reason.

>> aldor -grun -laldor self2.as
> "self2.as", line 17:     yield with {add2:(MyDom,MyDom)->MyDom}
>                      ....^
> [L17 C5] #1 (Fatal Error) Compiler bug: no exit list for terrorSequence
> (ooops).
> 
> ------------
> 
> I guess this means I should submit a bug report ... but until
> Aldor is open source or we find some other way to deal with it
> I am not too strongly motivated.

I have the suspicion if you wrap the "with {..}" stuff with a Record, it 
might help. But it's a bug anyway.

 > Given the urgency (to us at
> least!) of resolving the issue of the open source status of
> Aldor, I am disappointed not to hear anything yet from Steven
> Watt or Mike Dewar as Mike did state directly in an email to
> me that they intended to discuss it during the recent meetings
> in Europe... :( I am again impatient and thinking about drastic
> alternatives.

I can assure you that Stephen and Mike discussed the issue when they 
where both in Dagstuhl. And Tim and me met Stephen in Sophia-Antipolis 
at the Bronstein conference. Stephen told me that he wants to sort out 
the license issue until the end of August. It would of course be best to 
have Aldor free before the beginning of the next semester.

\start
Date: Thu, 27 Jul 2006 20:49:41 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: non-reflection
Cc: Christian Aistleitner

Hello Bill,

> This same program using a List data structure instead of a
> Generator compiles (almost):

I have shortened your program a bit. So now it is no longer about 
reflections.

--- BEGIN: aaa13.as
#include "aldor"
#include "aldorio"

exports: List Category == [
     with {+:(%, %) -> %},
     with {foo:(%, %) -> %},
     with {-: % -> %}
];

default sig: Category;
for sig in exports repeat {
	cat: Category == sig;
	stdout << (Integer has cat) << newline;
}
---END aaa13.as

That compiles and runs, but the output is not as you would expect given 
the fact that Integer surely as such an addition.

 >aldor -grun -laldor aaa13.as
F
F
F

And it even does not help if you say

    define cat: Category == with sig;

Note however, that I define (and redefine a constant inside the loop 
body. Using == inside loop bodies has once been told to me by an Aldor 
developer from NAG, but I am not sure that I understand what the scope 
of cat is.

You can add a line

stdout << (SingleFloat has cat) << newline;

after the for loop. And this gives just another F as output.

\start
Date: 27 Jul 2006 20:59:07 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re:  exports and constants
Cc: Christian Aistleitner

Ralf Hemmecke writes:

[...]

| > I agree that this is nothing "fancy". Actually, reflection is
| > not really such a "fancy" concept at all, its just that we have
| > got used to not having access to this sort of information in
| > non lisp-based programming without first-order types.
| 
| Right, I am not used to reflection. Is there a collection of nice
| examples where reflection is a "must have"? 


It is hard to argue for "must have", because the only thing we need is
a binary file editor :-)

However, the way I see reflection uses in my own work is not too far
from the examples discussed in the papers

  *  Unrolling and Simplifying Expressions with Template Haskell, by
     Ian Lynagh, May 2003.

  *  Automatic skeletons in Template Haskell, by Kevin Hammond, Jost
     Berthold and Rita Loogen, June 2003.

  *  Optimising Embedded DSLs using Template Haskell, by Sean
     Seefried, Manuel Chakravarty, Gabriele Keller, March 2004.

at

   http://www.haskell.org/th/#papers


Jacques Carette also has excellent discussions in connection with
Gaussian elimination.

\start
Date: Thu, 27 Jul 2006 23:59:35 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re:  exports and constants
Cc: Christian Aistleitner

> | Right, I am not used to reflection. Is there a collection of nice
> | examples where reflection is a "must have"? 

> It is hard to argue for "must have", because the only thing we need is
> a binary file editor :-)
> 
> However, the way I see reflection uses in my own work is not too far
> from the examples discussed in the papers
> 
>   *  Unrolling and Simplifying Expressions with Template Haskell, by
>      Ian Lynagh, May 2003.
> 
>   *  Automatic skeletons in Template Haskell, by Kevin Hammond, Jost
>      Berthold and Rita Loogen, June 2003.
> 
>   *  Optimising Embedded DSLs using Template Haskell, by Sean
>      Seefried, Manuel Chakravarty, Gabriele Keller, March 2004.

Would it be possible to give a few lines of explanation. What interests 
me most is: what would I gain if I had reflections in Aldor? Would that 
make my programming easier/more convenient. Or would it add more power 
to Aldor? I have not yet read those papers, but to me it looks very much 
like reflections are useful for optimizing code that I have written.

A simple short overview of the situation is very much appreciated.

\start
Date: Wed, 26 Jul 2006 19:28:17 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: Front page esthetic

Bill Page wrote:
> The reason this is being rejected is also do to another anti-spam
> change to the Axiom Wiki system. A few weeks ago based on Bob
> McElrath's suggestion a configured a feature of ZWiki that we had
> not been previously using that provides for direct content filtering
> of posted text. The idea is that it is possible to maintain a list
> of words and links which are extremely unlikely to be part of any
> valid post to the web site. I did this in response to about two or
> three nasty spam emails that were getting through each day. But
> these guys are devious and it turns out this requires rather
> constant attention to make it keep working to filter out the bad
> stuff. This is all based on simple regular expression pattern
> matching. Nothing fancy.

Do you mean the banned_links stuff?  That shouldn't care whether you use
<a href="http://xxx.com"> or "blah":http://xxx.com...

I think it just applies the regex to the incoming text before it gets
handed to structured text.

\start
Date: Thu, 27 Jul 2006 20:30:28 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: Front page esthetic

Bob,

On Wednesday, July 26, 2006 10:28 PM you asked:
>
> Bill Page wrote:
> > The reason this is being rejected is also do to another
> > anti-spam change to the Axiom Wiki system. ...
> > This is all based on simple regular expression pattern
> > matching. Nothing fancy.
>
> Do you mean the banned_links stuff?  That shouldn't care
> whether you use
> <a href="http://xxx.com"> or "blah":http://xxx.com...
>
> I think it just applies the regex to the incoming text before
> it gets handed to structured text.
>

Yes, that is right. I just got mad one night about the number
of link spam comments that Axiom Wiki was collecting and I
decided I didn't want to keep adding more and more patterns
after the fact, so I entered a banned_links pattern of

  ?:\shref\s*=\s*['"]?http://

This has the effect of killing any comment or edit that
contains something that looks like an HTML link

   ... href="http:// ...

but the StructuredText links still get through.

Maybe it is a bit harsh but I think there is no particularly
good reason to support HTML coding (at least for links) in
StructuredText/Pamphlet page types. What do you think?

\start
Date: Fri, 28 Jul 2006 08:14:05 +0200
From: Christian Aistleitner
To: Tim Daly
Subject: Re:  exports and constants

Hello,

On Thu, 27 Jul 2006 14:21:03 +0200, Tim Daly wrote:

>> I agree, .asy or Foam is better than C or LISP, for what you are
>> considering. But Ralf considered looking into the compiler sources. The
>> discussion has now drifted towards "I do not need the sources; I simply
>> compile to <some Language> and get the required information by mysolf".
>> Thereby, I guess you are barking up the wrong tree.
>
> I might mention that the lisp output would be significantly easier
> to parse and maintain.

If you pursue the "I do not need the sources; I simply compile to <some  
Language> and get the required information by myself" idea, I'd still  
think asy or Foam are better than LISP or C.

Obviously, C is worst solution, as it is hard to parse.
But asy, foam, asd LISP files are all more or less in LISP syntax. And asy  
and foam even use only a proper subset of the langauge. And the needed  
inforamiotn is presented more adequately IMHO.

You want a simple parser. I fully agree. But parsing asy or foam is  
probably even easier than parsing LISP.

\start
Date: 28 Jul 2006 08:55:44 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: Rng

unfortunately, I'm out of time currently, but:

Tim Daly writes:

> Axiom has some categories, such as RNG, which don't seem to match those of
> regular math. One question is whether this is just a design flaw or does it
> expose a new computational object that we need to examine theoretically.

No. RNG is quite standard in Algebra. I think it's even in Hungerford. I cannot
see a design flaw there.

\start
Date: Fri, 28 Jul 2006 09:13:38 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Rng

On 07/28/2006 08:55 AM, Martin Rubey wrote:
> unfortunately, I'm out of time currently, but:
> 
> Tim Daly writes:
> 
>> Axiom has some categories, such as RNG, which don't seem to match those of
>> regular math. One question is whether this is just a design flaw or does it
>> expose a new computational object that we need to examine theoretically.
> 
> No. RNG is quite standard in Algebra. I think it's even in Hungerford. 
> I cannot see a design flaw there.
> 
> Martin

So how would you implement "NaturalNumber"? Is that NNI or PI? Current 
Axiom chooses not to provide NaturalNumber at all. One always have to be 
explicit and choose NNI or PI instead. Isn't that a similar situation to 
RNG and RING? Who decides what is common and what not?

\start
Date: Fri, 28 Jul 2006 09:20:33 +0200
From: Christian Aistleitner
To: Bill Page, Ralf Hemmecke
Subject: Re:  exports and constants

Hello,

> Does it really make sense
> that such a high level language should care about the name
> that a particular programmer assigned to one of it's objects?

yes, there are lots of applications of reflection that do not involve  
debugging. So you should typically be able to get the names of things.


> #include "aldor"
> #include "aldorio"
>
> #pile
>
> MyDom: with
>   exports: Generator Category
>   add2:(MyDom,MyDom) -> MyDom
>   sub2:(MyDom,MyDom) -> MyDom
>   neg: MyDom -> MyDom
>  == add
>   import from Integer
>   Rep == Integer
>
>   exports:Generator Category == generate
>     yield with {add2:(MyDom,MyDom)->MyDom}
>     yield with {sub2:(MyDom,MyDom)->MyDom}
>     yield with {neg:MyDom->MyDom}
>
>   add2(x:%,y:%):% == per(rep(x) + rep(y))
>   sub2(x:%,y:%):% == per(rep(x) - rep(y))
>   neg(x:%):% == per(-rep(x))

Actually, I do not like your code, as this does not give you the kind of
information you would like to have with a reflection framework (e.g.:  
Using proper types for types and functions, Getting parameter types), and
will cause you lots of problems  -- but maybe I am too early thinking
about such issues. However, besides the parsing part, the extensions and
all the other issues, if it's the way you choose, let me help you gettin
it to compile and run. The following piece of code works:

#include "aldor"
#include "aldorio"

macro T == Category;
macro yieldT( expt ) == { yield ( expt@T ) }

EXPORT0: T == with {add2:(%,%)->%};
EXPORT1: T == with {sub2:(%,%)->%};
EXPORT2: T == with {neg: % -> %};

MyDom:  with {
     exports: () -> Generator T;
     EXPORT0;
     EXPORT1;
     EXPORT2;
} == add {
   import from Integer;
   Rep == Integer;


   exports(): Generator T == generate {
	yieldT EXPORT0;
	yieldT EXPORT1;
	yieldT EXPORT2;
   };

   add2(x:%,y:%):% == {
       per(rep(x) + rep(y))
   };

   sub2(x:%,y:%):% == {
       per(rep(x) - rep(y));
   };

   neg(x:%):% == {
       per(-rep(x));
   };

}

checkSign( Dom: with{}, sign: T ):Boolean == {
     Dom has sign;
}

import from MyDom;
for sign in exports() repeat
{
     stdout << ( checkSign( Integer, sign ) ) << newline;
     stdout << ( checkSign( MyDom, sign ) ) << newline;
}


Its output is:
____________________________________________
tmgisi@spencer
cwd: ~
$ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx
-lalgebra -laldor test3.as && ./test3
cc1: note: -fwritable-strings is deprecated; see documentation for details
cc1: note: -fwritable-strings is deprecated; see documentation for details
F
T
F
T
F
T


Just as expected. What did I do to get the code working?

I got rid of pile.
Piles are simply a pain to my eyes.

I turned exports into a function, as you'd probably want to call it more
than once.

You yielded anonymous categories, created just within the yield clause. 
This looked dangerous to me, so I turned them into proper definitions  
within MyDom's add part. This however gave problems when checking by has
(as the Categories where no longer anonymous), so I had to use them  
already in the with clause, and moved them to the top-level scope  
(EXPORT0, ...).

I use the macro yieldT instead of simply yield, to tell the compiler the
yielded thing really is a Category. For some of my experiments this wasn't
necessary -- for some it was.

I moved your "has" check in a separate function. It doesn't seem to work
out well, if the Cat part of "Dom has Sig" is not constant in scope.

That's it.

> Except that I can not seem to get the "has" expression to
> work the way I expected it to. Maybe this is another bug?

Your code demonstrates more than just one compiler bug ... ;)

> [ warning about "-fwritable-strings" ]
> This is one more example of something that
> could probably be easily and quickly resolved if Aldor was open
> source.

I doubt that. In May, I got a mail from one of the compiler people telling
me

I have spent the last couple of days looking into this [Remark by CA: the
"-fwritable-strings" issue] , but the whole compiler uses char * a = "abc"
(and the compiler is about 250K LOC).  In most of the places they seem to
be treated as const char *, but I still have a long way to go.

So somebody is already working on it, and I believe him, that it's not one
of those problems you fix in the 5 minutes till lunch break ;)
Nevertheless, maybe he'd get help and feedback once the compiler is freed.


> I do not see any advantage of the syntax
>
>> for s in exports(Mydomain) repeat ...
>
> over my
>
>   for s in exports$Mydomain repeat ...
>
> which does not involve any explicit external function call.

First of all (as I described in the upper part of my mail), you wouldn't
be able to get two different generators. Hence, if the generator ran out
of elements, you cannot restart it -- very nasty thing ;)

The second issue is abstraction. Even if you get the thing done your way
I'd never call exports$SomeDom directly.

Create some domain

Reflection( T: Type ): with {
	exports: () -> Generator Category
}

and use exports$(Reflection(SomeDom)). Thereby you can extend the whole 
reflection thing quite naturally, and if reflection gets built into  
compiler/runtime, you wouldn't have to change the programs relying on  
reflection, but only need to change the domain Reflection.

\start
Date: 28 Jul 2006 10:00:34 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Polynomials, abstract objects, provisos

Hi Ralf,

Ralf Hemmecke writes:

> > A polynomial really is a polynomial.
> 
> Another difference between mathematics and computational mathematics...  If
> polynomials where just polynomials why then was there some clever guy who
> thought about implementing recursive and distributed multivariate
> polynomials?  When it comes to efficiency, the datastructure matters.

There is a misunderstanding happening here. In fact, one of the strengths of
Axiom is that we have different datastructures for the same mathematical
objects!

What I meant is something entirely different: in Axiom, any object is a
"concrete" mathematical object. I think that in some sense, "assumptions" of
other CAS should be modelled in Axiom by different domains.

I think that efficiency in Axiom is to a big part due to the fact that at any
point of a computation, everything of an object is known.

I don't know how we should model "abstract polynomials", but I'm not even sure
whether we should have such a thing.

Concerning provisos, this really affects only the domain EXPR, in my opinion.

\start
Date: Fri, 28 Jul 2006 10:09:15 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: [Axiom-developer] Re: Aldor translations
Cc: Christian Aistleitner

> Axiom's core is currently based on Lisp, and I personally think this is
> a Good Thing.  If we output Aldor to something other than Lisp, we face
> the problem of communicating between the main Lisp environment and
> whatever happens to the non-Lisp code Aldor has exported.  To me, this
> seems to invite a world of compatibility issues, cross-platform
> problems, FFI issues, etc.

If Axiom is an will be based on LISP that is fine with me, but you 
should note that Aldor is an ordinary programming language. Why would 
you want to restrict its applicability. If someone just likes Aldor and 
wants to use it in his environment with maybe lots of C-libraries, what 
does that hurt Axiom?

What I want to say is that Aldor is Aldor and not LISP. Anything that 
binds Aldor more closely to Lisp as it is now, is bad. That doesn't, 
however, mean that Axiom should use something else than the LISP output 
of Aldor.

Do you think it would be a bad idea to produce a symbolic library for 
Axiom and make it available to C programmers by simply targetting C as 
the Aldor output?

\start
Date: Fri, 28 Jul 2006 10:44:22 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: Polynomials, abstract objects, provisos

[recursive vs. distributed polynomials]

> I don't know how we should model "abstract polynomials", but I'm not
> even sure whether we should have such a thing.

That would be possible, but suppose you want to do a Gr=F6bner basis
computation. Who is going to choose the most efficient data representation?

In fact, one could model that, but where should it be stored?

The GB algorithm could only make some statements about "I probably run
fastest with this and that representation", but the "abstract
polynomials" might not provide such a representation. What to do then?

Or you could store the knowledge that "for GB computations this or that
representation is best" in the "abstract polynomials". Then somebody
comes and adds a knew algorithm to the system and the "abstract
polynomials" just don't know about the appropriate representation.

I think it is totally hard to map the mathematical concept of
polynomials to just ONE "abstract polynomial" type and make the choice
of the underlying datastructure invisible.

> Concerning provisos, this really affects only the domain EXPR, in my op=
inion.

Provisos look to me like a tree of results stored in one object. But
maybe I should read Tim's thesis first.

Anyway, yesterday I spoke with Antoine Hersen about provisos.
He came up with the following simple system in Q[x,y].

x*y = b
a*x = b

With provisos, I guess we are speaking about polynomials in Q(a,b)[x,y]
where we are looking for a solution in some extension of Q depending on
the parameters a and b.

As we all know, the result of the second equation splits into 4 cases
depending on whether a and/or b is 0. And the result is best described
by the set of solutions together with the conditions.

To make it simple the type would be

(subset of Q, equations/elements in Q(a,b))

and all 4 cases live in just ONE proviso? (Maybe I missed something.)
Anyway. Now solve the first equation. Interestingly, the type would be

(subset Q(x), equations in Q(a,b,x)),

since if a=b=0 you cannot say anything about x.

The question is: What type should provisos have? See, I start with
Q(a,b)[x,y] in the beginning. How do I know that I will need Q(a,b,x) in =

the result?

\start
Date: Fri, 28 Jul 2006 03:19:03 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Aldor translations
Cc: Christian Aistleitner

--- Ralf Hemmecke wrote:

> Do you think it would be a bad idea to produce a symbolic library for
> Axiom and make it available to C programmers by simply targetting C
> as the Aldor output?

No, if it is indeed as simple as that.  I didn't realize the algebra
code in Axiom could be made to work without the interp behind it - I
think that was the incorrect assumption I was making.

I'm not sure how easy it would be to get the same behavior of the code
in two different language translations, but I guess that is up to the
Aldor system.

\start
Date: Fri, 28 Jul 2006 12:40:55 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Aldor translations
Cc: Christian Aistleitner

>> Do you think it would be a bad idea to produce a symbolic library for
>> Axiom and make it available to C programmers by simply targetting C
>> as the Aldor output?
> 
> No, if it is indeed as simple as that.  I didn't realize the algebra
> code in Axiom could be made to work without the interp behind it - I
> think that was the incorrect assumption I was making.

Well, it is like calling functions from GMP, only that the Axiom library 
would provide some symbolic algorithms.

However, we first have to translate the Axiom library to pure Aldor. 
Currently it relies on some features of Axiom that I haven't yet figured 
out.

> I'm not sure how easy it would be to get the same behavior of the code
> in two different language translations, but I guess that is up to the
> Aldor system.

He? Where do you see the problem? The Aldor compiler (ehm, actually 
FOAM) was designed to translate well to LISP and C. The compiler 
probably provides different runtime systems for LISP and C, but that is 
a problem of the compiler not of Aldor.

\start
Date: Fri, 28 Jul 2006 13:06:47 -0400
From: Bill Page
To: Christian Aistleitner
Subject: RE: [Aldor-l] Re:  exports and constants

Christian,

On July 28, 2006 3:21 AM you wrote:
> Bill Page wrote: 
> > Does it really make sense that such a high level language
> should care about the name that a particular programmer
> assigned to one of it's objects?
> 
> yes, there are lots of applications of reflection that do not 
> involve debugging. So you should typically be able to get the
> names of things.
>

I still see conceptual problems with "names". I can take one
source code containing, say a local variable named X that
compiles and runs properly, do a text substitution of X to Y
(assumming that the variable Y does not aldready occur) to create
an entirely new source code that compiles abd which (usually)
results in exactly the same machine code. The "name" I give to
the variable X (or Y) does not play any logical role in the
program. It is like a comment. It is only interesting (perhaps)
to someone wishing to debug the source code and who knows the
(human) meaning of X.

But there are other names, such as the names of functions and
types from an external library that do certainly make sense to
associate with the object code.
 
> 
> > [ example of "self-identifying" code ]
> 
> Actually, I do not like your code, as this does not give you 
> the kind of information you would like to have with a reflection 
> framework (e.g.: Using proper types for types and functions,
> Getting parameter types), and  will cause you lots of problems
>  -- but maybe I am too early thinking about such issues.

I am not sure what you mean by "proper types" but it seems
clear that it is possible in Aldor to add many different kinds
of self-identifying information as exported constants.

> However, besides the parsing part, the extensions and  
> all the other issues, if it's the way you choose, let me help 
> you getting it to compile and run. The following piece of code
> works:
> ... 

Thank you very much indeed for this solution! :-))

I will study it carefully and try to extend it to examples of
more practical applications of reflection and self-identification.

\start
Date: Sat, 29 Jul 2006 00:54:58 -0400
From: Bill Page
To: Christian Aistleitner
Subject: Re:  exports and constants

Christian,

On July 28, 2006 3:21 AM you wrote:

>...
> However, besides the parsing part, the extensions and all
> the other issues, if it's the way you choose, let me help 
> you getting it to compile and run. The following piece of
> code works:
> ... 
> 
> Just as expected. What did I do to get the code working?
> 
> I got rid of pile.
> Piles are simply a pain to my eyes.
> 

 :} I like coffee
 :{ You like tea
 ;} It really doesn't matter to me

See http://wiki.axiom-developer.org/SandBoxReflectionInAldor

> I turned exports into a function, as you'd probably want to 
> call it more than once.
>

I don't understand the relevance of whether exports is a function
or not. As a generator we can use it as often as we like. No?
 
> You yielded anonymous categories, created just within the 
> yield clause. This looked dangerous to me, so I turned them
> into proper definitions within MyDom's add part. This however
> gave problems when checking by has (as the Categories where
> no longer anonymous), so I had to use them already in the with
> clause, and moved them to the top-level scope (EXPORT0, ...).

Unfortunately Aldor treats named categories differently than
anonymous ones:

"7.5 ... Note that Aldor is constructed so that a domain is only
a member of a named category if it explicitly inherits from the
category - not if it merely exports the same collection of
(explicit) declarations."

I think being able to use anonymous categories is quite
important because we really do want to be able check for just
the presence of explicit declarations. The names artificially
assigned to these declarations is not important to us and of
course it would be rather awkward to have to name every
declaration in the system.

Also if I did use named categories shouldn't I use the 'define'
keyword since ultimately I will probably be interested in using
the value of these categories in forming other domains?

Still, it is reassuring that at least Aldor can compile this
stuff in the case of named categories!

> 
> I use the macro yieldT instead of simply yield, to tell the 
> compiler the yielded thing really is a Category. For some of
> my experiments this wasn't necessary -- for some it was.

This looks like another case of rather weak type inference in
the compiler.

> 
> I moved your "has" check in a separate function. It doesn't 
> seem to work out well, if the Cat part of "Dom has Sig" is
> not constant in scope.

No, I don't think that is a problem. I have an example that
works where Sig is not constant in scope. Maybe it was a
different issue?

> 
> That's it.
>

Wonderful! Thanks.
 
> > Except that I can not seem to get the "has" expression to
> > work the way I expected it to. Maybe this is another bug?
> 
> Your code demonstrates more than just one compiler bug ... ;)
>

Yes I guess so. While playing with this code we seem to have
found several different ways to make the compiler or the
generated code fail. :(
 
> > [ warning about "-fwritable-strings" ]
> > This is one more example of something that could probably be
> > easily and quickly resolved if Aldor was open source.
> 
> I doubt that. In May, I got a mail from one of the compiler 
> people telling me
> 
> I have spent the last couple of days looking into this 
> [Remark by CA: the  
> "-fwritable-strings" issue] , but the whole compiler uses 
> char * a = "abc"  
> (and the compiler is about 250K LOC).  In most of the places 
> they seem to be treated as const char *, but I still have a
> long way to go.
> 
> So somebody is already working on it, and I believe him, that 
> it's not one of those problems you fix in the 5 minutes till
> lunch break ;) Nevertheless, maybe he'd get help and feedback
> once the compiler is freed.

Absolutely! It is ridiculous and extremely disappointing that
we all have been waiting years now for things like this and other
compiler bugs to be resolved simply because of licensing issues
that could have been resolved a long time ago. :( From comments
posted to the Axiom Wiki web site it is clear there is a lot of
interest in Aldor - most even consider it essential for the future
of Axiom itself - so I have no doubt that there would be a lot of
resources available to work on such problems if only Aldor were
open source.

> 
> 
> > I do not see any advantage of the syntax
> >
> >> for s in exports(Mydomain) repeat ...
> >
> > over my
> >
> >   for s in exports$Mydomain repeat ...
> >
> > which does not involve any explicit external function call.
> 
> First of all (as I described in the upper part of my mail), 
> you wouldn't be able to get two different generators. Hence,
> if the generator ran out of elements, you cannot restart it
> -- very nasty thing ;)

No, I don't understand this. It seems to work fine for me at

http://wiki.axiom-developer.org/SandBoxReflectionInAldor

Perhaps I am missing something here?

> 
> The second issue is abstraction. Even if you get the thing 
> done your way, I'd never call exports$SomeDom directly.
> 
> Create some domain
> 
> Reflection( T: Type ): with {
> 	exports: () -> Generator Category
> }
> 
> and use exports$(Reflection(SomeDom)).
>
> Thereby you can extend the whole reflection thing quite naturally,
> and if reflection gets built into compiler/runtime, you wouldn't
> have to change the programs relying on reflection, but only need
> to change the domain Reflection.
> 

Yes, that makes sense. Thanks.

\start
Date: Sat, 29 Jul 2006 07:43:05 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: non-constant constants   
Cc: Christian Aistleitner

Hi Bill,

>> I turned exports into a function, as you'd probably want to 
>> call it more than once.

> I don't understand the relevance of whether exports is a function
> or not. As a generator we can use it as often as we like. No?

Try the following piece of code.

---BEGIN aaa14.as
#include "aldor"
#include "aldorio"

main(): () == {
	import from Integer, List Integer;
	
	fun(): Generator Integer == generate {
		yield 0;
		yield 1;
	};

	const: Generator Integer == fun();

	stdout << [fun()] << newline;
	stdout << [fun()] << newline;
	stdout << [const] << newline;
	stdout << [const] << newline;
}
main();
---END aaa14

 >aldor -grun -laldor aaa14.as
[0,1]
[0,1]
[0,1]
[]

I agree that const is not constant. But a Generator is inherently 
destructive.

If you like you could also say something like
   a: Record(x: Integer) == [1];
   a.x := 0;
and the "constant" a changes. But you should note that the last line is
actually
   set!(a, x, 0)
so that is a destructive function and thus you should expect strange 
things. The BANG functions (like set!) are only for people who know what 
they do.

\start
Date: Sat, 29 Jul 2006 02:21:48 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [Aldor-l] non-constant constants was: re: exports and constants
Cc: Christian Aistleitner

Ralf,

Thanks for the example.

On July 29, 2006 1:43 AM you wrote:
> 
> >> I turned exports into a function, as you'd probably want to 
> >> call it more than once.
> 
> > I don't understand the relevance of whether exports is a function
> > or not. As a generator we can use it as often as we like. No?
> 
> Try the following piece of code.
> 
> ---BEGIN aaa14.as
> #include "aldor"
> #include "aldorio"
> 
> main(): () == {
> 	import from Integer, List Integer;
> 	
> 	fun(): Generator Integer == generate {
> 		yield 0;
> 		yield 1;
> 	};
> 
> 	const: Generator Integer == fun();
> 
> 	stdout << [fun()] << newline;
> 	stdout << [fun()] << newline;
> 	stdout << [const] << newline;
> 	stdout << [const] << newline;
> }
> main();
> ---END aaa14
> 
>  >aldor -grun -laldor aaa14.as
> [0,1]
> [0,1]
> [0,1]
> []
> 
> I agree that const is not constant. But a Generator is inherently 
> destructive.
>

Hmmm... I see. A constant that is not constant... Generators are
"mutable"? That seems like a very peculiar and questionable semantics
to me!

So if I write:

  for x in const repeat
    ...
  for x in const repeat
    ...

The 2nd loop is guarranteed never to execute?!

But if I have some other constant constant like a list

  const2: List Integer == [1,2,3]

  for x in const2 repeat
    ...
  for x in const2 repeat
    ...

or even

  for x in 1..10 repeat
    ...
  for x in 1..10 repeat
    ...
 
this works as expected even though in Aldor iteration over a list
is implemented as a generator.

> If you like you could also say something like
>    a: Record(x: Integer) == [1];
>    a.x := 0;
> and the "constant" a changes. But you should note that the 
> last line is
> actually
>    set!(a, x, 0)
> so that is a destructive function and thus you should expect strange 
> things. The BANG functions (like set!) are only for people 
> who know what they do.
> 

Of course but I do not see the relevance of this to a generator.
Yes I understand that a generator is always in a certain "state"
and what the generator yields depends on that state, but surely
there are reasonable contexts in which the state of the generator
is reset?

Further what does this have to do with the type of the constant,
i.e. whether it is

  const: Generator Integer

or

  const: () -> Generator Integer

Do you know of any other language where Generators have the
same semantics as in Aldor?

\start
Date: 29 Jul 2006 09:19:09 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Polynomials, abstract objects, provisos

Ralf Hemmecke writes:

> [recursive vs. distributed polynomials]

> > I don't know how we should model "abstract polynomials", but I'm not ev=
en sure
> > whether we should have such a thing.
>
> That would be possible, but suppose you want to do a Gr=F6bner basis
> computation. Who is going to choose the most efficient data representatio=
n?

[...]

I have no idea what you are talking about, sorry. I was referring to Tim's =
(?)
idea that we could say something like:

p: Abstract POLY INT

i.e., not assign p a value,

and still do interesting things with it. And I doubt that this is something
within reach, as it is, in my opinion, rather orthogonal to the philosophy =
of
the current Axiom Algebra.

Something easier to grasp is probably:

z: Abstract Complex INT

and then be able to say

w := conjugate z.

In other words: there would be no data representation as we are used to
currently.

Again, note that although I find this an interesting subject, I believe tha=
t it
is currently out of reach.

\start
Date: Sat, 29 Jul 2006 09:31:24 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Aldor-l] Re:  exports and constants
Cc: Christian Aistleitner

> Unfortunately Aldor treats named categories differently than
> anonymous ones:
> 
> "7.5 ... Note that Aldor is constructed so that a domain is only
> a member of a named category if it explicitly inherits from the
> category - not if it merely exports the same collection of
> (explicit) declarations."

> I think being able to use anonymous categories is quite
> important because we really do want to be able check for just
> the presence of explicit declarations. The names artificially
> assigned to these declarations is not important to us and of
> course it would be rather awkward to have to name every
> declaration in the system.

Well, I like to speak Aldor ;-). Your reference to the AUG above exactly 
means that there is one "F" output below. Nothing else.

---BEGIN aaa15.as
#include "aldor"
#include "aldorio"

macro MACCAT == with {foo: () -> ()}
macro MACDOM == add {foo(): () == {}}
define CatA: Category == MACCAT;
A: CatA == MACDOM;
M: MACCAT == MACDOM;
stdout << (A has CatA) << newline;
stdout << (M has CatA) << newline;
stdout << (A has MACCAT) << newline;
stdout << (A has MACCAT) << newline;
---END aaa15.as

 >aldor -grun -laldor aaa15.as
T
F
T
T

And if you enter the definitions of A and M above into "aldor -gloop"
you'll see.

%7 >> M
   () @
  with foo: () -> ()
     ==  add ()

                                            Comp: 0 msec, Interp: 0 msec
%8 >> A
   () @
CatA with
     ==  add ()

In fact, A exports a bit more than M, namely that it belongs to CatA. 
Since "has" is executed at runtime, it certainly makes a difference 
whether the program just has to check the existence of a symbol "CatA" 
or whether is must check all the exports i.e. signatures (which could be 
hundreds for complicated categories).

> Also if I did use named categories shouldn't I use the 'define'
> keyword since ultimately I will probably be interested in using
> the value of these categories in forming other domains?

Right. But I have not yet seen any instance where the compiler treats 
category definitions with or without "define" differently. But that 
current behaviour can not be relied on. So it is better practice to 
write "define".

\start
Date: Sat, 29 Jul 2006 10:08:00 +0200
From: Christian Aistleitner
To: Bill Page
Subject: Re:  exports and constants
Cc: aldor-l@aldor.org

Hello,

> I still see conceptual problems with "names". I can take one
> source code containing, say a local variable named X that
> compiles and runs properly, do a text substitution of X to Y
> (assumming that the variable Y does not aldready occur) to create
> an entirely new source code that compiles abd which (usually)
> results in exactly the same machine code. The "name" I give to
> the variable X (or Y) does not play any logical role in the
> program. It is like a comment. It is only interesting (perhaps)
> to someone wishing to debug the source code and who knows the
> (human) meaning of X.
>
> But there are other names, such as the names of functions and
> types from an external library that do certainly make sense to
> associate with the object code.

maybe I did not make my statement clear enough. In code like:

SomeDom: with {
   func:( B: A, C: B ) -> ();
} == add {
	func( B: A, C: B ): () == {
         local x: Integer;
         x=1;
       }
}

Reflection should be able to tell you "SomeDom contains a function with 
name func".
Reflection should be able to tell you "SomeDom contains a function with 
name func, whose first parameter is B and is of type A".
Reflection should not be able to tell you "SomeDom contains a function  
with name func, which uses the variable x".

So I guess me actually agree on this one, don't we?

>> > [ example of "self-identifying" code ]
>>
>> Actually, I do not like your code, as this does not give you
>> the kind of information you would like to have with a reflection
>> framework (e.g.: Using proper types for types and functions,
>> Getting parameter types), and  will cause you lots of problems
>>  -- but maybe I am too early thinking about such issues.
>
> I am not sure what you mean by "proper types" but it seems
> clear that it is possible in Aldor to add many different kinds
> of self-identifying information as exported constants.

I'll give you some hints about the tip of the iceberg. Consider the piece
of code above. What would your exports function yield? Probably something
like
generate {
   yield with { func: ( B: A, C: B ) -> () }
}

But that's of limited use. How can you extract information from "with  
{ func: ( B: A, C: B ) -> () }"?
You should have to extract the identifier "func" and it's type "( B: A, C: 
B ) -> ()". But your yielded expression is a black box -- you can test it, 
but not look inside of it.
You should be able to determine the domain and codomain of mappings. You
should be able to "explode" "( B: A, C: B )" into "B of type A and C of 
type B".

But as I said, it's probably to early to discuss these issues now.

\start
Date: Sat, 29 Jul 2006 10:15:00 +0200
From: Christian Aistleitner
To: Bill Page
Subject: Re:  exports and constants

Hello,

> Also if I did use named categories shouldn't I use the 'define'
> keyword since ultimately I will probably be interested in using
> the value of these categories in forming other domains?

when sticking to the AUG, you are right. However, in real life, the Aldor  
Compiler does not seem to need it. I never came across a situation that  
worked with a define, but failed without it...

>> I moved your "has" check in a separate function. It doesn't
>> seem to work out well, if the Cat part of "Dom has Sig" is
>> not constant in scope.
>
> No, I don't think that is a problem. I have an example that
> works where Sig is not constant in scope. Maybe it was a
> different issue?

Maybe. I did not claim, that it is an error. It just looks dangerous and  
does not work when not hidden in a function. But it works when within a  
function.
I can only guess about the reason.

\start
Date: Sat, 29 Jul 2006 10:31:59 +0200
From: Christian Aistleitner
To: Bill Page, Ralf Hemmecke
Subject: Re: [Aldor-l] non-constant constants was: re:	exports and constants

Hello,

>> [ Generators ]
>
> Hmmm... I see. A constant that is not constant...

For exactly this reason, you should not define a Generator to be constan=
t.  =

It's bad style ;)
You can modify every connstant that has destructive functions...

Is there any language forbidding this?

> Generators are "mutable"? That seems like a very peculiar and  =

> questionable semantics
> to me!

No. It's the whole point of generators...


> So if I write:
>
>   for x in const repeat
>     ...
>   for x in const repeat
>     ...
>
> The 2nd loop is guarranteed never to execute?!

I assume, you have some
   const == someGenerator;
before the for loops. Then segfaults happen (occasionally) with such  =

constructs.
But after all, you should not write such code.

> But if I have some other constant constant like a list
>
>   const2: List Integer == [1,2,3]
>
>   for x in const2 repeat
>     ...
>   for x in const2 repeat
>     ...
>
> or even
>
>   for x in 1..10 repeat
>     ...
>   for x in 1..10 repeat
>     ...
> this works as expected even though in Aldor iteration over a list
> is implemented as a generator.

yes. Because the you call the generator FUNCTION once your every for loo=
p.
Your loops *magic* are translated into
for x in generator const2 repeat
{
    ...
}
for x in generator const2 repeat
{
    ...
}
(or something equivalent). So the generatos are NOT constants. But the  =

List you take the generator of is constant.

>> If you like you could also say something like
>>    a: Record(x: Integer) == [1];
>>    a.x := 0;
>> and the "constant" a changes. But you should note that the
>> last line is
>> actually
>>    set!(a, x, 0)
>> so that is a destructive function and thus you should expect strange
>> things. The BANG functions (like set!) are only for people
>> who know what they do.
>>
>
> Of course but I do not see the relevance of this to a generator.
> Yes I understand that a generator is always in a certain "state"
> and what the generator yields depends on that state, but surely
> there are reasonable contexts in which the state of the generator
> is reset?
>
> Further what does this have to do with the type of the constant,
> i.e. whether it is>
>   const: Generator Integer
>
> or
>
>   const: () -> Generator Integer

I already explained things above. If it's still a mystery to you ... tel=
l  =

me, and I'll be more explicit.

> Do you know of any other language where Generators have the
> same semantics as in Aldor?

For example Java:
http://java.sun.com/j2se/1.3/docs/api/java/util/Iterator.html

For example C++:
http://www.sgi.com/tech/stl/Iterators.html

\start
Date: Sat, 29 Jul 2006 11:08:15 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: Polynomials, abstract objects, provisos

> I have no idea what you are talking about, sorry. I was referring to Tim's 
> idea that we could say something like:
> 
> p: Abstract POLY INT
> 
> i.e., not assign p a value,

Sorry, then I did not understand that.

> and still do interesting things with it. And I doubt that this is something
> within reach, as it is, in my opinion, rather orthogonal to the philosophy of
> the current Axiom Algebra.

> Something easier to grasp is probably:
> 
> z: Abstract Complex INT
> 
> and then be able to say 
> 
> w := conjugate z.
> 
> In other words: there would be no data representation as we are used to
> currently.

I don't believe your last statement. Somewhere it must be stored that w 
and z are connected via "conjugate", so there must be some storage 
involved. Now the question is who is going to remember these relations?

Since I don't want the interpreter be too smart, I would like to encode 
such things in the library. And that could be done (theoretically at least).

Assume we have a domain A that exports foo: % -> % then you would need 
another domain DelayedA that basicly has the same exports as A and 
additionally two coerce functions A -> DelayedA and back.

In DelayedA function applications would be collected and only executed 
if you really provide an element of A. But there are more elements in 
DelayedA than in A, namely those that have no value in A.

In other words one would have a kind of ExpressionTrees where you carry 
the type information.

But don't quote me on that my ideas are completely underdeveloped. And 
there is certainly something missing that might look like provisos. For 
example, if you declare "a: Integer" and then say "5/a". It might be a 
bit easier to get the type of 5/a right. The value is a bit more 
problematic since at some point when you finally assign a value to "a" 
an exception might happen and your program has to deal with that. But an 
exception is an easy exercise. It is getting more complicated if the 
"unvalued but typed" expression might result in multible values.

\start
Date: Sat, 29 Jul 2006 12:12:39 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Aldor-l] non-constant constants was: re:	exports and constants
Cc: Christian Aistleitner, Laurentiu Dragan, Stephen Watt

On 07/29/2006 08:21 AM, Bill Page wrote:

> Hmmm... I see. A constant that is not constant... Generators are
> "mutable"? That seems like a very peculiar and questionable semantics
> to me!

Hmm, I don't know what to say here about that semantics. Now if you 
mention it, I don't even know if this is explained in the AUG.
But yes, Generators are mutable.

I remember that I have once seen a library implementation of "Generator" 
where there appeared a "step!" function (this one is still in axllib).

Already from the name you would believe that there is some destructive 
operation going on internally. For libaldor the function is called "next!".

But think about this.

gen: Generator Integer == generate {yield 0; yield 1}
for i in 1..1 for g in gen repeat stdout << g << newline;
for i in 1..1 for g in gen repeat stdout << g << newline;

You would probaly want to see two 0s as output. Right?

But you could also say (gen defined as above and then)

stdout << (next! gen) << newline;
stdout << (next! gen) << newline;

Of course, you see 0 and 1 as output and you might have expected it 
since you used a BANG function (next!).

But maybe you are right, constants should remain constants even in the 
case of Generators. That is actually a good question about the semantics 
of "Generator" and it should be made clear.

Look at the end of Section "5.14 Loops". There you'll find the "step!" 
function mentioned explicitly. But that still doesn't mean that

gen: Generator Integer == ...

should be mutable. If it were ":=" above, OK, but it's "==".

> So if I write:
> 
>   for x in const repeat
>     ...
>   for x in const repeat
>     ...
> 
> The 2nd loop is guarranteed never to execute?!

Currently that is the case. And believe me, that strange behaviour has 
already caused me some trouble.

> But if I have some other constant constant like a list

>   const2: List Integer == [1,2,3]
> 
>   for x in const2 repeat
>     ...
>   for x in const2 repeat
>     ...
> 
> or even
> 
>   for x in 1..10 repeat
>     ...
>   for x in 1..10 repeat
>     ...
>  
> this works as expected even though in Aldor iteration over a list
> is implemented as a generator.

Oh, that is easy to explain. Remember, we are not in Axiom. The only 
thing that can appear after "in" in Aldor is a generator. But const2 or 
1..10 isn't such a thing. So Aldor adds syntactic sugar, namely it puts 
a function application "generator" just at the right place. So in fact 
your code then reads like

   for x in generator const2 repeat ...
   for x in generator 1..10 repeat ...

So each time that "for x in const2 repeat" appears in your code, a *new* 
  thing of type "Generator Integer" is constructed from the list const2 
or from the IntegerSegment(Integer) given by 1..10.

> Further what does this have to do with the type of the constant,
> i.e. whether it is
> 
>   const: Generator Integer
> 
> or
> 
>   const: () -> Generator Integer
> 
> Do you know of any other language where Generators have the
> same semantics as in Aldor?

I agree. Constants should remain constant unless you do explicit 
destructive things with them. For the constant gen from above I don't 
consider

   for i in gen repeat ...

to be a destructive operation on "gen", since it is totally invisible 
that there is a BANG function anywhere.

Even if the at runtime the state of the generator must be change, I 
think the compiler should produce code so that the two for loops produce 
exactly the same output.

for i in 1..1 for g in gen repeat stdout << g << newline;
for i in 1..1 for g in gen repeat stdout << g << newline;

So in fact, the compiler could make a copy of the *constant* gen before 
it is given to the "for" loop. (Unfortunately there is no "copy" 
functions for "Generator"s yet, and I even believe that such a function 
is (nearly) impossible to write efficiently, because you might have 
Generators that depend on Generators.

However, I believe it is OK, if "next! gen" modifies the constant. It is 
in the responsibility of the programmer not the do anything harmful if 
s/he uses BANG functions.

\start
Date: 29 Jul 2006 14:20:54 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Polynomials, abstract objects, provisos

Ralf Hemmecke writes:

> > I have no idea what you are talking about, sorry. I was referring to Tim's (?)
> > idea that we could say something like:
> > p: Abstract POLY INT
> > i.e., not assign p a value,
> 
> Sorry, then I did not understand that.

Huu, email has its complications. Great!
> 
> > and still do interesting things with it. And I doubt that this is something
> > within reach, as it is, in my opinion, rather orthogonal to the philosophy of
> > the current Axiom Algebra.
> 
> > Something easier to grasp is probably:
> > z: Abstract Complex INT
> > and then be able to say w := conjugate z.
> > In other words: there would be no data representation as we are used to
> > currently.
> 
> I don't believe your last statement. Somewhere it must be stored that w and z
> are connected via "conjugate", so there must be some storage involved. 

Quite right. That's why I added "as we are used to currently". 

> Now the question is who is going to remember these relations?

> Since I don't want the interpreter be too smart, I would like to encode such
> things in the library. And that could be done (theoretically at least).

Yes, we are of the same opinion (modulo email).

\start
Date: Sat, 29 Jul 2006 16:53:45 +0200
From: Ralf Hemmecke
To: Christian Aistleitner
Subject: Re: [Aldor-l] Re:  exports and constants

>> I still see conceptual problems with "names". I can take one
>> source code containing, say a local variable named X that
>> compiles and runs properly, do a text substitution of X to Y
>> (assumming that the variable Y does not aldready occur) to create
>> an entirely new source code that compiles abd which (usually)
>> results in exactly the same machine code. The "name" I give to
>> the variable X (or Y) does not play any logical role in the
>> program.

You are right, but of course all exported names that are in the API 
matter. Suppose you want to write an interpreter for Aldor in Aldor 
(something like B-natural perhaps). Ideally I would expect that that can 
be done in such a way that it does not matter what the underlying 
libraries are. There might be even libraries that would be written after 
the interpreter and the interpreter should treat them as the ones he 
already knows about.

I guess that is a good example of where you would like to be able to ask 
an available library which types it contains, ask the domains about 
their exports, and eventually call some of the functions.

Situation is as follows. You have given libaldor.al (no sources). Build 
an interpreter by just using that functionality. Then I give you 
libalgebra.al and libmyalg.al and the interpreter should do what it is 
supposed to do (basically behave like the foam interpreter (aldor 
-gloop) but a bit faster and maybe with some nice way of guessing types.

\start
Date: Sat, 29 Jul 2006 12:17:57 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: Polynomials, abstract objects, provisos

Martin,

> > [recursive vs. distributed polynomials]
> 
> > > I don't know how we should model "abstract polynomials", but I'm not even sure
> > > whether we should have such a thing.
> > 
> > That would be possible, but suppose you want to do a Grbner basis
> > computation. Who is going to choose the most efficient data representation?
> 
> [...]
> 
> I have no idea what you are talking about, sorry. I was referring to Tim's (?)
> idea that we could say something like:
> 
> p: Abstract POLY INT
> 
> i.e., not assign p a value,
> 
> and still do interesting things with it. And I doubt that this is something
> within reach, as it is, in my opinion, rather orthogonal to the philosophy of
> the current Axiom Algebra.
> 
> Something easier to grasp is probably:
> 
> z: Abstract Complex INT
> 
> and then be able to say 
> 
> w := conjugate z.
> 
> In other words: there would be no data representation as we are used to
> currently.
> 
> Again, note that although I find this an interesting subject, I believe that it
> is currently out of reach.

One possible thought is to create

 IndefiniteInteger

which exports the operations of integer but does so in an
"abstract" way. That is, the result of multiplying two 
IndefinteIntegers is an IndefiniteInteger but there is 
no data representation.

One could then create an IndefinitePolynomial over the
IndefiniteIntegers which exports operations that remain
in IndefinitePolynomial.

Unfortunately this method has two problems.

First, it implies either copies of domains such as
IndefiniteInteger or it implies that you figure out
how to build an "Indefinite" domain that lives in the
type tower such as:

   Polynomial (Indefinite (Integer))
   Indefinite (Polynomial (Integer))
   Indefinite (Polynomial (Indefinite (Integer)))

My thinking at the moment leads me to carry the information
in the proviso as in

   x provided (..... (x is Integer) ....)
   x provided (..... (x is Polynomial(Integer)) ....)

etc.

\start
Date: Sat, 29 Jul 2006 13:59:22 -0400
From: Tim Daly
To: list
Subject: topic modeling

One of the long term goals I've been thinking about is the
petamachine problem. Given a machine with a THz of cpu, a
TByte of memory, a Petabyte of storage, and an OC5 data link
how would you use it to improve computational math research?

One of the subideas is that all of the mathematics that has
ever been published would probably fit on a few terabytes of
disk space. And any new mathematics would be available in a
streaming electronic form. Part of the cpu would be dedicated
to watching the newly arriving stream and classifying the 
information in ways that I personally find useful.

I've muttered about expanding the latex tags to have \idea,
\concept, etc. so that newly born papers could be more easily
classified. However, a new technology seems to make that less
interesting. It's called topic modeling. See

http://blogs.zdnet.com/emergingtech?p=304

Given a continuous process that scans incoming papers you
could add them to a semantic network which models information
that I find useful and in ways that I find useful.

Axiom could strongly benefit from such technology if we could
find a good source of technical papers. Starting from an initial
source we could collect electronic conference papers and classify
them. Then Axiom could just look up a concept like "Groebner Basis",
follow it to "Homological Algebra" then onto "Computing P-modules"
and then onto finding an algorithm for computing a presentation
of a finitely generated P-module. Ideally the paper would be
literate and contain code that was automatically incorporated
into the system. 

The Crystal idea has a facet that constantly watches the user
interaction, maintians an "intensional stance" of the user,
and tries to find related, relevant work. This technology would
be ideal behind such a facet.

Automatic classification algorithms are always more effective
in limited domains (e.g. math) than in unspecified domains.

Sounds like an NSF or INRIA grant idea to me.

\start
Date: Sat, 29 Jul 2006 22:34:05 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Polynomials, abstract objects, provisos

> One could then create an IndefinitePolynomial over the
> IndefiniteIntegers which exports operations that remain
> in IndefinitePolynomial.

I believe nobody wants that approach. I have just tried to build an 
example of IndefiniteIntegers. Suppose you have found a good data 
representation for it, then what type would you expect the zero? 
function has? The only think I can think of is

zero?: % -> IndefiniteBoolean;

So you end up in building always a domain and its indefinite 
counterpart. That is surely unmanageable.

> Unfortunately this method has two problems.
> 
> First, it implies either copies of domains such as
> IndefiniteInteger or it implies that you figure out
> how to build an "Indefinite" domain that lives in the
> type tower such as:
> 
>    Polynomial (Indefinite (Integer))
>    Indefinite (Polynomial (Integer))
>    Indefinite (Polynomial (Indefinite (Integer)))

I like your second approach better, but after I thought a bit about it, 
I believe that you cannot do this without reflection.

What would be the type of the function "Indefinite"? Clearly it should 
accept any domain. So it would be (T: Type) -> ResultType.

The result type should, however be identical to the (dynamical) type of 
T. Since Indefinite(Integer) should allow any integer operation and 
Indefinite(Boolean) should allow any operations that is defined in 
Boolean. So we would have ...

Indefinite(T: Type): TypeOf(T) == add {...}               -- (*)

So we are out of business here.

Another approach I could think of is that one works with objects (values 
that know its type). One can simulate that in Aldor, too. (Look at 
chapter 21.10 "Objects" in the pdf version of the AUG.)

But again, how would you write "obj1 + obj2"? You must lookup what + 
could actually mean. At compile time you have no chance. So the whole 
business is something for an interpreter. And then (for the interpreter) 
I believe something like (*) should be possible.

> My thinking at the moment leads me to carry the information
> in the proviso as in
> 
>    x provided (..... (x is Integer) ....)
>    x provided (..... (x is Polynomial(Integer)) ....)

I somehow think that (*) and your proviso approach are very similar. The 
x basically is like a typed variable (that has no value).

So what should be built is a "typed expression tree" where the leaves 
are typed variables that have no values and the inner nodes are 
functions that wait for their arguments to become actual values.
Whenever a all arguments of a inner node (=function) are actual values, 
then the subtree collapses to an actual value.

I have not yet an idea how to treat a multivalued result.

Any other ideas?

\start
Date: Sat, 29 Jul 2006 20:35:04 -0400
From: Tim Daly
To: Antoine Hersen
Subject: Re: topic modeling

> Classification is a popular subject in AI and especially data mining, I did
> not read the paper but there is a lot different technique. And having an
> article in ZDnet and making a round in the blogospher is not reliable
> indicator of a scientific breakthrough.

I did some work on semantic classification while at IBM Research.
The system was called KROPS, a combination of a rule-based programming
language based on OPS and a semantic network by Eric Mays called KREP.
I showed that there is a dual relationship between semantic nets
and rete-network rules, a unification that allows rules to be expressed
as classification and vice-versa.

KREP uses a special kinds of classification called subsumption which
has provable properties of the classification.

You can read about subsumption here:
  http://www.isi.edu/isd/LOOM/papers/macgregor/aaai94.pdf

KROPS (KREP/OPS) was the basis for IBM's FAME project
  http://www.research.ibm.com/journal/rd/363/ibmrd3603H.pdf

KROPS is described in:
 "Integrating rules and inheritance networks in a knowledge-based
  financial marketing consultation system" Proc. HICCS (1988)
  Pages 496-500

\start
Date: Sat, 29 Jul 2006 22:59:10 -0400
From: Tim Daly
To: list
Subject: ICMS 06 Talk

Someone on this list mentioned that they were giving a talk
at ICMS 06. Could you update Marc with the information?

------- Start of forwarded message -------
From: Marc Moreno Maza

Tim,

Here's Xin's web page where you can download his AXIOM code.

http://www.csd.uwo.ca/People/gradstudents/xli96/ 


Could you please semd me pointers or slides for the AXIOM
talk at ICMS 06?

Sincerely,

Marc


On Sun, Jul 16, 2006 at 06:42:32AM -0400, root wrote:
> Marc,
> 
> I've returned home and finally recovered from the time change.
> When you get a chance can you point me at the code you want to 
> include in Axiom?
> 
> Tim

\start
Date: Sun, 30 Jul 2006 00:36:45 -0400
From: Alfredo Portes
To: Antoine Hersen
Subject: Re: topic modeling

Classification in fact is an field of Artificial intelligence, more specific a
Natural Language Process sing. More than the current, buzz about "Semantic
Web", the field has had advanced considerably during the last 3 - 5
years period,
because an improvement on various techniques.

As Tim has indicated, IBM has been always on top of this research
involving NLP. This past week was announced how their voice
recognition software does not need user training a breakthrough for
this type of commercial applications.

I am very interested in the NLP area. I consider Tim's idea a very
current and important one. Given the incredible amount of scientific
information on the web, and the amount that is inputted constantly,
the problem of classification and retrieval of this information seems
vital.

Having smart systems that can search for this information, classify
and stored them, will be right there with the idea of literate papers
that can be found and added to the system. I will be more interested
in a system that can find the information and create a literate
document from it. As Tim said, this kind of systems perform better
when they are domain specific.

Regards,

A.P.

On 7/29/06, Tim Daly wrote:
> > Classification is a popular subject in AI and especially data mining, I did
> > not read the paper but there is a lot different technique. And having an
> > article in ZDnet and making a round in the blogospher is not reliable
> > indicator of a scientific breakthrough.
>
> I did some work on semantic classification while at IBM Research.
> The system was called KROPS, a combination of a rule-based programming
> language based on OPS and a semantic network by Eric Mays called KREP.
> I showed that there is a dual relationship between semantic nets
> and rete-network rules, a unification that allows rules to be expressed
> as classification and vice-versa.
>
> KREP uses a special kinds of classification called subsumption which
> has provable properties of the classification.
>
> You can read about subsumption here:
>   http://www.isi.edu/isd/LOOM/papers/macgregor/aaai94.pdf
>
> KROPS (KREP/OPS) was the basis for IBM's FAME project
>   http://www.research.ibm.com/journal/rd/363/ibmrd3603H.pdf
>
> KROPS is described in:
>  "Integrating rules and inheritance networks in a knowledge-based
>   financial marketing consultation system" Proc. HICCS (1988)
>   Pages 496-500

\start
Date: 30 Jul 2006 09:48:50 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: src/lib/bsdsignal.c.pamphlet

Tim Daly writes:

| src/lib/bsdsignal.c.pamphlet {\wc -> {\sl -- fixed in the next release --t

Tim, I've not seen a corresponding commit to the silver branch.
I applied the below

-- Gaby

2006-07-30  Tim Daly  Tim Daly

	* bsdsignal.c.pamphlet: Fix typo.


*** bsdsignal.c.pamphlet	(revision 15545)
--- bsdsignal.c.pamphlet	(local)
*************** SA\_NOCLDSTOP & If this bit is set when 
*** 79,85 ****
  SA\_NOCLDWAIT & If this bit is set when calling {\sl sigaction()} for the\\
               & SIGCHLD signal, the system will not create zombie processes\\
               & when children of the calling process exit. If the calling\\
!              & process subsequently issues a {\wf wait()} (or equivalent),\\
               & it blocks until all of the calling process's child processes\\
               & terminate, and then returns a value of -1 with errno set to\\
               & ECHILD.\\
--- 79,85 ----
  SA\_NOCLDWAIT & If this bit is set when calling {\sl sigaction()} for the\\
               & SIGCHLD signal, the system will not create zombie processes\\
               & when children of the calling process exit. If the calling\\
!              & process subsequently issues a {\sl wait()} (or equivalent),\\
               & it blocks until all of the calling process's child processes\\
               & terminate, and then returns a value of -1 with errno set to\\
               & ECHILD.\\

\start
Date: Sun, 30 Jul 2006 06:36:04 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: topic modeling

--- Tim Daly wrote:

> I've muttered about expanding the latex tags to have \idea,
> \concept, etc. so that newly born papers could be more easily
> classified. However, a new technology seems to make that less
> interesting. It's called topic modeling. See
> 
> http://blogs.zdnet.com/emergingtech?p=304
> 
> Given a continuous process that scans incoming papers you
> could add them to a semantic network which models information
> that I find useful and in ways that I find useful.

Do you mean have each user of Axiom define their own model according to
their individual needs?  I suppose that makes sense to an extent.

A possible test for such a system might be to use the MSC2000 system -
some papers have subject assignment (or assignments) by their authors. 
A system for automatic classification could scan those papers, generate
primary and sub-classifications using MSC2000 categories, and then
check the generated results against those assigned by the authors. 
Eventually, journals might be able to automatically classify incoming
papers using such algorithms, although I think there will always be an
advantage to having a human evaluate the focus and application of a
paper.
 
> Axiom could strongly benefit from such technology if we could
> find a good source of technical papers.

I would think the only currently viable sources would be the major
journals in particular fields of interest, since they will carry the
major bodies of research for their fields.  Whether they would be
interested in such an idea I don't know.

> Starting from an initial
> source we could collect electronic conference papers and classify
> them. Then Axiom could just look up a concept like "Groebner Basis",
> follow it to "Homological Algebra" then onto "Computing P-modules"
> and then onto finding an algorithm for computing a presentation
> of a finitely generated P-module. Ideally the paper would be
> literate and contain code that was automatically incorporated
> into the system. 

An interesting idea indeed - unfortunately, the starting point would be
to retro-fit existing work into such a system, in order to have
something to build on.  The sheer magnitude of the task aside, I rather
doubt copyright, journal finanical self interest, and other such
mundane issues would allow such a broad program to take off in the
current climate, except possibly in a few sub-disiciplines.

> The Crystal idea has a facet that constantly watches the user
> interaction, maintians an "intensional stance" of the user,
> and tries to find related, relevant work. This technology would
> be ideal behind such a facet.

Indeed.

> Automatic classification algorithms are always more effective
> in limited domains (e.g. math) than in unspecified domains.
> 
> Sounds like an NSF or INRIA grant idea to me.
 
\start
Date: 30 Jul 2006 17:40:53 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Tim Daly writes:

| To find the error you need to run Latex in its normal noisy mode. Do
| 
|  make NOISE=
| 
| and you'll see the latex output.

    [...]

! Missing { inserted.
<inserted text> 
                {
l.150 S
       IGXCPU    & terminate process    & cpu time limit exceeded {\bf setrl...

? 

\start
Date: 30 Jul 2006 17:50:21 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Tim Daly writes:

| To find the error you need to run Latex in its normal noisy mode. Do
| 
|  make NOISE=
| 
| and you'll see the latex output.

! Missing $ inserted.
<inserted text> 
                $
l.195 The {\sl uap} argument to a POSIX SA_
                                           SIGINFO handler points to an inst...

\start
Date: 30 Jul 2006 18:13:18 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Tim Daly writes:

| To find the error you need to run Latex in its normal noisy mode. Do
| 
|  make NOISE=
| 
| and you'll see the latex output.

LaTeX Warning: File `ps/axiomFront.ps' not found on input line 15.


! LaTeX Error: File `ps/axiomFront.ps' not found.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...                                              
                                                  
l.15 \center{\includegraphics{ps/axiomFront.ps}
                                               }
? 
! LaTeX Error: Cannot determine size of graphic in ps/axiomFront.ps
                                               (no Boundin
gBox).

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...                                              
                                                  
l.15 \center{\includegraphics{ps/axiomFront.ps}
                                               }
? <ps/axiomFront.ps>

LaTeX Warning: File `ps/bluebayou.ps' not found on input line 17.


! LaTeX Error: File `ps/bluebayou.ps' not found.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...                                              
                                                  
l.17 \includegraphics{ps/bluebayou.ps}
                                      \\
? 

\start
Date: Sun, 30 Jul 2006 12:47:32 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

patched. fixed in the next release. --t

(no, i still don't have SVN working. there is no time)

\start
Date: Sun, 30 Jul 2006 12:49:46 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

please post "diff -Naur" patch  files. 
this does not have sufficient information. 
what file contains this line?

t

================================================================

| To find the error you need to run Latex in its normal noisy mode. Do
| 
|  make NOISE=
| 
| and you'll see the latex output.

! Missing $ inserted.
<inserted text> 
                $
l.195 The {\sl uap} argument to a POSIX SA_
                                           SIGINFO handler points to an inst...

? 

\start
Date: Sun, 30 Jul 2006 19:39:40 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Tim,

Don't you have a debian system running? Then you simply have to type

apt-get install subversion

I think we should submit patches to Silver (that is why it is there) and 
you take them from the subversion repository before you release a new 
gold branch.

Otherwise I fear that Gold and Silver diverge.

We all should take care that the silver trunk (almost) always compiles.

\start
Date: 30 Jul 2006 19:47:31 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Tim Daly writes:

| patched. fixed in the next release. --t
| 
| (no, i still don't have SVN working. there is no time)

Then, please could send a patch to the list?  

\start
Date: 30 Jul 2006 19:48:33 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Ralf Hemmecke writes:

[...]

| Otherwise I fear that Gold and Silver diverge.

That is one my big concerns too.  It is a situation I would hate to
see happen.

\start
Date: 30 Jul 2006 19:50:55 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Tim Daly writes:

| please post "diff -Naur" patch  files. 

This is not a patch file.  It is LaTeX error on one of the pamphlet file. 

I meant to send the build log (when it is finished) but previous
attemps met resistance as the log is judged "too big" for the mailer
at the other end of SF.

\start
Date: 30 Jul 2006 19:52:25 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Tim Daly writes:

| To find the error you need to run Latex in its normal noisy mode. Do
| 
|  make NOISE=
| 
| and you'll see the latex output.

(./transsolve.spad.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german,
ngerman, bahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
esperanto, estonian, finnish, greek, icelandic, irish, italian, latin, magyar,
norsk, polish, portuges, romanian, russian, serbian, slovak, slovene, spanish,
swedish, turkish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo)) (./axiom.sty)
No file transsolve.spad.aux.
[1]
No file transsolve.spad.toc.
[2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
! You can't use `macro parameter character #' in horizontal mode.
l.513 generates the error (reported as bug #
                                             102):
? 

\start
Date: Sun, 30 Jul 2006 14:10:12 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

I've tried to get debian running several times without success.
I downloaded a 9 CD Debian set, spent half a day trying to install
it and it fails. 
Bad karma, I guess.

On the other hand, I have to say that I don't have the cycles
available to keep Gold and Silver in sync. It's not for lack
of desire, it's lack of time.

When I agreed to the SVN repository I was under the impression that
there was a demand for a place where users could create clone systems
so they could pursue their own goals, similar to what I do locally.
There was never an understanding on my part that I'd be doing any
maintenance on it.

\start
Date: 30 Jul 2006 20:55:53 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Tim Daly writes:

| On the other hand, I have to say that I don't have the cycles
| available to keep Gold and Silver in sync. It's not for lack
| of desire, it's lack of time.

then, just send the patches you applied to gold to the list.  That
way, other people (like) who would have time can apply them.

| When I agreed to the SVN repository I was under the impression that
| there was a demand for a place where users could create clone systems
| so they could pursue their own goals, similar to what I do locally.
| There was never an understanding on my part that I'd be doing any
| maintenance on it.

You're not asked to maintain it :-)  Just play with us to make sure
that corrections to gold is also present in silver.

However, the only meaningful way people can productively "play" with
th silver branch is when it is not far from the gold.  Nobody would
want to waste its time on a system that is *for sure* very remote from
the gold.  We all agree that we don't have enough resource; the last
thing we want to do is to waste the scarse resources in many wasteful
forks. 

\start
Date: Sun, 30 Jul 2006 15:34:16 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

> However, the only meaningful way people can productively "play" with
> th silver branch is when it is not far from the gold. 

I have several systems that are very, very far from Gold.
They include interpreter rewrites, algebra rewrites, browser
rewrites, etc. The only way to make progress is to move away
from Gold, mangle functionality, prove it, merge it, test it,
and then promote it. This takes months.

My impression was that SVN was going to be a place where people could
clone Silver and do their own subsystem, say to explore ideas like
working with Sage or a complete rewrite using ALLPROSE.. I don't have
the time to look at the Sage idea but someone could do this in SVN and
let people play with it. Once it works the way people like then the
effort to merge it into Silver and promote it to Gold can start.


>                                                        Nobody would
> want to waste its time on a system that is *for sure* very remote from
> the gold.  

We had a very long email thread about update rates to Axiom.
The issue was striking a balance between "immediate fixes" and
"reasonable workload". After much discussion we agreed that a
new copy of the system would be released approximately once every
2 months. This is not immediate (notice that Gold has not changed
since April, despite fixes being applied). This is not slanted
toward a reasonable workload (6 months).

So patches get collected and the Gold copy is built/tested/ported
every 2 months or so. I missed the goal this past month due to
preparation for ISSAC and now, due to updates caused by ISSAC.

Gold gets released every couple months. Silver can do a simple
  diff -r --brief Gold Silver
to see exact changes.

Given the rate of change it isn't possible for Silver to drift
far from Gold.


On the other hand, Silver can do immediate patches if someone is
willing to do them. My objection to immediate patches in Gold is
that it takes me several days to "release" a Gold system (due to
testing and porting). I don't want to release a broken system.

If I took on the responsibility of doing immediate patches to 
Silver that would completely negate the whole "update rate"
balance discussion. You can't just throw a patch at a system.
You have to check it. That takes time even for simple patches.
For instance, I have a simple fix to the Makefiles for libXpm
that makes the system compile correctly on FC5. However, it
breaks Redhat systems. So if I just applied the patch to Silver
without testing some of the users would have broken code.

; We all agree that we don't have enough resource; the last
> thing we want to do is to waste the scarse resources in many wasteful
> forks. 

Resource is exactly the point of the "reasonable update rate" issue.
There are things that only I can do and these are things that I should
spend time doing. There are things that others can do (like apply
patches to Silver) and these are things that I should not be doing.

\start
Date: 30 Jul 2006 23:41:37 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Tim Daly writes:

| > However, the only meaningful way people can productively "play" with
| > th silver branch is when it is not far from the gold. 
| 
| I have several systems that are very, very far from Gold.
| They include interpreter rewrites, algebra rewrites, browser
| rewrites, etc. The only way to make progress is to move away
| from Gold, mangle functionality, prove it, merge it, test it,
| and then promote it. This takes months.

Yes, but I was specifically talking of this

   #  patched. fixed in the next release. --t

Whatever that "next release" is, I strongly believe that that patch
ought to be in silver too -- because it is fixing a problem that is also
present in silver.  

If you can't apply the patches because of system packages issues,
please just send it to the list. 

| My impression was that SVN was going to be a place where people could
| clone Silver and do their own subsystem, say to explore ideas like
| working with Sage or a complete rewrite using ALLPROSE..

That is correct.  However, it would be a good use if they don't have
to clone all the problems that are known to be already fixed...

| I don't have
| the time to look at the Sage idea but someone could do this in SVN and
| let people play with it. Once it works the way people like then the
| effort to merge it into Silver and promote it to Gold can start.

That is a very good thing to do, indeed.

| >                                                        Nobody would
| > want to waste its time on a system that is *for sure* very remote from
| > the gold.  
| 
| We had a very long email thread about update rates to Axiom.
| The issue was striking a balance between "immediate fixes" and
| "reasonable workload". After much discussion we agreed that a
| new copy of the system would be released approximately once every
| 2 months. This is not immediate (notice that Gold has not changed
| since April, despite fixes being applied). This is not slanted
| toward a reasonable workload (6 months).

I don't propose we change that "regular best effort".  The only thing
that I'm suggesting is that, when we have a problem in both Gold and
Silver and you have a fix for it (against Gold), just send the patch
to the list.

| So patches get collected and the Gold copy is built/tested/ported
| every 2 months or so. I missed the goal this past month due to
| preparation for ISSAC and now, due to updates caused by ISSAC.

that is quite reasonable: you are doing too many things and I don't
know where you find the time to handle all that :-)

| Gold gets released every couple months. Silver can do a simple
|   diff -r --brief Gold Silver
| to see exact changes.

That would not be workable because:
  (1) silver contains the "immediate" fix;
  (2) not everything in Silver will end up in Gold;
  (3) the diff between Gold and Silver after two months, in general is
      not just what Gold added.

| Given the rate of change it isn't possible for Silver to drift
| far from Gold.
| 
| 
| On the other hand, Silver can do immediate patches if someone is
| willing to do them. My objection to immediate patches in Gold is
| that it takes me several days to "release" a Gold system (due to
| testing and porting). I don't want to release a broken system.

I believe everybody agrees on Gold being very very stable.  The
description of Silver (and my understanding of it) is that it contains
immediate fixes (though it must be stable), and only when the fixes
mature enough and uncrontroversial, they can move to Gold.
One of the reasons I volunteered to maintain Silver is precisely to
help share the workload.

| If I took on the responsibility of doing immediate patches to 
| Silver that would completely negate the whole "update rate"
| balance discussion.

In that case, just send your patches against Gold (i.e. when you say
"fixed in next release").

| You can't just throw a patch at a system.
| You have to check it. That takes time even for simple patches.

All that is understood.

| For instance, I have a simple fix to the Makefiles for libXpm
| that makes the system compile correctly on FC5. However, it
| breaks Redhat systems. So if I just applied the patch to Silver
| without testing some of the users would have broken code.

I understood that.  Nobody suggested you apply the patches to Silver
without testing.

| ; We all agree that we don't have enough resource; the last
| > thing we want to do is to waste the scarse resources in many wasteful
| > forks. 
| 
| Resource is exactly the point of the "reasonable update rate" issue.
| There are things that only I can do and these are things that I should
| spend time doing. There are things that others can do (like apply
| patches to Silver) and these are things that I should not be doing.

We can test and apply the patches if we *have* them.  Please, just
send your version against Gold.

\start
Date: 31 Jul 2006 00:47:51 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Tim --

  I'm looking into the LaTeX issues with bsdsignal.c.pamphlet.
One of them has to do with the following tabular material:

\begin{tabular}{ll}
[EFAULT] & Either {\sl act} or {\sl oact} points to memory that is not a\\
         & valid part of the process address space\\
[EINVAL] & The {\sl sig} argument is not a valid signal number\\
[EINVAL] & An attempt is made to ignore or supply a handler for SIGKILL\\
         & or SIGSTOP
\end{tabular}

I suspect LaTeX is interpreting the stuff in [...] as an option, then
gets confused.  Did you mean to use double brackets [[...]]?

More generally, the style does not seem consitent to me; sometimes it
is {\sl ... }, sometimes is [[....]], sometimes it is just plain text.
What are the general rules?

\start
Date: 31 Jul 2006 01:39:28 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Gabriel Dos Reis writes:

| Tim --
| 
|   I'm looking into the LaTeX issues with bsdsignal.c.pamphlet.
| One of them has to do with the following tabular material:
| 
| \begin{tabular}{ll}
| [EFAULT] & Either {\sl act} or {\sl oact} points to memory that is not a\\
|          & valid part of the process address space\\
| [EINVAL] & The {\sl sig} argument is not a valid signal number\\
| [EINVAL] & An attempt is made to ignore or supply a handler for SIGKILL\\
|          & or SIGSTOP
| \end{tabular}
| 
| I suspect LaTeX is interpreting the stuff in [...] as an option, then
| gets confused.  Did you mean to use double brackets [[...]]?

With the patch below, testing passed the points of failure.  I'll
commit once the full build is finished.

There, however, remain other issues related to included PostScript
files not found.  More on that later.

-- Gaby

2006-07-30  Gabriel Dos Reis  Gabriel Dos Reis

	* bsdsignal.c.pamphlet: Fix typo "(\bf" -> "{\bf".
	"SA_" -> "SA\_".
	Remove material in brackets; LaTeX was confused.

*** bsdsignal.c.pamphlet	(revision 15546)
--- bsdsignal.c.pamphlet	(local)
*************** SIGTTIN    & stop process         & back
*** 146,152 ****
             &                      & control terminal\\
  SIGTTOU    & stop process         & background write attempted from\\
             &                      & control terminal\\
! SIGIO      & discard signal       & I/O is possible on a descriptor (\bf fcntl(2)}\\
  SIGXCPU    & terminate process    & cpu time limit exceeded {\bf setrlimit(2)}\\
  SIGXFSZ    & terminate process    & file size limit exceeded {\bf setrlimit(2)}\\
  SIGVTALRM  & terminate process    & virtual time alarm {\bf setitimer(2)}\\
--- 146,152 ----
             &                      & control terminal\\
  SIGTTOU    & stop process         & background write attempted from\\
             &                      & control terminal\\
! SIGIO      & discard signal       & I/O is possible on a descriptor {\bf fcntl(2)}\\
  SIGXCPU    & terminate process    & cpu time limit exceeded {\bf setrlimit(2)}\\
  SIGXFSZ    & terminate process    & file size limit exceeded {\bf setrlimit(2)}\\
  SIGVTALRM  & terminate process    & virtual time alarm {\bf setitimer(2)}\\
*************** info argument to a SA\_SIGINFO handler c
*** 192,207 ****
  cause of the signal, usually on of the SI\_\ldots values from {\sl <sys/signal.h>}
  or codes specific to a signal, i.e. one of the FPE\_\ldots values for SIGFPE.
  
! The {\sl uap} argument to a POSIX SA_SIGINFO handler points to an instance of 
  ucontext\_t.
  
  The {\bf sigaction()} system call will fail and no new signal handler will be
  installed if one of the following occurs:
  \begin{tabular}{ll}
! [EFAULT] & Either {\sl act} or {\sl oact} points to memory that is not a\\
           & valid part of the process address space\\
! [EINVAL] & The {\sl sig} argument is not a valid signal number\\
! [EINVAL] & An attempt is made to ignore or supply a handler for SIGKILL\\
           & or SIGSTOP
  \end{tabular}
  \section{MAC OSX and BSD platform change}
--- 192,207 ----
  cause of the signal, usually on of the SI\_\ldots values from {\sl <sys/signal.h>}
  or codes specific to a signal, i.e. one of the FPE\_\ldots values for SIGFPE.
  
! The {\sl uap} argument to a POSIX SA\_SIGINFO handler points to an instance of 
  ucontext\_t.
  
  The {\bf sigaction()} system call will fail and no new signal handler will be
  installed if one of the following occurs:
  \begin{tabular}{ll}
! EFAULT & Either {\sl act} or {\sl oact} points to memory that is not a\\
           & valid part of the process address space\\
! EINVAL & The {\sl sig} argument is not a valid signal number\\
! EINVAL & An attempt is made to ignore or supply a handler for SIGKILL\\
           & or SIGSTOP
  \end{tabular}
  \section{MAC OSX and BSD platform change}

\start
Date: Sun, 30 Jul 2006 20:40:11 -0400
From: Alfredo Portes
To: Bill Page, 
Subject: Doyen

Hi Bill,

I think I finished copying the front-page for the Doyen CD from
axiom-developer.
Please when you have a chance, if you can check the site:

http://doyen.sytes.net

Work still has to be done in the interior pages, but all the links in
the front page take to their appropriate content.

Anybody that feels more information should be added, especially when
the live cds are distributed in conferences, please let me know, or
please feel free to make the changes yourself.

\start
Date: 31 Jul 2006 03:12:34 +0200
From: Gabriel Dos Reis
To: list
Subject: Axiom build failure on an x86_64-unknown-linux-gnu

Hi,

I got a new machine (64-bit) for work 

gdr@monad:~/build> cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      :               Intel(R) Pentium(R) D CPU 2.80GHz
stepping        : 7
cpu MHz         : 2793.182
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm
bogomips        : 5592.20
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      :               Intel(R) Pentium(R) D CPU 2.80GHz
stepping        : 7
cpu MHz         : 2793.182
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall
nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm
bogomips        : 5586.19
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:


and I've been trying to set up Axiom on it.  It is running SuSE 10.1
So far, I've been unsuccessful to build Axiom.  The failure is at

[...]
1 linking /home/gdr/build/axiom.2006-07-30/build/mnt/linux/lib/viewman
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so when searching for -lX11
/usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.a when searching for -lX11
/usr/bin/ld: cannot find -lX11
collect2: ld returned 1 exit status
make[4]: *** [/home/gdr/build/axiom.2006-07-30/build/mnt/linux/lib/viewman] Error 1


The root of the problem is that (I suspect) Axiom has hardcoded the
path to libX11, e.g. /usr/X11R6/lib.  In fact, on a 64-bit system, it
is better to let configure find the good path (people have already
solved this kind of problem, we don't need to go through it again).
The path should be /usr/X11R6/lib64.

\start
Date: Sun, 30 Jul 2006 21:35:28 -0400
From: Bill Page
To: Alfredo Portes
Subject: RE: Doyen

Alfredo

Thanks for setting this up. This content on the DoyenCD is
very important. I hope some other people here on this list
take a few moments to review the pages that you have already
added and to suggest a few more pages that should be merged
from the Axiom Wiki.

It is very easy to update the documentation on the DoyenCD
now that you have set up this web site.

On July 30, 2006 8:40 PM you wrote:
> 
> I think I finished copying the front-page for the Doyen CD
> from axiom-developer. Please when you have a chance, if you
> can check the site:
> 
> http://doyen.sytes.net
>

I think it's looking good!

Do you think we should contact our Axiom sponsors to make sure
they have no objection to being named on the frontpage of Doyen?
I presume that CAISS has already given permission, but perhaps
we should also get the official approval of RISC. Ralf Hemmecke
is our contact person there.
 
> Work still has to be done in the interior pages, but all the
> links in the front page take to their appropriate content.

I noticed (e.g. click Axiom Book download) that you were still
missing the 'Mirrors' dtml method that serves to re-direct
downloads and remind people about donation, participation
options etc.

I just got the source text here:

http://wiki.axiom-developer.org/Mirrors/src

and created a new named Mirrors with a page type of
'StructuredText(+DTML)'. Of course you might want to change a
few things, e.g. add another link to the page that allows the
user to choose between a local download from the local Cdrom or
from either the main axiom-developer site or the axiom-risc
mirror. Maybe the over the web downloads aren't necessary here?

> 
> Anybody that feels more information should be added, especially
> when the live cds are distributed in conferences, please let
> me know, or please feel free to make the changes yourself.
> 

Besides creating the Mirrors page I also updated the link to
IssueTracker so that it always points to axiom-developer.org.
I'll try to find a little more time tomorrow to take another
look.

\start
Date: Sun, 30 Jul 2006 21:48:26 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Axiom build failure on an x86_64-unknown-linux-gnu

Gaby,

On July 30, 2006 9:13 PM you wrote:
> 
> I got a new machine (64-bit) for work 
> 
> ... 
> and I've been trying to set up Axiom on it.  It is running SuSE
> 10.1 So far, I've been unsuccessful to build Axiom.  The failure
> is at
> 
> [...]
> 1 linking /home/gdr/build/axiom.2006-07-30/build/mnt/linux/lib/viewman
> /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so 
> when searching for -lX11
> /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.a 
> when searching for -lX11
> /usr/bin/ld: cannot find -lX11
> collect2: ld returned 1 exit status
> make[4]: *** 
> [/home/gdr/build/axiom.2006-07-30/build/mnt/linux/lib/viewman] Error 1
>

I have been running Axiom on an  AMD64 Fedora Core 4 system for
about a year.
 
> 
> The root of the problem is that (I suspect) Axiom has hardcoded the
> path to libX11, e.g. /usr/X11R6/lib.  In fact, on a 64-bit system,
> it is better to let configure find the good path (people have already
> solved this kind of problem, we don't need to go through it again).
> The path should be /usr/X11R6/lib64.
>

Yes. This was discussed just about this time last year:

http://lists.nongnu.org/archive/html/axiom-developer/2005-06/msg00449.html

What is the current state of the work towards creating a proper
configure for the Axiom build? Are you actively working on it?
If so, do you need any help with specific parts of the build or
any other issues?

\start
Date: Sun, 30 Jul 2006 22:10:07 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Axiom build failure on an x86_64-unknown-linux-gnu

Gaby,

in src/hyper/Makefile.pamphlet do:

-           ${LIB}/bsdsignal.o ${LDFLAGS} ${XLIB}/libXpm.a -lX11 -lm -L${LIB} )
+           ${LIB}/bsdsignal.o ${LDFLAGS} -l Xpm -lX11 -lm -L${LIB} )

in src/graph/view2D/Makefile.pamphlet do:

-	 -o ${OUT}/view2D ${XLIB}/libXpm.a $(LDFLAGS) 
+	 -o ${OUT}/view2D -l Xpm $(LDFLAGS) 



This isn't the full, correct change but it will work for your problem.
The next release, which I'm working on now, should fix it fully.

\start
Date: Sun, 30 Jul 2006 22:24:26 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Axiom build failure on an x86_64-unknown-linux-gnu

NOTE: do NOT apply this change globally as it does not work everywhere.


=================================================================
in src/hyper/Makefile.pamphlet do:

-           ${LIB}/bsdsignal.o ${LDFLAGS} ${XLIB}/libXpm.a -lX11 -lm -L${LIB} )
+           ${LIB}/bsdsignal.o ${LDFLAGS} -l Xpm -lX11 -lm -L${LIB} )

in src/graph/view2D/Makefile.pamphlet do:

-	 -o ${OUT}/view2D ${XLIB}/libXpm.a $(LDFLAGS) 
+	 -o ${OUT}/view2D -l Xpm $(LDFLAGS) 



This isn't the full, correct change but it will work for your problem.
The next release, which I'm working on now, should fix it fully.

\start
Date: 31 Jul 2006 06:41:41 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom build failure on an x86_64-unknown-linux-gnu

Bill Page writes:

| Gaby,
| 
| On July 30, 2006 9:13 PM you wrote:
| > 
| > I got a new machine (64-bit) for work 
| > 
| > ... 
| > and I've been trying to set up Axiom on it.  It is running SuSE
| > 10.1 So far, I've been unsuccessful to build Axiom.  The failure
| > is at
| > 
| > [...]
| > 1 linking /home/gdr/build/axiom.2006-07-30/build/mnt/linux/lib/viewman
| > /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so 
| > when searching for -lX11
| > /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.a 
| > when searching for -lX11
| > /usr/bin/ld: cannot find -lX11
| > collect2: ld returned 1 exit status
| > make[4]: *** 
| > [/home/gdr/build/axiom.2006-07-30/build/mnt/linux/lib/viewman] Error 1
| >
| 
| I have been running Axiom on an  AMD64 Fedora Core 4 system for
| about a year.

well, looks like, we have a portability problem...

| > The root of the problem is that (I suspect) Axiom has hardcoded the
| > path to libX11, e.g. /usr/X11R6/lib.  In fact, on a 64-bit system,
| > it is better to let configure find the good path (people have already
| > solved this kind of problem, we don't need to go through it again).
| > The path should be /usr/X11R6/lib64.
| >
| 
| Yes. This was discussed just about this time last year:
| 
| http://lists.nongnu.org/archive/html/axiom-developer/2005-06/msg00449.html
| 
| What is the current state of the work towards creating a proper
| configure for the Axiom build? Are you actively working on it?

yes; I'm still working on it.  Rather, I was still wroking on it till
the last hectic month and half.  But when I came back, I did resume
the work.

\start
Date: 31 Jul 2006 06:43:27 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom build failure on an

Tim Daly writes:

| NOTE: do NOT apply this change globally as it does not work everywhere.

sure -- the build is from a source check out anonymously, and there is
no chance I would risk a global check in :-)

Thanks!

\start
Date: Mon, 31 Jul 2006 10:05:11 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Hi Gaby,

I have also come across that bug some time. It is just a missing 
backslash in front of the special character #.

I've included the patch at the end.

Why I did not send it was that I find "diff -Naur" rather inconvenient.
And I was not yet fully through with the compilation of Silver, but 
wanted to submit a whole changeset. Unfortunately, some other business 
stopped my work on the compilation.

I usually have just one working copy. If I come across a problem, I fix 
it and try to recompile. If it works, fine. But if I should submit a 
"diff -Naur" patch I need the old an the new file. The old file is gone, 
of course, so I need a checkout of a second (original) working copy to 
be able to "diff -Naur". I believe that that is completely unnecessary, 
because the SVN working copy as well as the tla working copy have the 
original files stored either in .svn or in the {arch} subdirectories.

I just don't know how I would use "diff" in a convenient way. Could 
somebody suggest something and put it onto the Wiki?

http://wiki.axiom-developer.org/HowToSubmitPatches

That would really make things simpler.

Thanks
Ralf

On 07/30/2006 07:52 PM, Gabriel Dos Reis wrote:
> Tim Daly writes:
> 
> | To find the error you need to run Latex in its normal noisy mode. Do
> | 
> |  make NOISE=
> | 
> | and you'll see the latex output.
> 
> (./transsolve.spad.tex
> LaTeX2e <2003/12/01>
> Babel <v3.8d> and hyphenation patterns for american, french, german,
> ngerman, bahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,
> esperanto, estonian, finnish, greek, icelandic, irish, italian, latin, magyar,
> norsk, polish, portuges, romanian, russian, serbian, slovak, slovene, spanish,
> swedish, turkish, ukrainian, nohyphenation, loaded.
> (/usr/share/texmf/tex/latex/base/article.cls
> Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
> (/usr/share/texmf/tex/latex/base/size10.clo)) (./axiom.sty)
> No file transsolve.spad.aux.
> [1]
> No file transsolve.spad.toc.
> [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
> ! You can't use `macro parameter character #' in horizontal mode.
> l.513 generates the error (reported as bug #
>                                              102):
> ? 




--- transsolve.spad.pamphlet	2006-07-02 23:05:52.000000000 +0200
+++ transsolve.spad.pamphlet.new	2006-07-02 23:13:27.000000000 +0200
@@ -510,7 +510,7 @@
  \begin{verbatim}
    solve(sinh(z)=cosh(z),z)
  \end{verbatim}
-generates the error (reported as bug # 102):
+generates the error (reported as bug \# 102):
  \begin{verbatim}
   >> Error detected within library code:
      No identity element for reduce of empty list using operation append

\start
Date: Mon, 31 Jul 2006 10:24:43 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

On 07/30/2006 08:10 PM, root wrote:
> I've tried to get debian running several times without success.
> I downloaded a 9 CD Debian set, spent half a day trying to install
> it and it fails. 
> Bad karma, I guess.

But you have Fedora running, and I believe that it comes with a 
Subversion package. ;-)

> On the other hand, I have to say that I don't have the cycles
> available to keep Gold and Silver in sync. It's not for lack
> of desire, it's lack of time.

No problem Tim, if you don't want to bother with Silver too much then 
just make your most recent Gold branch available as a tla archive on

http://axiom-developer.org/archive/axiom

and call it Silver. Gaby if you agree we should keep that branch in sync 
with the SVN trunk.

> When I agreed to the SVN repository I was under the impression that
> there was a demand for a place where users could create clone systems
> so they could pursue their own goals, similar to what I do locally.

Yes, sure, but SVN let's you also create branches, and there is no 
reason to have the latest patches that are applied to the 
"next-release-gold" also to the silver (trunk). In fact, I strongly believe

   next-release-gold  == silver/trunk                            (*)

> There was never an understanding on my part that I'd be doing any
> maintenance on it.

IIRC, I once set up a tla working copy that was at the same time a SVN 
working copy. It would actually be easy to keep (*) in sync via such a 
working copy.

But even if we agree that (*) does not hold and we have to send "diff 
-Naur" patches via the mailing list to Tim it would be just perfect to 
have Tim's "next-release-gold" somewhere available.

Gaby, if you agree on this "special working copy" I could try to figure 
out how I did that and send you the algorithm to set it up. (I think, 
that you should be the maintainer of it. And nobody else would be 
allowed to commit to silver/trunk.)

\start
Date: Mon, 31 Jul 2006 10:43:40 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

> So patches get collected and the Gold copy is built/tested/ported
> every 2 months or so.

No problem. But we should also start to think about freezing the 
"next-release-gold", call it "GoldAxiomVersion-x.y-ReleaseCandidate", 
make it available publicly and post to the mailing list that everyone 
should test it on his/her system to find problems. If there is no 
problem reported anymore, Tim could turn the release-candidate into a 
true Gold-release.

That process would share the workload of Tim and prevent things that 
happened once with releasing a broken Gold system.

> Gold gets released every couple months. Silver can do a simple
>   diff -r --brief Gold Silver
> to see exact changes.

That is too late. People want to see the hottest edge.

next-release-gold == silver/trunk

I am very much in favour of that. And I thought that was the idea from 
the beginning---mirror the hottest edge on sourceforge.net.

> If I took on the responsibility of doing immediate patches to 
> Silver that would completely negate the whole "update rate"
> balance discussion. You can't just throw a patch at a system.
> You have to check it. That takes time even for simple patches.
> For instance, I have a simple fix to the Makefiles for libXpm
> that makes the system compile correctly on FC5. However, it
> breaks Redhat systems. So if I just applied the patch to Silver
> without testing some of the users would have broken code.

Tim, if someone is willingly not taking the Gold release, but decides 
for Silver==(all patches applied to the latest Gold release), s/he 
should know that things might be broken. But that is not a bug, it's a 
feature. People could help to figure out why the system doesn't build 
and could supply another patch to you. If they just see Gold and not the 
latest patches+bugfixes, people might find just bugs that are already 
fixed. It's a waste of time and might make people turn away from Axiom.

> There are things that only I can do

For example?

\start
Date: Mon, 31 Jul 2006 11:18:23 +0200
From: Frederic Lehobey
To: Axiom developers <list>
Subject: Re: Axiom build failure on an x86_64-unknown-linux-gnu
Cc: Soren Hansen

Hi,

On Mon, Jul 31, 2006 at 03:12:34AM +0200, Gabriel Dos Reis wrote:

> and I've been trying to set up Axiom on it.  It is running SuSE 10.1
> So far, I've been unsuccessful to build Axiom.  The failure is at
>
> [...]
> 1 linking /home/gdr/build/axiom.2006-07-30/build/mnt/linux/lib/viewman
> /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.so when search=
ing for -lX11
> /usr/bin/ld: skipping incompatible /usr/X11R6/lib/libX11.a when searchi=
ng for -lX11
> /usr/bin/ld: cannot find -lX11
> collect2: ld returned 1 exit status
> make[4]: *** [/home/gdr/build/axiom.2006-07-30/build/mnt/linux/lib/view=
man] Error 1
>
>
> The root of the problem is that (I suspect) Axiom has hardcoded the
> path to libX11, e.g. /usr/X11R6/lib.  In fact, on a 64-bit system, it
> is better to let configure find the good path (people have already
> solved this kind of problem, we don't need to go through it again).
> The path should be /usr/X11R6/lib64.

Other people are experiencing the same kind of problem. You can find
there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376017 (in the
http://bugs.debian.org/cgi-bin/bugreport.cgi/axiom_ftbfs.debdiff?bug=37=
6017;msg=10;att=1
file) the solution used by the Ubuntu people (namely Soren Hansen
Soren Hansen). (Interesting lines are at the end of the monolithic
patch with respect to Camm's Debian package.)

\start
Date: 31 Jul 2006 13:27:48 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom build failure on an x86_64-unknown-linux-gnu

Tim Daly writes:

| Gaby,
|
| in src/hyper/Makefile.pamphlet do:
|
| -           ${LIB}/bsdsignal.o ${LDFLAGS} ${XLIB}/libXpm.a -lX11 -lm -L${=
LIB} )
| +           ${LIB}/bsdsignal.o ${LDFLAGS} -l Xpm -lX11 -lm -L${LIB} )
|
| in src/graph/view2D/Makefile.pamphlet do:
|
| -	 -o ${OUT}/view2D ${XLIB}/libXpm.a $(LDFLAGS)
| +	 -o ${OUT}/view2D -l Xpm $(LDFLAGS)
|
|
|
| This isn't the full, correct change but it will work for your problem.
| The next release, which I'm working on now, should fix it fully.

Thanks Tim.
The problem is with X11 lib, not with Xpm (at least I've not gotten to
that point yet).  The above patch does not solve the build faiilure.

I'll look at Frederric's suggestion -- but later, because of daytime job.

\start
Date: Mon, 31 Jul 2006 13:33:06 +0200
From: Kai Kaminski
To: Ralf Hemmecke
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

> I usually have just one working copy. If I come across a problem, I 
> fix it and try to recompile. If it works, fine. But if I should submit 
> a "diff -Naur" patch I need the old an the new file. The old file is 
> gone, of course, so I need a checkout of a second (original) working 
> copy to be able to "diff -Naur". I believe that that is completely 
> unnecessary, because the SVN working copy as well as the tla working 
> copy have the original files stored either in .svn or in the {arch} 
> subdirectories.
>
> I just don't know how I would use "diff" in a convenient way. Could 
> somebody suggest something and put it onto the Wiki?
>
> http://wiki.axiom-developer.org/HowToSubmitPatches
I don't have Subversion installed right now, so I can't check wether 
this actually works, but according to the documentation the following 
should do the trick:

svn diff --diff-cmd /usr/bin/diff -x "-Naur" some.foo.pamphlet

Of course, it is possible to specify the revisions to compare etc. For 
more details, see http://svnbook.red-bean.com/en/1.0/re09.html.

Kai

PS: If this is what you've been looking for, I'll put it on the wiki.

\start
Date: Mon, 31 Jul 2006 13:53:27 +0200
From: Ralf Hemmecke
To: Kai Kaminski
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

> svn diff --diff-cmd /usr/bin/diff -x "-Naur" some.foo.pamphlet

Super.

> PS: If this is what you've been looking for, I'll put it on the wiki.

Yes, please.

Thank you.

\start
Date: Mon, 31 Jul 2006 08:48:18 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Ralf,

Before you change a file, copy it. I usually do:

   cp transolve.spad.pamphlet transolve.spad.pamphlet.org
   edit transolve.spad.pamphlet
   rebuild

and if it succeeds then I do:

   diff -Naur transolve.spad.pamphlet.org transolve.spad.pamphlet >patch

and post the patch.

\start
Date: 31 Jul 2006 15:35:40 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Ralf Hemmecke writes:

| Hi Gaby,
| 
| I have also come across that bug some time. It is just a missing
| backslash in front of the special character #.
| 
| I've included the patch at the end.

Thanks, I'll test it commit to Silver.

| Why I did not send it was that I find "diff -Naur" rather inconvenient.
| And I was not yet fully through with the compilation of Silver, but
| wanted to submit a whole changeset. Unfortunately, some other business
| stopped my work on the compilation.
| 
| I usually have just one working copy. If I come across a problem, I
| fix it and try to recompile. If it works, fine. But if I should submit
| a "diff -Naur" patch I need the old an the new file. The old file is
| gone, of course, so I need a checkout of a second (original) working
| copy to be able to "diff -Naur". I believe that that is completely
| unnecessary, because the SVN working copy as well as the tla working
| copy have the original files stored either in .svn or in the {arch}
| subdirectories.


SVN comes with its own built-in "diff" utility that differs from usual
"diff" command.  Consequently, it does not understand the "-Naur"
option.  That is rather inconvenient.  I do agree.  When we moved GCC
to SVN, that was one of the "minor" inconveniences I found.

"Fortunately", people have been through that trouble before and
documented the "solution":

  http://gcc.gnu.org/wiki/SvnTricks

Look at the section "How can I get context diffs? How do I configure
an external diff tool?"

You don't need to have duplicate copies of Axiom before sending a
patch.  I suspect one would make more mistakes by hand-managing diffs
of copies than having widely-tested tools do it.

For those who uses SVK, I'll add a documentation later.

\start
Date: Mon, 31 Jul 2006 16:18:22 +0200
From: Kai Kaminski
To: Ralf Hemmecke
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

--Apple-Mail-2--45356570
	charset=US-ASCII;
	format=flowed

>> svn diff --diff-cmd /usr/bin/diff -x "-Naur" some.foo.pamphlet
>
> Super.
>
>> PS: If this is what you've been looking for, I'll put it on the wiki.
>
> Yes, please.
I can't change the wiki page, because it keeps asking me for a 
username/password. I probably have those, since I've used the wiki 
before, but I can't remember them. I attached the modified page source 
to this mail, so maybe someone else can just put it up.

I also added the equivalent commands for CVS and GNU Arch version 1.3.4 
and later. Since I only have GNU Arch version 1.3.0 I couldn't test the 
  Arch command. It would be nice if someone else could check that.

Kai


--Apple-Mail-2--45356570
	name="HowToSubmitPatches"
	filename=HowToSubmitPatches

This page describes how to submit a piece of code that corrects or
extends the Axiom project.

In general a patch file is of the form::

    cd the.dir
    diff -Naur file.pamphlet file.pamphlet.new >the.dir.file.pamphlet.patch

This has the following
features:

  * it tells where the patch is being applied

  * the '-Naur' options gives context

  * the impact of a change to multiple files become visible

If you don't like to keep the old version of files around, you
can use one of the following instead::

    svn diff --diff-cmd /usr/bin/diff -x -Naur file.pamphlet >the.dir.file.pamphlet.patch
    
    tla diff -D -Naur file.pamphlet >the.dir.file.pamphlet.patch

    cvs diff -NauR file.pamphlet >the.dir.file.pamphlet.patch

This assumes that you are using CVS, Subversion or GNU Arch 1.3.4 or later. 

Finally, send the patch to
<a href="mailto:Tim Daly">Tim Daly</a>.

Tim Daly reads the patches before applying them, so be sure to document the
reasons for the change in the pamphlet file. It may seem trivial
but remember that I didn't do the initial analysis so he, and others,
will have to understand after the fact.

In most cases in a pamphlet file if you're changing a few lines
of code or a whole function it should be documented thus::

    ...
    (defun foo ()
      (list
        "this is ok code"
        "this is broken code"
        "this is also broken"
        "this is ok"
      ) 
    )
 
turns
into::

    \subsection{foo list fix}
    This code used to read:
    \begin{verbatim}
        "this is broken code"
        "this is also broken"
    \end{verbatim}
    but clearly the elements of the list are wrong. We are going to
    print this list for the user so we don't want them to know anything
    is broken. Thus we have wonderful new code that will inspire confidence.
    This list is printed with the [[printlist]] function.
    <<foo list fix>>=
        "this is great code"
        "this inspires confidence"
    @
    ...
    (defun foo ()
      (list
        "this is ok code"
    <<foo list fix>>
        "this is ok"
      )
    )

and, yes, that this is tedious.

In general, it is also useful to update the pamphlet files with 
documentation-only changes as you understand what a block of code
is intended to do. Most of this information has been lost to history
and the world can leverage your efforts at understanding if you take
the time to document it. In many ways this is as important as fixing
the code.


**PS**: We will soon have another way to submit patches, since any modification should
first go into the <a href="../AxiomDownload">silver branch</a> and survive public review,
but the need to document properly will not be modified.

\start
Date: Mon, 31 Jul 2006 16:47:44 +0200
From: Ralf Hemmecke
To: Kai Kaminski
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

> I can't change the wiki page, because it keeps asking me for a 
> username/password. I probably have those, since I've used the wiki 
> before, but I can't remember them. I attached the modified page source 
> to this mail, so maybe someone else can just put it up.

Done. Thanks for supplying the change.

I have modified a little, because patches should be sent to the list and 
not just Tim alone.

Bill, I guess Kai had problems because he did not provide a reason for 
the change. (I fell into the same trap.)

Could you make change the Edit page and let appear "Reason for the 
Change" in red?

\start
Date: Mon, 31 Jul 2006 10:46:46 -0400
From: Alfredo Portes
To: Kai Kaminski
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Kai,

You just need to provide a little comment in the text field: "Reason
for edit:". This is new feature put in place by Bill to avoid spam in
the Wiki. With this we will not get a password prompt.

Regards,

Alfredo Portes

On 7/31/06, Kai Kaminski wrote:
> >> svn diff --diff-cmd /usr/bin/diff -x "-Naur" some.foo.pamphlet
> >
> > Super.
> >
> >> PS: If this is what you've been looking for, I'll put it on the wiki.
> >
> > Yes, please.
> I can't change the wiki page, because it keeps asking me for a
> username/password. I probably have those, since I've used the wiki
> before, but I can't remember them. I attached the modified page source
> to this mail, so maybe someone else can just put it up.
>
> I also added the equivalent commands for CVS and GNU Arch version 1.3.4
> and later. Since I only have GNU Arch version 1.3.0 I couldn't test the
>   Arch command. It would be nice if someone else could check that.

\start
Date: Mon, 31 Jul 2006 17:03:51 +0200
From: Kai Kaminski
To: Ralf Hemmecke
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

>> I can't change the wiki page, because it keeps asking me for a 
>> username/password. I probably have those, since I've used the wiki 
>> before, but I can't remember them. I attached the modified page 
>> source to this mail, so maybe someone else can just put it up.
...
> Bill, I guess Kai had problems because he did not provide a reason for 
> the change. (I fell into the same trap.)
You are right. I just fixed a typo on the same page and it worked. 
Thanks.

\start
Date: 31 Jul 2006 17:20:01 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Ralf Hemmecke writes:

[...]

| Bill, I guess Kai had problems because he did not provide a reason for
| the change. (I fell into the same trap.)

Me too.

The system should not make it hard for "good citizens" to contribute
modifications. 


For every new session, the system repeatedly asks me to set preference
before editing.  Is there a way I can do that once for all and be done
with it? 

\start
Date: Mon, 31 Jul 2006 14:54:58 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: Problem building SIlver Axiom on Gentoo Linux

On July 31, 2006 10:18 AM Kai Kaminski
> 
> 
> >> svn diff --diff-cmd /usr/bin/diff -x "-Naur" some.foo.pamphlet
> >
> > Super.
> >
> >> PS: If this is what you've been looking for, I'll put it 
> on the wiki.
> >
> > Yes, please.
>
> I can't change the wiki page, because it keeps asking me for a 
> username/password.

<sigh> :((

I have explained here the reason for this. I think it the
message you see when you click cancel which tells you why
you were prompted should be fairly self explanatory: It is
because you did not supply a reason for the change. In order
to cut down on spam, only users with Zope managers user id
can make changes without explanations.

> I probably have those, since I've used the wiki before,
> but I can't remember them.

You don't need them.

> I attached the modified page source to this mail, so maybe
> someone else can just put it up.

Wiki pages can be modified by anyone - even you.

> 
> I also added the equivalent commands for CVS and GNU Arch 
> version 1.3.4 and later. Since I only have GNU Arch version
> 1.3.0 I couldn't test the Arch command. It would be nice if
> someone else could check that.
> 

\start
Date: Mon, 31 Jul 2006 15:04:50 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Problem building SIlver Axiom on Gentoo Linux

On July 31, 2006 11:20 AM Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> ... 
> | Bill, I guess Kai had problems because he did not provide a 
> | reason for the change. (I fell into the same trap.)
> 
> Me too.
> 
> The system should not make it hard for "good citizens" to contribute
> modifications. 
>

True. I am open to suggestions about how best to prevent spam
without making it hard for good citizens to contribute.

I thought that requiring an explanation for a change was kind of
minimally invasive since in general we want such explanations
anyway while robot programs spamming the wiki (so far at least)
have not been programmed to provide reasons for their changes.

The missleading thing, I guess, is that you don't get immediate
explanation because the system prompts you for a user id and
password right way and only after you click cancel does it tell
you why. This has the advantage of telling robot programs "too
authorized", but it seems to give the wrong impression to users.
It's a bit awkward to change this considering the way Zope works,
but I think I can fix that with some javascript that tells you
first that you must supply a reason rather than the other way
around.
 
> 
> For every new session, the system repeatedly asks me to set
> preference before editing.  Is there a way I can do that once
> for all and be done with it? 
> 

Your preferences are saved as cookies. If your browser allows
it, they will be retained from one session to the next. If saving
cookies is disabled, then you will have to re-enter preferences
each time.

\start
Date: Mon, 31 Jul 2006 15:13:13 -0400
From: Bill Page
To: Bill Page
Subject: RE: Problem building SIlver Axiom on Gentoo Linux

On July 31, 2006 3:05 PM my email program wrote:
> ...
> you why. This has the advantage of telling robot programs "too
> authorized", but it seems to give the wrong impression to users.
> ...

I was sure I told it to say "not authorized". This HTTP 401 return
code is often enough to scare away a robot. But Zope does not
return this error code until after an attempt to login fails.

\start
Date: 31 Jul 2006 21:21:37 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Bill Page writes:

[...]

| > For every new session, the system repeatedly asks me to set
| > preference before editing.  Is there a way I can do that once
| > for all and be done with it? 
| > 
| 
| Your preferences are saved as cookies. If your browser allows
| it, they will be retained from one session to the next. If saving
| cookies is disabled, then you will have to re-enter preferences
| each time.

I'm "forced" to enable my browser to save cookies, otherwise I would
not have been able to do those many everyday-life-thing on the web. 

For instance, my bugzilla account at GCC has all the stuff saved for
once. 

\start
Date: Mon, 31 Jul 2006 15:38:51 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Problem building SIlver Axiom on Gentoo Linux

On July 31, 2006 3:22 PM Gaby wrote:
> 
> Bill Page writes:
> 
> [...]
> 
> | > For every new session, the system repeatedly asks me to set
> | > preference before editing.  Is there a way I can do that once
> | > for all and be done with it? 
> | > 
> | 
> | Your preferences are saved as cookies. If your browser allows
> | it, they will be retained from one session to the next. If saving
> | cookies is disabled, then you will have to re-enter preferences
> | each time.
> 
> I'm "forced" to enable my browser to save cookies, otherwise I would
> not have been able to do those many everyday-life-thing on the web. 
> 
> For instance, my bugzilla account at GCC has all the stuff saved
> for once. 
> 

Yes. So you say that for some reason this is not working for you on
Axiom Wiki? What browser are you using? The cookie thing works for
me on FireFox (both linux and windows) and using Explorer on Windows.

Note: There is an intermediate option on most browsers that allows
"session only" cookies which means the cookie values will be retained
only while your browser is open, but not actually retained on disk.
Only use this if you need to acess a site that requires cookies but
don't want the cookies actually stored on your hard disk.

\start
Date: Mon, 31 Jul 2006 15:39:56 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Problem building SIlver Axiom on Gentoo Linux

Ralf,

Thanks for the suggestion.

On July 31, 2006 10:48 AM you wrote:
> ... 
> Could you make change the Edit page and let appear "Reason for
> the Change" in red?
> 

Done.

\start
Date: Mon, 31 Jul 2006 21:46:21 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Editing Wiki pages

On 07/31/2006 08:54 PM, Bill Page wrote:
>> I can't change the wiki page, because it keeps asking me for a 
>> username/password.

> In order to cut down on spam, only users with Zope managers user id 
> can make changes without explanations.

Bill, unless you are telling me that you removed me from the zope 
manager list, I wonder why I was not able to change the wiki without 
giving a reason. I provided my name and password and it kept popping up 
the password dialog.

\start
Date: Mon, 31 Jul 2006 16:05:38 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Editing Wiki pages

Ralf,

On July 31, 2006 3:46 PM you wrote:
> 
> On 07/31/2006 08:54 PM, Bill Page wrote:
> >> I can't change the wiki page, because it keeps asking me for a 
> >> username/password.
> 
> > In order to cut down on spam, only users with Zope managers user id 
> > can make changes without explanations.
> 
> Bill, unless you are telling me that you removed me from the zope 
> manager list, I wonder why I was not able to change the wiki without 
> giving a reason. I provided my name and password and it kept 
> popping up the password dialog.
> 

Hmmm... you are right. I do not know the reason it continues to
prompt. But I wanted to avoid this anyway. I have added some simple
javascript to the page so that now you get a pop-up message
immediately instead of depending on the 401 return code.

Is this better?

\start
Date: 31 Jul 2006 22:55:46 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Problem building SIlver Axiom on Gentoo Linux

Bill Page writes:

| On July 31, 2006 3:22 PM Gaby wrote:
| > 
| > Bill Page writes:
| > 
| > [...]
| > 
| > | > For every new session, the system repeatedly asks me to set
| > | > preference before editing.  Is there a way I can do that once
| > | > for all and be done with it? 
| > | > 
| > | 
| > | Your preferences are saved as cookies. If your browser allows
| > | it, they will be retained from one session to the next. If saving
| > | cookies is disabled, then you will have to re-enter preferences
| > | each time.
| > 
| > I'm "forced" to enable my browser to save cookies, otherwise I would
| > not have been able to do those many everyday-life-thing on the web. 
| > 
| > For instance, my bugzilla account at GCC has all the stuff saved
| > for once. 
| > 
| 
| Yes. So you say that for some reason this is not working for you on
| Axiom Wiki?

Exactly.

| What browser are you using? The cookie thing works for
| me on FireFox (both linux and windows) and using Explorer on Windows.

    soliton[15:54]% rpm -q mozilla
    mozilla-1.7.5-17.10

As I said, it works pretty well with other websites...

| Note: There is an intermediate option on most browsers that allows
| "session only" cookies which means the cookie values will be retained
| only while your browser is open, but not actually retained on disk.

I checked I did not use that one -- and GCC bugzilla and many other
sites would have not worked anyway.

\start
Date: 01 Aug 2006 03:32:32 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Front page esthetic

Bill Page writes:

| Antoine,
| 
| Thank you very much for the comment. I have made some
| changes and look forward to further suggestions.

Hi Bill,

  I find the front page of Axiom quite "visually heavy" -- and many
times I miss there the information I'm looking for.

  So, I took a look at few free software or open source computer algebra
systems, to see what other people are up to.

   http://maxima.sourceforge.net/
   http://yacas.sourceforge.net/
   http://www.singular.uni-kl.de/
   http://turnbull.mcs.st-and.ac.uk/~gap/

All of them appears to me to be quite simple -- and I like that
simplicity.  Especially that of Maxima.  It takes very little time to
display -- compared to Axiom's.

 
Important to me is that the front-page must send the message that this
is related to research.  Yes, we have links to workshops and all
that.  But, most importantly, links to reserach papers related to
Axiom must be clearly and unambigously linked from there -- I sent a
message to axiom-mail to that effect but for some reasons it never
shows up :-(

My suggestion would be to simplify the "visual load" of the
front-page.  I know that sounds a bit unhelpful but it is a start of
suggestion :-)

People should be able to find the exciting/appealing things about
Axiom from its front-page.  We should not require them to "dig through".


To my mind the description of Axiom should should mention application
to engineering, computer science -- not just Physics or Mathematics.

HTH,

\start
Date: 01 Aug 2006 03:47:29 +0200
From: Gabriel Dos Reis
To: list
Subject: [silver] PATCH to zimmer.input

the patchlet below fixes a LaTeX escape issue.
Tested on an i686-pc-linux-gnu.
Applied.

-- Gaby
2006-07-31  Gabriel Dos Reis  Gabriel Dos Reis

	* zimmer.input.pamphlet: Escape "&".

*** zimmer.input.pamphlet	(revision 15548)
--- zimmer.input.pamphlet	(local)
***************
*** 5,11 ****
  \author{The Axiom Team}
  \maketitle
  \begin{abstract}
! These examples come from Postel & Zimmermann's paper in the 5th Rhine
  Conference on Computer Algebra.
  \end{abstract}
  \eject
--- 5,11 ----
  \author{The Axiom Team}
  \maketitle
  \begin{abstract}
! These examples come from Postel \& Zimmermann's paper in the 5th Rhine
  Conference on Computer Algebra.
  \end{abstract}
  \eject


\start
Date: Mon, 31 Jul 2006 23:22:35 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Front page esthetic

Gaby,

I am glad to receive your comments about the Axiom Wike site.
Please forgive me if some of my replies sound overly defensive.
I admit I have a biased view - but that is what makes it even
more important that other people comment about this stuff...

On July 31, 2006 9:33 PM you wrote:
> 
>   I find the front page of Axiom quite "visually heavy" -- and
> many times I miss there the information I'm looking for.
> 

Could you give an example of information that you were looking
for but did not find? That sort of observation would be a big
help.

>   So, I took a look at few free software or open source 
> computer algebra systems, to see what other people are up to.
> 
>    http://maxima.sourceforge.net/
>    http://yacas.sourceforge.net/
>    http://www.singular.uni-kl.de/
>    http://turnbull.mcs.st-and.ac.uk/~gap/
> 
> All of them appears to me to be quite simple -- and I like that
> simplicity.  Especially that of Maxima.  It takes very little
> time to display -- compared to Axiom's.
>

When I look at

http://maxima.sourceforge.net

My first reaction is: Hmmm, that doesn't look so different than the
Axiom Wiki FrontPage... The time to display seems quite similar over
a high speed connection and a reasonably fast system (AMD 3500+).

Differences I noticed:

1) Maxima uses just a left side-bar but Axiom Wiki currently uses
   both left and right side-bars, but just a left side-bar
   navigation bar on all other pages.

2) The Axiom Wiki FrontPage has more graphics including an example
   Axiom output graphic.

3) The Maxima web site is not a wiki.

4) The Maxima web site has no search function.

I don't find anything that makes the Maxima page seem simpler or
that gives me the impression that information is more readily
accessible. What am I missing?

When I looked at:

http://yacas.sourceforge.net

I thought:

1) Yacas FrontPage doesn't say much and has only a minimal set
   of links (no side-bars).

2) Yacas uses a fixed left side-bar on other pages.

3) Not a wiki.

4) No search.

When I look at:

http://www.singular.uni-kl.de/

my reaction is:

1) Looks a lot like Axiom Wiki.

2) Has search.

3) Has both left and right side-bars.

4) Not a wiki.

Looking at:

http://turnbull.mcs.st-and.ac.uk/~gap/

The first things I see are:

1) Looks sort of like Axiom Wiki but uses only a left side-bar.

2) Hard to find search.

3) Left side-bar provides site navigation like on Axiom Wiki.

4) Not a wiki.

-----------

I am not sure what to conclude by the above. If you have time,
could you repeat this exercise and give your first impressions
for each?

>  
> Important to me is that the front-page must send the message that
> this is related to research.  Yes, we have links to workshops and
> all that.  But, most importantly, links to research papers related
> to Axiom must be clearly and unambiguously linked from there --

Are you aware of the Axiom bibliography on the Axiom Portal?

http://portal.axiom-developer.org/refs

Maybe this deserves a link on the Axiom Wiki FrontPage?

> I sent a message to axiom-mail to that effect but for some reasons
> it never shows up :-(

I did not see any posting to axiom-mail. In fact I haven't seen
any real postings to axiom-mail for some time - only spam (about
10 to 20 spam message per day). I wonder if this list is working
properly? Most people seem to prefer the axiom-devel list. Maybe
we have too many lists?

> 
> My suggestion would be to simplify the "visual load" of the
> front-page.  I know that sounds a bit unhelpful but it is a
> start of suggestion :-)

I am not clear on what you mean by "visual load". Are you
referring to the layout? The color scheme?

> 
> People should be able to find the exciting/appealing things
> about Axiom from its front-page.  We should not require them
> to "dig through".
> 

I agree.

Can you give an example of something that is exciting and/or
appealing about Axiom that is not found on the FrontPage?

What constituents "dig through" to you? Do you mean just
that they don't find the information on the FrontPage?
How many clicks to finding the right information do you
think is reasonable?

> 
> To my mind the description of Axiom should mention
> application to engineering, computer science -- not just
> Physics or Mathematics.
> 

I agree. I really would like to be able to list examples
of all of these. Did you see any mention of physics on the
FrontPage? I would claim that computer science is clearly
implied by the contents of the FrontPage even if not
explicitly named.

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