\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: Mon, 01 May 2006 10:54:12 +0200
From: David Mentre
To: Gabriel Dos Reis
Subject: re: Editing wiki frontpage

Hello Gaby,

Gabriel Dos Reis writes:

> When contributing a patch for consideration in the silver branch,
> please send a message to the mailing list
>
>     axiom-dev@axiom-developer.org

Shouldn't it be list?

\start
Date: Mon, 01 May 2006 11:25:10 +0200
From: David Mentre
To: Gabriel Dos Reis
Subject: Issue building silver tree (was: re: Editing wiki frontpage)

Gabriel Dos Reis writes:

> Obtaining a working copy from the Sourceforge SVN repository
> ============================================================
[...]
>
> * read-only access:
>
>    Check out the silver branch of Axiom source code with
>
>      svn co https://svn.sourceforge.net/svnroot/axiom/trunk axiom.silver

I checked out a fresh silver tree following above instructions and this
tree does not build.

(after a 'make')

10 copying /home/david/pub/axiom-libre/silver/axiom/src/scripts to /home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/text-base/axiom.sty.svn-base': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/prop-base/axiom.sty.svn-base': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/props/axiom.sty.svn-work': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/wcprops/axiom.sty.svn-work': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/entries': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/empty-file': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/README.txt': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/format': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/dir-wcprops': Permission denied
make: *** [litcmds] Error 1


I suppose this is related to the .svn/ directories being spread all over
the axiom tree.

'make clean' does not work neither, with the same error.

\start
Date: Mon, 1 May 2006 08:44:40 -0400
From: Tim Daly
To: David Mentre
Subject: re: sourceforge cvs
Cc: Yegor Bryukhov

David,

Sourceforge SVN seems to be broken. Yours is the latest complaint
I've seen from the sourceforge SVN/CVS archives. Bill spent some
time trying to clean them up. I'd suggest doing a tla checkout
from the arch repository and then doing:

  diff -r --brief archcheckout svncheckout

they should be exactly the same modulo the arch and svn control
repositories. You can remove most of the noise with grep -v thus:

  diff -r --brief archcheckout svncheckout | grep -v arch-id 

Tim


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

> Obtaining a working copy from the Sourceforge SVN repository
> ============================================================
[...]
>
> * read-only access:
>
>    Check out the silver branch of Axiom source code with
>
>      svn co https://svn.sourceforge.net/svnroot/axiom/trunk axiom.silver

I checked out a fresh silver tree following above instructions and this
tree does not build.

(after a 'make')

10 copying /home/david/pub/axiom-libre/silver/axiom/src/scripts to /home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/text-base/axiom.sty.svn-base': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/prop-base/axiom.sty.svn-base': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/props/axiom.sty.svn-work': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/wcprops/axiom.sty.svn-work': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/entries': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/empty-file': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/README.txt': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/format': Permission denied
cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/dir-wcprops': Permission denied
make: *** [litcmds] Error 1


I suppose this is related to the .svn/ directories being spread all over
the axiom tree.

'make clean' does not work neither, with the same error.

Best wishes,
d.

====================================================================
> There is definitely a strange problem with the CVS at SourceForge.

I have not been following the thread closely but SF has locked  
anonymous checkout because they had problems with it.

I work on a project where the latest we can get is a March 9th update  
when the developer keeps adding stuff everyday.

There is a note somewhere on SF about that.

JC Helary

====================================================================
> On 26 avril 2006  22:01 -0400, Tim Daly (root) wrote:
> ...
> > These are the first few lines of the Makefile for the latest
> > version just checked out from the sourceforge cvs.
> ...
> > #GCLVERSION=gcl-2.6.7
> > GCLVERSION=gcl-2.6.8pre
> ...
> 
> Checked out another time on a reiserfs partition without success
> (always the Axiom (December 2005) version). So it seems that I'm 
> alone with this problem, another thing that I don't understand today.
> The "Browse CVS Repository" service don't work too for me...
> 
> Sorry for the inconvenience.
> 

There is definitely a strange problem with the CVS at SourceForge.

The CVS browse now shows everything as atleast 3 months old:

http://cvs.sourceforge.net/viewcvs.py/axiom/axiom/

(December 2005) and

http://cvs.sourceforge.net/viewcvs.py/axiom/axiom/Makefile?view=markup

shows the old version of the Makefile without gcl-2.6.8pre

But that is very odd! Because two days ago I did a 'cvs update'
from SourceForge and I did obtain the correct new version.

And further more the Savannah CVS browse is also up to date:

http://cvs.savannah.nongnu.org/viewcvs/axiom/?root=axiom

(patch-49)

I don't understand it.

\start
Date: Mon, 1 May 2006 09:06:59 -0400
From: Bill Page
To: David Mentre
Subject: RE: Issue building silver tree (was: re: Editing wiki frontpage)

David,

On May 1, 2006 5:25 AM you wrote:
> 
> Gabriel Dos Reis writes:
> 
> > Obtaining a working copy from the Sourceforge SVN repository
> > ============================================================
> [...]
> >
> > * read-only access:
> >
> >    Check out the silver branch of Axiom source code with
> >
> >      svn co https://svn.sourceforge.net/svnroot/axiom/trunk 
> axiom.silver
> 
> I checked out a fresh silver tree following above 
> instructions and this tree does not build.
> 
> (after a 'make')
> 
> 10 copying 
> /home/david/pub/axiom-libre/silver/axiom/src/scripts to 
> /home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin
> cp: cannot create regular file 
> `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.s
> vn/text-base/axiom.sty.svn-base': Permission denied

Jay Belanger has identified this problem as due to incorrect
"recursive copies" in the Axiom Makefile. See:

http://lists.nongnu.org/archive/html/axiom-developer/2006-04/msg00161.html

although he did not propose a fix.

> ...
> `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.s
> vn/dir-wcprops': Permission denied
> make: *** [litcmds] Error 1
> 
> 
> I suppose this is related to the .svn/ directories being 
> spread all over the axiom tree.

Yes. The same thing actually happens with CVS as well except
that CVS does not protect these directories that way SVN does
so a make from CVS sources works although technically there is
still a problem.

> 
> 'make clean' does not work neither, with the same error.
> 

You cannot correct this problem by make clean. The problem
occurs in Axiom Make file because "it tries to create the same
.svn directory twice". Of course copying .svn directories
is just a side effect of some uncareful (incorrect) code in
the Makefile. To correct this it would be necessary to fix the
Axiom Makefile or to avoid it by first deleting all the and
.svn directories and files throughout the source tree.

\start
Date: Mon, 01 May 2006 15:22:17 +0200
From: David Mentre
To: Tim Daly
Subject: re: sourceforge cvs

Tim Daly writes:

> Sourceforge SVN seems to be broken. Yours is the latest complaint I've
> seen from the sourceforge SVN/CVS archives.

In fact, I wasn't complaining but just giving a hint on the silver
branch. :-) As there was work on this branch, I thought the issue was
fixed.

> Bill spent some
> time trying to clean them up. I'd suggest doing a tla checkout
> from the arch repository and then doing:
>
>   diff -r --brief archcheckout svncheckout
>
> they should be exactly the same modulo the arch and svn control
> repositories. You can remove most of the noise with grep -v thus:
>
>   diff -r --brief archcheckout svncheckout | grep -v arch-id 

\start
Date: 01 May 2006 15:26:58 +0200
From: Gabriel Dos Reis
To: David Mentre
Subject: re: Editing wiki frontpage

David Mentre writes:

| Hello Gaby,
| 
| Gabriel Dos Reis writes:
| 
| > When contributing a patch for consideration in the silver branch,
| > please send a message to the mailing list
| >
| >     axiom-dev@axiom-developer.org
| 
| Shouldn't it be list?

yes, Absolutely.

\start
Date: 01 May 2006 15:30:50 +0200
From: Gabriel Dos Reis
To: David Mentre
Subject: Re: Issue building silver tree (was: re: Editing wiki frontpage)

David Mentre writes:

| Gabriel Dos Reis writes:
| 
| > Obtaining a working copy from the Sourceforge SVN repository
| > ============================================================
| [...]
| >
| > * read-only access:
| >
| >    Check out the silver branch of Axiom source code with
| >
| >      svn co https://svn.sourceforge.net/svnroot/axiom/trunk axiom.silver
| 
| I checked out a fresh silver tree following above instructions and this
| tree does not build.
| 
| (after a 'make')

[ ...]

That is odd.  I was able to build Axiom following those instructions
(modulo the patch issue I reported earlier).  I checked out with write
permission, i.e. with --username=<sf-user-id>; I don't know whether
that makes a difference.

Bill and others identified the problems as being related to recursive
copy.  I'll be working for a solution to this problem.

\start
Date: 01 May 2006 16:12:15 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: sourceforge cvs
Cc: Yegor Bryukhov

Tim Daly writes:

| David,
| 
| Sourceforge SVN seems to be broken. Yours is the latest complaint
| I've seen from the sourceforge SVN/CVS archives. Bill spent some
| time trying to clean them up. 

I'm thankful to Bill for helping sorting the conversion issues out.
(very few are left, but unimportant).

The probem David reported, this time, has nothing intrinsic to do with
SVN.   It is a bug in the existing makefils (whether from tla or CVS
does not matter) that SVN's way of keeping things exposes.

There is also an issue with your "recursive noise" patch, that I'll
fix in the silver branch shortly.

\start
Date: 01 May 2006 22:34:12 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom trunk failure

Tim Daly writes:

| yep. it turns off the "tail recursion" noise. bill schelter and i
| worked on creating tail recursion in AKCL. This was just a debugging
| message at the time. For some reason it outlived its useful life and
| continues in the current code base. the message "exposes" lisp to 
| the user of the axiom interpreter so i removed it.
| 
| it should patch correctly. i suspect there is a mismatch between
| the GCL version you are using and the patch level you are using.
| 
| in the zips subdirectory all patches are named by the .tgz file
| to which they apply. the name also includes the directory path
| to the file and the name of the file. so 
| 
| zips/gcl-2.6.7
| 
| has patches like
| 
| gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch
| 
| which lives in lsp/gcl-2.6.7/cmpnew/gcl_cmpflet.lsp

Tim,

  I fixed the problem in the silver branch, by copying the patch file
from the tla branch to the SVN branch.  Now, we are brack to buildville.

It would be helpful if we could also have the GCL-2.6.8pre patches
also in the silver branch.  In particular, we should have all the
current codes in the gold branch in the silver branch .

Next:

   (1) fix other file "corruptions" introduced  during the conversion;
   (2) fix the recursive copy problem.

I don't promise to do all that by tonight :-)

\start
Date: Mon, 1 May 2006 16:36:11 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Axiom trunk failure

silver was converted from patch-49 which has the gcl-2.6.8pre patches.
those patches were in the system as of patch-48.

\start
Date: 01 May 2006 22:55:09 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom trunk failure

Tim Daly writes:

| silver was converted from patch-49 which has the gcl-2.6.8pre patches.
| those patches were in the system as of patch-48.

I do not have them in checked out SVN version, nor are they visible here

   http://svn.sourceforge.net/viewcvs.cgi/axiom/trunk/axiom/zips/ 


I was under the impression that patch-49 happened after the conversion
to SVN.

\start
Date: Mon, 1 May 2006 20:47:08 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Axiom trunk failure

On May 1, 2006 4:34 PM Gabriel Dos Reis wrote:
> 
> It would be helpful if we could also have the GCL-2.6.8pre patches
> also in the silver branch.  In particular, we should have all the
> current codes in the gold branch in the silver branch .
> 

I suggest:

  tla delta -diffs axiom--main--1-patch--47 axiom--main--1--patch49

http://wiki.gnuarch.org/Tla_20Reference_2fdelta

\start
Date: 02 May 2006 08:12:03 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom trunk failure

Tim Daly writes:

| yep. it turns off the "tail recursion" noise. bill schelter and i
| worked on creating tail recursion in AKCL. This was just a debugging
| message at the time. For some reason it outlived its useful life and
| continues in the current code base. the message "exposes" lisp to 
| the user of the axiom interpreter so i removed it.

Tim,

Is there a reason why this code should not be contributed back to GCL
so that we don't have to patch GCL all the time?  

\start
Date: 02 May 2006 08:50:17 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Axiom trunk failure

Bill Page writes:

| On May 1, 2006 4:34 PM Gabriel Dos Reis wrote:
| > 
| > It would be helpful if we could also have the GCL-2.6.8pre patches
| > also in the silver branch.  In particular, we should have all the
| > current codes in the gold branch in the silver branch .
| > 
| 
| I suggest:
| 
|   tla delta -diffs axiom--main--1-patch--47 axiom--main--1--patch49
| 
| http://wiki.gnuarch.org/Tla_20Reference_2fdelta

Hi Bill,

  Thanks for the suggestion.


It does not work quite right.  The reason is that the missing changes
are not those from -patch-47 to -patch-49.  The missing changes form a
strict subset of "delta -patch-47 -patch-49", as can be infered from
the CHANGELOG.  The SVN repo is missing anything (officially recorded
in the CHANGELOG) from 20060115 till now.  I browsed the tla reference
manual; I don't seem to see a way to specify revision at a particular
date.  I'll try the CVS repo..

\start
Date: 02 May 2006 12:07:35 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Syncing SVN repo and -patch-49

Gabriel Dos Reis writes:

| I'll try the CVS repo..

Was successful.

I've applied the diff attached to this mail (except the gcl tarball),
as reported by both tla and cvs.

The SVN repo should now be in sync with -patch-49.
Built and tested on an i686-pc-linux-gnu.

\start
Date: Tue, 2 May 2006 09:28:14 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Axiom trunk failure

no particular reason. you can submit it as a patch. --t

\start
Date: 02 May 2006 23:00:29 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: star merge and the silver branch

Ralf Hemmecke writes:

[...]

| Of course, SVN has some weaknesses (especially not being able to do a
| star-merge), but since you could live with CVS for many years, I am
| sure you can cope with that missing feature anyway.

Hi Ralf,

  Since you have been teasing us about this feature for a long time,
I put a short description of how to work on the Axiom silver branch
with SVK.  See

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

SVK has implemented Tom Lord's "star merge" algorithm (I have not
used it myself)

    http://svkbook.elixus.org/nightly/en/svk.ref.svk.c.smerge.html

I do however use SVK frequently (though I'm no expert) and the steps I
put on the wiki are those I followed to set up a working SVK
repository for myself.


Since the wiki has a very first firm idea about which parts of my edits
count as verbatim, the formating is a bit odd in some places
(especially the section on SVK).  Please correct as you go through.
This wiki seems to be more stubborn than others I've met.
 
suggestions for improvement welcome.
[if you're into using SVK, I recommend version 1.05 or newer]
   
\start
Date: 02 May 2006 23:49:58 +0200
From: Gabriel Dos Reis
To: David Mentre
Subject: Re: Issue building silver tree (was: re: Editing wiki frontpage)

David Mentre writes:

| Gabriel Dos Reis writes:
| 
| > Obtaining a working copy from the Sourceforge SVN repository
| > ============================================================
| [...]
| >
| > * read-only access:
| >
| >    Check out the silver branch of Axiom source code with
| >
| >      svn co https://svn.sourceforge.net/svnroot/axiom/trunk axiom.silver
| 
| I checked out a fresh silver tree following above instructions and this
| tree does not build.
| 
| (after a 'make')
| 
| 10 copying /home/david/pub/axiom-libre/silver/axiom/src/scripts to /home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin
| cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/text-base/axiom.sty.svn-base': Permission denied
| cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/prop-base/axiom.sty.svn-base': Permission denied
| cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/props/axiom.sty.svn-work': Permission denied
| cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/wcprops/axiom.sty.svn-work': Permission denied
| cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/entries': Permission denied
| cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/empty-file': Permission denied
| cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/README.txt': Permission denied
| cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/format': Permission denied
| cp: cannot create regular file `/home/david/pub/axiom-libre/silver/axiom/mnt/linux/bin/tex/.svn/dir-wcprops': Permission denied
| make: *** [litcmds] Error 1
| 
| 
| I suppose this is related to the .svn/ directories being spread all over
| the axiom tree.
| 
| 'make clean' does not work neither, with the same error.

Hi David,

  SVK does not keep administrative files (like SVN or CVS) in the
checked out working directories; consequently you should not see those
problems if you work with SVK.  Of course, that does not mean we
should not fix the real problem.

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

see the section on SVK.

\start
Date: Tue, 2 May 2006 20:13:26 -0700 (PDT)
From: Cliff Yapp
To: Jay Belanger
Subject: Check for item in PATH in Emacs?

Does anybody know of a way to check for, say, "axiom" in the PATH on a
particular system from Emacs?  Trying to run something via comint seems
to result in an error which stops everything.  I'm trying to first run
"axiom" if it's available (it turns out graphics do work when run from
the Emacs buffer) and if it isn't available fall back to "AXIOMsys".  I
know I could do some hackery with running "which axiom" on Linux but
I'm hoping for something more straightforward and portable.

\start
Date: 03 May 2006 21:40:14 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: size issue with noweb
Cc: Douglas Troeger, David Mentre

Tim Daly writes:

[...]

|                                          Worse yet is the 
| include hell (which is the key reason why axiom is not yet
| running on a mac) where each opsys changes the order of these
| tiny include files.

As far as I know, Axiom will not be the first program to be ported to
mac that uses C! :-)

[...]

| Tools affect the way you think about a problem and even
| what you can think about. We need to stop living with the
| historical limitations of tools from my childhood and start
| working with real, industrial strength tools.

wholeheartly agreed.  

>From that to gigantic monolotic files I would have to swim through... 

Thankfully, I'm not in your shoes :-)

\start
Date: 03 May 2006 22:35:46 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: noweb

Tim Daly writes:

| there is still a bit of controversy over the noweb inclusion.
| some people (notably, but not limited to, FreeBSD) want to
| use natively installed noweb rather than build it. There is 
| supposed to be a version of noweb with the fix installed but
| i do not have it and have not tested it.

OK.  Certainly relying on the system noweb will simplify our build
machinery, or at least the version I'm currently working on.

However, I must point out that not all system have noweb install -- I
just checked that my development environment does not have noweb [from
which you will correctly infer that I do not use noweb].

A way out of this dilemma is as you suggest below:

| a possible path is to use the configure script to test whether
| the native installed noweb has the proper fix and, if not, to
| build a local copy. as is evident from reading configure i'm
| not a shell script programmer so i don't try to decide this
| issue. i'm waiting for someone with better configure skills
| to tackle the issue.

Well, my question popped up precisely because I started working on
converting Axiom's build machinery to use Autoconf.  I'm doing this on
a branch from the silver sources called "build-improvements".  No,
there is no change checked in yet; all is on my machine.
So, consider the writer of this message as being at your service
working on that aspect of that particular aspect of noweb requirement,
if given sufficient details :-) 

| modules.c is one way to fix the noweb bug. i've submitted it
| as a patch to norman ramsey but he rejected it saying that i
| should use sed/awk to fix the problem rather than patch the
| C code. unfortunately i'm not a sed/awk programmer so rather
| than learn two new tools i simply kept the patch (which works).

Can you give me a test for detecting the problem, or at least a
detailed description of how to reproduce it?  Did Norman Ramsey
suggest on which file you should use the sed/awk fix?
Again, I'm willing to help out that issue:  It stands in my way of
making progress on the build machinery stuff.

| if the system-installed noweb is used certain domains are broken.
| this will happen quietly in the current system unless you use
|  make NOISE=

OK, I'll provide a configure option called --verbose to instruct
generated Makefiles to set NOISE as approprite..

| 
| is there an 'axiom-dev@nongnu.org' mailing list?

No, that is just me who botched the Axiom mailing list -- fixed
thusly.  I do not have a copy of my original mail, please could you
resend it to the list?  Thanks!

There seems to be two lists named axiom-developer: One at sourceforge,
and one at nongnu.org.  I believe we should "close" the former. 

\start
Date: Wed, 3 May 2006 16:44:18 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: noweb

the axiom-developer@lists.sourceforge.net was created because the
mailing list list failed for a week or so.

once you create a mailing list you cannot delete it.
to my knowledge no one uses axiom-developer@lists.sourceforge.net
and since it's never been mentioned nobody knows about it.
now you've ruined it. 
blown it. 
completely let the cat out of the bag.
opened the barn door.
sold the plans.
sent it up the river.
broadcast it to the masses.
blogged it all over town.

ah, the upcoming horror and ensuing destruction! 

\start
Date: 03 May 2006 23:19:14 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: noweb

Tim Daly writes:

| the axiom-developer@lists.sourceforge.net was created because the
| mailing list list failed for a week or so.

OK.

| once you create a mailing list you cannot delete it.

yes, that is why I put "close" in quote.

| to my knowledge no one uses axiom-developer@lists.sourceforge.net
| and since it's never been mentioned nobody knows about it.

I subscribed to that list because it is displayed on the front page of
Axiom at sourceforge -- "just in case".

| now you've ruined it. 
| blown it. 
| completely let the cat out of the bag.
| opened the barn door.
| sold the plans.
| sent it up the river.
| broadcast it to the masses.
| blogged it all over town.
| 
| ah, the upcoming horror and ensuing destruction! 

\start
Date: Wed, 3 May 2006 18:05:31 +0200
From: Nicolas Thiery
To: Ralf Hemmecke
Subject: Re: A{ld,xi}o{r,m}-Combinat

> Actually, I must thank Nicolas quite a bit. He showed in his talks
> how useful recursion is. And how this is currently done in
> MuPAD. Basically, in MuPAD-combinat it is of importance that one
> should be able to define combinatorial classes via a
> grammer. MuPAD-combinat then computes a fixed point for this grammar
> in order to get the combinatorial classes.  And as I understood
> Nicolas, that code is quite huge and complicated.

To be exact: the MuPAD-Combinat code that deals with decomposable
classes is monolithic. The distributed approach that we just used in
Aldor, and that we plan to use in the future for MuPAD-Combinat, will
be more natural, more modular, and easier to maintain and to
extend. It will also deprecate the grammar-analysis code.

Now for the code size itself ... If we want to keep all the features,
there is still some work to do. I don't expect much more than 10% code
reduction thanks to the distributed approach, and maybe another 10%
thanks to the quality of the Aldor language.

> >I hope we somehow find it possible to arrange more (and more frequent)
> > such "sprints" on all sorts of Axiom subjects.
> I'm all for it. We had lot's of fun, too. ;-)

Definitely.

> Nicolas, am I wrong if I say that you and perhaps your "team" now
> more seriously consider Aldor/Axiom as an option? Of course, that
> all depends on the availablility of Aldor.

I definitely loved that language (I also love typing, but I am still
not 100% sure whether in practice it would not go in the way for our
kind of usage, namely rapid development of experimentation code for
research. The flexibility of the MuPAD language definitely saved us a
lot of time in many occasions).

So, an exact sentence would be:
 - If Aldor was completely free
 - If the Axiom and Aldor community where merged with ongoing work to
   unify their libraries
 - If I was to restart from scratch a project like MuPAD-Combinat
I would definitely hop in and choose that direction.

Now, the MuPAD-Combinat code and community can't be moved that easily;
it took five years to build them, and we still haven't completed the
transition from Maple!

So, the current status is that I will follow very closely what you
guys are doing. And help you whenever I can (but, badly enough,
without being able to put much work power in that). And try to make
sure that we keep things synchronized. Go ahead: please steal whatever
code/doc/tests you can!

Thanks Martin and Ralf for that very fun workshop!

						Nicolas

PS: I will put the slides of my talk on the MuPAD-Combinat web page
shortly: http://mupad-combinat.sf.net/

\start
Date: Wed, 3 May 2006 21:05:06 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: Axiom trunk failure

On Tuesday, May 02, 2006 2:12 AM Gabriel Dos Reis wrote:
>
> Tim Daly (root) writes:
>
> | yep. it turns off the "tail recursion" noise. bill schelter
> | and i worked on creating tail recursion in AKCL. This was
> | just a debugging message at the time. For some reason it
> | outlived its useful life and continues in the current code
> | base. the message "exposes" lisp to the user of the axiom
> | interpreter so i removed it.
>
> Tim,
>
> Is there a reason why this code should not be contributed back
> to GCL so that we don't have to patch GCL all the time? 
>

As far as I know this patch is irrelevant since the message is
controlled by the GCL switch

  (setq compiler::*suppress-compiler-notes* t)

http://lists.nongnu.org/archive/html/gcl-devel/2003-09/msg00189.html
http://lists.nongnu.org/archive/html/gcl-devel/2003-09/msg00195.html

Note that the patch is not used on Debian.

\start
Date: Wed, 3 May 2006 21:34:09 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: noweb

Gaby,

Thanks for your continuing work on the Axiom Silver branch! :)

On Wednesday, May 03, 2006 4:36 PM you wrote:
> ...
> Tim Daly (root) wrote:
> | modules.c is one way to fix the noweb bug. i've submitted it
> | as a patch to norman ramsey but he rejected it saying that i
> | should use sed/awk to fix the problem rather than patch the
> | C code. unfortunately i'm not a sed/awk programmer so rather
> | than learn two new tools i simply kept the patch (which works).
>
> Can you give me a test for detecting the problem, or at least
> a detailed description of how to reproduce it?  Did Norman
> Ramsey suggest on which file you should use the sed/awk fix?
> Again, I'm willing to help out that issue:  It stands in my
> way of making progress on the build machinery stuff.

Please forgive my irritation but this issue *has* been discussed
repeatedly on this list. Most recently see:

http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00226.html

Here is the awk script again since the version stored in the
axiom-developer archive is mangled because it confuses some of
script with an email address:

axiom-noweb:
------------

#!/bin/sh

awk '
/@use /  { uses [substr($0, 6)] = 1 }
/@defn / { defns[substr($0, 7)] = 1 }
{ print }
END {
  for (i in uses)
    if (!defns[i])
      printf "@begin code\n@defn %s\n@nl\n@text <<%s>>\n@end code\n", i,
i
}'

exit 0

# test with

sed '1,/test with/d' $0 | notangle -filter $0

<<*>>=
return x << 2 >> 2;
@

--------

All we have to do is include this script with the Axiom
distribution and call it as a filter as he shows.

% notangle -filter axiom-noweb

Really, this script is not so hard to understand is it? The
documentation for noweb filters is here:

http://www.literateprogramming.com/noweb_hacker.pdf

\start
Date: Wed, 3 May 2006 22:08:50 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Check for item in PATH in Emacs?

On Tuesday, May 02, 2006 11:13 PM C Y wrote:
>
> Does anybody know of a way to check for, say, "axiom" in the
> PATH on a particular system from Emacs?  Trying to run something
> via comint seems to result in an error which stops everything.
> I'm trying to first run "axiom" if it's available (it turns out
> graphics do work when run from the Emacs buffer) and if it isn't
> available fall back to "AXIOMsys".  I know I could do some hackery
> with running "which axiom" on Linux but I'm hoping for something
> more straightforward and portable.
>
I'm no emacs hacker, but it looks like some code in emacs esh-ext
might do what you want. See:

http://www.cgl.uwaterloo.ca/~mmwasile/data/elisp/eshell-2.4.2/esh-ext.el

...
(defun eshell-search-path (name)
  "Search the environment path for NAME."
  (if (file-name-absolute-p name)
      name
    (let ((list (parse-colon-path (getenv "PATH")))
	  suffixes n1 n2 file)
      (while list
	(setq n1 (concat (car list) name))
	(setq suffixes eshell-binary-suffixes)
	(while suffixes
	  (setq n2 (concat n1 (car suffixes)))
	  (if (and (or (file-executable-p n2)
		       (and eshell-force-execution
			    (file-readable-p n2)))
		   (not (file-directory-p n2)))
	      (setq file n2 suffixes nil list nil))
	  (setq suffixes (cdr suffixes)))
	(setq list (cdr list)))
      file)))
...

\start
Date: 04 May 2006 04:33:42 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Axiom trunk failure

Bill Page writes:

| On Tuesday, May 02, 2006 2:12 AM Gabriel Dos Reis wrote:
| > 
| > Tim Daly (root) writes:
| > 
| > | yep. it turns off the "tail recursion" noise. bill schelter
| > | and i worked on creating tail recursion in AKCL. This was
| > | just a debugging message at the time. For some reason it
| > | outlived its useful life and continues in the current code
| > | base. the message "exposes" lisp to the user of the axiom
| > | interpreter so i removed it.
| > 
| > Tim,
| > 
| > Is there a reason why this code should not be contributed back
| > to GCL so that we don't have to patch GCL all the time?  
| > 
| 
| As far as I know this patch is irrelevant

Great!  I'm preparing a patchlet to remove its application to the
silver branch.

| since the message is controlled by the GCL switch
| 
|   (setq compiler::*suppress-compiler-notes* t)
| 
| http://lists.nongnu.org/archive/html/gcl-devel/2003-09/msg00189.html
| http://lists.nongnu.org/archive/html/gcl-devel/2003-09/msg00195.html

What happened to that proposal to Camm?  That message seems to have
received no public answer...

| Note that the patch is not used on Debian.

That is good.

\start
Date: 04 May 2006 04:43:28 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Axiom trunk failure

Bill Page writes:

| On Tuesday, May 02, 2006 2:12 AM Gabriel Dos Reis wrote:
| > 
| > Tim Daly (root) writes:
| > 
| > | yep. it turns off the "tail recursion" noise. bill schelter
| > | and i worked on creating tail recursion in AKCL. This was
| > | just a debugging message at the time. For some reason it
| > | outlived its useful life and continues in the current code
| > | base. the message "exposes" lisp to the user of the axiom
| > | interpreter so i removed it.
| > 
| > Tim,
| > 
| > Is there a reason why this code should not be contributed back
| > to GCL so that we don't have to patch GCL all the time?  
| > 
| 
| As far as I know this patch is irrelevant since the message is
| controlled by the GCL switch
| 
|   (setq compiler::*suppress-compiler-notes* t)
| 
| http://lists.nongnu.org/archive/html/gcl-devel/2003-09/msg00189.html

Tim,

  According to that message all but two of your patches to GCL would
be already present in GCL.  Please could you clarify why we are still
keeping more than patches for GCL?

\start
Date: Wed, 3 May 2006 22:54:18 -0400
From: Tim Daly
To: Bill Page
Subject: re: noweb

Bill,

> Please forgive my irritation but this issue *has* been discussed
> repeatedly on this list. Most recently see:

i realize that the current solution is an irritation to you.
i'd suggest that you check out a copy of axiom and integrate
the patch. it's not as simple as it seems. fully integrating
the patch involves, at least,

  *) change configure to check for an installed noweb
  *) if noweb is not installed build it
  *) if noweb is installed check to see if the filter already exists
  *) if noweb is already patched use it
  *) if noweb is not patched use the scripted patch

  *) put the patch in src/scripts
  *) modify src/scripts/Makefile.pamphlet to document and include the patch
  
  *) modify the main makefile to exclude the current patch

  *) document the changes
  *) build and test it against a prior version
  *) post the diffs.

the limiting factor for accepting this fix is that i just don't
feel it's a priority. i have a lot of changes to axiom "in the
pipe", all of which are taking up my time and attention. a well
tested changeset would go a long way to getting it off your
irritation list.

> Really, this script is not so hard to understand is it?

yes, it is. really. it just reads as line noise to me. for example,
the variable 'uses' is not defined anywhere. nor is 'defns'.
what exactly is it trying to iterate over and where does the
data come from? this is all probably apparent to a sed/awk/shell
programmer but the point of literate programming is to make it
apparent to those people who need to maintain it. if i can't
understand it without learning 3 new languages then the next
person who needs to maintain it might not understand it either.

the fact that you understand a scripting language does not
make it the least bit transparent to me. 

\start
Date: 04 May 2006 05:04:36 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: noweb

Tim Daly writes:

| Bill,
| 
| > Please forgive my irritation but this issue *has* been discussed
| > repeatedly on this list. Most recently see:
| 
| i realize that the current solution is an irritation to you.
| i'd suggest that you check out a copy of axiom and integrate
| the patch. it's not as simple as it seems. fully integrating
| the patch involves, at least,
| 
|   *) change configure to check for an installed noweb
|   *) if noweb is not installed build it

My current Autoconf work does that.  It builds noweb at configure time
if none of the noweb utility is found.  It currently does that for the build
platform; it will do it for the target platform if necessary.

|   *) if noweb is installed check to see if the filter already exists

I can do this if I'm given sufficient detail of how to detect the
problem and where the filter could possibly reside.

\start
Date: Wed, 3 May 2006 23:12:41 -0400
From: Bill Page
To: Tim Daly
Subject: re: noweb

Tim,

You wrote:

> ...
> Bill Page wrote:
> > Really, this script is not so hard to understand is it?
>
> yes, it is. really. it just reads as line noise to me. for
> example, the variable 'uses' is not defined anywhere. nor
> is 'defns'. what exactly is it trying to iterate over and
> where does the data come from?

This is part of noweb. It would help a lot if you would bother
to read the noweb documentation:

http://www.literateprogramming.com/noweb_hacker.pdf

This was written by the author of noweb so I do expect that
he had literate programming in mind.

> this is all probably apparent to a sed/awk/shell
> programmer but the point of literate programming is to make it
> apparent to those people who need to maintain it. if i can't
> understand it without learning 3 new languages then the next
> person who needs to maintain it might not understand it either.
>
> the fact that you understand a scripting language does not
> make it the least bit transparent to me.
>

Get serious! awk is a standard unix tool and is part of every
linux distribution. It has been around for at least as long
the C programming language. We make no attempt to explain C
programming or even lisp programming to anyone, so why should
we need to explain awk?

\start
Date: 04 May 2006 05:10:27 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Axiom trunk failure

Gabriel Dos Reis writes:

| Bill Page writes:
| 
| | On Tuesday, May 02, 2006 2:12 AM Gabriel Dos Reis wrote:
| | > 
| | > Tim Daly (root) writes:
| | > 
| | > | yep. it turns off the "tail recursion" noise. bill schelter
| | > | and i worked on creating tail recursion in AKCL. This was
| | > | just a debugging message at the time. For some reason it
| | > | outlived its useful life and continues in the current code
| | > | base. the message "exposes" lisp to the user of the axiom
| | > | interpreter so i removed it.
| | > 
| | > Tim,
| | > 
| | > Is there a reason why this code should not be contributed back
| | > to GCL so that we don't have to patch GCL all the time?  
| | > 
| | 
| | As far as I know this patch is irrelevant
| 
| Great!  I'm preparing a patchlet to remove its application to the
| silver branch.

Bill --

Here is a patch for it.  I suppresed the patch for any version of GCL
greater than 2.6.7.  Should I be more aggressive than that?

Tim --

I nominate this patch for the gold branch.  In the long run, I believe
we should not construct a ghetto carefully delimitated by myriad of
local patches. 

\start
Date: Wed, 3 May 2006 23:17:37 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: noweb

Gaby,

On Wednesday, May 03, 2006 11:05 PM you wrote:
> ...
> |   *) if noweb is installed check to see if the filter already
> |      exists
>
> I can do this if I'm given sufficient detail of how to detect
> the problem and where the filter could possibly reside.
>

It would make good sense to me to put the 'axiom-noweb' file in
the Axiom scripts directory. It can be called simply by changing
the definition of the NOTANGLE variable in the Makefile to:

  NOTANGLE="notangle -filter axiom-noweb"

\start
Date: Wed, 3 May 2006 23:19:36 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: Axiom trunk failure

> |   (setq compiler::*suppress-compiler-notes* t)

this change is already integrated into the new bookvol5.pamphlet file.
however that file is radically changed from the current version
and is not yet ready to be released to the outside world. when
that major change is released in a future version the whole issue
will disappear. 

>   According to that message all but two of your patches to GCL would
> be already present in GCL.  Please could you clarify why we are still
> keeping more than patches for GCL?

time. again, the issue is time. it takes a long time to make changes
to axiom assuming you're going to ensure they are correct before
releasing them to the world.

GCL works as it is currently installed in axiom. many other things
do not. still other facilities needs documenting. yet more need
enhancing. 

the long term will find axiom on ansi common lisp, hopefully
without patches to any of the ansi lisp systems, including gcl.
however i have not yet finished the ansi port but when that major 
change is released in a future version the whole issue will disappear.


about every 6 months i finish a major portion of axiom work (e.g.
the original algebra, the original book, the browser recovery, the
graphics recovery, the sman "feature complete" build, major ports,
the tutorial book, etc). there are yet more in the pipe and when
i sit down to work on axiom in the limited time i have available
i need to work on big changes which make the system more useful
and accessible. 

if you follow the GCL discussions from the past it is possible
to re-engineer axiom so it will run on a natively installed GCL.
to do that you need to:

  *) change configure to detect if gcl is installed
  *) change configure to ensure that the native gcl is the
     correct version and patch level
  *) if not, build gcl from zips and apply the correct patches

i would note here that it is NOT acceptable to stop the build
and insist that the user install/upgrade some other package. axiom 
builds should 'just work'. 
  
  *) change/document the top level makefile to reflect these changes

  *) change/document the lsp/makefile to reflect these changes

  *) change/docuemnt the src/boot/makefile, src/interp/makefile, and
     src/algebra/makefile to build using native gcl

  *) document the changes
  *) test the changes against a prior version
  *) test the changes on all known ports
  *) post the patches

there is no such thing as a simple job.

\start
Date: 04 May 2006 05:33:31 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Axiom trunk failure

Gabriel Dos Reis writes:

[...]

| | | As far as I know this patch is irrelevant
| | 
| | Great!  I'm preparing a patchlet to remove its application to the
| | silver branch.
| 
| Bill --
| 
| Here is a patch for it.

Gosh, I forgot the real thing.  
It is there, real this time.

-- Gaby

lsp/ChangeLog
2006-05-03  Gabriel Dos Reis  <gdr@acm.org>
 
 	* Makefile.pamphlet: Skip tail-recursive patch for GCL version
 	greater or equal to 2.6.7.  Document.
 
zips/ChangeLog
2006-05-03  Gabriel Dos Reis  Gabriel Dos Reis
 
  	* gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch: Delete.
  	* gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch: Likewise.
  	* gcl-2.6.7pre.cmpnew.gcl_cmpcall.lsp.patch: Likewise.
  	* gcl-2.6.7pre.cmpnew.gcl_cmpflet.lsp.patch: Likewise.
  	* gcl-2.6.8pre.cmpnew.gcl_cmpcall.lsp.patch: Likewise.
 
*** lsp/Makefile.pamphlet	(revision 32)
--- lsp/Makefile.pamphlet	(local)
*************** Bill Schelter added tail recursion for A
*** 383,389 ****
  he left code in the system to print a message when the code was
  executed. We no longer care but it is still in GCL. We patch the
  call rather than the cmpnote function as cmpnote might have later
! usage.
  <<gcl-2.5.2.tail-recursive.patch>>=
  	@(cd ${GCLVERSION}/cmpnew ; \
  	  echo 11 applying tail-recursive noise patch ; \
--- 383,393 ----
  he left code in the system to print a message when the code was
  executed. We no longer care but it is still in GCL. We patch the
  call rather than the cmpnote function as cmpnote might have later
! usage.  
! 
! Bill Page reported that this tail-recursive patch is no longer
! necessary for recent releases of GCL.  Consequently, it has 
! been disabled for all versions of GCL greater than 2.6.7.
  <<gcl-2.5.2.tail-recursive.patch>>=
  	@(cd ${GCLVERSION}/cmpnew ; \
  	  echo 11 applying tail-recursive noise patch ; \
*************** GCL 2.6.1 renamed the files.
*** 457,478 ****
  	  echo 12 applying tail-recursive noise patch ; \
  	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpcall.lsp.patch )
  @
- <<gcl-2.6.7.tail-recursive.patch>>=
- 	@(cd ${GCLVERSION}/cmpnew ; \
- 	  echo 11 applying tail-recursive noise patch ; \
- 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpflet.lsp.patch )
- 	@(cd ${GCLVERSION}/cmpnew ; \
- 	  echo 12 applying tail-recursive noise patch ; \
- 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpcall.lsp.patch )
- @
- <<gcl-2.6.8pre.tail-recursive.patch>>=
- 	@(cd ${GCLVERSION}/cmpnew ; \
- 	  echo 11 applying tail-recursive noise patch ; \
- 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpflet.lsp.patch )
- 	@(cd ${GCLVERSION}/cmpnew ; \
- 	  echo 12 applying tail-recursive noise patch ; \
- 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpcall.lsp.patch )
- @
  \subsubsection{collectfn fix}
  GCL-2.6.1 renamed collectfn.lsp to gcl\_collectfn.lsp.
  We rename it back into place because we have later Makefiles
--- 461,466 ----
*** zips/gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch	(revision 32)
--- zips/gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch	(local)
***************
*** 1,13 ****
- --- gcl_cmpcall.lsp	Sun Jul 24 12:54:28 2005
- +++ gcl_cmpcall.lsp.tpd	Sun Jul 24 12:58:36 2005
- @@ -264,7 +264,9 @@
-              (wt-label *exit*))
-        (unwind-no-exit 'tail-recursion-mark)
-        (wt-nl "goto TTL;")
- -      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname))
- +; 20031022000 tpd we don't need to know this
- +;      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname)
- +      )
-  
-       ;;; Open-codable function call.
-       ((and (listp args)
--- 0 ----

Property changes on: zips/gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

*** zips/gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch	(revision 32)
--- zips/gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch	(local)
***************
*** 1,15 ****
- --- gcl_cmpflet.lsp	Sun Jul 24 12:54:29 2005
- +++ gcl_cmpflet.lsp.tpd	Sun Jul 24 13:44:18 2005
- @@ -390,8 +390,10 @@
-            (wt-label *exit*))
-      (unwind-no-exit 'tail-recursion-mark)
-      (wt-nl "goto TTL;")
- -    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
- -             (fun-name (car fd))))
- +; 20031022000 tpd we don't need to know this
- +;    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
- +;             (fun-name (car fd)))
- +    )
-     (t (push-args args)
-        (wt-nl (c-function-name "L" (fun-cfun (car fd)) (fun-name (car fd))) "(")
-        (dotimes** (n (fun-level (car fd))) (wt "base" n ","))
--- 0 ----

Property changes on: zips/gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

*** zips/gcl-2.6.7pre.cmpnew.gcl_cmpcall.lsp.patch	(revision 32)
--- zips/gcl-2.6.7pre.cmpnew.gcl_cmpcall.lsp.patch	(local)
***************
*** 1,13 ****
- --- gcl_cmpcall.lsp	Sun Jul 24 12:54:28 2005
- +++ gcl_cmpcall.lsp.tpd	Sun Jul 24 12:58:36 2005
- @@ -264,7 +264,9 @@
-              (wt-label *exit*))
-        (unwind-no-exit 'tail-recursion-mark)
-        (wt-nl "goto TTL;")
- -      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname))
- +; 20031022000 tpd we don't need to know this
- +;      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname)
- +      )
-  
-       ;;; Open-codable function call.
-       ((and (listp args)
--- 0 ----

Property changes on: zips/gcl-2.6.7pre.cmpnew.gcl_cmpcall.lsp.patch
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

*** zips/gcl-2.6.7pre.cmpnew.gcl_cmpflet.lsp.patch	(revision 32)
--- zips/gcl-2.6.7pre.cmpnew.gcl_cmpflet.lsp.patch	(local)
***************
*** 1,15 ****
- --- gcl_cmpflet.lsp	Sun Jul 24 12:54:29 2005
- +++ gcl_cmpflet.lsp.tpd	Sun Jul 24 13:44:18 2005
- @@ -390,8 +390,10 @@
-            (wt-label *exit*))
-      (unwind-no-exit 'tail-recursion-mark)
-      (wt-nl "goto TTL;")
- -    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
- -             (fun-name (car fd))))
- +; 20031022000 tpd we don't need to know this
- +;    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
- +;             (fun-name (car fd)))
- +    )
-     (t (push-args args)
-        (wt-nl (c-function-name "L" (fun-cfun (car fd)) (fun-name (car fd))) "(")
-        (dotimes** (n (fun-level (car fd))) (wt "base" n ","))
--- 0 ----

Property changes on: zips/gcl-2.6.7pre.cmpnew.gcl_cmpflet.lsp.patch
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

*** zips/gcl-2.6.8pre.cmpnew.gcl_cmpcall.lsp.patch	(revision 32)
--- zips/gcl-2.6.8pre.cmpnew.gcl_cmpcall.lsp.patch	(local)
***************
*** 1,13 ****
- --- gcl_cmpcall.lsp	Sun Jul 24 12:54:28 2005
- +++ gcl_cmpcall.lsp.tpd	Sun Jul 24 12:58:36 2005
- @@ -264,7 +264,9 @@
-              (wt-label *exit*))
-        (unwind-no-exit 'tail-recursion-mark)
-        (wt-nl "goto TTL;")
- -      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname))
- +; 20031022000 tpd we don't need to know this
- +;      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname)
- +      )
-  
-       ;;; Open-codable function call.
-       ((and (listp args)
--- 0 ----
*** zips/gcl-2.6.8pre.cmpnew.gcl_cmpflet.lsp.patch	(revision 32)
--- zips/gcl-2.6.8pre.cmpnew.gcl_cmpflet.lsp.patch	(local)
***************
*** 1,15 ****
- --- gcl_cmpflet.lsp	Sun Jul 24 12:54:29 2005
- +++ gcl_cmpflet.lsp.tpd	Sun Jul 24 13:44:18 2005
- @@ -390,8 +390,10 @@
-            (wt-label *exit*))
-      (unwind-no-exit 'tail-recursion-mark)
-      (wt-nl "goto TTL;")
- -    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
- -             (fun-name (car fd))))
- +; 20031022000 tpd we don't need to know this
- +;    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
- +;             (fun-name (car fd)))
- +    )
-     (t (push-args args)
-        (wt-nl (c-function-name "L" (fun-cfun (car fd)) (fun-name (car fd))) "(")
-        (dotimes** (n (fun-level (car fd))) (wt "base" n ","))
--- 0 ----

\start
Date: Wed, 3 May 2006 23:39:12 -0400
From: Bill Page
To: Tim Daly
Subject: re: Axiom trunk failure

Tim,

On Wednesday, May 03, 2006 11:20 PM you wrote:
> ... it takes a long time to make changes to axiom assuming
> you're going to ensure they are correct before releasing
> them to the world.

This is the wrong assumption to make about open source. You
are not "releasing" a product, you are doing collaborative
development - hopefully involving many other people. The
quality of the result depends on their participation.

> ...
> about every 6 months i finish a major portion of axiom work
> (e.g. the original algebra, the original book, the browser
> recovery, the graphics recovery, the sman "feature complete"
> build, major ports, the tutorial book, etc). there are yet
> more in the pipe and when i sit down to work on axiom in the
> limited time i have available i need to work on big changes
> which make the system more useful and accessible.
>

It does not make sense that you are trying to do all this by
yourself. If Axiom is going to get anywhere this has to be a
collaborative effort.

> if you follow the GCL discussions from the past it is possible
> to re-engineer axiom so it will run on a natively installed GCL.
> to do that you need to:
>
>   *) change configure to detect if gcl is installed
>   *) change configure to ensure that the native gcl is the
>      correct version and patch level
>   *) if not, build gcl from zips and apply the correct patches
>
> i would note here that it is NOT acceptable to stop the build
> and insist that the user install/upgrade some other package.
> axiom builds should 'just work'.

I *strongly* disagree with this. Even the GCL build itself
will stop if it does not find the necessary prerequisits.
Satisfying prerequists is not the job of the build software.
This is handled by other tools like apt-get and yum.

> ...
> there is no such thing as a simple job.
>

There is such a thing as a job that is too large for one
man.

\start
Date: 04 May 2006 05:36:54 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom trunk failure

Tim Daly writes:

[...]

| if you follow the GCL discussions from the past it is possible
| to re-engineer axiom so it will run on a natively installed GCL.
| to do that you need to:
| 
|   *) change configure to detect if gcl is installed
|   *) change configure to ensure that the native gcl is the
|      correct version and patch level

What is the "correct version"?

\start
Date: Wed, 3 May 2006 23:56:49 -0400
From: Tim Daly
To: Bill Page
Subject: re: noweb

> Get serious! awk is a standard unix tool and is part of every
> linux distribution. It has been around for at least as long
> the C programming language. We make no attempt to explain C
> programming or even lisp programming to anyone, so why should
> we need to explain awk?

three points:

1) perl, python, asp, javascript, etc are all part of any standard
linux distribution as are several dozen other langauges like m4
(used by sendmail). though i've written commercial applications
in over 60 languages and used unix for over 20 years i do not speak
any of these languages.

axiom uses only a few languages, lisp, C, some trivial shell scripts,
latex and make. it also (currently) includes boot which is completely
undocumented. 

i'd much rather reduce the number of languages need to understand
axiom rather than enlarge the number. some are necessary (like
lisp, spad, aldor) but some are optional (e.g. java in the aldor
merge) and more properly should be done using existing tools.

there are many feasible solutions to a problem. and there are
many "convenient" solutions in many different languages. but 
solutions which expand the needed skill set for maintainers are
much less desireable than ones which do not.

as a policy i favor minimizing the number of languages used.
adding sed (1 language), awk (a second), clever bash shell
scripts (a third), java (a fourth), auto* (a fifth), simply
reduces the number of people who can reliably maintain the system
and increases the work required to port, possibly to the point
of being impossible.




2) sed and awk are NOT standard parts of a windows distribution.
again as a matter of policy we need to reduce the requirements
so we can work across a larger number of systems. ideally all 
of axiom would run in common lisp and porting becomes a copy
operation. C is only slightly more problematic. in fact, the
key reason that axiom does not currently run on the mac is breakage
caused by C. awk/sed/autoconf all seriously complicate the port issue.

frankly i'd much rather see the tools devolve into lisp implementations.
gcl, sbcl and clisp generate native exe files on windows and executables
on linux. given that lisp is a full programming language and is integral
to axiom why don't we write code that is trivial to port rather than
add requirements that are certain to make axiom unportable?

as a policy i favor doing things in lisp unless it can be shown
that such a solution is impossible. in the future i'd make the
same claim about using aldor (assuming we free aldor).





3) in fact i'm making every attempt to explain the lisp programs
as you'll see in the eventual bookvol5.pamphlet file. it is
NOT necessary to explain the language idioms but it IS necessary
to explain what is happening in a block of code.

the noweb script will be sitting in a standalone pamphlet in src/scripts.
it will not appear as an integral part of anything to a future maintainer.
so the future maintainer can reasonably expect to have a (possibly 
redundant) explanation of why this script exists, what it does, what
data it expect to work on, etc. this is NOT the same as explaining
the awk language constructs.


i would argue that literate programming is a fundamental change in
mindset that requires you to explain to some future maintainer how
and why any new code works. he should be able to read the paragraph
and know where this code fits as well as what it is trying to accomplish.
that's NOT the same as explaining the awk/sed language. but it IS the
whole point of literate programming.

\start
Date: Thu, 4 May 2006 00:04:13 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: Axiom trunk failure

> Gosh, I forgot the real thing.  
> It is there, real this time.

2 points,

1) did you test the patches? did you do a full system erase,
system checkout, system build, system test? 

2) you changed not only the current system (gcl-2.6.8pre) but
the previous system (gcl-2.6.7). did you test both versions?

i know this seems like such a trivial patch that it "ought" to work
but remember that you're asking for changes to a system that many
people you might never meet are using. 

as a matter of policy changes need to be fully tested. 
because you changed gcl-2.6.7 i'll actually have to do a 
round-trip rebuild of a gcl-2.6.7 system as well as a gcl-2.6.8pre
system. i do testing every time. and it takes a lot of time.
but you'd be amazed at the number of ways things can break.
witness the mistake i made (despite my best efforts) when
i posted a broken --patch-48

\start
Date: Thu, 4 May 2006 00:28:58 -0400
From: Bill Page
To: Tim Daly
Subject: re: noweb

Tim,

On Wednesday, May 03, 2006 11:57 PM you wrote:
> ...
> three points:
>
> 1) perl, python, asp, javascript, etc are all part of any standard
> linux distribution ...
>
> as a policy i favor minimizing the number of languages used.
> adding sed (1 language), awk (a second), clever bash shell
> scripts (a third), java (a fourth), auto* (a fifth), simply
> reduces the number of people who can reliably maintain the system
> and increases the work required to port, possibly to the point
> of being impossible.
>
The reality is that as soon as you write 'lisp' you have already
very drastically reduced the number of possible maintainers. In
comparison requiring a knowledge of 'sed', 'awk', 'bash', and
'java' barely has any impact on the current generation of open
source developers.

>
> 2) sed and awk are NOT standard parts of a windows distribution.
> again as a matter of policy we need to reduce the requirements
> so we can work across a larger number of systems.

Actually 'sed' and 'awk' are standard tools in all of the open
source development environments for windows (but of course are
not part of the Microsoft windows "distribution"). Specifically
they are part of the MSYS/MinGW environment that is currently
used to build GCL and Axiom.

> ideally all of axiom would run in common lisp and porting
> becomes a copy operation. C is only slightly more problematic.

I think porting applications written in "common lisp" between
linux and Windows is at least as problematic as those written
in C as our experience with the AxiomUI code written by Kai
Kaminski showed. Kai wrote in Clisp which runs on both linux
and windows but the code was not automatically portable.

> in fact, the key reason that axiom does not currently run on
> the mac is breakage caused by C. awk/sed/autoconf all seriously
> complicate the port issue.

I don't think this is any more complicated than the porting of
any other open source linux application.

>
> frankly i'd much rather see the tools devolve into lisp
> implementations. gcl, sbcl and clisp generate native exe
> files on windows and  executables on linux. given that lisp
> is a full programming language and is integral to axiom why
> don't we write code that is trivial to port rather than
> add requirements that are certain to make axiom unportable?

I don't believe that it is trivial to port lisp applications.
We still require some windows specific patches to the Axiom
lisp sources before it will compile under gcl on windows.

> ...
> 3) in fact i'm making every attempt to explain the lisp programs
> as you'll see in the eventual bookvol5.pamphlet file. it is
> NOT necessary to explain the language idioms but it IS necessary
> to explain what is happening in a block of code.
>
> the noweb script will be sitting in a standalone pamphlet in
> src/scripts. it will not appear as an integral part of anything
> to a future maintainer. so the future maintainer can reasonably
> expect to have a (possibly redundant) explanation of why this
> script exists, what it does, what data it expect to work on, etc.
> this is NOT the same as explaining the awk language constructs.
>

How this script works was explained by Norman Ramsey in his
original post:

http://lists.nongnu.org/archive/html/axiom-developer/2002-11/msg00059.ht
ml

------------
Write an awk script that copies all lines to stdout, and in the
process, identifies each @use that has no corresponding @defn.
For each such @use emit this code chunk:

@begin code
@defn this is my text
@text <<this is my text>>
@end code
------------

>
> i would argue that literate programming is a fundamental change in
> mindset that requires you to explain to some future maintainer how
> and why any new code works. he should be able to read the paragraph
> and know where this code fits as well as what it is trying to
> accomplish.
> that's NOT the same as explaining the awk/sed language. but it
> IS the whole point of literate programming.
>

I agree that Norman Ramsey's description of this awk script should
be included in the associated pamphlet file.

\start
Date: Thu, 4 May 2006 00:48:44 -0400
From: Bill Page
To: Tim Daly
Subject: re: noweb

Tim,

On Wednesday, May 03, 2006 11:57 PM you wrote:
>
> 3) ...
>
> the noweb script will be sitting in a standalone pamphlet in
> src/scripts. it will not appear as an integral part of anything
> to a future maintainer.
> ...

Although this script is not so important in the overall toolset
for the Axiom source distribution (being only a consequence of
the standard implementation of noweb), I think the noweb filter
script itself should be a chunk in the main 'Makefile.pamphlet'
and adequately explained there in the context of the discussion
of literate programming and the choice of noweb. This is where
any maintainer is most likely to look first in the case of a
failure of this kind.

\start
Date: Thu, 4 May 2006 00:59:11 -0400
From: Tim Daly
To: Bill Page
Subject: re: Axiom trunk failure

> > ... it takes a long time to make changes to axiom assuming
> > you're going to ensure they are correct before releasing
> > them to the world.
> 
> This is the wrong assumption to make about open source. You
> are not "releasing" a product, you are doing collaborative
> development - hopefully involving many other people. The
> quality of the result depends on their participation.

participation is great and i've accepted almost every patch
sent to me. i'm hoping to see a drastic increase in the
number of tested patches. 

we differ about the "releasing a product" philosophy.
most people either use axiom or they don't. very, very
few people will make changes. thus we who make changes
have a responsibility to maintain the quality of the system. 

i'm applying personal standards here but i do not believe
we should release anything that isn't the very best we can do.
and it should be simple to install, work properly, be fully
documented, well tested, and proven as correct as we can.
this is computational mathematics, not word processing.

it's fine to do anything we want in the silver branch
but the golden version should be as close to perfect
as we can make it.


> > ... 
> > about every 6 months i finish a major portion of axiom work
> > (e.g. the original algebra, the original book, the browser
> > recovery, the graphics recovery, the sman "feature complete"
> > build, major ports, the tutorial book, etc). there are yet
> > more in the pipe and when i sit down to work on axiom in the
> > limited time i have available i need to work on big changes
> > which make the system more useful and accessible. 
> > 
> 
> It does not make sense that you are trying to do all this by
> yourself. If Axiom is going to get anywhere this has to be a
> collaborative effort.

being open source axiom can be changed in any way by anyone.
so far i haven't seen much in the way of patches posted to
the list. i HAVE set up almost a dozen separate branches in
the tla archive for people who have proposed major changes.
some of them have multiple names associated with the branches.
i'm assuming that these people are working on their own with
the goal of eventually merging their branch with the main line.
so far that hasn't happened but it could. why would someone
work on a branch and never merge it? the work will eventually
get lost. there are 22 people with write access to arch.
many have their own branch.

it's quite possible for you to make a major system change
by integrating the windows changes back into the main stream.
you could get it building cross-platform and post patches.
we should be able to just type 'AXIOM=.../windows' ; make
and get a working windows version. once that works we can
try to get the browser/graphics/sman working. but right now,
even for me, the windows version feels a bit like a black box.
i have a semi-working browser but can't integrate it into the
main line until the rest of the windows changes get merged.

i have a huge number of goals for axiom. but these are all my own
goals (like the internal rewrite, the proviso research, etc).  so i'm
working to "scratch my own itches". when i complete a major task i
merge my changes into the main branch. but until those tasks complete
they all occur on my own machines. so far many people such as
Bertfried Fauser (clifford algebra), Bill Walster (interval analysis),
Chuck Miller (Mac port), Camm (GCL) have all collaborated with me. but
only some of those have moved into the working stages yet. i have a
textbook on clifford algebra and a textbook on interval analysis open
on my desk. i'm learning a lot and writing algebra code but these two
problems alone will be multi-year efforts.

i've joined axiom to the numerical mathematics consortium
(http://www.nmconsortium.org/FldRte/?id=72&page=Associate+Members)
because i have an interest in recovering the numerical library
facility for axiom. i have rewritten the BLAS library into literate
form and have gotten permission from a BLAS person to use his research
work as documentation for the routines. i'm in the process of
documenting the BLAS code now. when it completes i'll release a
numeric library for axiom that is literate BLAS. then i'll move on to
the next numerical piece. along the way i'm learning about sensitivity
analysis, methods of graphing branch cuts, etc. and trying to add what
i've learned to the documentation for the code.

for me, axiom opens up whole worlds of interesting work.
i'm not trying to be a one-man show but i don't see other patches.
i'm amazed that no-one else seems to see the opportunities.
or if they do then i'm puzzled why they don't exploit them.
anybody can do anything with axiom. 

my only regret is that my full time job is not axiom.

 
> > if you follow the GCL discussions from the past it is possible
> > to re-engineer axiom so it will run on a natively installed GCL.
> > to do that you need to:
> > 
> >   *) change configure to detect if gcl is installed
> >   *) change configure to ensure that the native gcl is the
> >      correct version and patch level
> >   *) if not, build gcl from zips and apply the correct patches
> > 
> > i would note here that it is NOT acceptable to stop the build
> > and insist that the user install/upgrade some other package.
> > axiom builds should 'just work'.
> 
> I *strongly* disagree with this. Even the GCL build itself
> will stop if it does not find the necessary prerequisits.
> Satisfying prerequists is not the job of the build software.
> This is handled by other tools like apt-get and yum.

well, we'll always disagree on this. always.

i have used redhat's rpm, redhat's update, apt-get, and yum. and they
all break things that used to work and upgrade packages that i don't
want touched. i have a recently installed FC5 system that was intended
to be used for axiom porting. after a yum update it is now
non-functional. now i have to waste time doing a re-install of FC5. i
do NOT want this to happen to an axiom user, at least not because they
tried to install axiom.

it should 'just work', correctly, cleanly, and out of the box.

> > ... 
> > there is no such thing as a simple job.
> > 
> 
> There is such a thing as a job that is too large for one
> man.

oh, absolutely. i will probably not finish half of what i
want to do with axiom in this lifetime. but i'm having great
fun doing it anyway.

\start
Date: Thu, 4 May 2006 01:00:29 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: Axiom trunk failure

gcl-2.6.8pre is the "correct version". see the GCLVERSION in the
top level Makefile. i'm not sure how you can check the version
number in GCL but there must be a way.

\start
Date: Thu, 4 May 2006 01:21:15 -0400
From: Bill Page
To: Tim Daly
Subject: re: Axiom trunk failure

On Thursday, May 04, 2006 1:00 AM Tim Daly (root) wrote:

>
> gcl-2.6.8pre is the "correct version". see the GCLVERSION in the
> top level Makefile. i'm not sure how you can check the version
> number in GCL but there must be a way.
>

  echo '(lisp-implementation-version)' | gcl

\start
Date: Thu, 4 May 2006 01:31:27 -0400
From: Bill Page
To: Tim Daly
Subject: re: Axiom trunk failure

Tim,

On Thursday, May 04, 2006 12:59 AM you wrote:
> ...
> Bill Page wrote:
> >
> > I *strongly* disagree with this. Even the GCL build itself
> > will stop if it does not find the necessary prerequisits.
> > Satisfying prerequists is not the job of the build software.
> > This is handled by other tools like apt-get and yum.
>
> well, we'll always disagree on this. always.
>
> i have used redhat's rpm, redhat's update, apt-get, and yum.
> and they all break things that used to work and upgrade packages
> that i don't want touched. i have a recently installed FC5
> system that was intended to be used for axiom porting. after a
> yum update it is now non-functional.

You have reported this to the Fedora Core developers?

> now i have to waste time doing a re-install of FC5. I do NOT
> want this to happen to an axiom user, at least not because they
> tried to install axiom.

If you do not trust programs that attempt to automatically
resolve dependencies then why would you want to build this
functionality into the Axiom source distribution?

>
> it should 'just work', correctly, cleanly, and out of the box.
>

I think the developers of apt-get and yum might agree with
you. ;) But I think most developers would prefer to take care
of this themselves.

People who want to work with Axiom without these hassles
should install the appropriate binary version.

\start
Date: Thu, 4 May 2006 02:33:23 -0400
From: Bill Page
To: list
Subject: downloading via BitTorrent

BitTorrent is a peer-to-peer file distribution protocol.

http://en.wikipedia.org/wiki/Bittorrent

I have recently installed BitTorrent clients (MLDonkey) on both
the axiom-developer.org server and axiom.risc.uni-linz.ac.at
mirror.

http://mldonkey.sourceforge.net/Main_Page

As an aside: I think MLDonkey itself is rather interesting since
it is implemented in OCaml:

http://mldonkey.sourceforge.net/ObjectiveCaml

OCaml is a functional/imperative language not too different from
Aldor and the Axiom SPAD compiler and is the language in which
Coq proof assistant is written:

http://pauillac.inria.fr/coq

and so is quite important for potential integration of mathematical
theorem into Axiom.

And MLdonkey also implements it's graphical user interface via a
web browser.

-------

Anyway, BitTorrent is hugely successful at downloading large files
by distributing the responsibility for serving these files to the
clients doing the downloading themselves. The two installations of
MLDonkey provide the "seeds" from which it is always possible to
obtain a copy of a file but they are usually not solely responsible
for delivering copies of these files to clients - that is normally
shared among those client (peer) systems who have already downloaded
the file. This makes it possible provide very high download rates
to a large number of people because the "serving" of the files is
also distributed to other downloaders.

Part of making a file available via BitTorrent is the requirement
to produce a '.torrent' file that contains the binary "signature"
of the original file (among other control information). This
ensures that in spite of being pieced together from many different
download sources, the resulting file is identical to the original
file as registered at a "tracker". So this method also provides
greater security and authenticity of the downloaded file. BitTorrent
trackers also double as search engines for downloadable files.

3 days ago I created a '.torrent' file for the current Windows
binary version of Axiom and registered it at a commonly used
tracker named TorrentBox.com. I also seeded the file at
axiom-developer and axiom.risc and added a link to the '.torrent'
file in the Windows section of:

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

I just checked the status of this file at TorrentBox and I was
amazed to see that in just 3 days the Windows version of Axiom
has already been downloaded 126 times. See:

http://www.torrentbox.com/torrents-search.php?search=axiom&cat=50

Torrent Info=09

Edit this .torrent
DL Torrent	axiom-windows-0.1.4.exe.torrent
Info hash	8bb782d62719700957cf2dc6cf0f1f447f227622
Category	Apps - Windows
Size	      48.01 MB (50339854 Bytes)
Added	      2006-05-01
Views	      56
Hits	      50
Snatched	126 time(s)
Upped by	billpage
Peers	      2 seeders + 0 leechers = 2 peers

---------

This also says that 50 of this "hits" were a result of searches
on the TorrentBox tracker itself while the other 76 were
presumably from the link on the AxiomDownload page.

These 126 downloads were in *addition* to the 29 times the same
file was downloaded from axiom-developer.org

http://page.axiom-developer.org/usage/usage_200605.html

and 204 times it was been downloaded from the axiom.risc mirror

http://axiom.risc.uni-linz.ac.at/webalizer/usage_200605.html

Isn't that rather surprising!???

I did not really expect that there was such a demand for the
Windows version of Axiom. Right now I think the use of BitTorrent
is much more common among Windows users - partly because
BitTorrent is very popular for downloading large music and
video files and linux is not (yet) very good at handling
these. But good BitTorrent clients do also exist for linux.

If anyone has any comments or suggestions about the use of
BitTorrent to distribute the Axiom binaries please let me know.
I am thinking seriously about making all of the Axiom binary
and source tarball files available this way.

\start
Date: Thu, 04 May 2006 09:25:54 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: noweb

Hi Bill, hello Gaby,

Look at this...

http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00262.html

I would even say: Throw away the noweb sources, throw away this awk 
script and rather go to the Axiom sources and correct a usage of an 
undefined chunk. Why would one want to have undefined chunks in the 
first place?

See also

http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00247.html

That is a bug. Ahm, was a bug, because "noweb 2.11 - released 6 April 
2006" (http://www.eecs.harvard.edu/~nr/noweb/dist/noweb/CHANGES) seems 
to have corrected it. I've not yet time to check 2.11, though.

Ralf


On 05/04/2006 03:34 AM, Page, Bill wrote:
> Gaby,
> 
> Thanks for your continuing work on the Axiom Silver branch! :)
> 
> On Wednesday, May 03, 2006 4:36 PM you wrote:
>> ...
>> Tim Daly (root) wrote: 
>> | modules.c is one way to fix the noweb bug. i've submitted it
>> | as a patch to norman ramsey but he rejected it saying that i
>> | should use sed/awk to fix the problem rather than patch the
>> | C code. unfortunately i'm not a sed/awk programmer so rather
>> | than learn two new tools i simply kept the patch (which works).
>>
>> Can you give me a test for detecting the problem, or at least
>> a detailed description of how to reproduce it?  Did Norman
>> Ramsey suggest on which file you should use the sed/awk fix?
>> Again, I'm willing to help out that issue:  It stands in my
>> way of making progress on the build machinery stuff.
> 
> Please forgive my irritation but this issue *has* been discussed
> repeatedly on this list. Most recently see:
> 
> http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00226.html
> 
> Here is the awk script again since the version stored in the
> axiom-developer archive is mangled because it confuses some of
> script with an email address:
> 
> axiom-noweb:
> ------------
> 
> #!/bin/sh
> 
> awk '
> /@use /  { uses [substr($0, 6)] = 1 }
> /@defn / { defns[substr($0, 7)] = 1 }
> { print }
> END {
>   for (i in uses)
>     if (!defns[i])
>       printf "@begin code\n@defn %s\n@nl\n@text <<%s>>\n@end code\n", i,
> i
> }'
> 
> exit 0
> 
> # test with
> 
> sed '1,/test with/d' $0 | notangle -filter $0
> 
> <<*>>=
> return x << 2 >> 2;
> @
> 
> --------
> 
> All we have to do is include this script with the Axiom
> distribution and call it as a filter as he shows.
> 
> % notangle -filter axiom-noweb
> 
> Really, this script is not so hard to understand is it? The
> documentation for noweb filters is here:
> 
> http://www.literateprogramming.com/noweb_hacker.pdf

\start
Date: Thu, 04 May 2006 09:36:57 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: re: noweb

[Norman Ramsey's awk script...]
>> Really, this script is not so hard to understand is it?
> 
> yes, it is. really. it just reads as line noise to me. for example,
> the variable 'uses' is not defined anywhere. nor is 'defns'.
> what exactly is it trying to iterate over and where does the
> data come from? this is all probably apparent to a sed/awk/shell
> programmer but the point of literate programming is to make it
> apparent to those people who need to maintain it. if i can't
> understand it without learning 3 new languages then the next
> person who needs to maintain it might not understand it either.

Even if I think that we actually don't need the awk script, I very much 
agree with Tim in the sense that code pieces should be explained in such 
a way that also people that have no or little experience in that 
particular language have a chance to understand the code. Yes, it also 
means to explain, why it is not necessary to initialize/declare 'uses' 
and 'defn' before using these variables.

For me, literate programming also means: make it easier for people who 
come after you.

\start
Date: 04 May 2006 10:06:31 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom trunk failure

Tim Daly writes:

| > Gosh, I forgot the real thing.  
| > It is there, real this time.
| 
| 2 points,

Thanks for the quick review.

| 
| 1) did you test the patches? did you do a full system erase,
| system checkout, system build, system test? 

* I have not checked in the patch so there is no system checkout to be
  made.  I reckon I was fast in nominating the patch for golden
  branch.  I should have said it is a first cut to see whether the
  first order is correct, e.e.g whether the GCL version I set as cut
  was OK.  Remember one of my questions was:

      Should I be more aggressive than that?


* the only system erase I have to do is that of the build directory
  because the "lndir" procedure I described here

      http://wiki.axiom-developer.org/AxiomSilverBranch
   
  permits build outside of the source directory -- which I do anyway
  because I consider the current scheme not acceptable.  Hopefully,
  the Autoconf work will remove that additional step unnecessary.

| 2) you changed not only the current system (gcl-2.6.8pre) but
| the previous system (gcl-2.6.7). did you test both versions?

Does that mean you consider that only gcl-2.6.8pre should be touched?
That was my key original question I'm interested in having answer for :-)

| i know this seems like such a trivial patch that it "ought" to work
| but remember that you're asking for changes to a system that many
| people you might never meet are using. 

Please Tim, stop lecturing on "ought to work" and assume we all know
take that as a basic working assumption assuming.

| as a matter of policy changes need to be fully tested. 

That requirement is part of the "Preparing and submitting patches" 
section of

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

Yes, I failed to mention on which plateform I have tested the patch,
primarily because I was interested in whether the first order cut is
OK. 

| because you changed gcl-2.6.7 i'll actually have to do a 
| round-trip rebuild of a gcl-2.6.7 system as well as a gcl-2.6.8pre
| system. 

Assume that will be done and clearly stated when I'm about to commit
the changes.

| i do testing every time. and it takes a lot of time.

I know building Axiom currently takes a lot of time -- I did five
builds yesterday, and while the system was building I was able to make
good progress on daytime job projects.  There ought to be
a way of saying "make -jN" and have it work.  Yes, I read the FAQ as
of why it is not possible.  But we should fix it.

| but you'd be amazed at the number of ways things can break.

Tim, I know how much of superstition is at the basis of software
construction even though it should be a rational activity.  So, no,
I'll not be amazed at all :-)

Testing for both versions of GCL are running on x86.


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!

\start
Date: 04 May 2006 10:29:20 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom trunk failure

Tim Daly writes:

[...]

| most people either use axiom or they don't. very, very
| few people will make changes. thus we who make changes
| have a responsibility to maintain the quality of the system. 

I concur with that assessment.

| i'm applying personal standards here but i do not believe
| we should release anything that isn't the very best we can do.

Fully agreed.  

We should also not forget the conventional wisdom that the best is the
enemy of good.  

| and it should be simple to install, work properly, be fully
| documented, well tested, and proven as correct as we can.

Again fully agreed.

| this is computational mathematics, not word processing.

some may disagree :-)

| it's fine to do anything we want in the silver branch
| but the golden version should be as close to perfect
| as we can make it.

That is understood.  In fact, I hope you don't think of the silver

[...]

| it's quite possible for you to make a major system change
| by integrating the windows changes back into the main stream.
| you could get it building cross-platform and post patches.
| we should be able to just type 'AXIOM=.../windows' ; make
| and get a working windows version.

we should just be able to type "./configure; make make install"
and have it working.  Expect that soon for Unix-like systems!
(And I hope it will work for Cygwin-based systems too.)

[...]

| i've joined axiom to the numerical mathematics consortium
| (http://www.nmconsortium.org/FldRte/?id=72&page=Associate+Members)
| because i have an interest in recovering the numerical library
| facility for axiom. i have rewritten the BLAS library into literate
| form and have gotten permission from a BLAS person to use his research
| work as documentation for the routines. i'm in the process of
| documenting the BLAS code now. when it completes i'll release a
| numeric library for axiom that is literate BLAS. then i'll move on to
| the next numerical piece. along the way i'm learning about sensitivity
| analysis, methods of graphing branch cuts, etc. and trying to add what
| i've learned to the documentation for the code.

One way of getting people involved is to, say, list those projects on
the Axiom web-site as "open projects" or something like that.  
If we must be speaking from experience, that has been productive for
GCC.  One man trying to do everything "in secret" is just not going to
work.  If you have dreams for Axiom (and you do!), please write up and
post it to the Axiom web-site; eventually you'll get contributions from
people.

| for me, axiom opens up whole worlds of interesting work.
| i'm not trying to be a one-man show but i don't see other patches.

yes, but how much of those potential interesting work have you
actively advertised on Axiom website?  I'm not saying that the magic
cure, but it does work for GCC for example.

| i'm amazed that no-one else seems to see the opportunities.
| or if they do then i'm puzzled why they don't exploit them.
| anybody can do anything with axiom. 

Yes, but it takes time for people to contribute.  You should be
patient.  Not intended to to shock you, but do you think Axiom is as
widely known as the M&M?  Were I work it is mostly some mathematicians
curiosity and I do know it is not the only place where I've seen that
sentiment.  We first need to get Axiom better known than just Tim's
dream.  We need to get it to "the mass" -- I hate that word.  No
matter how wonderful Axiom is, you are not going to see much
contribution if it is not made widely available and known.
You already know this, but we should not forget that "software
building" contributes exactly zero when it comes to tenure.  When
people feel like they have to invest lot into Axiom development before
getting the "interesting bits" out they will put it in their task
queues with lower priority.

\start
Date: 04 May 2006 10:35:50 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Axiom trunk failure

Bill Page writes:

[...]

| > now i have to waste time doing a re-install of FC5. I do NOT
| > want this to happen to an axiom user, at least not because they
| > tried to install axiom.
| 
| If you do not trust programs that attempt to automatically
| resolve dependencies then why would you want to build this
| functionality into the Axiom source distribution?

yes, why do you believe the set of options you will use to build your
own versions inside user's environment will ever work or make any sense?
As far as I can, reading through the archive, it has been reported
that to get Axiom build on Ubuntu one needs to pass down special
configure options to GCL.  You have to trust; the only issue is where
to draw the bar.  You have seen lots of objections to have Axiom build
its own ghetto; I believe those objections should be given lot of
considerations.  I do not necessarily promote apt-get and such, but I
do believe that we ought to stop building an Axiom ghetto. 

\start
Date: 04 May 2006 10:42:22 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: noweb

Tim Daly writes:


[...]

| 2) sed and awk are NOT standard parts of a windows distribution.
| again as a matter of policy we need to reduce the requirements
| so we can work across a larger number of systems. ideally all 
| of axiom would run in common lisp and porting becomes a copy
| operation. C is only slightly more problematic. in fact, the
| key reason that axiom does not currently run on the mac is breakage
| caused by C. awk/sed/autoconf all seriously complicate the port issue.

What are the complications posed by autoconf?  

It is a developer tool, not end-user tool.  It has been used
successfully for a wide range of applications on a wide range of
platforms -- where the applications "should just work".

| frankly i'd much rather see the tools devolve into lisp implementations.
| gcl, sbcl and clisp generate native exe files on windows and executables
| on linux. given that lisp is a full programming language and is integral
| to axiom why don't we write code that is trivial to port rather than
| add requirements that are certain to make axiom unportable?

You want to increase the number of contributors and yet insist on
doing everything in Lisp?  I don't think that is going to scale
long-term-wise. 

\start
Date: 04 May 2006 10:53:54 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: noweb

Ralf Hemmecke writes:

| Hi Bill, hello Gaby,
| 
| Look at this...
| 
| http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00262.html

Many thanks.
Obviously, there have been many talks about this noweb thingy.  I just
don't understand why it lingers for so long.

| I would even say: Throw away the noweb sources, throw away this awk
| script and rather go to the Axiom sources and correct a usage of an
| undefined chunk. Why would one want to have undefined chunks in the
| first place?

If people agree that the undefined chunks are bugs, then this whole
noweb stuff is an unfortunate mystifying coverup.

| See also
| 
| http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00247.html
| 
| That is a bug. Ahm, was a bug, because "noweb 2.11 - released 6 April
| 2006" (http://www.eecs.harvard.edu/~nr/noweb/dist/noweb/CHANGES) seems
| to have corrected it. I've not yet time to check 2.11, though.

Do you think you will have a chance to test it soon?

\start
Date: 04 May 2006 11:01:55 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom trunk failure

Gabriel Dos Reis writes:

[...]

| Testing for both versions of GCL are running on x86.

full system build + test completed for GCL-2.6.8pre.
Now launching build for GCL-2.6.7.

\start
Date: Thu, 4 May 2006 08:57:31 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: noweb

On Thursday, May 04, 2006 4:54 AM Gabriel Dos Reis wrote:
>
> Ralf Hemmecke writes:
>
> |
> | Look at this...
> |
http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00262.html
>
> Many thanks.
> Obviously, there have been many talks about this noweb thingy.
> I just don't understand why it lingers for so long.

Only because no one has taken the job of preparing and submitting
a patch to Tim that he will accept. Obviously I could write this
patch or even Tim could write this patch but that would not solve
the real problem that we do not have enough developer resources.
I would much rather spend a lot of time (repeatedly :) explaining
this problem in as much detail as necessary in the hopes that we
will eventually find someone (or even several people!) who are
willing to work on this problem as a way of "getting their feet
wet" (i.e. learning to do some simple axiom development). I think
Gaby's "Silver Branch" is the first time we have had a real
opportunity to correct the problem of not enough axiom developers.

Thank you Gaby!

>
> | I would even say: Throw away the noweb sources, throw away
> | this awk script and rather go to the Axiom sources and correct
> | a usage of an undefined chunk. Why would one want to have
> | undefined chunks in the first place?
>
> If people agree that the undefined chunks are bugs, then this
> whole noweb stuff is an unfortunate mystifying coverup.
>

If you read the above email carefully and actually try both
Tim modified noweb and Norman Ramsey's patch you will see that
this is *not* simply a problem of an undefined chunk. The
problem is a collision of syntax that causes noweb to think
that something is a chunk plus an escape mechanism that does
not allow one to conveniently override this behavior.

In the file '  src/interp/fnewmeta.lisp.pamphlet' the text:

  <<' Name '>>

is not really a reference to a chunk but noweb thinks it is
and the standard (designed in) behavior of noweb when it
finds such an "undefined chunk" is simply to omit it. This
breaks the Axiom code.

Of course would could define this as a chunk using the noweb
escape sequence @<<

  <<' Name '>>=
  @<<' Name '>>
  @ 

and solve this one case where it is really a problem (or even
use the escape sequence inline).

http://tex.loria.fr/litte/ieee.pdf

But this solution seems rather unnatural.

Tim's modification and Norman Ramsey's filter script both
change noweb's standard behavior so that if a chunk is
"undefined" then it simply passes the text of the apparent
reference straight through notangle unmodified.

The point of the filter script is to avoid the need to
include noweb source in the Axiom tree but to accomplish
the same thing as Tim's original patch.

\start
Date: Thu, 4 May 2006 08:53:43 -0400
From: Tim Daly
To: Bill Page
Subject: Re: downloading via BitTorrent

excellent job. 

i saw the launchmany and finally figured out that it was a bittorrent tool. 

\start
Date: Thu, 4 May 2006 06:20:13 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Check for item in PATH in Emacs?

Cool!  Thanks Bill.  I actually hacked up my own version yesterday
which might be a little simpler for our purposes, but I've yet to test
it on Windows.  I'll upload it to the wiki this morning - I THINK this
version should work without trouble on Windows or Linux, but I'll feel
better if it is confirmed ;-).

--- Bill Page wrote:

> On Tuesday, May 02, 2006 11:13 PM C Y wrote:
> > 
> > Does anybody know of a way to check for, say, "axiom" in the
> > PATH on a particular system from Emacs?  Trying to run something
> > via comint seems to result in an error which stops everything.
> > I'm trying to first run "axiom" if it's available (it turns out
> > graphics do work when run from the Emacs buffer) and if it isn't
> > available fall back to "AXIOMsys".  I know I could do some hackery
> > with running "which axiom" on Linux but I'm hoping for something
> > more straightforward and portable.
> > 
> I'm no emacs hacker, but it looks like some code in emacs esh-ext
> might do what you want. See:
> 
>
http://www.cgl.uwaterloo.ca/~mmwasile/data/elisp/eshell-2.4.2/esh-ext.el
> 
> ...
> (defun eshell-search-path (name)
>   "Search the environment path for NAME."
>   (if (file-name-absolute-p name)
>       name
>     (let ((list (parse-colon-path (getenv "PATH")))
> 	  suffixes n1 n2 file)
>       (while list
> 	(setq n1 (concat (car list) name))
> 	(setq suffixes eshell-binary-suffixes)
> 	(while suffixes
> 	  (setq n2 (concat n1 (car suffixes)))
> 	  (if (and (or (file-executable-p n2)
> 		       (and eshell-force-execution
> 			    (file-readable-p n2)))
> 		   (not (file-directory-p n2)))
> 	      (setq file n2 suffixes nil list nil))
> 	  (setq suffixes (cdr suffixes)))
> 	(setq list (cdr list)))
>       file)))
> ...

\start
Date: Thu, 4 May 2006 06:49:00 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Tim Daly
Subject: re: Axiom trunk failure

--- Bill Page wrote:

> I think the developers of apt-get and yum might agree with
> you. ;) But I think most developers would prefer to take care
> of this themselves.
> 
> People who want to work with Axiom without these hassles
> should install the appropriate binary version.

I think autoconf will allow us to "have our cake and eat it too", so to
speak.  Maxima benefited tremendously from having a real
configure-make-install ability and I expect Axiom will be no different.
 Autoconf and friends are very, very useful in my experience - we are
able to automatically build a single Maxima install on three or more
different lisp implementations, and provide the user with a runtime
choice on which one they want to use :-).  So if they want the
friendlyness of Clisp or the speed of cmucl, they can make that choice
on a per-session basis.  I know this is impractical and maybe less
interesting for Axiom, but it is a useful illustration of what can be
done with autoconf.  I expect using either system libraries or falling
back to building included ones will be well within its abilities.  IIRC
BRL-CAD has some similar options, although I don't know that they
implement "try system libs first and then automatically fall back to
internal ones if failure" logic.

\start
Date: Thu, 4 May 2006 07:21:07 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Bill Page
Subject: re: noweb

--- Tim Daly wrote:

> i'd much rather reduce the number of languages need to understand
> axiom rather than enlarge the number. some are necessary (like
> lisp, spad, aldor) but some are optional (e.g. java in the aldor
> merge) and more properly should be done using existing tools.

I agree.
 
> there are many feasible solutions to a problem. and there are
> many "convenient" solutions in many different languages. but 
> solutions which expand the needed skill set for maintainers are
> much less desireable than ones which do not.
> 
> as a policy i favor minimizing the number of languages used.
> adding sed (1 language), awk (a second), clever bash shell
> scripts (a third), java (a fourth), auto* (a fifth), simply
> reduces the number of people who can reliably maintain the system
> and increases the work required to port, possibly to the point
> of being impossible.

In particular, we will be hoping for not programmers in the normal
sense but mathematical researchers doing programming :-).

The one exception I might be willing to grant from that list is the
auto* system, because it encodes a lot of operating-environment
specific logic that "regular" languages don't, and that information is
something Axiom might need.  Axiom's lisp parts can be handled (and
should be handled, IMO) using ASDF.  However, outside of Lisp (like,
say, the case of wanting to select GCL or CMUCL to build with, or
building non-lisp libraries we can't rewrite into lisp like (as an
example) cernlib to be interfaced via FFI) autoconf and friends are
very nearly the universal solution.  I think a literate document
version of autoconf scripts will be both a viable solution and a good
one.

In the very, VERY long term I would like to see all significant
mathematical capabilities implemented as part of the Axiom system using
Lisp or Aldor, but the amount of work out there is HUGE, the work
required to code and document it up to Axiom's standards is even MORE
huge, and I expect we will never catch up with all the new work coming
out.

> 2) sed and awk are NOT standard parts of a windows distribution.
> again as a matter of policy we need to reduce the requirements
> so we can work across a larger number of systems. ideally all 
> of axiom would run in common lisp and porting becomes a copy
> operation. C is only slightly more problematic. in fact, the
> key reason that axiom does not currently run on the mac is breakage
> caused by C. awk/sed/autoconf all seriously complicate the port
> issue.

I agree with this.  Lisp is not perfect in this regard but it is
reasonably close and becoming more so with time.
 
> frankly i'd much rather see the tools devolve into lisp
> implementations. gcl, sbcl and clisp generate native exe files on
> windows and executables on linux. given that lisp is a full 
> programming language and is integral to axiom why don't we write
> code that is trivial to port rather than
> add requirements that are certain to make axiom unportable?

I agree in general with this.    
 
> as a policy i favor doing things in lisp unless it can be shown
> that such a solution is impossible. in the future i'd make the
> same claim about using aldor (assuming we free aldor).

I agree.  In fact, if CFFI becomes mature enough we might be able to
get away with using things like the QT graphics libraries while keeping
all of our code in Lisp.  What's your take on Lisp FFIs Tim?  Do they
constitute a non-lisp dependency?  I suppose in once sense they most
certainly do but at some level, the Windows GDI libraries if nothing
else, we will have to interface with non-lisp functionality.  If the
system changes under us we will have to follow it.  Even Garnet and
McCLIM rely on CLX and (in Garnet's case) GDI, and to integrate
smoothly with user environments higher level backends will be needed
(There is working going on on a McCLIM GTK backend now).  

> 3) in fact i'm making every attempt to explain the lisp programs
> as you'll see in the eventual bookvol5.pamphlet file. it is
> NOT necessary to explain the language idioms but it IS necessary
> to explain what is happening in a block of code.

Looking forward to that book!

> the noweb script will be sitting in a standalone pamphlet in
> src/scripts. it will not appear as an integral part of anything to
> a future maintainer.
> so the future maintainer can reasonably expect to have a (possibly 
> redundant) explanation of why this script exists, what it does, what
> data it expect to work on, etc. this is NOT the same as explaining
> the awk language constructs.

If we are going to need to redo noweb in Lisp in order to be able to
scale properly to large documents, maybe we can regard both the script
and noweb itself as a temporary solution? 
 
> i would argue that literate programming is a fundamental change in
> mindset that requires you to explain to some future maintainer how
> and why any new code works. he should be able to read the paragraph
> and know where this code fits as well as what it is trying to
> accomplish.

I'm trying to do that as much as I'm able in the Emacs interface.  By
the way Tim, is Elisp OK or does that count as another language?  For
something like this we have to work in the language of the program -
should we just accept that if someone wants to edit this code they
would be reasonably expected to be familiar with the workings of that
program, or at least enough so that they could figure out well
commented literate code?

\start
Date: Thu, 4 May 2006 07:26:34 -0700
From: Bob McElrath
To: Bill Page
Subject: Spam

By the way, I just discovered the zwiki property max_anonymous_links
which may help with some of the spam on mathaction.  I see though that
mathaction is running zwiki 0.36.  It looks like this feature was added
in 0.41.

\start
Date: 04 May 2006 16:47:24 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: re: noweb / Lisp Skills

Cliff Yapp writes:

> --- Tim Daly wrote:
> 
> > i'd much rather reduce the number of languages need to understand axiom
> > rather than enlarge the number. some are necessary (like lisp, spad, aldor)
> > but some are optional (e.g. java in the aldor merge) and more properly
> > should be done using existing tools.
> 
> I agree.

I disagree slightly. I'd say that we should try to regard some things as black
boxes. For example, emacs is such a black box, so is noweb and so on. Of
course, we have to be careful which black boxes we choose.

Thus, (were a take sed, awk, java, auto* etc. as tools which may or may not be
the black boxes I would choose)

> > adding sed (1 language), awk (a second), clever bash shell scripts (a
> > third), java (a fourth), auto* (a fifth), simply reduces the number of
> > people who can reliably maintain the system

is probably not true. On the contrary, choosing the right black boxes might in
fact *increase* the number of people able to contribute in a sensible way to
axiom.

Tim, I think your lisp skills would really be needed to get the axiom
interpreter into good shape and make it understand dependendend types, for
example. We would really need this now, for the axiom-combinat project. If it
doesn't happen any time soon, we might have an aldor-combinat project which is
only very partially functional in Axiom.

I just don't have the required skills. My skills are in combinatorics, not in
writing interpreters and compilers. I don't really want to understand the
interpreter -- at least not right now -- I just want to be able to use it.

And I'm absolutely certain that I don't want to understand how noweb works. No
matter whether it is coded in Lisp, Aldor or C.


Things to do on the interpreter side needed for the axiom-combinat project:

* make it understand Aldor:

  * dependent types
  * extend
  * creating domains on the command line

* separate the mathematical knowledge about the domains from the interpreter,
  possibly incorporate ideas of Nic Doye

\start
Date: Thu, 4 May 2006 10:49:08 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: Spam

Bob,

On Thursday, May 04, 2006 10:27 AM you wrote:
>
> By the way, I just discovered the zwiki property
> max_anonymous_links which may help with some of the
> spam on mathaction.  I see though that mathaction is
> running zwiki 0.36.  It looks like this feature
> was added in 0.41.
>

Yah, that is a bit of a problem. I haven't had time to devote
to bringing mathaction up to the newer versions of zwiki or
even the newer version of your latexwiki code. I have done some
experiments over the last year with the newer versions but
I have not had the time to properly plan the migration of the
content and the wikipage.pt (and related) customizations that
we use on mathaction.  ... This is another "axiom" project
that seems to have become larger than a one person project. :)

Suggestions about how to proceed on this so that we can take
advantage of all of the new work that Simon has been doing to
help prevent and reverse would be much appreciated.

I am however already making extensive use of the 'banned_links'
property by continuing to update the example that you provided
so that at least usually the spammer doesn't get a 2nd chance
to offend anyone.

\start
Date: 04 May 2006 16:48:07 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: noweb

Bill Page writes:

| On Thursday, May 04, 2006 4:54 AM Gabriel Dos Reis wrote:
| > 
| > Ralf Hemmecke writes:
| > 
| > | 
| > | Look at this...
| > | 
| http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00262.html
| > 
| > Many thanks.
| > Obviously, there have been many talks about this noweb thingy.
| > I just don't understand why it lingers for so long.
| 
| Only because no one has taken the job of preparing and submitting
| a patch to Tim that he will accept. Obviously I could write this
| patch or even Tim could write this patch but that would not solve
| the real problem that we do not have enough developer resources.
| I would much rather spend a lot of time (repeatedly :) explaining
| this problem in as much detail as necessary in the hopes that we
| will eventually find someone (or even several people!) who are
| willing to work on this problem as a way of "getting their feet
| wet" (i.e. learning to do some simple axiom development).


I do hope we are close to a point where this will not pop up again :-)

[...]

| > | I would even say: Throw away the noweb sources, throw away
| > | this awk script and rather go to the Axiom sources and correct
| > | a usage of an undefined chunk. Why would one want to have
| > | undefined chunks in the first place?
| > 
| > If people agree that the undefined chunks are bugs, then this
| > whole noweb stuff is an unfortunate mystifying coverup.
| > 
| 
| If you read the above email carefully and actually try both
| Tim modified noweb and Norman Ramsey's patch you will see that
| this is *not* simply a problem of an undefined chunk. The
| problem is a collision of syntax that causes noweb to think
| that something is a chunk plus an escape mechanism that does
| not allow one to conveniently override this behavior.

I read the message saw other problems that people mentioned.  I
(mis)interpreted Ralf's statement as saying that it was a bug in noweb
-- that is now corrected.

| In the file '  src/interp/fnewmeta.lisp.pamphlet' the text:
| 
|   <<' Name '>>
| 
| is not really a reference to a chunk but noweb thinks it is
| and the standard (designed in) behavior of noweb when it
| finds such an "undefined chunk" is simply to omit it. This
| breaks the Axiom code.
| 
| Of course would could define this as a chunk using the noweb
| escape sequence @<<
| 
|   <<' Name '>>=
|   @<<' Name '>>
|   @  
| 
| and solve this one case where it is really a problem (or even
| use the escape sequence inline).

Thanks for re-detailing the issue.

At this point, here is my planning:

  (1) I'll finish my initial shot at the Autoconf styff; check it in
      the branch "build-improvements" so that I can have feedback.
      That work currently build noweb only if it is not system-installed.

  (2) Resolve the noweb issue: preferably include the newest version
      if it really corrects the bug; otherwise use your axiom-noweb
      script. 

  (3) Make a complete proposal for the silver branch.  I hope by that
      time we will resolve Tim's concerns.

Now, I have to do daytime job :-)

\start
Date: 04 May 2006 17:05:11 +0200
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: noweb / Lisp Skills

Martin Rubey writes:

[...]

| And I'm absolutely certain that I don't want to understand how noweb works. No
| matter whether it is coded in Lisp, Aldor or C.

Hear! Hear! Hear!

Martin has a very good summary.  Many reserachers and potential
contributors out there are not interested in learning Lisp just to be
able to use Axiom, which already requires its own language.  That make
the number of people capable to maintaining and evoling the
interperter already very small.

Lisp has been out for over half a century.  It did not take over the
world.  I don't know why; but that is food for thought.

| Things to do on the interpreter side needed for the axiom-combinat project:
| 
| * make it understand Aldor:
| 
|   * dependent types

Does not Axiom already user dependent type?  Do you have something
specific in mind?

|   * extend
|   * creating domains on the command line
| 
| * separate the mathematical knowledge about the domains from the interpreter,
|   possibly incorporate ideas of Nic Doye

Have a look at work done on dependent types.  There was a nice talk
this year at POPL (Charleston, SC).

      http://www.e-pig.org/


No, I'm not proposing to write Axiom in Haskell.  But, I'm suggesting
we don't ignore the work done in the programming language community. 

\start
Date: Thu, 4 May 2006 11:24:34 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: noweb

Gaby,

On Thursday, May 04, 2006 10:48 AM you wrote:
> ...
> I read the message saw other problems that people mentioned.  I
> (mis)interpreted Ralf's statement as saying that it was a bug
> in noweb -- that is now corrected.
>

There was a bug in noweb that was corrected in a recent version
but that bug has nothing to do with Tim's patch for the undefined
chunk issue and does not affect current Axiom code in any way.
(I believe that it did affect something that Ralf was doing with
his documentation system for Aldor.)

> ...

\start
Date: Thu, 04 May 2006 17:27:31 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis,
Subject: re: noweb

On 05/04/2006 10:53 AM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> | Hi Bill, hello Gaby,
> | 
> | Look at this...
> | 
> | http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00262.html
> 
> Many thanks.
> Obviously, there have been many talks about this noweb thingy.  I just
> don't understand why it lingers for so long.
> 
> | I would even say: Throw away the noweb sources, throw away this awk
> | script and rather go to the Axiom sources and correct a usage of an
> | undefined chunk. Why would one want to have undefined chunks in the
> | first place?
> 
> If people agree that the undefined chunks are bugs, then this whole
> noweb stuff is an unfortunate mystifying coverup.
> 
> | See also
> | 
> | http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00247.html
> | 
> | That is a bug. Ahm, was a bug, because "noweb 2.11 - released 6 April
> | 2006" (http://www.eecs.harvard.edu/~nr/noweb/dist/noweb/CHANGES) seems
> | to have corrected it. I've not yet time to check 2.11, though.
> 
> Do you think you will have a chance to test it soon?
> 
> -- Gaby

Below you find the example of the code that I sent to Norman Ramsey.
I've just downloaded noweb 2.11 and compiled it. No problem with the 
code below anymore. BUT... see next mail.

Ralf

-----------------------------------------------------------------------
--Mail from Wed, 24 Aug 2005 14:02:55 +0200
--To:  Norman Ramsey

Is it by design that

/usr/lib/noweb/markup test.nw > out.markup
gives

echo $?
2

and as output

test.nw:3: unescaped << in documentation chunk
test.nw:5: Module name doesn't end
test.nw:5: unescaped << in documentation chunk
test.nw:6: Module name doesn't end
test.nw:6: unescaped << in documentation chunk

for the little file test.nw

%%%%% test.nw %%%%%
A test file.

<<*>>=
-- Here comes some code
<<: A -> B
<<: (A, B) -> X
@
and we go on with the text.

%%%%%% end test.nw %%%%

\start
Date: 04 May 2006 17:39:00 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: re: noweb / Lisp Skills

Gabriel Dos Reis writes:

> Martin has a very good summary.  Many reserachers and potential
> contributors out there are not interested in learning Lisp just to be
> able to use Axiom, which already requires its own language.  That make
> the number of people capable to maintaining and evoling the
> interperter already very small.

Well, in fact I believe that the sets of people doing maths with Axiom and
people hacking the compiler or interpreter will be nearly disjoint.

> Lisp has been out for over half a century.  It did not take over the
> world.  I don't know why; but that is food for thought.

I think that lisp is a wonderful language and I think that it *might* be worth
the effort to reimplement Aldor in Lisp. But the reason for this is entirely
different from reimplementing a comparatively simple tool like noweb. Having an
Aldor interpreter in Lisp would be certainly a very sensible thing.
 
> | Things to do on the interpreter side needed for the axiom-combinat project:
> | 
> | * make it understand Aldor:
> | 
> |   * dependent types
> 
> Does not Axiom already user dependent type?  Do you have something
> specific in mind?

not completely:

f: (n: Integer) -> PrimeField n

is OK for Aldor, but not for SPAD. This is the reason for series returning the
ANY Type, for example.

\start
Date: Thu, 4 May 2006 08:36:13 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Bill Page
Subject: re: Axiom trunk failure

--- Tim Daly wrote:

> participation is great and i've accepted almost every patch
> sent to me. i'm hoping to see a drastic increase in the
> number of tested patches. 

Tim, how is something like the Emacs mode handled?  It's not properly a
patch and it's far from done, but just so I know what I'm supposed to
do with it.  Would something like that, once feature complete, be a
"third party" tool or part of Axiom proper?
 
> i'm applying personal standards here but i do not believe
> we should release anything that isn't the very best we can do.
> and it should be simple to install, work properly, be fully
> documented, well tested, and proven as correct as we can.
> this is computational mathematics, not word processing.

Agree 100%.  Which reminds me, I need to get back to the proof engine
reading...
 
> being open source axiom can be changed in any way by anyone.
> so far i haven't seen much in the way of patches posted to
> the list. 

Tim, the procedure for patches is well documented now, but what about
entire new pamphlets?  Same basic idea, submit to the list for
inclusion?  Do we need some kind of mathematical peer review if it's a
totally new area for Axiom? Or do we want to postpone adding any new
ones until what's already there is properly tuned up?

> it's quite possible for you to make a major system change
> by integrating the windows changes back into the main stream.
> you could get it building cross-platform and post patches.

Quick check - is there anybody now doing active development on Axiom
for Windows?  I'm sure we have users there but anybody who knows how to
compile it?

> we should be able to just type 'AXIOM=.../windows' ; make
> and get a working windows version. once that works we can
> try to get the browser/graphics/sman working. but right now,
> even for me, the windows version feels a bit like a black box.

Heh - Maxima still feels that way to me on Windows, after several
significant releases.  A literate document on creating a Windows
install.exe file would be a boon to lots of free software projects, I
think.  Of course, we are introducing the scripting language for the
Nullsoft installer and maybe one or two other special cases, but I have
a feeling it will be a very long time before we can avoid the need for
such tools and use a lisp based install.exe.

> i have a semi-working browser but can't integrate it into the
> main line until the rest of the windows changes get merged.

Cool!

> i've joined axiom to the numerical mathematics consortium
> (http://www.nmconsortium.org/FldRte/?id=72&page=Associate+Members)
> because i have an interest in recovering the numerical library
> facility for axiom. i have rewritten the BLAS library into literate
> form and have gotten permission from a BLAS person to use his
> research work as documentation for the routines.

WOW!  Exciting news!

> i'm in the process of documenting the BLAS code now. when it
> completes i'll release a numeric library for axiom that is literate
> BLAS. then i'll move on to the next numerical piece. along the way
> i'm learning about sensitivity analysis, methods of graphing branch
> cuts, etc. and trying to add what i've learned to the documentation
> for the code.

Out of curosity, is a lisp version of BLAS possible or are the
performance tuning requirements too severe?  I know numerical code has
to pay very careful attention to stuff like that.
 
> for me, axiom opens up whole worlds of interesting work.
> i'm not trying to be a one-man show but i don't see other patches.
> i'm amazed that no-one else seems to see the opportunities.
> or if they do then i'm puzzled why they don't exploit them.

Time constraints are the big problem.  Also, I have to learn to walk
before I can run :-/.

> anybody can do anything with axiom. 

:-).  Do yes, but not (yet) do quickly.  At least not me.

> my only regret is that my full time job is not axiom.

I'll second that regret - you've accomplished an amazing amount of work
already Tim.  You full time on Axiom would be awesome.

\start
Date: Thu, 04 May 2006 17:43:57 +0200
From: Ralf Hemmecke
To: Norman Ramsey
Subject: Bug in noweb-2.11

Dear Norman,

I think, I've found another bug in noweb.

According to the documentation of NOWEB, it is OK if << appears 
unescaped on a line if there is no corresponding >> on the same line.

With the following code

%%%%% test.nw %%%%%
stdout << "blah";

<<*>>=
-- Here comes some code
<<: A -> B
<<: (A, B) -> X
@
and we go on with the text.
%%%%%% end test.nw %%%%

I get the strange behaviour.

notangle test.nw
test.nw:2: unescaped << in documentation chunk
echo $?
1

Hmm, notangle does not spit out any code chunk. :-(
I am also not sure about the error code.

'man notangle' says

   ERROR MESSAGES
        If notangle or noweave encounters a chunk name within
        documentation, it assumes that this indicates an error,
        usually misspelling ``<<name>>=''. Other error messages
        should be self-explanatory.

        It is incorrect to refer to a chunk that is never defined,
        but it is OK for chunks to be defined and not used.

It does not say anything about the meaning of errcode=1 or errcode=2.

'noweave test.nw' seems to be OK, but also returns errcode=1.

\start
Date: Thu, 4 May 2006 11:46:07 -0400
From: Bill Page
To: Martin Rubey
Subject: re: noweb / Lisp Skills

On Thursday, May 04, 2006 10:47 AM Martin Rubey wrote:
> ...
> Things to do on the interpreter side needed for the
> axiom-combinat project:
>
> * make it understand Aldor:
>
>   * dependent types
>   * extend
>   * creating domains on the command line
>

Is what you are suggesting the same thing as making library
programming possible at the level of the interpreter? If
so, they I supose that you realize that this is already an
issue at the level of SPAD and is not really an Aldor
specific problem. It seems to me that the differences
between the interpreter and library compiler environments
were largely built-in as part of the original design of
Axiom. I think the designers decided that the interpreter
*should* behave differently than the compiler and that
some of the things the compiler does should specifically
not be available to the interactive user.

It is certainly possible right now to use dependent types
and the Aldor 'extend' functionality in Axiom right now
so long as you remain within the Aldor library code. The
problem is that neither of these can currently be "exposed"
the the interactive user through the Axiom interpreter.
I think however that these two cases a rather different.
I think it should be possible to implement dependent types
in the interpreter and the fact that it doesn't currently
work is apparently already considers a bug by Peter Broadbery.
But the the 'extend' functionality is another issue because
that whould require providing the equivalent of the library
compiler at the interpreter level.

Aldor has the ability to run a "read-eval-print-loop" (the
-gloop option) which provides a limited kind of direct
interaction with the compiler. This is not possible with
SPAd and it is not currently possible to access Aldor in
this way through the Axiom interpreter - but maybe it should
be possible?

> * separate the mathematical knowledge about the domains
>   from the interpreter, possibly incorporate ideas of
>   Nic Doye
>

I think this is good idea but perhaps best accomplished
by re-implementing the Axiom interpreter as something
linke B# rather than retro-fitting the existing code.

\start
Date: 04 May 2006 17:42:53 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: noweb

Bill Page writes:

| Gaby, 
| 
| On Thursday, May 04, 2006 10:48 AM you wrote:
| > ... 
| > I read the message saw other problems that people mentioned.  I
| > (mis)interpreted Ralf's statement as saying that it was a bug
| > in noweb -- that is now corrected.
| >
| 
| There was a bug in noweb that was corrected in a recent version
| but that bug has nothing to do with Tim's patch for the undefined
| chunk issue and does not affect current Axiom code in any way.
| (I believe that it did affect something that Ralf was doing with
| his documentation system for Aldor.)

Now, that gets it straight in my head.  Thanks!

\start
Date: 04 May 2006 17:52:46 +0200
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: noweb / Lisp Skills

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > Martin has a very good summary.  Many reserachers and potential
| > contributors out there are not interested in learning Lisp just to be
| > able to use Axiom, which already requires its own language.  That make
| > the number of people capable to maintaining and evoling the
| > interperter already very small.
| 
| Well, in fact I believe that the sets of people doing maths with Axiom and
| people hacking the compiler or interpreter will be nearly disjoint.

:-)

[...]

| > | * make it understand Aldor:
| > | 
| > |   * dependent types
| > 
| > Does not Axiom already user dependent type?  Do you have something
| > specific in mind?
| 
| not completely:
| 
| f: (n: Integer) -> PrimeField n
| 
| is OK for Aldor, but not for SPAD. This is the reason for series returning the
| ANY Type, for example.

Ah, okey.  Good point!  Many thanks.

\start
Date: Thu, 04 May 2006 17:57:23 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: noweb

> In the file '  src/interp/fnewmeta.lisp.pamphlet' the text:
> 
>   <<' Name '>>
> 
> is not really a reference to a chunk but noweb thinks it is
> and the standard (designed in) behavior of noweb when it
> finds such an "undefined chunk" is simply to omit it. This
> breaks the Axiom code.

Maybe that is a bug, too. In such a case I would rather like to see at 
least a warning that the code chunk is undefined.

> Of course would could define this as a chunk using the noweb
> escape sequence @<<
> 
>   <<' Name '>>=
>   @<<' Name '>>
>   @  
> 
> and solve this one case where it is really a problem (or even
> use the escape sequence inline).
> 
> http://tex.loria.fr/litte/ieee.pdf
> 
> But this solution seems rather unnatural.

I agree that the escaping is rather unnatural, but just escape this ONE 
line in the thousands of lines form AXIOM and the noweb problem is gone.

We could be careful when writing new code/documentation and escape those 
problematic cases. There are not so many after all.

\start
Date: Thu, 04 May 2006 18:00:51 +0200
From: Ralf Hemmecke
To: list
Subject: NOWEB

Tim, you complained about the speed of NOWEB...

Here a copy from noweb-2.11/src/INSTALL...

To build noweb:

   1) First point to compilers to be used to built the tools and
      library by setting these variables in the Makefile:
        CC         the name of an ANSI C compiler
        LIBSRC	  'awk' or 'icon', depending on which library
      If you have Icon, use the Icon version of the noweb library; this
      code speeds up noweave by a factor of 3.  The Icon versions have
      fewer bugs and provide more filters (e.g., convert LaTeX to HTML
      in documentation chunks).  Not all of the examples will work with
      the awk library.  If you have an Icon compiler and believe it
      works, set `ICONC=iconc -f l' in the Makefile.  (Icon is freely
      available from the University of Arizona, but the compiler is no
      longer maintained.)

I have compiled noweb like this...

cd noweb-2.11/src

export N=$HOME/software/noweb

make LIBSRC=icon BIN=$N LIB=$N/lib MAN=$N/man TEXINPUTS=$N/tex 
ELISP=$N/elisp

make LIBSRC=icon BIN=$N LIB=$N/lib MAN=$N/man TEXINPUTS=$N/tex 
ELISP=$N/elisp install

Do you use icon instead of awk???

\start
Date: Thu, 04 May 2006 18:19:24 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: re: Axiom trunk failure

Hi,

Le jeudi 04 mai 2006 =E0 10:29 +0200, Gabriel Dos Reis a =E9crit :

[...]

> we should just be able to type "./configure; make make install"
> and have it working.  Expect that soon for Unix-like systems!
> (And I hope it will work for Cygwin-based systems too.)

GCL does not compile on Cygwin. Some portions of GCL are related to
Cygwin but they are not maintained anymore as far as I know. GCL on
Windows uses the MinGW/MSYS environment (so it's not possible to build X
based applications such that graphics and hyperdoc).

\start
Date: Thu, 4 May 2006 12:33:43 -0400
From: Bill Page
To: Cliff Yapp
Subject: re: Axiom trunk failure

On Thursday, May 04, 2006 11:36 AM C Y wrote:
> ...
> Quick check - is there anybody now doing active development
> on Axiom for Windows? I'm sure we have users there but anybody
> who knows how to compile it?

The procedure for compiling Axiom on Windows is here:

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

As far as I know no one is current actively making changes to
the axiom--windows--1 source distribution. The only people I
know for sure who have compiled Axiom for Windows from source
is me and Mike Thomas (the gcl developer who first fully solved
the problem of building Axiom on Windows).

>
> > we should be able to just type 'AXIOM=.../windows' ; make
> > and get a working windows version. once that works we can
> > try to get the browser/graphics/sman working. but right now,
> > even for me, the windows version feels a bit like a black box.
>

A tla "diff" of the axiom--main--1 (about patch-30 or so I think)
and axiom--windows--1 versions will show the changes that were made
to the Axiom sources but unfortunately none of these where ever
fully documented.

At this point I think our best option for updating the Windows
build will be to wait for Gaby to complete the integration of
the Debian patches into the Silver archive and then create a
new branch specifically for Windows. It will considerably
simplify the Windows build if we can use the Debian build
strategy.

> Heh - Maxima still feels that way to me on Windows, after several
> significant releases.  A literate document on creating a Windows
> install.exe file would be a boon to lots of free software projects,
> I think.  Of course, we are introducing the scripting language for
> the Nullsoft installer and maybe one or two other special cases,
> but I have a feeling it will be a very long time before we can
> avoid the need for such tools and use a lisp based install.exe.

The Nullsoft installer script was contributed by Dan Martens, the
TeXmacs for Windows developer.

Unfortunately there is no literate document nor even any information
on the Axiom Wiki about how to create the NullSoft windows install
file. The best I can offer is everything I think is relevant in the
axiom-developer email list archive, e.g.

http://lists.nongnu.org/archive/html/axiom-developer/2005-02/msg00164.ht
ml
http://lists.nongnu.org/archive/html/axiom-developer/2005-01/msg00518.ht
ml
http://lists.nongnu.org/archive/html/axiom-developer/2004-12/msg00233.ht
ml
http://lists.nongnu.org/archive/html/axiom-developer/2004-12/msg00107.ht
ml
http://lists.nongnu.org/archive/html/axiom-developer/2004-12/msg00084.ht
ml
http://lists.nongnu.org/archive/html/axiom-developer/2004-06/msg00068.ht
ml
http://lists.nongnu.org/archive/html/axiom-developer/2003-10/msg00227.ht
ml

But given the axiom.nsi file that is included in the Windows binary
distribution, the procedure to produce the NullSoft install.exe file
is actually very simple. I would be glad to help anyone who wants to
attempt this ... and this time maybe we can jointly write some useful
documentation! :)

\start
Date: Thu, 4 May 2006 12:43:47 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: NOWEB

On Thursday, May 04, 2006 12:01 PM Ralf Hemmecke wrote:
>
> Tim, you complained about the speed of NOWEB...
>
> Here a copy from noweb-2.11/src/INSTALL...
>
> To build noweb:
>
>    1) First point to compilers to be used to built the tools and
>       library by setting these variables in the Makefile:
>         CC         the name of an ANSI C compiler
>         LIBSRC	  'awk' or 'icon', depending on which library
>       If you have Icon, use the Icon version of the noweb
>       library; this code speeds up noweave by a factor of 3.
>       The Icon versions have fewer bugs and provide more filters
>       (e.g., convert LaTeX to HTML in documentation chunks).
>       Not all of the examples will work with the awk library.
>       If you have an Icon compiler and believe it works, set
>      `ICONC=iconc -f l' in the Makefile.  (Icon is freely
>       available from the University of Arizona, but the compiler
>       is no longer maintained.)
>

I have installed Icon on the axiom-developer.org server and it
seems like a nice neat little language ... but I am sure Tim
will say: "Oh horrors, yet another programming language!" :)

>
> I have compiled noweb like this...
>
> cd noweb-2.11/src
>
> export N=$HOME/software/noweb
>
> make LIBSRC=icon BIN=$N LIB=$N/lib MAN=$N/man =
TEXINPUTS=$N/tex
> ELISP=$N/elisp
>
> make LIBSRC=icon BIN=$N LIB=$N/lib MAN=$N/man =
TEXINPUTS=$N/tex
> ELISP=$N/elisp install
>
> Do you use icon instead of awk???
>

I have also build noweb this way (partly because I was at one
time very interested in the filter to convert from LaTeX to
HTML) and I agree that the version of noweb that uses the
icon library is much faster. I also hacked a while on the
LaTeX to HTML code written in Icon, but eventually I abandoned
that approach in favour of the current pamphlet file support
on MathAction that does not involve conversion of LaTeX to
HTML.

\start
Date: Thu, 04 May 2006 18:46:38 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: re: Axiom trunk failure

Le jeudi 04 mai 2006 =E0 18:19 +0200, Vanuxem Gr=E9gory a =E9crit :
> Hi,
>
> Le jeudi 04 mai 2006 =E0 10:29 +0200, Gabriel Dos Reis a =E9crit :
>
> [...]
>
> > we should just be able to type "./configure; make make install"
> > and have it working.  Expect that soon for Unix-like systems!
> > (And I hope it will work for Cygwin-based systems too.)
>
> GCL does not compile on Cygwin. Some portions of GCL are related to
> Cygwin but they are not maintained anymore as far as I know. GCL on
> Windows uses the MinGW/MSYS environment (so it's not possible to build =
X
> based applications such that graphics and hyperdoc).

Hum I forgot something.

But, as Tim said earlier, hyperdoc and probably graphics could be ported
to Cygwin.

\start
Date: Thu, 4 May 2006 13:06:26 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: re: Axiom trunk failure

On Thursday, May 04, 2006 12:47 PM Vanuxem Gr=E9gory wrote:
> >
> > GCL does not compile on Cygwin. Some portions of GCL are related
> > to Cygwin but they are not maintained anymore as far as I know.
> > GCL on Windows uses the MinGW/MSYS environment (so it's not
> > possible to build X based applications such that graphics and
> > hyperdoc).
>
> Hum I forgot something.
>
> But, as Tim said earlier, hyperdoc and probably graphics
> could be ported to Cygwin.
>

Tim has already successfully (more or less) compiled hyperdoc
using Cygwin. See this thread:

http://lists.nongnu.org/archive/html/axiom-developer/2005-12/msg00439.htm=
l
http://lists.nongnu.org/archive/html/axiom-developer/2005-12/msg00438.htm=
l
http://lists.nongnu.org/archive/html/axiom-developer/2005-12/msg00428.htm=
l

Although the hyperdoc program was compiled under Cygwin, the
X server part does run as a stand alone windows app called
Xming see:

http://sourceforge.net/projects/xming
http://wiki.freedesktop.org/wiki/Xming

So I don't think Cygwin is actually required for this. Axiom
graphics is a more complex program than hyperdoc but it should
also be possible to run it "native" on Windows this way.

There is obviously a very great demand by Axiom on Windows users
for these missing Axiom features. Anything we could do to solve
this problem would benefit a look of new Axiom users.

\start
Date: 04 May 2006 20:16:40 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: NOWEB

Bill Page writes:

| On Thursday, May 04, 2006 12:01 PM Ralf Hemmecke wrote:
| > 
| > Tim, you complained about the speed of NOWEB...
| > 
| > Here a copy from noweb-2.11/src/INSTALL...
| > 
| > To build noweb:
| > 
| >    1) First point to compilers to be used to built the tools and
| >       library by setting these variables in the Makefile:
| >         CC         the name of an ANSI C compiler
| >         LIBSRC	  'awk' or 'icon', depending on which library
| >       If you have Icon, use the Icon version of the noweb 
| >       library; this code speeds up noweave by a factor of 3.
| >       The Icon versions have fewer bugs and provide more filters
| >       (e.g., convert LaTeX to HTML in documentation chunks).
| >       Not all of the examples will work with the awk library.
| >       If you have an Icon compiler and believe it works, set
| >      `ICONC=iconc -f l' in the Makefile.  (Icon is freely
| >       available from the University of Arizona, but the compiler
| >       is no longer maintained.)
| >
| 
| I have installed Icon on the axiom-developer.org server and it
| seems like a nice neat little language ... but I am sure Tim
| will say: "Oh horrors, yet another programming language!" :)

And I will second him!

[Note: I have written small programs in Icon, and enjoyed 
"Graphics Programming in Icon" which you can get almost for free if
you in academia.]

\start
Date: Thu, 04 May 2006 20:50:47 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: re: Axiom trunk failure

hi Bill,

Le jeudi 04 mai 2006 =E0 13:06 -0400, Page, Bill a =E9crit :

[...]

> Tim has already successfully (more or less) compiled hyperdoc
> using Cygwin. See this thread:
>
> http://lists.nongnu.org/archive/html/axiom-developer/2005-12/msg00439.h=
tml
> http://lists.nongnu.org/archive/html/axiom-developer/2005-12/msg00438.h=
tml
> http://lists.nongnu.org/archive/html/axiom-developer/2005-12/msg00428.h=
tml

Thanks,

Humm it seems to me that all the axiom-developer's mailing list archives
are in your mind  :-) (It's not the first time that you refer to these
archives)

\start
Date: Thu, 4 May 2006 15:09:52 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: NOWEB

Gaby,

On Thursday, May 04, 2006 2:17 PM you wrote:
> ...
> Bill Page writes:
> |
> | I have installed Icon on the axiom-developer.org server and it
> | seems like a nice neat little language ... but I am sure Tim
> | will say: "Oh horrors, yet another programming language!" :)
>
> And I will second him!
>
> [Note: I have written small programs in Icon, and enjoyed
> "Graphics Programming in Icon" which you can get almost for
> free if you in academia.]
>

Sometimes I wonder how someone who does not really appreciate
diverse programming languages would ever be motivated to
become an Axiom developer ... although I would not expect
Axiom *users* to necessarily be so multilingual. ;)

I think Icon was a worthy predecessor of the currently very
popular web scripting languages like perl and python that came
later but did a lot of the same things (not necessarily as
well ):

http://www.cs.arizona.edu/icon/index.htm

Icon has venerable history rather similar to Axiom's, beginning
in 1977:

http://portal.acm.org/citation.cfm?doid=155360.155363

But it certainly is not a "dead" language yet:

http://www.cs.arizona.edu/icon/status.htm

The Icon books are now in fact free for all and I can highly
recommend both of them. You can download them here:

http://www.cs.arizona.edu/icon/gb

\start
Date: Thu, 04 May 2006 21:19:04 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: Blas in axiom (was Re: Axiom trunk failure)

Hi Tim,

Le jeudi 04 mai 2006 =E0 00:59 -0400, root a =E9crit :

[...]

> i've joined axiom to the numerical mathematics consortium
> (http://www.nmconsortium.org/FldRte/?id=72&page=Associate+Members)
> because i have an interest in recovering the numerical library
> facility for axiom. i have rewritten the BLAS library into literate
> form and have gotten permission from a BLAS person to use his research
> work as documentation for the routines. i'm in the process of
> documenting the BLAS code now. when it completes i'll release a
> numeric library for axiom that is literate BLAS. then i'll move on to
> the next numerical piece. along the way i'm learning about sensitivity
> analysis, methods of graphing branch cuts, etc. and trying to add what
> i've learned to the documentation for the code.

Humm... I have a lot of questions about your work on a Blas library.

Is it coded in spad ? Is the interface fixed ?  If so did you use the
naming and calling convention of Blas ? For example the
<grep>[s|d|c|z]axpy</grep> blas routine are named axpy in your
implementation ? Same question apply for routines arguments
(<grep>inc.</grep> for vector and <grep>ld.</grep> for leading dimension
of matrices). Is the Float domain supported or only the DoubleFloat one?

In fact if I have all these questions it's because my version of Axiom
contains an interface to Blas and part of Lapack libraries but only for
reals (i.e DoubleFloat). This is probably a different implementation
since, in my work, the interface is coded in C and Lisp and needed a
complete new <grep>\<.*Matrix.*\></grep> tree in spad. It needs working
Blas and Lapack libraries too, either in C or in Fortran (in my case GCL
is linked to AMD's ACML).

The complex case is more difficult to solve (the internals of complex
long-float in GCL does not facilitate this task) and I actually don't
know if I will add an interface to it or how I will achieve this goal.
So if you can briefly explain your work I would be very happy.

I worked on this several months or years ago and re-begin to work on it
recently.


And yes, I know, I'm too curious.

PS : My implementation still require a lot of work but there is always
work to be done.

\start
Date: Thu, 04 May 2006 12:24:08 -0700
From: Simon Michael
To: list
Subject: Re: Spam

Hi guys.. I'd like to return to this (making mathaction work with latest 
zwiki). Bill, did you see my mail asking you to merge Bob's latest 
latexwiki patches ? I can do it but I think someone familiar with latexwiki 
will do a better job of resolving the conflicts. Chat me on #zwiki if I can 
support.

\start
Date: Thu, 4 May 2006 15:44:21 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: re: Axiom trunk failure

Greg,

On Thursday, May 04, 2006 2:51 PM you wrote:
>
> Humm it seems to me that all the axiom-developer's mailing
> list archives are in your mind  :-)>

:)

You also can download the axiom-developer email archives here:

ftp://lists.gnu.org/axiom-developer

;) and of course anyone can search them online at:

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

The point is, I guess it is easy for most of us to somehow
find the time to be verbose by email but we do not find the
time to write pamphlet file documentation or even to update
wiki web pages.  As a result these archives represent quite
a lot of, admittedly rather "low density", but very important
information about Axiom.

If anyone has a suggestion for a good package to archive, index
and search these email files off-line (on a desktop or maybe on
the axiom-developer.org server) then I would be very interested.
Securing these files might become important for the long term
future of Axiom if we do not find the time or a better way to
distill the really useful information from the archive into
a more accessible form or if for some reason the online email
archive becomes inaccessible.

\start
Date: 04 May 2006 21:50:07 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: NOWEB

Bill Page writes:

| Gaby,
| 
| On Thursday, May 04, 2006 2:17 PM you wrote:
| > ... 
| > Bill Page writes:
| > | 
| > | I have installed Icon on the axiom-developer.org server and it
| > | seems like a nice neat little language ... but I am sure Tim
| > | will say: "Oh horrors, yet another programming language!" :)
| > 
| > And I will second him!
| > 
| > [Note: I have written small programs in Icon, and enjoyed 
| > "Graphics Programming in Icon" which you can get almost for
| > free if you in academia.]
| > 
| 
| Sometimes I wonder how someone who does not really appreciate
| diverse programming languages would ever be motivated to
| become an Axiom developer ... although I would not expect
| Axiom *users* to necessarily be so multilingual. ;)

I do not have an answer to your question.  Different people function
differently. 

But, if the question is directed to me, then the answer is "I do
play with lots of programming languages, and fluent in quite a few of
them, with totally different paradigms -- I would not be here, if it
were otherwise".  Now, if you ask me whether in a large project I
would recommend that we use all of them, then my first order answer is
NO! 

Maybe there is a confusion about appreciating diverse programming
languages and appreciating the set of tools we should use to deliver a
coherent, attractive, scalable, and maintainable project.

I don't want my scarce resource (time) to be sunk in a black hole.
When it comes to tenure, the number of languages one appreciates counts
for exactly zero.  Software *development* counts for zero -- even in
the area of software.  The number of papers count highly; grants are
important.  
I don't want to write about people writing software. I would prefer to 
write about software, largely based on experience.  For that, I prefer
invest the "wasted time" in something that can make a difference; that
people use. I see an opportunity in Axiom.  I would hate it becomes a
black hole where all sorts of languages get sunk into because of 
"diverse programming language appreciation."  The reasons why we should
add new tools to our tool bagage should be their effectiveness to
solve specific problems we are facing, not just because we want to be
diverse.  There is something to be said for breath, there is also
something to be said for depth.   There must be a balance somewhere
given the limited resources we have.

| I think Icon was a worthy predecessor of the currently very
| popular web scripting languages like perl and python that came
| later but did a lot of the same things (not necessarily as
| well ):

You mean SNOBOL? :-)

[ The whom I work for currently is a long term SNOBOL
  hacker; yet he invented a different language that will not be suitable
  for discussion here :-p  And we do work in an environment where we
  highly appreciate diverse languages and paradigms. ]

| 
| http://www.cs.arizona.edu/icon/index.htm
| 
| Icon has venerable history rather similar to Axiom's, beginning
| in 1977:

Thanks; not mean to be rude -- but I'm an Icon hacker.  I spent long
time studying Icon.  For example, I wanted to add generators (not
co-routines) to C++; among other things I digested Icon's
implementation.  That was not too long ago.

\start
Date: Thu, 4 May 2006 16:28:58 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: NOWEB

Gaby,

On Thursday, May 04, 2006 3:50 PM you wrote:
> ...
> Maybe there is a confusion about appreciating diverse
> programming languages and appreciating the set of tools
> we should use to deliver a coherent, attractive, scalable,
> and maintainable project.

I understand your point and actually in principle I do agree
with you (and Tim) I just don't think it makes any sense to
take it to the extreme, e.g. "all lisp".

> Bill Page wrote:
> | I think Icon was a worthy predecessor of the currently very
> | popular web scripting languages like perl and python that
> | came later but did a lot of the same things (not necessarily
> | as well ):
>
> You mean SNOBOL? :-)

Icon was a child of SNOBOL just as (in a looser sense) perl and
python are children of Icon. But it seems that children often
do not appreciate their parents until they themselves get older.
Perhaps I would be giving too much away to admit that the first
language I ever used with "real string processing" was SNOBOL.
But in fact I never programmed in Icon until last year.

>
> |
> | http://www.cs.arizona.edu/icon/index.htm
> |
> | Icon has venerable history rather similar to Axiom's,
> | beginning in 1977:
>
> Thanks; not mean to be rude -- but I'm an Icon hacker.  I spent
> long time studying Icon.  For example, I wanted to add generators
> (not co-routines) to C++; among other things I digested Icon's
> implementation.  That was not too long ago.
>

I certainly do not consider your comments rude, nor do I mean
any insult. :)

Norman Ramsey's code for doing LaTeX to HTML conversion is written
in Icon and uses the method of completions - not really native to
Icon but quite easily implemented. I learned a lot by studying
that code.

\start
Date: Fri, 05 May 2006 11:49:33 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Explanation of the branches

Dear Gaby,

Thank you for all your work on the silver branch

But in order not to lose track of all the possible branches that might 
be created in the SVN repository, do you think, it would be a good idea 
to list them together here

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

For each branch I would like to see a short explanation of why this 
branch exists and who actually maintains it.

Maybe that could also be done with tools at sourceforge, but I am not 
yet overly familiar with that. Maybe you suggest something better.

Maybe

http://wiki.axiom-developer.org/FAQ -- How can I submit a patch?

should be adapted, become a separate page, and should be linked to from 
FAQ and AxiomSilverBranch.

\start
Date: Fri, 05 May 2006 11:55:47 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: star merge and the silver branch

On 05/02/2006 11:00 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> [...]
> 
> | Of course, SVN has some weaknesses (especially not being able to do a
> | star-merge), but since you could live with CVS for many years, I am
> | sure you can cope with that missing feature anyway.
> 
> Hi Ralf,
> 
>   Since you have been teasing us about this feature for a long time,
> I put a short description of how to work on the Axiom silver branch
> with SVK.  See
> 
>     http://wiki.axiom-developer.org/AxiomSilverBranch
> 
> SVK has implemented Tom Lord's "star merge" algorithm (I have not
> used it myself)
> 
>     http://svkbook.elixus.org/nightly/en/svk.ref.svk.c.smerge.html
> 
> I do however use SVK frequently (though I'm no expert) and the steps I
> put on the wiki are those I followed to set up a working SVK
> repository for myself.

Hmmm, currently I use psvn.el http://www.xsteve.at/prg/emacs/ and I am 
relatively satisfied with it. Unfortunately, I had no luck with
http://svk.elixus.org/?SVKTools. My xemacs has some problem with them 
and I just did not look into this problem.

\start
Date: 05 May 2006 11:59:20 +0200
From: Martin Rubey
To: Bill Page
Subject: re: noweb / Lisp Skills

Bill Page writes:

> On Thursday, May 04, 2006 10:47 AM Martin Rubey wrote:
> > ... 
> > Things to do on the interpreter side needed for the 
> > axiom-combinat project:
> > 
> > * make it understand Aldor:
> > 
> >   * dependent types
> >   * extend
> >   * creating domains on the command line
> >
> 
> Is what you are suggesting the same thing as making library
> programming possible at the level of the interpreter? 

Yes. In aldor -gloop this is possible.

In fact, maybe it would be better to try to integrate the type guessing
mechanism of Axiom into the Aldor interpreter. That is, throw away the axiom
interpreter and replace it by aldor -gloop.

Again, I said already that I'm unskilled in the art of interpreter and compiler
writing. I only try to state what would be important to me from a
mathematicians point of view.

> If so, they I supose that you realize that this is already an issue at the
> level of SPAD and is not really an Aldor specific problem. It seems to me
> that the differences between the interpreter and library compiler
> environments were largely built-in as part of the original design of Axiom. I
> think the designers decided that the interpreter *should* behave differently
> than the compiler and that some of the things the compiler does should
> specifically not be available to the interactive user.

If this was intentional, it was a mistake. But I'm pretty sure that it was due
to limitations of time and money, rather than intention.

> It is certainly possible right now to use dependent types and the Aldor
> 'extend' functionality in Axiom right now so long as you remain within the
> Aldor library code. The problem is that neither of these can currently be
> "exposed" the the interactive user through the Axiom interpreter.

Yes. This is the way we are going to work around these problems, in fact. But
it's dead ugly.

> I think however that these two cases a rather different.  I think it should
> be possible to implement dependent types in the interpreter and the fact that
> it doesn't currently work is apparently already considers a bug by Peter
> Broadbery.

I believe so too, and I think that supporting dependent types would make for a
very good start. It doesn't need to be super clean, since in the long run we
will have to rewrite the interpreter from scratch anyway (or use aldor -gloop),
but it would make the transition a lot easier.

> But the the 'extend' functionality is another issue because that whould
> require providing the equivalent of the library compiler at the interpreter
> level.

Yes, this might have been wrong on my side. It seems that extend does not even
work in aldor -gloop. However, I think it should.

Is it already possible to extend Axiom domains with Aldor code? (I should check
this)

\start
Date: 05 May 2006 12:57:47 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: star merge and the silver branch

Ralf Hemmecke writes:

| On 05/02/2006 11:00 PM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke writes:
| > [...]
| > | Of course, SVN has some weaknesses (especially not being able to
| > do a
| > | star-merge), but since you could live with CVS for many years, I am
| > | sure you can cope with that missing feature anyway.
| > Hi Ralf,
| >   Since you have been teasing us about this feature for a long time,
| > I put a short description of how to work on the Axiom silver branch
| > with SVK.  See
| >     http://wiki.axiom-developer.org/AxiomSilverBranch
| > SVK has implemented Tom Lord's "star merge" algorithm (I have not
| > used it myself)
| >     http://svkbook.elixus.org/nightly/en/svk.ref.svk.c.smerge.html
| > I do however use SVK frequently (though I'm no expert) and the steps
| > I
| > put on the wiki are those I followed to set up a working SVK
| > repository for myself.
| 
| Hmmm, currently I use psvn.el http://www.xsteve.at/prg/emacs/ and I am
| relatively satisfied with it. Unfortunately, I had no luck with
| http://svk.elixus.org/?SVKTools. My xemacs has some problem with them
| and I just did not look into this problem.

Ah OK.  It was an FYI in case "star-merge" is essential for for you.

\start
Date: Fri, 05 May 2006 13:05:04 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: noweb / Lisp Skills

On 05/05/2006 11:59 AM, Martin Rubey wrote:
> Bill Page writes:
> 
>> On Thursday, May 04, 2006 10:47 AM Martin Rubey wrote:
>>> ... 
>>> Things to do on the interpreter side needed for the 
>>> axiom-combinat project:
>>>
>>> * make it understand Aldor:
>>>
>>>   * dependent types
>>>   * extend
>>>   * creating domains on the command line
>>>
>> Is what you are suggesting the same thing as making library
>> programming possible at the level of the interpreter? 
> 
> Yes. In aldor -gloop this is possible.

> In fact, maybe it would be better to try to integrate the type guessing
> mechanism of Axiom into the Aldor interpreter. That is, throw away the axiom
> interpreter and replace it by aldor -gloop.

Hmm, I am not sure whether I would currently suggest "aldor -gloop" as a
replacement for the Axiom interpreter. The idea that the interpreter and
compiler languages are identical is attractive, but

1) "aldor -gloop" is slow and needs something like BNatural to make Aldor
simpler for endusers. But it might be a good start in the long run.

2) The aldor interpreter seems a bit buggy to me.

>> If so, they I supose that you realize that this is already an issue at the
>> level of SPAD and is not really an Aldor specific problem. It seems to me
>> that the differences between the interpreter and library compiler
>> environments were largely built-in as part of the original design of Axiom. I
>> think the designers decided that the interpreter *should* behave differently
>> than the compiler and that some of the things the compiler does should
>> specifically not be available to the interactive user.

> If this was intentional, it was a mistake.

I also think that. The interpreter should actually be a shell around the 
compiler and the libraries. One could even have several such shell 
similar to csh, bash, etc. (The question is whether different 
shells/interpreters would be desirable.) In particular, if an 
interpreter allows to read something like .input files (that are 
interpreted like the command line) than one cannot expect to get easy 
translation of .input to .as since the interpreter might have added 
automatic type coercion. The extreme would be that only pure Aldor (.as) 
files are allowed. But though it might be tempting to force people to 
think about the types they actually want, it would probably be much to 
hard for beginners. One has to get used to all this type stuff.

>> But the the 'extend' functionality is another issue because that whould
>> require providing the equivalent of the library compiler at the interpreter
>> level.

> Yes, this might have been wrong on my side. It seems that extend does not even
> work in aldor -gloop. However, I think it should.

Currently the Axiom interpreter can call the compiler and thus extend 
(well, not the Aldor "extend") the functionality of Axiom per session.

What would people think about a (library) function "compile" that takes 
a string as input (or better something of type "AldorCode" and considers 
  this to be aldor code that has to be compiled. The result would be the 
compiled function that then can be used as any other function. So one 
would say something like

f := compile(Integer -> Integer, "(i:Integer): Integer -> i+1")
n: Integer := 2;
f(n);

Of course I could write this without the quotes, but imagine that the 
string has been dynamically produced by a program.

\start
Date: 05 May 2006 13:02:44 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Explanation of the branches

Ralf Hemmecke writes:

| Dear Gaby,
| 
| Thank you for all your work on the silver branch
| 
| But in order not to lose track of all the possible branches that might
| be created in the SVN repository, do you think, it would be a good
| idea to list them together here
| 
| http://wiki.axiom-developer.org/AxiomSilverBranch
| 
| For each branch I would like to see a short explanation of why this
| branch exists and who actually maintains it.
| 
| Maybe that could also be done with tools at sourceforge, but I am not
| yet overly familiar with that. Maybe you suggest something better.
| 
| Maybe
| 
| http://wiki.axiom-developer.org/FAQ -- How can I submit a patch?
| 
| should be adapted, become a separate page, and should be linked to
| from FAQ and AxiomSilverBranch.

All you suggestions make good sense; I'll try to update the wiki page
today about the branches.  Currently there is only two: one named
"daly" (Tim what is the purpose of that branch?), and
"build-improvements" (for my work on using Autoconf -- not functional
yet). 

You're right that "How can I submit a patch" should be a separate
page.  I have had not a great success with the current wiki
settings...

\start
Date: Fri, 05 May 2006 13:40:34 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: noweb
Cc: Norman Ramsey

Hello, is somebody so familiar with the documentation of noweb, to point 
exactly at a place in the documentation that says something about what 
noweb SHOULD do if it sees

   <<NOT DEFINED CODE CHUNK NAME>>

in either documentation or code chunk?

The only place where I think it would be necessary to escape <<  is if 
an = sign immediately follows the >> AND the << starts at the first 
column. In all other situations the line should be output by noweb 
literally and NO error message should occurs. Maybe a WARNING (to 
stderr) would be nice, but still errcode=0.

Ralf Hemmecke


> | In the file '  src/interp/fnewmeta.lisp.pamphlet' the text:
> | 
> |   <<' Name '>>
> | 
> | is not really a reference to a chunk but noweb thinks it is
> | and the standard (designed in) behavior of noweb when it
> | finds such an "undefined chunk" is simply to omit it. This
> | breaks the Axiom code.
> | 
> | Of course would could define this as a chunk using the noweb
> | escape sequence @<<
> | 
> |   <<' Name '>>=
> |   @<<' Name '>>
> |   @  
> | 
> | and solve this one case where it is really a problem (or even
> | use the escape sequence inline).

\start
Date: Fri, 05 May 2006 10:46:02 -0400
From: Norman Ramsey
To: Ralf Hemmecke
Subject: re: noweb 

 > Hello, is somebody so familiar with the documentation of noweb, to point 
 > exactly at a place in the documentation that says something about what 
 > noweb SHOULD do if it sees
 > 
 >    <<NOT DEFINED CODE CHUNK NAME>>
 > 
 > in either documentation or code chunk?
 > 
 > The only place where I think it would be necessary to escape <<  is if 
 > an = sign immediately follows the >> AND the << starts at the first 
 > column. In all other situations the line should be output by noweb 
 > literally and NO error message should occurs. Maybe a WARNING (to 
 > stderr) would be nice, but still errcode=0.

No.  Misspelled chunk names or missing chunks should result in errors,
as should chunk names appearing in documentation.

I have made a note that noweb's manual needs to be amended.

 > 
 > Ralf Hemmecke
 > 
 > 
 > > | In the file '  src/interp/fnewmeta.lisp.pamphlet' the text:
 > > | 
 > > |   <<' Name '>>
 > > | 
 > > | is not really a reference to a chunk but noweb thinks it is
 > > | and the standard (designed in) behavior of noweb when it
 > > | finds such an "undefined chunk" is simply to omit it. This
 > > | breaks the Axiom code.
 > > | 
 > > | Of course would could define this as a chunk using the noweb
 > > | escape sequence @<<
 > > | 
 > > |   <<' Name '>>=
 > > |   @<<' Name '>>
 > > |   @  
 > > | 
 > > | and solve this one case where it is really a problem (or even
 > > | use the escape sequence inline).

\start
Date: Fri, 5 May 2006 12:01:44 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: noweb 
Cc: Norman Ramsey

Ralf, Norman, Tim, et al.

>
> Ralf Hemmecke wrote:
> >
> > The only place where I think it would be necessary to
> > escape <<  is if an = sign immediately follows the >>
> > AND the << starts at the first column. In all other
> > situations the line should be output by noweb literally
> > and NO error message should occurs. Maybe a WARNING (to
> > stderr) would be nice, but still errcode=0.
>

On Friday, May 05, 2006 10:46 AM Norman Ramsey wrote:
>
> No.  Misspelled chunk names or missing chunks should result
> in errors, as should chunk names appearing in documentation.
>

As we all know this has been an "issue" in Axiom for some
time now since Tim Daly originally proposed a patch which
(essentially) implemented the behavior that Ralf suggests
above. At the time Norman also pointed out and provided
alternate code that implements this behavior using an
awk filter. Since all of Axiom's code depends on noweb,
I think it would be very nice to have this issue resolved.

The way I see it, what Ralf and Tim are suggesting is motivated
primarily by convenience for the author, i.e.  changing the
external source code as little as possible - even not at all -
when placing it inside a noweb literate program document.
But the reality is that any linear document syntax will
require some method of escaping external constructs that
conflict with the document syntax even if we do not wish to
place no other any limitation on the syntactical structure
of the external content. But this escape mechanism is only
an internal representation issue - something that we should
be very familiar with in the context of Axiom! :) The 'tangle'
and 'weave' operators make this escape mechanism invisible
on output.

Unfortunately developers still often use editing tools that
do not properly hide the internal representation of the
literate document so that on input the escape syntax can
sometimes seem quite inconvenient. I think the problem
really lies with these input tools and not with the internal
representation at all. As a minimum it would be nice to
have an "import tool" that coerces the external source code
syntax into the proper internal representation, i.e. something
that automatically adds the required escape codes. Even better
might be to have an editing "mode" (in emacs for example)
which recognizes and appropriately hides this coding for
the sake of convenience.

The bottom line here is that I agree with Norman that
modifying noweb's behavior is not the correct solution
and that if anything it should be more exact and strict.

\start
Date: Fri, 5 May 2006 14:05:01 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: noweb 
Cc: Norman Ramsey

On Friday, May 05, 2006 12:02 PM I wrote:
> ...
> Unfortunately developers still often use editing tools that
> do not properly hide the internal representation of the
> literate document so that on input the escape syntax can
> sometimes seem quite inconvenient. I think the problem
> really lies with these input tools and not with the internal
> representation at all. As a minimum it would be nice to
> have an "import tool" that coerces the external source code
> syntax into the proper internal representation, i.e. something
> that automatically adds the required escape codes. Even better
> might be to have an editing "mode" (in emacs for example)
> which recognizes and appropriately hides this coding for
> the sake of convenience.
> ...

I forgot to add that there is in fact another tool called
'untangle' in the literate programming toolkit. 'untangle'
(perhaps poorly named) is sort of a cross between 'tangle'
and 'weave'. Norman has written:

  "nountangle converts a literate program into an ordinary
  program by turning interleaved documentation into comments."

  noweb man page:

  "'notangle' produces a program with proper spacing and
  indentation. 'nountangle' does that while also transforming
  documentation chunks to block comments."

  http://www.literateprogramming.com/best/anoweb.html

  "To be able to share programs with colleagues who don't enjoy
  literate programming, I modified notangle by adding to its
  pipeline a stage that places each line of documentation in
  a comment and moves it to the succeeding code chunk. The
  resulting script, nountangle, transforms a literate program
  into a traditional commented program, without loss of
  information and with only a modest penalty in readability."

In order to perform 'untangle' in a manner that would be
compatible with a given target source language it would be
necessary for 'untangle' to generate the comments in a syntax
compatible with the target language. This might get pretty
complicated if there are multiple target languages in the
original literate program document or if it contains multiple
top-level root chunks. But this is not really necessary if
we are interested only in reading and editability

In principle 'untangle' could provide a kind of transparent
editing of the source code (including the documentation as
presented in the comments). The non-source code document
structure could be represented exactly by additional "sentinel
lines" added to the comments that relate these comments back
to the original literate program document so that in principle
'untangling' is completely reversible (re-tangle?). But as
you can imagine implementing this inverse operator to 'untangle'
(Note: 'tangle' is not the inverse of 'untangle'!) might not
be so easy. However I think, for example that Leo does exactly
this sort of thing.

Unfortunately 'retangle' is not currently implemented as part
of noweb. But there might someday be a "noweb 3"! See:

http://www.eecs.harvard.edu/~nr/noweb/todo3.html

If 'retangle' was available this would allow relatively
transparent editing of the "untangled" version of the
document and "re-tangling" it back into literate program
format - provided of course that the editor is careful not
to corrupt the structure of the embedded sentinel lines.

\start
Date: Sat, 6 May 2006 09:14:01 -0400
From: Tim Daly
To: Christian Aistleitner
Subject: Re: [Aldor-l] Functions and Expression trees

> my current work involves converting aldor objects to and from OpenMath
> format, via. the ExpressionTree type (from the algebra lib.). I'm a bit
> stuck when it comes to function objects, I don't seem to be able to get a
> handle on anything, the signatures of the functions or the body of the
> function.
>
> It would be really nice to have an extree(f) function [...]

Within the Axiom interpreter it is possible to get this information
although it would take some knowledge of the inner workings of the
system. The key function is called pf2Sex (parse form to s-expression). 

(The input expression to pf2Sex below indicated by the "1>" is the
result of a novel research parser by Bill Burge. This parser, which
he called a "zipper" parser constructs a form which consists of the
input string and its symbols. Every symbol in the parse contains the
original input string, the position of the symbol in that string and
the parse of the string from that position. It is of the form

  type "inputstringobject" . position . parse

as in 

 -type     ((|id| (|posn| 
 -input      (0 
               "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
               1 
               1 
               "strings")
 -position    . 4)) 
 -parse      . |Integer|))

This novel parsing method has never been documented. Bill Burge
used Axiom as a research platform for parsing methods.)

The output of pf2Sex (shown at "<1" below) contains the DEF
structure (which is Axiom's equivalent of lisp DEFUN) and
contains the symbols, the types, and the parsed expression.

Thus all of the information you could possibly want about an
expression exists and it would be possible to implement a
package in Axiom that would return the original expression, 
any part of its parse tree, and the final result of the parse.


It knows what the current line is:

(2) -> )lisp (trace |pf2Sex|)

Value = (|pf2Sex|)
(2) -> g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)


  1> (|pf2Sex| 
      (|Definition| 
       (|listOf| 
        (|Typed| 
         ((|id| (|posn| 
          (0 
          "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
          1 
          1 
          "strings") 
         . 0)) 
        . |g|)
          (|nothing|)))
        (|Lambda| 
         (|listOf| 
          (|Typed| 
           ((|id| (|posn| 
             (0 
               "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
               1 
               1 
               "strings")
              . 2)) 
             . |a|)
           ((|id| (|posn| 
             (0 
               "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
               1 
               1 
               "strings")
              . 4)) 
             . |Integer|))
          (|Typed| 
           ((|id| (|posn| 
             (0 
               "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
               1 
               1 
               "strings") 
              . 12))
             . |b|)
           ((|id| (|posn| 
             (0 
               "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
               1 
               1
               "strings") 
              . 14)) 
             . |Integer|)))
         ((|id| (|posn| 
           (0 
             "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
             1 
             1 
             "strings") 
            . 23)) 
           . |Integer|)
         (|Application| 
          ((|id| (|posn| 
           (0 
            "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
            1 
            1 
            "strings") 
           . 44)) 
          . +)
          (|Tuple| 
           (|listOf| 
            (|Application| 
             ((|id| (|posn| 
              (0 
               "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
                1 
                1 
                "strings") 
               . 38)) 
              . +)
             (|Tuple| 
              (|listOf| 
               ((|id| (|posn| 
                (0 
                 "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
                 1 
                 1 
                 "strings") 
                . 36)) 
               . |a|)
               (|Application| 
                ((|id| (|posn| 
                 (0 
                  "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
                  1 
                  1 
                  "strings") 
                 . 41)) 
                . *) 
                (|Tuple| 
                 (|listOf| 
                  ((|integer| (|posn| 
                   (0 
                    "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
                    1 
                    1 
                    "strings") 
                   . 40)) 
                  . "4")
                  ((|id| (|posn| 
                   (0 
                    "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
                    1 
                    1 
                    "strings") 
                   . 42)) 
                  . |b|)))))))
            (|Application| 
             ((|id| (|posn| 
              (0 
               "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
               1 
               1 
               "strings") 
              . 47)) 
             . *)
             (|Tuple| 
              (|listOf| 
               ((|id| (|posn| 
                (0 
                 "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
                 1 
                 1 
                 "strings") 
                . 46)) 
               . |a|)
               ((|id| (|posn| 
                 (0 
                  "g(a:Integer,b:Integer):Integer == ( a + 4*b + a*b)" 
                  1 
                  1 
                  "strings") 
                 . 48)) 
                . |b|))))))))))

  <1 (|pf2Sex| 
       (DEF 
        (|g| |a| |b|) 
        (|Integer| |Integer| |Integer|) 
        (NIL NIL NIL) 
        (+ (+ |a| (* 4 |b|)) (* |a| |b|))))

   Function declaration g : (Integer,Integer) -> Integer has been added
      to workspace.
                                                                   Type: Void

\start
Date: 06 May 2006 16:35:29 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom trunk failure

Tim Daly writes:

| > Gosh, I forgot the real thing.  
| > It is there, real this time.
| 
| 2 points,
| 
| 1) did you test the patches? did you do a full system erase,
| system checkout, system build, system test? 
| 
| 2) you changed not only the current system (gcl-2.6.8pre) but
| the previous system (gcl-2.6.7). did you test both versions?
| 
| i know this seems like such a trivial patch that it "ought" to work
| but remember that you're asking for changes to a system that many
| people you might never meet are using. 
| 
| as a matter of policy changes need to be fully tested. 
| because you changed gcl-2.6.7 i'll actually have to do a 
| round-trip rebuild of a gcl-2.6.7 system as well as a gcl-2.6.8pre
| system. i do testing every time. and it takes a lot of time.
| but you'd be amazed at the number of ways things can break.
| witness the mistake i made (despite my best efforts) when
| i posted a broken --patch-48

Tim,

  Here is the patch I am about to commit.  
I built Axiom with GCLVERSION set to both 2.6.7 and 2.6.8pre on an
i686-pc-linux-gnu.  No regression.

Note for myself:

    TODO:  Add a configure option set select the version of GCL to
    build (if we ever have to build it).

-- Gaby

lsp/ChangeLog
2006-05-03  Gabriel Dos Reis  <gdr@acm.org>

	* Makefile.pamphlet: Skip tail-recursive patch for GCL version
	greater or equal to 2.6.7.  Document.

zips/ChangeLog	(local)
2006-05-03  Gabriel Dos Reis  Gabriel Dos Reis

 	* gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch: Delete.
 	* gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch: Likewise.
 	* gcl-2.6.7pre.cmpnew.gcl_cmpcall.lsp.patch: Likewise.
 	* gcl-2.6.7pre.cmpnew.gcl_cmpflet.lsp.patch: Likewise.
 	* gcl-2.6.8pre.cmpnew.gcl_cmpcall.lsp.patch: Likewise.

--- lsp/Makefile.pamphlet	(revision 34)
+++ lsp/Makefile.pamphlet	(local)
@@ -383,7 +383,11 @@
 he left code in the system to print a message when the code was
 executed. We no longer care but it is still in GCL. We patch the
 call rather than the cmpnote function as cmpnote might have later
-usage.
+usage.  
+
+Bill Page reported that this tail-recursive patch is no longer
+necessary for recent releases of GCL.  Consequently, it has 
+been disabled for all versions of GCL greater than 2.6.7.
 <<gcl-2.5.2.tail-recursive.patch>>=
 	@(cd ${GCLVERSION}/cmpnew ; \
 	  echo 11 applying tail-recursive noise patch ; \
@@ -457,22 +461,6 @@
 	  echo 12 applying tail-recursive noise patch ; \
 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpcall.lsp.patch )
 @
-<<gcl-2.6.7.tail-recursive.patch>>=
-	@(cd ${GCLVERSION}/cmpnew ; \
-	  echo 11 applying tail-recursive noise patch ; \
-	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpflet.lsp.patch )
-	@(cd ${GCLVERSION}/cmpnew ; \
-	  echo 12 applying tail-recursive noise patch ; \
-	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpcall.lsp.patch )
-@
-<<gcl-2.6.8pre.tail-recursive.patch>>=
-	@(cd ${GCLVERSION}/cmpnew ; \
-	  echo 11 applying tail-recursive noise patch ; \
-	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpflet.lsp.patch )
-	@(cd ${GCLVERSION}/cmpnew ; \
-	  echo 12 applying tail-recursive noise patch ; \
-	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpcall.lsp.patch )
-@
 \subsubsection{collectfn fix}
 GCL-2.6.1 renamed collectfn.lsp to gcl\_collectfn.lsp.
 We rename it back into place because we have later Makefiles
@@ -1018,7 +1006,6 @@
 <<gcl-2.6.7pre.socket.patch>>
 <<gcl-2.6.7pre.libspad.patch>>
 <<gcl-2.6.7pre.toploop.patch>>
-<<gcl-2.6.7pre.tail-recursive.patch>>
 <<gcl-2.6.7pre.collectfn.fix>>
 <<gclConfigureMake>>
 	@echo 13 finished system build on `date` | tee >gcldir
@@ -1061,7 +1048,6 @@
 <<gcl-2.6.7.socket.patch>>
 <<gcl-2.6.7.libspad.patch>>
 <<gcl-2.6.7.toploop.patch>>
-<<gcl-2.6.7.tail-recursive.patch>>
 <<gcl-2.6.7.collectfn.fix>>
 <<gclConfigureMake>>
 	@echo 13 finished system build on `date` | tee >gcldir
@@ -1103,8 +1089,7 @@
 <<gcl-2.6.8pre.socket.patch>>
 <<gcl-2.6.8pre.libspad.patch>>
 <<gcl-2.6.8pre.toploop.patch>>
-<<gcl-2.6.8pre.tail-recursive.patch>>
 <<gcl-2.6.8pre.collectfn.fix>>
 <<gclConfigureMake>>
 	@echo 13 finished system build on `date` | tee >gcldir
--- zips/gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch	(revision 34)
+++ zips/gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch	(local)
@@ -1,13 +0,0 @@
---- gcl_cmpcall.lsp	Sun Jul 24 12:54:28 2005
-+++ gcl_cmpcall.lsp.tpd	Sun Jul 24 12:58:36 2005
-@@ -264,7 +264,9 @@
-             (wt-label *exit*))
-       (unwind-no-exit 'tail-recursion-mark)
-       (wt-nl "goto TTL;")
--      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname))
-+; 20031022000 tpd we don't need to know this
-+;      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname)
-+      )
- 
-      ;;; Open-codable function call.
-      ((and (listp args)

Property changes on: zips/gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

--- zips/gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch	(revision 34)
+++ zips/gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch	(local)
@@ -1,15 +0,0 @@
---- gcl_cmpflet.lsp	Sun Jul 24 12:54:29 2005
-+++ gcl_cmpflet.lsp.tpd	Sun Jul 24 13:44:18 2005
-@@ -390,8 +390,10 @@
-           (wt-label *exit*))
-     (unwind-no-exit 'tail-recursion-mark)
-     (wt-nl "goto TTL;")
--    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
--             (fun-name (car fd))))
-+; 20031022000 tpd we don't need to know this
-+;    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
-+;             (fun-name (car fd)))
-+    )
-    (t (push-args args)
-       (wt-nl (c-function-name "L" (fun-cfun (car fd)) (fun-name (car fd))) "(")
-       (dotimes** (n (fun-level (car fd))) (wt "base" n ","))

Property changes on: zips/gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

--- zips/gcl-2.6.7pre.cmpnew.gcl_cmpcall.lsp.patch	(revision 34)
+++ zips/gcl-2.6.7pre.cmpnew.gcl_cmpcall.lsp.patch	(local)
@@ -1,13 +0,0 @@
---- gcl_cmpcall.lsp	Sun Jul 24 12:54:28 2005
-+++ gcl_cmpcall.lsp.tpd	Sun Jul 24 12:58:36 2005
-@@ -264,7 +264,9 @@
-             (wt-label *exit*))
-       (unwind-no-exit 'tail-recursion-mark)
-       (wt-nl "goto TTL;")
--      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname))
-+; 20031022000 tpd we don't need to know this
-+;      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname)
-+      )
- 
-      ;;; Open-codable function call.
-      ((and (listp args)

Property changes on: zips/gcl-2.6.7pre.cmpnew.gcl_cmpcall.lsp.patch
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

--- zips/gcl-2.6.7pre.cmpnew.gcl_cmpflet.lsp.patch	(revision 34)
+++ zips/gcl-2.6.7pre.cmpnew.gcl_cmpflet.lsp.patch	(local)
@@ -1,15 +0,0 @@
---- gcl_cmpflet.lsp	Sun Jul 24 12:54:29 2005
-+++ gcl_cmpflet.lsp.tpd	Sun Jul 24 13:44:18 2005
-@@ -390,8 +390,10 @@
-           (wt-label *exit*))
-     (unwind-no-exit 'tail-recursion-mark)
-     (wt-nl "goto TTL;")
--    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
--             (fun-name (car fd))))
-+; 20031022000 tpd we don't need to know this
-+;    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
-+;             (fun-name (car fd)))
-+    )
-    (t (push-args args)
-       (wt-nl (c-function-name "L" (fun-cfun (car fd)) (fun-name (car fd))) "(")
-       (dotimes** (n (fun-level (car fd))) (wt "base" n ","))

Property changes on: zips/gcl-2.6.7pre.cmpnew.gcl_cmpflet.lsp.patch
___________________________________________________________________
Name: svn:eol-style
 -native
Name: svn:keywords
 -Author Date Id Revision

--- zips/gcl-2.6.8pre.cmpnew.gcl_cmpcall.lsp.patch	(revision 34)
+++ zips/gcl-2.6.8pre.cmpnew.gcl_cmpcall.lsp.patch	(local)
@@ -1,13 +0,0 @@
---- gcl_cmpcall.lsp	Sun Jul 24 12:54:28 2005
-+++ gcl_cmpcall.lsp.tpd	Sun Jul 24 12:58:36 2005
-@@ -264,7 +264,9 @@
-             (wt-label *exit*))
-       (unwind-no-exit 'tail-recursion-mark)
-       (wt-nl "goto TTL;")
--      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname))
-+; 20031022000 tpd we don't need to know this
-+;      (cmpnote "Tail-recursive call of ~s was replaced by iteration." fname)
-+      )
- 
-      ;;; Open-codable function call.
-      ((and (listp args)
--- zips/gcl-2.6.8pre.cmpnew.gcl_cmpflet.lsp.patch	(revision 34)
+++ zips/gcl-2.6.8pre.cmpnew.gcl_cmpflet.lsp.patch	(local)
@@ -1,15 +0,0 @@
---- gcl_cmpflet.lsp	Sun Jul 24 12:54:29 2005
-+++ gcl_cmpflet.lsp.tpd	Sun Jul 24 13:44:18 2005
-@@ -390,8 +390,10 @@
-           (wt-label *exit*))
-     (unwind-no-exit 'tail-recursion-mark)
-     (wt-nl "goto TTL;")
--    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
--             (fun-name (car fd))))
-+; 20031022000 tpd we don't need to know this
-+;    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
-+;             (fun-name (car fd)))
-+    )
-    (t (push-args args)
-       (wt-nl (c-function-name "L" (fun-cfun (car fd)) (fun-name (car fd))) "(")
-       (dotimes** (n (fun-level (car fd))) (wt "base" n ","))



\start
Date: Sat, 6 May 2006 11:09:24 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: Axiom trunk failure

I've applied your patches. they will be available at the next release.

Note that you didn't remove the 
<<gcl-2.6.7pre.tail-recursive.patch>>=
chunk from lsp/Makefile even though you deleted the corresponding file.

\start
Date: 07 May 2006 00:49:33 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom trunk failure

Tim Daly writes:

| I've applied your patches. they will be available at the next release.

Thanks!

| Note that you didn't remove the 
| <<gcl-2.6.7pre.tail-recursive.patch>>=
| chunk from lsp/Makefile even though you deleted the corresponding file.

Fixed thusly.  
Tested on an i686-pc-linux-gnu.

-- Gaby

lsp/ChangeLog
2006-05-06  Gabriel Dos Reis  <gdr@acm.org>

	* Makefile.pamphlet (gcl-2.6.7pre.tail-recursive.patch): Remove.

--- lsp/Makefile.pamphlet	(revision 35)
+++ lsp/Makefile.pamphlet	(local)
@@ -453,14 +453,6 @@
 	  echo 12 applying tail-recursive noise patch ; \
 	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpcall.lsp.patch )
 @
-<<gcl-2.6.7pre.tail-recursive.patch>>=
-	@(cd ${GCLVERSION}/cmpnew ; \
-	  echo 11 applying tail-recursive noise patch ; \
-	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpflet.lsp.patch )
-	@(cd ${GCLVERSION}/cmpnew ; \
-	  echo 12 applying tail-recursive noise patch ; \
-	  ${PATCH} <${SPD}/zips/${GCLVERSION}.cmpnew.gcl_cmpcall.lsp.patch )
-@
 \subsubsection{collectfn fix}
 GCL-2.6.1 renamed collectfn.lsp to gcl\_collectfn.lsp.
 We rename it back into place because we have later Makefiles

\start
Date: Sun, 7 May 2006 10:55:58 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: Axiom trunk failure

my testing of your patches fails. 
i don't see how your tests could have succeeded.

there must be something missing. the point of the patch is to 
suppress printing of compiler notes. your patches remove my
patches but they do not suppress compiler notes. somewhere 
in initialization you must add the line:

#+:akcl (setq compiler::*suppress-compiler-notes* t)

did i miss something?

\start
Date: 07 May 2006 23:56:44 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom trunk failure

Tim Daly writes:

| my testing of your patches fails. 
| i don't see how your tests could have succeeded.
| 
| there must be something missing. the point of the patch is to 
| suppress printing of compiler notes. your patches remove my
| patches but they do not suppress compiler notes. somewhere 
| in initialization you must add the line:
| 
| #+:akcl (setq compiler::*suppress-compiler-notes* t)
| 
| did i miss something?

Do you have test failing?

Like I said I did a full build and test; I ran Axiom on some programs
of mine using recursion -- not large size though.  I did not see
anything failing nor see more noise than before -- as diff could tell me.

I went through the archive, and finally discover this in
src/interp/Makefile.pamplhet:

\section{Building SAVESYS and AXIOMSYS}
GCL likes to tell you when it has replaced a function call by a
tail-recursive call. This happens when the last form in a function
is a call to the same function. In general, we don't care so we set
compiler::*suppress-compiler-notes* to true in order to reduce the noise.

and below, there is this line:

        @ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> ${OUT}/makeint.lisp 


Are you having a failure that necesitate the setting of
compiler::*suppress-compiler-notes everything time Axiom is invoked?

\start
Date: Sun, 7 May 2006 18:48:03 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: Axiom trunk failure

sigh. just can't win this month. just found out why it failed on me.
i created code to test for the condition in a test file but i missed
the compiler:: package and instead ended up testing for the symbol in
the boot package.

my mistake. sorry about that. --t

\start
Date: 08 May 2006 01:23:48 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom trunk failure

Tim Daly writes:

| sigh. just can't win this month. just found out why it failed on me.
| i created code to test for the condition in a test file but i missed
| the compiler:: package and instead ended up testing for the symbol in
| the boot package.

Can I take that you concur you have a good build and test?


By the way, I would formulate a request to have another list where one
could send vaiours test resulst including build and other sort of
"noisy" messages.  Can you take care of that?

The axiom-commit list seems to have stopped working, do you have an
idea?

\start
Date: Mon, 08 May 2006 13:49:42 -0500
From: Jay Belanger
To: list
Subject: Re: Issue building silver tree

Bill Page writes:
...
> Jay Belanger has identified this problem as due to incorrect
> "recursive copies" in the Axiom Makefile. See:
>
> http://lists.nongnu.org/archive/html/axiom-developer/2006-04/msg00161.html
>
> although he did not propose a fix.

Has anybody yet?
I don't know if the double copying is necessary (the relevant copy
commands were in two different makefiles), but the incorrect
recursive copies problem could be taken care of by not making the
copying recursive.  The particular problem that I ran into was copying
a directory and its subdirectories.  The directory was
.../src/scripts, and the only subdirectory was .../src/scripts/tex.
So perhaps the lines
  cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin
could be replaced by something like (after making sure any directories
are created)
  cp -p ${SRC}/scripts/* ${MNT}/${SYS}/bin
  cp -p ${SRC}/scripts/tex/* ${MNT}/${SYS}/bin/tex
(and I'm not sure the second line is necessary).  Without the -r, the
hidden directories are ignored.
Of course, what I'm doing now is showing that I don't know much about
the build process.

\start
Date: 08 May 2006 22:18:11 +0200
From: Gabriel Dos Reis
To: Jay Belanger
Subject: re: Issue building silver tree

Jay Belanger writes:

| Bill Page writes:
| ...
| > Jay Belanger has identified this problem as due to incorrect
| > "recursive copies" in the Axiom Makefile. See:
| >
| > http://lists.nongnu.org/archive/html/axiom-developer/2006-04/msg00161.html
| >
| > although he did not propose a fix.
| 
| Has anybody yet?

There are various fixes, with varying "definition" of fix :-)

| I don't know if the double copying is necessary (the relevant copy
| commands were in two different makefiles), but the incorrect
| recursive copies problem could be taken care of by not making the
| copying recursive.  The particular problem that I ran into was copying
| a directory and its subdirectories.  

I don't think the copying is ever necessary; it is only there because
of some shortcomings.  You can either 

  * use SVK (see the silver branch procedure) in the meantime, and
    wait for the new build machinery to correct those;

  * or proposes patches against the current silver branch and have
    them reviewed.

| The directory was
| .../src/scripts, and the only subdirectory was .../src/scripts/tex.
| So perhaps the lines
|   cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin
| could be replaced by something like (after making sure any directories
| are created)
|   cp -p ${SRC}/scripts/* ${MNT}/${SYS}/bin
|   cp -p ${SRC}/scripts/tex/* ${MNT}/${SYS}/bin/tex
| (and I'm not sure the second line is necessary).  Without the -r, the
| hidden directories are ignored.
| Of course, what I'm doing now is showing that I don't know much about
| the build process.

I spent last week (well, just the "free time" part of it) going
through the build process.  I needed to read almost all of the
Makefile.dvi to get a better understanding of the process and I am
sure I only got the tip of the iceberg.  Tim did a tremnedous job; it
was really helpful he put all those details in there.
Still we should not need to read all of the Makefiles before getting a
good, high level idea of what is going on.

\start
Date: Tue, 09 May 2006 14:34:34 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: Axiom error in issue 289TroubleWithEscapesOrMap

Bill,

Can you look at the following issue (it seems that there is a strange
bug in IssueTracker):

http://wiki.axiom-developer.org/289TroubleWithEscapesOrMap

\start
Date: 09 May 2006 14:52:35 +0200
From: Martin Rubey
To: Gregory Vanuxem
Subject: Re: Axiom error in issue 289TroubleWithEscapesOrMap

Vanuxem Gr=E9gory Gregory Vanuxem writes:

> Bill,
>
> Can you look at the following issue (it seems that there is a strange
> bug in IssueTracker):

the bug is not in IssueTracker, but in MathAction itself. Note that the Iss=
ue
is classified as a MathAction bug...

Martin

> http://wiki.axiom-developer.org/289TroubleWithEscapesOrMap

\start
Date: 09 May 2006 16:10:27 +0200
From: Francois Maltey
To: Cliff Yapp
Subject: Re: Emacs mode in Windows

Hello, 

> Anyway, for those who absolutely can't wait to have something better
> than the dos window, this might help.  I don't know how to "special
> case" Windows cleanly in Emacs yet, so this version is a one-off from
> the sandbox pamphlet for now.  I loaded it by opening the file in
> Emacs, doing the byte-compile-and-load menu option, switching to
> scratch, and then typing M-x axiom-mode.  Something cleaner is probably
> possible but that's how I normally test this so I haven't figured out
> the clean way yet.

Is someone try to run axiomacs.el in windows ?
I only use it with linux. 
I don't know if emacs functions start-process and set-process-filter 
are possible in windows.

Axiomacs.el does the exchanges between emacs and axiom with *.input files. 

So I can use multi-lines blocs command, as in an *.imput file, 
and at the end I can save interpreter sessions.

There is an old version on wiki.axiom-developer.org, 
and I can send my current version if someone wants it.

\start
Date: Tue, 09 May 2006 17:32:20 +0200
From: Gregory Vanuxem
To: Martin Rubey
Subject: Re: Axiom error in issue 289TroubleWithEscapesOrMap

Hi,

Le mardi 09 mai 2006 =E0 14:52 +0200, Martin Rubey a =E9crit :
> Vanuxem Gr=E9gory Gregory Vanuxem writes:
>
> > Bill,
> >
> > Can you look at the following issue (it seems that there is a strange
> > bug in IssueTracker):
>
> the bug is not in IssueTracker, but in MathAction itself. Note that the=
 Issue
> is classified as a MathAction bug...
>
> Martin
> 
> > http://wiki.axiom-developer.org/289TroubleWithEscapesOrMap
>

About the bug #289, what is the error ? What is the expected result ?

On the lastest Axiom I found 3, and on older version I have to use the
')set func comp on' to find 3 again.

\start
Date: Tue, 09 May 2006 17:35:39 +0200
From: Gregory Vanuxem
To: Martin Rubey
Subject: Re: Axiom error in issue 289TroubleWithEscapesOrMap

Hi,

Le mardi 09 mai 2006 =E0 17:32 +0200, Vanuxem Gr=E9gory a =E9crit :
> Hi,
>
> Le mardi 09 mai 2006 =E0 14:52 +0200, Martin Rubey a =E9crit :
> > Vanuxem Gr=E9gory Gregory Vanuxem writes:
> >
> > > Bill,
> > >
> > > Can you look at the following issue (it seems that there is a stran=
ge
> > > bug in IssueTracker):
> >
> > the bug is not in IssueTracker, but in MathAction itself. Note that t=
he Issue
> > is classified as a MathAction bug...
> >
> > Martin
> > 
> > > http://wiki.axiom-developer.org/289TroubleWithEscapesOrMap
> >
>
> About the bug #289, what is the error ? What is the expected result ?
>
> On the lastest Axiom I found 3, and on older version I have to use the
> ')set func comp on' to find 3 again.

And I forgot what is the new command (replacing map(...) by [...]) to
work around this issue ?

\start
Date: Tue, 9 May 2006 10:51:01 -0700 (PDT)
From: Cliff Yapp
To: Francois Maltey
Subject: Re: Emacs mode in Windows

--- Francois Maltey wrote:

> Hello, 
> 
> > Anyway, for those who absolutely can't wait to have something
> > better than the dos window, this might help.  I don't know how
> > to "special case" Windows cleanly in Emacs yet, so this version
> > is a one-off from the sandbox pamphlet for now.  I loaded it by
> > opening the file in Emacs, doing the byte-compile-and-load menu
> > option, switching to scratch, and then typing M-x axiom-mode.
> > Something cleaner is probably possible but that's how I normally
> > test this so I haven't figured out the clean way yet.
> 
> Is someone try to run axiomacs.el in windows ?

I didn't think to test it while I had access to the Windows box.  If I
get another crack at it I can try - is there anybody here who has a
Windows box and is interested in Emacs+Windows?

I'm writing a new Emacs mode in which I'm trying to a) incorporate all
the features I might want b) add all the features needed to make it a
robust user environment for Axiom and c) do it in the "literate
program" style.  It's loosly based off of an earlier such effort by Jay
called EMaxima.  It was that file I was talking about with regards to a
Windows test, but it would certainly be worth checking yours too.

> I only use it with linux. 
> I don't know if emacs functions start-process and set-process-filter 
> are possible in windows.

Well, as of a couple weeks ago the mode I was working functioned using
comint.  I don't know about specific functions but the ones I used
seemed to work.  I have made updates since then so I don't know what
the Windows support status is right now.

> Axiomacs.el does the exchanges between emacs and axiom with *.input
> files. 
> 
> So I can use multi-lines blocs command, as in an *.imput file, 
> and at the end I can save interpreter sessions.

By the latter do you mean something like:

(1) -> integrate(x^2+x^3+x^4+
x^5+x^6, x)

If there is a desire for this I might be able to devise a way to do it
inside Emacs as well.  Maybe counting carriage returns and searching
forward that number of returns - 1 and then a last one to find the
end... Hmm...  Would need to rebind the return key to its original
purpose and use \C-[return] for axiom-eval...

> There is an old version on wiki.axiom-developer.org, 
> and I can send my current version if someone wants it.

Maybe you could update the one on the Wiki?  That would be quite
interesting.

Francois, if you get a chance could you try out my attempt at an Emacs
mode and see what you think?  I expect it doesn't have all the features
yours does but I'm trying to gradually build it up.

\start
Date: Tue, 09 May 2006 21:48:03 +0200
From: Ralf Hemmecke
To: list
Subject: Ann: ALLPROSE 0.2.0

Dear Aldor friends,

I'd like to announce version 0.2.0 of ALLPROSE.
(Aldor Literate Programming Support Environemnt)
http://www.hemmecke.de/aldor

ALLPROSE is intended for people who want to write libraries in Aldor and
don't want to bother about setting up the Makefiles and dependencies of
their categories and domains.

In addition to supporting the literate programming style for Aldor,
ALLPROSE also proposes a simple way of documenting the API of
dategories/domains/packages, ie, ALLPROSE suggests certain conventions
of how +++ documention should be structured.

Further features of ALLPROSE can be found in Section 5 of its documentation.

ALLPROSE is distributed under the GNU General Public License Version 2.

I hope that some people might find ALLPROSE useful.

What are the main new features in version 0.2.0?

* ALLPROSE can produce not only pdf, dvi, and ps versions of the 
documentation but also html.

* Better support to produce stand-alone executables.

* More support for the "extend" keyword.

To the Axiom developers...
ALLPROSE is not yet integrated with Axiom, but I hope I get some 
feedback so that I would know what people want.

\start
Date: Tue, 09 May 2006 16:37:42 -0400
From: Norman Ramsey
To: Ralf Hemmecke
Subject: re: noweb 

 > Unfortunately, the website http://www.eecs.harvard.edu/~nr/noweb/ is not
 > very explicit about pointing to a nice documentation that describes the
 > semantics of all the various situations where << and >> can appear
 > (non-escaped) in a simple and understandable manner. 

The definitive answer to such questions should be found on the man
page under FORMAT OF NOWEB FILES.  The man page for versions before
2.11a is definitely faulty.

I'm afraid you can have 'simple and understandable' or you can have 'precise'.
You can't have both.  The man page represents the usual muddled
compromise that provides neither.

\start
Date: Tue, 09 May 2006 21:24:36 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: noweb
Cc: Norman Ramsey

Hi Bill,

... noweb modifications ...

> The bottom line here is that I agree with Norman that
> modifying noweb's behavior is not the correct solution
> and that if anything it should be more exact and strict.

Actually, I did not say that I want to modify noweb in any way.
To me it was only not clear enough how noweb should behave in such
situations.

Unfortunately, the website http://www.eecs.harvard.edu/~nr/noweb/ is not
very explicit about pointing to a nice documentation that describes the
semantics of all the various situations where << and >> can appear
(non-escaped) in a simple and understandable manner. (At least such a
link is not very obvious to me.) I would have to get the noweb sources
http://www.eecs.harvard.edu/~nr/noweb/dist/ and figure out which of the
many files I have to weave in order to find the right documentation. :-(

In fact, that documentation situation is very much like in Axiom. All
files are literate programs, but it is hard to find a rough overview of
the building process, for example.

I hope an extended ALLPROSE (http://www.hemmecke.de/aldor/) will some
day remedy this situation. I'm not yet there, but I am working on it.

\start
Date: Tue, 09 May 2006 17:52:17 +0200
From: Gregory Vanuxem
To: Martin Rubey
Subject: Re: Axiom error in issue 289TroubleWithEscapesOrMap

Le mardi 09 mai 2006 =E0 14:52 +0200, Martin Rubey a =E9crit :
> Vanuxem Gr=E9gory Gregory Vanuxem writes:
>
> > Bill,
> >
> > Can you look at the following issue (it seems that there is a strange
> > bug in IssueTracker):
>
> the bug is not in IssueTracker, but in MathAction itself. Note that the=
 Issue
> is classified as a MathAction bug...

In fact I have found why there is this error on MathAction. It's because
your sequence of commands crashes Axiom. Adding a ')set func comp on'
resolves this issue.

> > http://wiki.axiom-developer.org/289TroubleWithEscapesOrMap

\start
Date: Tue, 9 May 2006 17:42:10 -0400
From: Bill Page
To: Gregory Vanuxem, Martin Rubey
Subject: RE: Axiom error in issue

Greg and Martin,

On Tuesday, May 09, 2006 8:35 AM Vanuxem Gr=E9gory wrote:
>
> Can you look at the following issue (it seems that there is a
> strange bug in IssueTracker):
>
> http://wiki.axiom-developer.org/289TroubleWithEscapesOrMap
>

I agree that the previous behaviour of this page seems to be a
strange bug in the way the page is rendered by MathAction. I
still do not understand it. For example if I change the word
'reduce' to reduce1' the display problem goes away (but of
course the code does not work).

and on Tuesday, May 09, 2006 11:53 AM greg added:
>
>  \begin{axiom}
> ++added:
> +)set func comp on

Good work!

Now it seems even more odd to me that just setting
')set function compile on' also makes the problem go away
and more over the code works. This option is still needed
on Axiom Wiki because the version of Axiom we are using has
not been updated to include the recent bug fix.

I guess that there must be something output by Axiom when the
function is not compiled (and therefore fails) that confuses
the MathAction Axiom output parser - maybe even the lack of
output.

Although this works with the compile option set, I think we
should keep this issue report open because it indicates a
weakness in MathAction that is hard to diagnose.

\start
Date: Tue, 9 May 2006 18:43:05 -0400
From: Bill Page
To: list
Subject: noweb vs. leo
Cc: Norman Ramsey

On Tuesday, May 09, 2006 4:38 PM Norman Ramsey wrote:
> ...
> I'm afraid you can have 'simple and understandable' or
> you can have 'precise'. You can't have both.  The man
> page represents the usual muddled compromise that provides
> neither.
>

I don't mean for the following commments to be interpreted
as critical but the above statement from someone who has
devoted a lot of effort to literate programming concerns me
greatly. Perhaps even, this illustrates the one major "fatal
flaw" in the whole concept of literate programming and the
reason that this methodology is not in wide use so many years
after it's invention:

Writing *good* documentation is still hard work - harder
even than the programming itself - and the first generation
of literate programming tools (of which noweb is a prime
example) seem to do nothing at all to make this easier.

And as Ralf pointed out recently that we have a similar
situation right now in the Axiom literate program source
files - the information might be there (e.g. in the
makefile.pamphlet) but it is not very accessible because
it lacks a simple and easily understood overview.

Ralf's ALLPROSE (Aldor Literate Programming Support
Environemnt) http://www.hemmecke.de/aldor tool is intended
to be "a framework for building Aldor libraries and their
documentation". Clearly this framework could be extended for
use with the Axiom library with it's 1,300 tightly inter-
elated algebra files. But I am concerned that it does not
address the underlying problem of writing really good and
easily accessible documentation.

The only literate programming tool that I am aware of that
does attempt to address this problem - at least in some
limited degree - is Leo. Where relevant I have tried to
quote directly from the Leo documentation below but I don't
want this to sound like an advertisement. In addition to
integrating source code and documentation in the same manner
as other literate programming tools, Leo also provides:

1) an outlining (folding) text editor and browser that allows
the source code, documentation and project details to be
presented in the context of a full outline (overview) of the
system.

"The outline pane shows your project as an outline. The outline
contains all your project's data. An outline consists of nodes.
Nodes have two parts, a headline and body text. The outline
pane shows headlines. Selecting a headline selects the entire
node; the node's body text appears in the body pane. The icon
box is a small icon directly to the left of the headline text.
If a node contains children, a smaller icon appears to the left
of the icon box. This icon contains a + or - symbol. Clicking
this expansion box expands or contracts the node."

2) A project manager that provides multiple views of project
tasks within a the same outline. Leo's outline is not limited
to being strictly hierachical because nodes can be "cloned".

"A cloned node is a copy of a node that changes when the original
changes. Changes to the children, grandchildren, etc. of a node
are simultaneously made to the corresponding nodes contained
in all cloned nodes."

"Clones allow multiple views of data to exist within a single
outline. The ability to create multiple views of data is crucial;
you don't have to try to decide what is the 'correct' view of
data. You can create as many views as you like, each tailored
exactly to the task at hand."

"For example, when I begin to fix a bug I first create a view
node to represent the bug. I then create a component node (not
cloned) that contains the original bug report. I may also create
other non-cloned nodes to contain notes and documentation. Next,
I go looking throughout Leo's code for nodes that relate in some
way to the bug. When I find such a node I clone it and move one
of the clones so it becomes a component of the view node for the
bug. Note: I can organize the components of the view node as I
please. In particular, I can create organizer nodes whose only
purpose is to contain groups of component nodes. In other words,
the full power of Leo outlines is available within view nodes."

I think this is very similar to what Tim Daly has written
about the need to view large complex literate programs like
Axiom from the point of view of a "crystal" with multiple
facets.

Although Leo's documentation is quite good:

http://webpages.charter.net/edreamleo/front.html

the trouble with Leo is that organizing a project to take best
advantage of all this involves some considerable effort. I am
continuing to try to work up the energy to tackle Axiom with
this tool.

\start
Date: Tue, 09 May 2006 19:35:28 -0400
From: Norman Ramsey
To: Bill Page
Subject: Re: noweb vs. leo 

 > On Tuesday, May 09, 2006 4:38 PM Norman Ramsey wrote:
 > > ... 
 > > I'm afraid you can have 'simple and understandable' or
 > > you can have 'precise'. You can't have both.  The man
 > > page represents the usual muddled compromise that provides
 > > neither.
 > 
 > I don't mean for the following commments to be interpreted
 > as critical but the above statement from someone who has
 > devoted a lot of effort to literate programming concerns me
 > greatly. Perhaps even, this illustrates the one major "fatal
 > flaw" in the whole concept of literate programming...

I wish now I'd made it clear that this statement is not intended to
cover all documentation for all programs but rather the narrow issue
of noweb's lexical analysis.  The fact is that a great deal of
complexity was introduced into the algorithm in order to enable a
great many common cases to work without requiring users to think about
noweb's markup, and while still enabling noweb to issue error messages
on inputs that are likely to be in error.  It is the complexity of the
algorithm itself that makes 'simple and understandable' incompatible
with 'precise'.  And the complexity of the algorithm in turn arises
from the complexity of the problem, namely to provide human-editable
markup that will serve the common cases well while still making it
possible to express any input.


 > The reason that this methodology is not in wide use so many years
 > after its invention:
 > 
 > Writing *good* documentation is still hard work - harder
 > even than the programming itself - and the first generation
 > of literate programming tools (of which noweb is a prime
 > example) seem to do nothing at all to make this easier.

I have said for years that if you want better documentation, don't
look to your tools---look to your *process*.  The good news is that
almost any kind kind of process will work: you just need multiple eyes
to review the documents, and you need accountability to be sure that
revisions are done and checked in.  It may well be that tools can help
with this, but they will be the same kinds of tools that are used to
support many other sorts of 'computer-supported cooperative work'.

 > And as Ralf pointed out recently that we have a similar
 > situation right now in the Axiom literate program source
 > files - the information might be there (e.g. in the
 > makefile.pamphlet) but it is not very accessible because
 > it lacks a simple and easily understood overview.

Always the first thing to go wrong with any large literate program. 
The effort involved in providing such overviews---and keeping them up
to date---is *enormous*.

 > The only literate programming tool that I am aware of that
 > does attempt to address this problem - at least in some
 > limited degree - is Leo [with its outlining facility].

We have found that for a moderately large project (say over 10,000
lines of code) an outline (or even a set of outlines) is not enough.
We rely heavily on a LaTeX table of contents (our best analog to a Leo
outline), but we also rely on diagrams and overview chapters.
This is all very expensive in time and effort, and I would say that in
my research group we seem to be able to afford this effort only
roughly every 5 to 10 years.  Of course we are a very small shop; your
mileage may vary.

 > I think this is very similar to what Tim Daly has written
 > about the need to view large complex literate programs like
 > Axiom from the point of view of a "crystal" with multiple
 > facets.

Also quite interesting.  And expensive, as every facet must be polished.

 > Organizing a project to take best advantage of all this involves
 > some considerable effort. I am continuing to try to work up the
 > energy to tackle Axiom with this tool.

Too true, and good luck :-)


Discussions of these sorts of questions used to enliven
comp.programming.literate.  May I have your permission to post this mail?

\start
Date: Tue, 9 May 2006 20:14:56 -0400
From: Bill Page
To: Norman Ramsey
Subject: RE: noweb vs. leo 

On Tuesday, May 09, 2006 7:35 PM Norman Ramsey wrote:
> ...
> We have found that for a moderately large project (say over
> 10,000 lines of code) an outline (or even a set of outlines) is
> not enough. We rely heavily on a LaTeX table of contents (our
> best analog to a Leo outline), but we also rely on diagrams and
> overview chapters. This is all very expensive in time and effort,
> and I would say that in my research group we seem to be able to
> afford this effort only roughly every 5 to 10 years.  Of course
> we are a very small shop; your mileage may vary.
>

Thanks for your comments and sharing your experience. Tim Daly
often mentions a "30 year" horizon for Axiom which perhaps puts
such an effort within reach for at least some current Axiom
developers but I fear that our available (volunteer) resources
are probably less than yours and our problem is larger than just
10,000 lines of code. :(

>  > I think this is very similar to what Tim Daly has written
>  > about the need to view large complex literate programs like
>  > Axiom from the point of view of a "crystal" with multiple
>  > facets.
>
> Also quite interesting.  And expensive, as every facet must
> be polished.
>

Apparently true, but as the song says (Edwin Starr):

 "There's got to be a better way ..." :)

>  > Organizing a project to take best advantage of all this [Leo]
>  > involves some considerable effort. I am continuing to try to
>  > work up the energy to tackle Axiom with this tool.
>
> Too true, and good luck :-)
>
>
> Discussions of these sorts of questions used to enliven
> comp.programming.literate.  May I have your permission to
> post this mail?
>

Certainly. I guess I should visit some time.

\start
Date: Tue, 9 May 2006 20:56:18 -0400
From: Tim Daly
To: Norman Ramsey
Subject: Re: noweb vs. leo

>We have found that for a moderately large project (say over 10,000
>lines of code) an outline (or even a set of outlines) is not enough.
>We rely heavily on a LaTeX table of contents (our best analog to a Leo
>outline), but we also rely on diagrams and overview chapters.
>This is all very expensive in time and effort, and I would say that in
>my research group we seem to be able to afford this effort only
>roughly every 5 to 10 years.  Of course we are a very small shop; your
>mileage may vary.

The axiom sources will eventually be available as a series of books.
There are 10 volumes planned so far. Volume 1, the tutorial exists.
Volume 5, the interpreter is being written now and is likely to be
the next volume available.

I don't expect that the books will actually be printed. The last time
I printed all of the axiom sources (double sided) comprising only the
naked source code it filled approximately 6 feet of linear shelf space.
The literate version will likely double that, at minimum. The algebra
volume alone will take up many linear feet if we succeed in the goal
of joining the source code with the research papers.

Of course these books are the actual source code of the system and
will dynamically change over time. We will need overview volumes
and a volume that is nothing but index and annotated bibliography.
I suspect other 'meta-volumes' will come into play.

In the grand scheme of things I see this set of volumes as the
kernel of a computational mathematics literature, joining the research
work with the actual algorithms and organized by subject matter.
Ordinary textbooks like Bronstein's Symbolic Integration will be
able to reference or include sections of the real algorithms that
are already documented and working.

At the moment the literate programs are just a collection of .dvi
files organized in parallel with the source tree, created during
system build time. We need to invent the machinery, analysis programs,
markup, indexing, and organization programs to create a useful,
searchable, browsable library.

I've given a little thought to the subject and experimented with
various methods. One approach you might find interesting is the
"booklet" idea. It's a natural extension of the noweb machinery.
All we do is give a syntax and semantics to the chunk names. If
the chunk name parses to a valid URL we fetch and include the URL:

<<any chunk name>>=      standard chunk replace
<<file:///tmp/foo.nw>>=  file /tmp/foo included in place
<<ftp://a.b/tmp.nw>>=    ftp fetch of the file

etc. We have a "booklet" program as part of the source tree
and I've used it to build a working example but have not had the
time to exploit the direction.

Books may or may not be the best form for the source code.
Bill Page has experimented with putting the literate sources
up as wiki-editable web pages, obviating the need for CVS.
This enables technologies like hyperlinking, animated flash,
"tutorial movies", online lectures, and dynamic source graphs.

The Doyen effort (daly.axiom-developer.org/doyen) will allow
research papers containing source to be drag-and-dropped onto
a running Axiom and dynamically added.

All of this is a research experiment as far as I'm concerned.
I do not have a clear idea of how to organize a huge pile of
software to make it into a living document and a coherent whole.
Like all research tasks, the shape changes and improves as we
struggle with the issues that arise.

\start
Date: 10 May 2006 03:02:08 +0200
From: Gabriel Dos Reis
To: Norman Ramsey
Subject: re: noweb vs. leo

Norman Ramsey writes:

| I have said for years that if you want better documentation, don't
| look to your tools---look to your *process*.  The good news is that
| almost any kind kind of process will work: you just need multiple eyes
| to review the documents, and you need accountability to be sure that
| revisions are done and checked in.  It may well be that tools can help
| with this, but they will be the same kinds of tools that are used to
| support many other sorts of 'computer-supported cooperative work'.

Amen.

\start
Date: Tue, 9 May 2006 23:06:42 -0400
From: Bill Page
To: Cliff Yapp, Francois Maltey
Subject: RE: Emacs mode in Windows

On Tuesday, May 09, 2006 1:51 PM C Y
> Francois Maltey wrote:
>
> > Axiomacs.el does the exchanges between emacs and axiom with
> > *.input files.
> >
> > So I can use multi-lines blocs command, as in an *.imput
> > file, and at the end I can save interpreter sessions.
>
> By the latter do you mean something like:
>
> (1) -> integrate(x^2+x^3+x^4+
> x^5+x^6, x)
>

No, I don't think that is what Francois means.

In Axiom the syntax accepted during interactive input at a
command prompt, e.g.

(1) -> for i in 1..3 repeat (i:=i+1; output i)

must consist of a single line or use line continuations
that look like this:

(1) -> for i in 1..3 repeat (_
         i:=i+1;_
         output i_
)

and are treated as if it was one long line. Note that
commands must be grouped by parenthesis.

Perhaps what you are thinking of, Cliff, is just to avoid
having to type the _ character to continue a line? But
Francios specifically mentioned *.input files.

The syntax for interactive input is different from the
syntax nomrally used in *.input files that are read into
Axiom like this:

  (1) -> )read xxx.input

The *.input file normally uses "pile" format instead of
parenthesis to group commands and looks similar to *.spad
files. For example the file xxx.input might contain:

  for i in 1..3 repeat
      i:=i+1
      output i

--------

The syntax of *.input files is also used on MathAction
between:

\begin{axiom}
...
\end{axiom}

When interacting with emacs I expect it would normally be
most convenient for Axiom users to be able to type the
*.input syntax in a emacs command buffer. Emacs would send
the contents of the buffer to Axiom by first writing this
buffer to a temporary file (say temp1.input) and then asking
Axiom to execute it by sending the command:

  )read temp1.input

instead of sending the contents of the buffer directly to
Axiom.

\start
Date: 10 May 2006 13:47:54 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Axiom wishlist (was re: noweb vs. leo)

Tim Daly writes:

| >We have found that for a moderately large project (say over 10,000
| >lines of code) an outline (or even a set of outlines) is not enough.
| >We rely heavily on a LaTeX table of contents (our best analog to a Leo
| >outline), but we also rely on diagrams and overview chapters.
| >This is all very expensive in time and effort, and I would say that in
| >my research group we seem to be able to afford this effort only
| >roughly every 5 to 10 years.  Of course we are a very small shop; your
| >mileage may vary.
| 
| The axiom sources will eventually be available as a series of books.
| There are 10 volumes planned so far. Volume 1, the tutorial exists.
| Volume 5, the interpreter is being written now and is likely to be
| the next volume available.
| 
| I don't expect that the books will actually be printed. The last time
| I printed all of the axiom sources (double sided) comprising only the
| naked source code it filled approximately 6 feet of linear shelf space.
| The literate version will likely double that, at minimum. The algebra
| volume alone will take up many linear feet if we succeed in the goal
| of joining the source code with the research papers.
| 
| Of course these books are the actual source code of the system and
| will dynamically change over time. We will need overview volumes
| and a volume that is nothing but index and annotated bibliography.
| I suspect other 'meta-volumes' will come into play.

Tim --

   Have you listed those projects somewhere on Axiom's website?

\start
Date: Wed, 10 May 2006 06:26:21 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Francois Maltey
Subject: RE: Emacs mode in Windows

--- Bill Page wrote:

> In Axiom the syntax accepted during interactive input at a
> command prompt, e.g.
> 
> (1) -> for i in 1..3 repeat (i:=i+1; output i)
> 
> must consist of a single line or use line continuations
> that look like this:
> 
> (1) -> for i in 1..3 repeat (_
>          i:=i+1;_
>          output i_
> )
> 
> and are treated as if it was one long line. Note that
> commands must be grouped by parenthesis.

OK.
 
> Perhaps what you are thinking of, Cliff, is just to avoid
> having to type the _ character to continue a line? But
> Francios specifically mentioned *.input files.

Well, I guess my mind jumped to the _ character issue because it is
sometimes advantageous to type things as multiple lines (large
matricies in particular can be clearer this way.)

> The syntax for interactive input is different from the
> syntax nomrally used in *.input files that are read into
> Axiom like this:
> 
>   (1) -> )read xxx.input
> 
> The *.input file normally uses "pile" format instead of
> parenthesis to group commands and looks similar to *.spad
> files. For example the file xxx.input might contain:
> 
>   for i in 1..3 repeat
>       i:=i+1
>       output i
> 
> --------

OK, so it's not something you would input into the regular command
line.

> The syntax of *.input files is also used on MathAction
> between:
> 
> \begin{axiom}
> ...
> \end{axiom}
> 
> When interacting with emacs I expect it would normally be
> most convenient for Axiom users to be able to type the
> *.input syntax in a emacs command buffer. Emacs would send
> the contents of the buffer to Axiom by first writing this
> buffer to a temporary file (say temp1.input) and then asking
> Axiom to execute it by sending the command:
>
>   )read temp1.input
> 
> instead of sending the contents of the buffer directly to
> Axiom.

OK...  This should be possible, but it sounds like this is a little
different from what I'm doing currently.  You don't want to support a
different syntax on the command line, but type *.input syntax in a
buffer and load it into a running emacs session.  I think the "right"
way to do that would be to introduce a separate axiom-input-mode that
intelligently handles that issue.  I'll have to give it some thought,
but it's a good idea.

\start
Date: Wed, 10 May 2006 10:13:25 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Movie upload

On Wednesday, May 10, 2006 9:30 AM C Y wrote:
>
> Hey Bill.  I made a video of Axiom in Emacs - nothing special
> and no sound (I don't have a microphone) but I was wondering
> if you could help me upload it.

Great. Uploading is simple.

> I created a link on the screencast page but it seems you
> need a login to actually upload the movies?
>

You should *not* create the link first.

Uploading a file is done on the 'edit' screen. To get to the
edit screen you have to specify your user id and email address
in the 'preferences' menu.

See Upload near the bottom of the edit page. Click on 'Browse',
choose you file, click 'Open', add an explanatory note, click
'Save' and the file is upload *and* and link it made near the
bottom of the page. The link that is created will not have
exactly the same syntax as those already present on this page.

If you want to change the location of the link and the
associated text, click 'edit' again and cut-and-paste the
link where you want it and add the text.


> Anyway, I've attached the files in question.  Any help
> appreciated - sorry if this should be obvious to me :-/.
>

I'll do it this time ... but next time it's up to you. ;)

\start
Date: Wed, 10 May 2006 07:39:20 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Movie upload

--- Bill Page wrote:
 
> > I created a link on the screencast page but it seems you
> > need a login to actually upload the movies?
> >
> 
> You should *not* create the link first.
> 
> Uploading a file is done on the 'edit' screen. To get to the
> edit screen you have to specify your user id and email address
> in the 'preferences' menu.

OK, check.
 
> See Upload near the bottom of the edit page. Click on 'Browse',
> choose you file, click 'Open', add an explanatory note, click
> 'Save' and the file is upload *and* and link it made near the
> bottom of the page. The link that is created will not have
> exactly the same syntax as those already present on this page.

Ah!

> If you want to change the location of the link and the
> associated text, click 'edit' again and cut-and-paste the
> link where you want it and add the text.

OK, makes sense.  There are actually two files - the html page and the
swf file itself - do I upload those one after the other?

I can see the html page, but it looks like my cruddy flash plugin
dropped the ball again for viewing.  Can y'all see it?

> > Anyway, I've attached the files in question.  Any help
> > appreciated - sorry if this should be obvious to me :-/.
> > 
> 
> I'll do it this time ... but next time it's up to you. ;)

Just didn't want to destroy the wiki :-P.  Wonder if I should get a
microphone.  Never tried that in Linux before...

BTY, was anybody else going to make a demo movie of Axiom's graphing
capabilities?  

\start
Date: Wed, 10 May 2006 10:58:32 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Movie upload

Cliff,

Thanks for creating this screencast. I hope you inspire more
people to submit similar things. We need a lot more than my
original "pitiful" efforts...

On Wednesday, May 10, 2006 10:39 AM you asked:
> ...
> > If you want to change the location of the link and the
> > associated text, click 'edit' again and cut-and-paste the
> > link where you want it and add the text.
>
> OK, makes sense.  There are actually two files - the html page
> and the swf file itself - do I upload those one after the other?

Yes. But I think you should use a more specific src="..." file
name than just "out.swf". I changed the name of the file to
'axiomemacsout.swf' and the HTML code to correspond:

  <embed src="axiomemacsout.swf" ...> ... </embed>

>
> I can see the html page, but it looks like my cruddy flash plugin
> dropped the ball again for viewing.  Can y'all see it?
>

Works for me. Maybe you tried it before I completed the upload
of the '.swf' file.


> > > Anyway, I've attached the files in question.  Any help
> > > appreciated - sorry if this should be obvious to me :-/.
> > >
> >
> > I'll do it this time ... but next time it's up to you. ;)
>
> Just didn't want to destroy the wiki :-P.

PLEASE use the wiki. DO NOT be afraid that you might "destroy"
it. Anything you can do through the standard user interface is
completely reversible if necessary.

> Wonder if I should get a microphone.  Never tried that in Linux
> before...

Yes, I think you should. If you are using newer version of linux
and shockwave apps then you should have no problems.

>
> BTY, was anybody else going to make a demo movie of Axiom's
> graphing capabilities? 
>

Go for it!

\start
Date: Wed, 10 May 2006 09:10:05 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Movie upload

--- Bill Page wrote:

> Cliff,
> 
> Thanks for creating this screencast. I hope you inspire more
> people to submit similar things. We need a lot more than my
> original "pitiful" efforts...

Hardly pitiful - quite the contrary, I'd say.  We just need to send you
a microphone ;-).  I'll chip in $5 to get Bill a mike - anybody else?
;-)

> On Wednesday, May 10, 2006 10:39 AM you asked:
> > ... 
> > > If you want to change the location of the link and the
> > > associated text, click 'edit' again and cut-and-paste the
> > > link where you want it and add the text.
> > 
> > OK, makes sense.  There are actually two files - the html page
> > and the swf file itself - do I upload those one after the other?
> 
> Yes. But I think you should use a more specific src="..." file
> name than just "out.swf". I changed the name of the file to 
> 'axiomemacsout.swf' and the HTML code to correspond:
> 
>   <embed src="axiomemacsout.swf" ...> ... </embed>

Opps.  Sorry about that - I forgot to rename it.  I had to do several
dry runs before I got something even close to reasonable, so I was
using a throwaway name.  I fixed the title but forgot to rename the swf
file.

> > I can see the html page, but it looks like my cruddy flash plugin
> > dropped the ball again for viewing.  Can y'all see it?
> > 
> 
> Works for me. Maybe you tried it before I completed the upload
> of the '.swf' file.

Nah, my flash plugin at work is rather messed up.  I've had similar
troubles before.

> > > I'll do it this time ... but next time it's up to you. ;)
> > 
> > Just didn't want to destroy the wiki :-P.
> 
> PLEASE use the wiki. DO NOT be afraid that you might "destroy"
> it. Anything you can do through the standard user interface is
> completely reversible if necessary.

Righto.
 
> > Wonder if I should get a microphone.  Never tried that in Linux
> > before...
> 
> Yes, I think you should. If you are using newer version of linux
> and shockwave apps then you should have no problems.

I'll have to take a look.  Just so I can find it later, this looks
useful...
http://www.daniel-lemire.com/blog/archives/2005/10/12/logitech-usb-desktop-microphone-under-linux/

> > BTY, was anybody else going to make a demo movie of Axiom's
> > graphing capabilities?  
> 
> Go for it!

OK, here we go...

\start
Date: Wed, 10 May 2006 12:31:40 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Emacs mode in Windows

On Wednesday, May 10, 2006 9:26 AM C Y wrote:
> ...
> Bill Page wrote:
> >
> > When interacting with emacs I expect it would normally be
> > most convenient for Axiom users to be able to type the
> > *.input syntax in a emacs command buffer. Emacs would send
> > the contents of the buffer to Axiom by first writing this
> > buffer to a temporary file (say temp1.input) and then asking
> > Axiom to execute it by sending the command:
> >
> >   )read temp1.input
> >
> > instead of sending the contents of the buffer directly to
> > Axiom.
>
> OK...  This should be possible, but it sounds like this is a
> little different from what I'm doing currently.  You don't want
> to support a different syntax on the command line, but type
> *.input syntax in a buffer and load it into a running emacs
> session.

Yes. To do that now with Axiom one might use the commands:

  )edit xxx.input
  )read xxx.input

and alternate between these two commands while you test
some new code. Alternatively you might do:

  )edit xxx.as
  )compile xxx.as

if you are writing a library routine in Aldor (or .spad if
you are writing SPAD cod).

> I think the "right" way to do that would be to introduce a
> separate axiom-input-mode that intelligently handles that
> issue. I'll have to give it some thought, but it's a good
> idea.
>

>From what Francois said in his earlier message, that is what
the 'axiomacs.el' mode does now for Axiom '.input' format.

If you are going to have different input modes, then I
think it makes most sense to associate this with the
type of input, e.g. '.input' format '.as' (Aldor) format,
and '.spad' (SPAD) format. This determines things like
how to do the syntax highlighting. Then when you 'execute'
in each of these modes it tells you what command to generate
in Axiom, e.g. ')read' or ')compile'.

Really, if you support these different modes then there is
really no need (usually) to have direct access to the Axiom
command line. E.g. we never interact directly with the command
line on MathAction.

\start
Date: Wed, 10 May 2006 13:02:49 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Emacs mode in Windows

On Wednesday, May 10, 2006 12:32 PM I wrote:
> ...
> To do that now with Axiom one might use the commands:
>
>   )edit xxx.input
>   )read xxx.input
>
> and alternate between these two commands while you test
> some new code. Alternatively you might do:
>
>   )edit xxx.as
>   )compile xxx.as
>
> if you are writing a library routine in Aldor (or .spad if
> you are writing SPAD cod).
> ...

Just so it is clear what I mean: I think of the emacs buffer
as replacing the use of the ')edit' command and that the
')read' or ')compile' command would be generated internally
by the 'execute' command.

\start
Date: Thu, 11 May 2006 00:30:51 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: noweb vs. leo
Cc: Norman Ramsey

Hi Bill,

> Ralf's ALLPROSE (Aldor Literate Programming Support
> Environemnt) http://www.hemmecke.de/aldor tool is intended
> to be "a framework for building Aldor libraries and their
> documentation". Clearly this framework could be extended for
> use with the Axiom library with it's 1,300 tightly inter-
> elated algebra files. But I am concerned that it does not
> address the underlying problem of writing really good and
> easily accessible documentation.

How can a framework "enforce" good documentation? But you won't believe, 
I thought a bit about it. For example, you won't get all the nice 
hyperlinking if you don't follow some rules/conventions. And if a file 
is not mentioned in a \sourcefile{...} command, you don't even see the 
documentation of the file at all, but rather you get a section that 
tells you about "undocumented files". Of course, I cannot "enforce" any 
good documentation, but at least there is some penalty if you don't 
follow the rules.

The actual bad thing is that people are so spoiled by quickly hacking in 
code and making things run that they (yes sometimes also me) forget 
about the long term future.

> The only literate programming tool that I am aware of that
> does attempt to address this problem - at least in some
> limited degree - is Leo.

I've recently looked at LEO. I tend to like the idea of different views 
(or different facets of the crystal, as Tim would say). But I also had 
the impression that LEO does not enforce literate programming. It just 
supports it, as far as I can say. Still, LEO might help Axiom in getting 
  its code organised. The problem actually is that people would have to 
get used to this kind of software. So I am, in fact, not too 
over-optimistic.

And there is still some point I don't quite see clearly. LEO allows to 
"clone" documentation so that it could be used in another view. My 
question would be who actually defines what and "atomic documentation 
piece" is? What happens if some documentation changes that is used 
somewhere else? There are lots of questions... and almost no time :-(

\start
Date: Thu, 11 May 2006 07:04:09 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, list
Subject: endpaper3

Hey Bill.  Just wanted to let you know I got a cvs version of graphviz
on my computer at home and was able to successfully (I think
successfully, at least) generate the endpaper3 document.  Just to
confirm I did this right, is it:

1.  run latex once to get the .dot files
2.  run dot -Tps on the generated dot files to get ps files
3.  run latex again once or twice on the tex file to get a dvi file
4.  use dvipdf to get a hyperlinked pdf

I hope we can get some autogenerated graphs like this into the pamphlet
files later one - I'm very impressed with the results.

\start
Date: Thu, 11 May 2006 07:53:51 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Emacs + input syntax

A couple of quick questions, so I know what I'm up against:

1.  I don't suppose the use of the _ character to indicate a new line
is unique to input syntax?  If not, would it be OK to make it so in
Emacs if I can make multi-line input without it in "normal" input mode?

2.  If the answer to both questions in #1 is no and I can't assume the
_ character is unique, is there any reliable way to detect when someone
is inputing input syntax rather than the normal user level input?

3.  If the answer to #2 is no, how should I know when to do the input
syntax eval instead of the normal eval?  I could define a different key
combination but if the user forgot to use it it might generate a bit of
a mess.

I've been looking at mmm-mode for other reasons, not the least of which
is the eventual need to handle literate documents, but I think I'm
going to need it sooner than that so I might have to take time out to
figure out how to use it, customize it, and integrate it.  It looks
like the most robust way to handle this might be to use an mmm-mode on
a per-input style level and figure out invisible text, which is all
right in a way because even in termainal mode I have other ideas for
mmm-mode and will need to come to terms with it.

If I need to do that, I'm going to have to take time out for a
re-organization and refactoring of the code.  I've got some tricks in
there now for dealing with things like flagging mismatched IO pairs,
but incorporating mmm-mode could result in massive changes all across
the board.

So here's the last question - is anybody using this mode now, or to be
more specific is anybody using it enough to warrant me squashing the
one or two easily fixed bugs before I rip the guts out?  If not I'll
just go ahead and ram heads with mmm-mode, but that will mean no
updates on the current mode for an unforseeable amount of time.

\start
Date: Thu, 11 May 2006 17:39:28 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Emacs + input syntax

Hi Cliff,

To be honest, I don't quite understand all your questions.
I don't know how useful it is to put _ always at the end of a line.
What about using Shift-Enter as in Maple? (What was it in Mma?)

The _ character is special. Think about producing a string that consists 
of a single ". You do this by writing

"_""

As for mmm-mode, I *use* it and I also suggest it for ALLPROSE. It works 
quite nicely for me and is for my taste better than noweb-mode. However, 
I cannot help you if you need to go into the code itself.

\start
Date: Thu, 11 May 2006 12:02:55 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: endpaper3

On Thursday, May 11, 2006 10:04 AM C Y wrote:
>
> Hey Bill.  Just wanted to let you know I got a cvs version of
> graphviz on my computer at home and was able to successfully
> (I think successfully, at least) generate the endpaper3 document.
> Just to confirm I did this right, is it:
>
> 1.  run latex once to get the .dot files
> 2.  run dot -Tps on the generated dot files to get ps files
> 3.  run latex again once or twice on the tex file to get a dvi
>     file
> 4.  use dvipdf to get a hyperlinked pdf
>

Yes, that is right. This is done automatically when you click
'Save' in a 'pamphlet' web page on MathAction.

> I hope we can get some autogenerated graphs like this into
> the pamphlet files later on - I'm very impressed with the
> results.
>

Sounds good to me. As far as I am concerned, the more graphics
the better! Using nodes and edges of the graph/diagram as
hyperlinks is convenient in a lot of cases.

\start
Date: 11 May 2006 18:13:26 +0200
From: Francois Maltey
To: Cliff Yapp
Subject: Re: Emacs + input syntax

Hello Cliff,

> A couple of quick questions, so I know what I'm up against:

> 1.  I don't suppose the use of the _ character to indicate a new line
> is unique to input syntax?  If not, would it be OK to make it so in
> Emacs if I can make multi-line input without it in "normal" input mode?
>
> 2.  If the answer to both questions in #1 is no and I can't assume the
> _ character is unique, is there any reliable way to detect when someone
> is inputing input syntax rather than the normal user level input?

I think it's too complex to detect inside emacs if
the syntax is an axiom-command-line or an axiom-input-style.

You may have a global variable axiom-input-mode, someones set to
'axiom-command-line, others to 'axiom-input-syntax.
   (setq axiom-input-mode 'axiom-command-line)
or (setq axiom-input-mode 'axiom-input-syntax)
at the beginning of axiommode.el

> 3.  If the answer to #2 is no, how should I know when to do the input
> syntax eval instead of the normal eval?  I could define a different key
> combination but if the user forgot to use it it might generate a bit of
> a mess.

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

When you use the *.input file method I find three exceptions
where you CAN'T create a new *.input file to send data to axiom.

After the first (1)-> : think to the bug arround the duplicate (1)->.
After )quit you must send a string to axiom, not a )read command.
After )d op axiom wait a yes.

So here is my old function which respond if I must send a file or not.

The reponse of this function is
  'wait [a file], 'wait-kbd [a string] or 'run [axiom is running]

(defun axiomRun-kernel-state-by-output nil
  (save-excursion
    (let (tmpa tmpb tmpc tmp)
      (goto-char axiomRun-marker-edit)
      (setq tmpa
        (and
          (posix-search-backward "^\\(([0-9]*) -> $\\)" nil t)
          (match-end 0)))
      (goto-char axiomRun-marker-edit)
      (setq tmpb
        (and
          (posix-search-backward "and return to the operating system:\n" ni=
l t)
          (match-end 0)))
      (goto-char axiomRun-marker-edit)
      (setq tmpc
        (and
          (posix-search-backward "yes and then pressing Enter :\n" nil t)
          (match-end 0)))
      (cond
        ((not (or tmpa tmpb tmpc)) 'run)
        ((= 14 (count-lines 1 axiomRun-marker-edit)) 'run)
        ((and tmpa (eq 1 (- (marker-position axiomRun-marker-edit) tmpa)))=

          'wait)
        ((and tmpb (eq 1 (- (marker-position axiomRun-marker-edit) tmpb)))
          'wait-kbd)
        ((and tmpc (eq 1 (- (marker-position axiomRun-marker-edit) tmpc)))=

          'wait-kbd)
        (t 'run)))))


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

There is an other problem :

If you send too quickly 2 lines to axiom, after a [Ctrl-K] [Ctrl-Y] as
1+2
3+4
axiom itself mismatch the output.

So axiom-mode might send lines (or blocks) one after the other.
Then there are two possibilities :

1-either you send only one line to axiom,
  and wait the next [return] for the next line
2-either you send only one line to axiom,
  and when the output show that axiom has finish one line
  the emacs mode sends the next one, and so on
  but finish when the cursor is inside or before the actual line.


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

> I've been looking at mmm-mode for other reasons, not the least of which
> is the eventual need to handle literate documents, but I think I'm
> going to need it sooner than that so I might have to take time out to
> figure out how to use it, customize it, and integrate it.  It looks
> like the most robust way to handle this might be to use an mmm-mode on
> a per-input style level and figure out invisible text, which is all
> right in a way because even in termainal mode I have other ideas for
> mmm-mode and will need to come to terms with it.

It's perhaps too complex to mix 2 modes.
One for axiom-run and second one for faces and colors.
I never do it.

> If I need to do that, I'm going to have to take time out for a
> re-organization and refactoring of the code.  I've got some tricks in
> there now for dealing with things like flagging mismatched IO pairs,
> but incorporating mmm-mode could result in massive changes all across
> the board.

Perhaps properties are sufficient to detect pair input/output.


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

> So here's the last question - is anybody using this mode now, or to be
> more specific is anybody using it enough to warrant me squashing the
> one or two easily fixed bugs before I rip the guts out?  If not I'll
> just go ahead and ram heads with mmm-mode, but that will mean no
> updates on the current mode for an unforseeable amount of time.

I admire your use of comint.

I found easiest to re-rewrite the input/output between axiom and emacs
when I done mupad-run and axiom-run.

I don't understand what you want to do with the mmm-mode.

\start
Date: Thu, 11 May 2006 12:28:19 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Emacs + input syntax

Cliff,

On Thursday, May 11, 2006 10:54 AM you wrote:
>
> A couple of quick questions, so I know what I'm up against:
>
> 1.  I don't suppose the use of the _ character to indicate a new
> line is unique to input syntax?

No. _ can be used as a line continuation both at the command line
and in .input files. And I think also in SPAD (and Aldor)?

> If not, would it be OK to make it so in Emacs if I can make
> multi-line input without it in "normal" input mode?

I am not sure what you mean. Do you mean that you would automatically
generate the _ line continuations if the emacs buffer consisted of
multiple lines so that in effect Axiom always is asked to execute
the entire contents of a buffer as if it was just one long line?
If this is what you mean, then I suppose that will work but you
would in effect be generating yet another slightly different
input syntax for Axiom. The main difference between this and the
syntax used in the ')read' command is that it would not allow
'#pile' (indentation) block structure. You would always have to
insert parenthesis (not {}!) and semicolons ; to separate commands.

>
> 2.  If the answer to both questions in #1 is no and I can't assume
> the _ character is unique, is there any reliable way to detect
> when someone is inputing input syntax rather than the normal user
> level input?

Again, I am not sure what you mean by "normal user level input".
Both the command line and the ')read' command accept _ as a line
continuation. The difference is in the use of '#pile' indentation
syntax as used in SPAD or not. This is also used in some modern
languages such as Python. On the other hand the Axiom command
line always treats everything as a single input line (continued
or not).

Aldor introduces yet another input syntax using brackets { }
and semicolons ; in a block notation that is common in "C"
and several other languages. But I suppose that is irrelevant
to the current discussion.

>
> 3.  If the answer to #2 is no, how should I know when to do
> the input syntax eval instead of the normal eval?  I could
> define a different key combination but if the user forgot
> to use it it might generate a bit of a mess.

I don't that is necessary. Simply treat everything as ')read'
style .input syntax. In all other respects .input syntax is
the same as the command line input. You have to allow _ in any
case, but you don't need to generate anything automatically.

>
> I've been looking at mmm-mode for other reasons, not the
> least of which is the eventual need to handle literate
> documents, but I think I'm going to need it sooner than
> that so I might have to take time out to figure out how
> to use it, customize it, and integrate it.  It looks
> like the most robust way to handle this might be to use
> an mmm-mode on a per-input style level and figure out
> invisible text, which is all right in a way because even
> in termainal mode I have other ideas for mmm-mode and
> will need to come to terms with it.

I think this is important if you support both command input
and SPAD/Aldor compiles. You need to know whether to generate
a ')read' command or a ')compile' command.

You might also want to provide syntax highlighting and
indentation folding (hiding).

And of course if you are allowing noweb markup text mixed
with your saved Axiom session that's a whole 'nother thing.

>
> If I need to do that, I'm going to have to take time out
> for a re-organization and refactoring of the code.  I've
> got some tricks in there now for dealing with things like
> flagging mismatched IO pairs, but incorporating mmm-mode
> could result in massive changes all across the board.

I would say "keep it simple". Just process all Axiom input
via ')read' for now.

>
> So here's the last question - is anybody using this mode
> now, or to be more specific is anybody using it enough to
> warrant me squashing the one or two easily fixed bugs before
> I rip the guts out?  If not I'll just go ahead and ram
> heads with mmm-mode, but that will mean no updates on the
> current mode for an unforseeable amount of time.
>

I think the change to always using ')read' for Axiom input
should be a simple and local change to your program as it
exists now.

\start
Date: Thu, 11 May 2006 19:01:02 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: Emacs + input syntax

On 05/11/2006 06:28 PM, Page, Bill wrote:
> No. _ can be used as a line continuation both at the command line
> and in .input files. And I think also in SPAD (and Aldor)?

I would always suggest to forget about the #pile mode when you program 
in Aldor, but as _ escapes the next character (and removes trailing 
spaces, yes _ also works in Aldor. You can compile the following file 
using "aldor -grun -laldor aaa.as".

--begin aaa.as
#include "aldor"
#include "aldorio"
#pile
import from Integer;

stdout <<_
12345 + _
78<< newl_
ine <<_
"hello _" __ world" << newline
--end aaa.as

Note that the identifier "newline" goes over two lines. That does not 
work for keywords, though.

\start
Date: Thu, 11 May 2006 11:36:54 -0700 (PDT)
From: Cliff Yapp
To: Francois Maltey
Subject: Re: Emacs + input syntax

--- Francois Maltey wrote:

> I think it's too complex to detect inside emacs if 
> the syntax is an axiom-command-line or an axiom-input-style.

I was afraid of that.
 
> You may have a global variable axiom-input-mode, someones set to 
> 'axiom-command-line, others to 'axiom-input-syntax.
>    (setq axiom-input-mode 'axiom-command-line) 
> or (setq axiom-input-mode 'axiom-input-syntax) 
> at the beginning of axiommode.el

That means you have to select all of one style or all of another,
something I am hoping to avoid.  I want to be able to use command line
syntax for most things but create the occasional *.input entry at will.

> When you use the *.input file method I find three exceptions 
> where you CAN'T create a new *.input file to send data to axiom.
> 
> After the first (1)-> : think to the bug arround the duplicate (1)->.
> After )quit you must send a string to axiom, not a )read command.
> After )d op axiom wait a yes.
> 
> So here is my old function which respond if I must send a file or
> not.

[snip]

OK, thanks - this could be useful.  I'm not sure why (1)-> should be an
issue, but I can look into it.
 
> There is an other problem : 
> 
> If you send too quickly 2 lines to axiom, after a [Ctrl-K] [Ctrl-Y]
> as
> 1+2
> 3+4
> axiom itself mismatch the output.

I think the simplest way to handle this would be to prevent any new
evaluations or maybe even insertions while axiom is waiting for output.
 I'll have to test it.

> So axiom-mode might send lines (or blocks) one after the other.
> Then there are two possibilities : 
> 
> 1-either you send only one line to axiom, 
>   and wait the next [return] for the next line

I thought that's what my mode was doing - it's possible it isn't, in
which case that's a bug.

> 2-either you send only one line to axiom, 
>   and when the output show that axiom has finish one line 
>   the emacs mode sends the next one, and so on
>   but finish when the cursor is inside or before the actual line.

In my mode it should only be possible to send one input at a time.  Why
would you want to send two at once?

> It's perhaps too complex to mix 2 modes. 

That's, in a nutshell, what mmm-mode is designed to handle.

> One for axiom-run and second one for faces and colors.
> I never do it. 

I'm not sure how to work things as of now, but I'll think about it.

> I admire your use of comint. 

Thanks, but credit for that must remain with Jay.
 
> I found easiest to re-rewrite the input/output between axiom and
> emacs when I done mupad-run and axiom-run.
> 
> I don't understand what you want to do with the mmm-mode.

Well, I'm assuming that .input syntax and command-line syntax have
distinct rules.  What I should be able to do (if I understand mmm-mode)
is create localized behavior on the axiom input line, and by changing
modes provide two different sets of behavior.  I have some other ideas
about allowing text/latex blocks before IO pairs as well, but that's
for later.

\start
Date: Thu, 11 May 2006 11:45:13 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Emacs + input syntax

--- Ralf Hemmecke wrote:

> Hi Cliff,
> 
> To be honest, I don't quite understand all your questions.

No problem - that's almost certainly due to those questions being
incorrectly put together or based on incorrect ideas.  I expect my use
of Axiom as of now is simplistic in the extreme - I have not yet
attempted a serious program in it.  I think that's why I'm not quite
grasping the *.input vs. command-line issue.

> I don't know how useful it is to put _ always at the end of a line.
> What about using Shift-Enter as in Maple? (What was it in Mma?)

I mentioned _ because that's apparently required for some interactions
with Axiom?  I think Shift-Enter or Control-Enter is reasonable.  What
I'm trying to grasp is the issue of )read commands, what people are
doing with them, and how to make Emacs handle it without leaving the
Axiom command line.

> The _ character is special. Think about producing a string that
> consists of a single ". You do this by writing
> 
> "_""

Ah.

> As for mmm-mode, I *use* it and I also suggest it for ALLPROSE. It
> works quite nicely for me and is for my taste better than noweb-mode.
> However, I cannot help you if you need to go into the code itself.

I sincerely hope I won't have to.  I also would MUCH prefer to just use
it, but if I have to modify it and incorporate it I will attempt to do
so.  Emacs has been around for a very long time and will likely
continue to be around for a long time - creating an interface the Right
Way is an investment that will hopefully pay dividends for years to
come.  I'm trying to figure out what the "Right Way" is.  I concede I'm
not the best person for this job, but all I can do is try.

\start
Date: Thu, 11 May 2006 12:07:24 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Emacs + input syntax

--- Bill Page wrote:

> Cliff, 
> 
> On Thursday, May 11, 2006 10:54 AM you wrote:
> > 
> > A couple of quick questions, so I know what I'm up against:
> > 
> > 1.  I don't suppose the use of the _ character to indicate a new
> > line is unique to input syntax?
> 
> No. _ can be used as a line continuation both at the command line
> and in .input files. And I think also in SPAD (and Aldor)?

OK.
 
> > If not, would it be OK to make it so in Emacs if I can make
> > multi-line input without it in "normal" input mode?
> 
> I am not sure what you mean. Do you mean that you would automatically
> generate the _ line continuations if the emacs buffer consisted of
> multiple lines so that in effect Axiom always is asked to execute
> the entire contents of a buffer as if it was just one long line?

Right.

> If this is what you mean, then I suppose that will work but you
> would in effect be generating yet another slightly different
> input syntax for Axiom.

Yes, but I think this is a logical extension, and definitely more
intuitive for new users.  Return for a line break and Shift-Return for
an evaluation are commonly used and well known - _ as a necessary
precursor to a line break is neither outside of Axiom.  Any other GUI
interface created for Axiom is not likely to use the _ notation for
line breaking.

> The main difference between this and the
> syntax used in the ')read' command is that it would not allow
> '#pile' (indentation) block structure. You would always have to
> insert parenthesis (not {}!) and semicolons ; to separate commands.

That's where mmm-mode should come in.  If I can master Emacs properly,
I think it might be possible to have a "pile" editing environment which
would enforce the rules.

What I am aiming for, based on what I have thought about so far, is a
default "non-pile" syntax environment (e.g. normal command line +
returns without _) and the user option to switch to an "input"
environment which supports all of the input syntax including pile
syntax.

> > 2.  If the answer to both questions in #1 is no and I can't assume
> > the _ character is unique, is there any reliable way to detect 
> > when someone is inputing input syntax rather than the normal user
> > level input?
> 
> Again, I am not sure what you mean by "normal user level input".
> Both the command line and the ')read' command accept _ as a line
> continuation. The difference is in the use of '#pile' indentation
> syntax as used in SPAD or not.

OK, I think I'm getting it.  So the difference between command line
legal syntax and input legal syntax is that the latter case allows (or
even requires) pile syntax?

> This is also used in some modern
> languages such as Python. On the other hand the Axiom command
> line always treats everything as a single input line (continued
> or not).

Got it.  I've programmed in python a little as part of my job, so its
not totally foreign.  Just a bit odd ;-).

> Aldor introduces yet another input syntax using brackets { }
> and semicolons ; in a block notation that is common in "C"
> and several other languages. But I suppose that is irrelevant
> to the current discussion.

Unless we are allowing Aldor in ")read" commands.  Then it might be
important.  But that's probably for the future.

> > 3.  If the answer to #2 is no, how should I know when to do
> > the input syntax eval instead of the normal eval?  I could
> > define a different key combination but if the user forgot
> > to use it it might generate a bit of a mess.
> 
> I don't that is necessary. Simply treat everything as ')read'
> style .input syntax. In all other respects .input syntax is
> the same as the command line input. You have to allow _ in any
> case, but you don't need to generate anything automatically.

That might work, but I think I would like to have special provisions
(if I can manage it) for input/pile syntax.

> > I've been looking at mmm-mode for other reasons, not the 
> > least of which is the eventual need to handle literate
> > documents, but I think I'm going to need it sooner than
> > that so I might have to take time out to figure out how
> > to use it, customize it, and integrate it.  It looks
> > like the most robust way to handle this might be to use
> > an mmm-mode on a per-input style level and figure out
> > invisible text, which is all right in a way because even
> > in termainal mode I have other ideas for mmm-mode and
> > will need to come to terms with it.
> 
> I think this is important if you support both command input
> and SPAD/Aldor compiles. You need to know whether to generate
> a ')read' command or a ')compile' command.

Well, the eventual goal is to support all normal ways of working with
Axiom.  Which would probably be easier if I knew more about them, but I
think a lot of the support for such things will need to come later.

> You might also want to provide syntax highlighting and
> indentation folding (hiding).

Yes.  That is part of the plan but is down the road a ways.

> And of course if you are allowing noweb markup text mixed
> with your saved Axiom session that's a whole 'nother thing.

Not quite.  What I'm planning to do is create a mechanism to insert
latex or text "boxes" before and after an input-output combination. 
I'm envisioning a "graded" approach - on the far right is the basic
command line (more or less what exists now).  On the far left is a
literate latex document with aldor code chuncks.  In the middle are
EAxiom latex documents - a document with Axiom user sessions embedded
such as in the Maxima manual - and annotated terminal sessions.  So you
will eventually have your choice of a variety of modes:

1)  Terminal mode - as seen now
2)  Terminal mode + comment regions
3)  EAxiom latex document with embedded sessions
4)  Literate program with lisp code chuncks
5)  Literate program with aldor code chuncks

If there is demand for it I suppose a generic text environment with
support for sending strings to LaTeX is also possible, although I'm not
sure why one would want to use text instead of LaTeX for such a
purpose.

> > If I need to do that, I'm going to have to take time out
> > for a re-organization and refactoring of the code.  I've
> > got some tricks in there now for dealing with things like
> > flagging mismatched IO pairs, but incorporating mmm-mode
> > could result in massive changes all across the board.
> 
> I would say "keep it simple". Just process all Axiom input
> via ')read' for now.

That might be the sensible thing.  One thing though - I'm not sure if
the _ trick for multiple lines/pile syntax will work from an Emacs
buffer.  I could probably work it by having the return check for a _
character immediately behind it, but I don't know if the default comint
bindings would do.  Hmm...

> > So here's the last question - is anybody using this mode
> > now, or to be more specific is anybody using it enough to
> > warrant me squashing the one or two easily fixed bugs before
> > I rip the guts out?  If not I'll just go ahead and ram
> > heads with mmm-mode, but that will mean no updates on the
> > current mode for an unforseeable amount of time.
> 
> I think the change to always using ')read' for Axiom input
> should be a simple and local change to your program as it
> exists now.

Do I have to use temp files, or is there a way to do )read "string"?

\start
Date: 11 May 2006 22:03:19 +0200
From: Francois Maltey
To: Cliff Yapp
Subject: Re: Emacs + input syntax

Francois again...

> > I think it's too complex to detect inside emacs if
> > the syntax is an axiom-command-line or an axiom-input-style.
>
> I was afraid of that.
>
> > You may have a global variable axiom-input-mode, someones set to
> > 'axiom-command-line, others to 'axiom-input-syntax.
> >    (setq axiom-input-mode 'axiom-command-line)
> > or (setq axiom-input-mode 'axiom-input-syntax)
> > at the beginning of axiommode.el
>
> That means you have to select all of one style or all of another,
> something I am hoping to avoid.

> I want to be able to use command line syntax for most things but
> create the occasional *.input entry at will.

Perhaps (*)
  glue lines with a _ at the end to the next one.             (inline synta=
x)
  glue lines with a space at beginning to the pr=C3=A9vious one.   (input s=
yntax)
  but cut all the others lines.

It may be interesting to have a very small function which make this cut.
Because having a block per paragraph (without empty-line) has also advantag=
es.

> I'm not sure why (1)-> should be an issue, but I can look into it.

Because when I run axiom (not axiomSYS) I have two prompts (1)-> on my
screen.
The first one isn't a real prompt because axiom display after a second.

> Well, I'm assuming that .input syntax and command-line syntax have
> distinct rules.

My advice changes... see (*)

> What I should be able to do (if I understand mmm-mode)
> is create localized behavior on the axiom input line, and by changing
> modes provide two different sets of behavior.

> I have some other ideas
> about allowing text/latex blocks before IO pairs as well, but that's
> for later.

When I played with mupad and emacs, I tryed to allow the insert of comments
between commands and output. It's a HUGE work and now I reject this idea.
Either I have a read-only buffer for axiom and all, as a typewriter.
Either I have a latex file and I cut/copy/paste blocks from/to axiom-buffer.
But of corse it's my advise, you may have good reasons to do what you want.

\start
Date: Thu, 11 May 2006 17:46:04 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: Emacs + input syntax

On Thursday, May 11, 2006 1:01 PM Ralf Hemmecke wrote:
> ...
> I would always suggest to forget about the #pile mode when
> you program in Aldor ...

Why? Your suggestion seems to me only a kind of
linguist prejudice.

I much prefer this notation. I think it is a strong
point of both SPAD and Aldor that they support it
(SPAD requires it). It is briefer, cleaner and easier
to read. What purpose does the extra bracket { ... }
syntax serve if we all agree that "good" programming
practice demands consistent indentation?

\start
Date: 11 May 2006 23:58:00 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Emacs + input syntax

Bill Page writes:

| On Thursday, May 11, 2006 1:01 PM Ralf Hemmecke wrote:
| > ... 
| > I would always suggest to forget about the #pile mode when 
| > you program in Aldor ...
| 
| Why? Your suggestion seems to me only a kind of
| linguist prejudice.

I think I'm with Ralf here.  I find the pile notation highly
confusing and irritating when editing.  It is one of the downsides I
find with Python, Haskell, Axiom, etc.  For me, it isn't different
those infamous "tabs" in Makefiles.  It is a relic from stone ages we
should not carry over. 
Your mileage may vary.

\start
Date: Thu, 11 May 2006 18:09:50 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: Emacs + input syntax

Gaby, Ralf,

On Thursday, May 11, 2006 5:58 PM you wrote:
>
> Bill Page writes:
>
> | On Thursday, May 11, 2006 1:01 PM Ralf Hemmecke wrote:
> | > ...
> | > I would always suggest to forget about the #pile mode when
> | > you program in Aldor ...
> |
> | Why? Your suggestion seems to me only a kind of
> | linguist prejudice.
>
> I think I'm with Ralf here.  I find the pile notation highly
> confusing and irritating when editing.  It is one of the
> downsides I find with Python, Haskell, Axiom, etc.  For me,
> it isn't different those infamous "tabs" in Makefiles.  It
> is a relic from stone ages we should not carry over.

In what sense is this notation "a relic"? Do you know other
"ancient" languages (besides SPAD) that used this syntax?

> Your mileage may vary.
>

It does. :-)

Can either of you give any objective argument about why
you prefer to write in a serialized one-dimensional manner,
encoding nested structures with the bracket (or even a
parenthesis) notation, instead of using the natural two
dimensional nature of the display media to express this
structure more succinctly?

If not, my label of "linguist prejudice" must surely apply.

\start
Date: Thu, 11 May 2006 18:22:32 -0400
From: Tim Daly
To: Bill Page
Subject: re: Emacs + input syntax

>Can either of you give any objective argument about why
>you prefer to write in a serialized one-dimensional manner,
>encoding nested structures with the bracket (or even a
>parenthesis) notation, instead of using the natural two
>dimensional nature of the display media to express this
>structure more succinctly?

yep. i can't count what i can't see. i can balance parens
over thousands of lines but i can't balance spaces. parens
give proper nesting no matter how i mangle the source. 
spaces don't. try carefully balancing spaces over 5 pages 
of code (e.g. large nested conditional statements). one
missing space and the meaning of the program SILENTLY changes.

my "hack" for doing this is to globally replace spaces following
a newline by a period and count periods. then, before compiling
the program, replace them by spaces.

oh, and you can easily screw the whole world over with an
editor that likes to replace spaces by tabs. no end of puzzlement
and grief follows.

> If not, my label of "linguist prejudice" must surely apply.

prejudice is pre-judging a decision.
experience is post-judging a decision.
the decision to pile is flawed.
based on experience.

\start
Date: 12 May 2006 00:24:47 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Emacs + input syntax

Bill Page writes:

| Can either of you give any objective argument about why
                             ^^^^^^^^^

We are talking about *syntax*, right?  As they say, it is like colors
and taste... 

| you prefer to write in a serialized one-dimensional manner,

I don't prefer to write serialized one-dimensional manner.  I prefer
to *see* syntactic markers for groups. 

| encoding nested structures with the bracket (or even a
| parenthesis) notation,

Are you going to propose we replace the square and round brackets with
the varieties of spaces?

| instead of using the natural two
| dimensional nature of the display media to express this
| structure more succinctly?

I do almost all of my works with terminals.  I use browsers only
when I'm forced to (like those online forms that don't work with
lynx, bugzillas, wikis, etc.)  Don't get me wrong; I do like and
appreciate pictures, n-dimensional illustrations; the indenting stuff
just does not work for me.  Yes, I do intend my codes.  And yes,
braces don't prevent you from indenting.

| If not, my label of "linguist prejudice" must surely apply.

It actually applies both ways, so I don't find it persuasive :-)

\start
Date: 12 May 2006 00:27:04 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Emacs + input syntax

Bill Page writes:

| Gaby, Ralf,
| 
| On Thursday, May 11, 2006 5:58 PM you wrote:
| > 
| > Bill Page writes:
| > 
| > | On Thursday, May 11, 2006 1:01 PM Ralf Hemmecke wrote:
| > | > ... 
| > | > I would always suggest to forget about the #pile mode when 
| > | > you program in Aldor ...
| > | 
| > | Why? Your suggestion seems to me only a kind of
| > | linguist prejudice.
| > 
| > I think I'm with Ralf here.  I find the pile notation highly
| > confusing and irritating when editing.  It is one of the
| > downsides I find with Python, Haskell, Axiom, etc.  For me,
| > it isn't different those infamous "tabs" in Makefiles.  It
| > is a relic from stone ages we should not carry over.
| 
| In what sense is this notation "a relic"? Do you know other
| "ancient" languages (besides SPAD) that used this syntax?

Makefile does not qualify? :-)

It is NOT the language that is a relic, it is the syntax -- like the
semicolons "known" to be the cancer of programming languages.   

\start
Date: Thu, 11 May 2006 22:39:07 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: re: Emacs + input syntax

Hi Cliff,

> What I am aiming for, based on what I have thought about so far, is a
> default "non-pile" syntax environment (e.g. normal command line +
> returns without _) and the user option to switch to an "input"
> environment which supports all of the input syntax including pile
> syntax.

I don't lknow whether you are aware of my aldor-mode 
(http://www.hemmecke.de/aldor) and whether it could be relevant for what 
you are trying to achieve. (It's a noweb file...)

Another aldor-mode has been written by Stephen Wilson 
<Stephen Wilson>. That is more proper elisp-ish than mine, but 
it's not a literate program and I am not aware of a place where this is 
distributed.

Anyway, I would like to see just ONE (perfect) aldor/axiom mode so that 
people don't have to test different things. That's a waste of time.

\start
Date: Fri, 12 May 2006 00:58:00 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Hello Gaby,

I have included aldor-l in this thread, because I think you raised an 
important question with the "functional type (sub-)language". 
Additionally, I've moved it from axiom-math to axiom-developer.

On 05/11/2006 08:49 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:

[snip]

> | > |        or   " Integer " is an abbreviation for Integer without parameter ?
> | 
> | > from the functional perspective, Integer is a nullary (type) function;
> | > it is actually a type constant.
> | 
> |  From a functional point of view you are certainly right, the only
> | problem is that Aldor is not functional.
> 
> That should not matter; and if it does, it is a bug!  

Well, to me it is not a bug. But I am not the language designer. I am 
sure Stephen Watt could make things clear here.

> Do you really want a type system whose language is not functional?

Actually, I haven't thought about this. I somehow have the feeling that 
the Aldor compiler implements such a functional type language. But I 
don't know whether this is on purpose.

 > Notice, that I'm not saying the term language should be functional.
 > I'm talking of the type (sub-)language.  How do you work with a type
 > system system whose constructors do not evaluate the same arguments to
 > the same value?

Surely, it would sound strange if I say:

a: SparseUnivariatePolynomial Integer := ...
b: SparseUnivariatePolynomial Integer := ...

and the compiler would reject

a + b

because it could not figure out that a and b are of the same type 
(because of non-functionality). So in this sense I certainly find a 
functional type language more natural.

> | BTW, I would rather say, Integer is a type constant. If Integer() is
> | defined and works in Axiom then please show me a definition of the
> | language that makes it clear that if one defines
> 
> Please, first, show me how you meaningfully work with a type system
> where the type language is not functional.

That is not a field where I'm an expert in.

> | Integer: SomeIntegerCategory
> | 
> | that also
> | 
> | Integer: () -> SomeIntegerCategory
> | 
> | To me, these two things clearly have a different type.

> The syntaxes are different; the question is whether the *semantics*
> should be different.  The answer must be "no", for a workable type
> system.

I don't agree. The program

----------------------------------------------------------
aldor -grun -laldor aaa.as
Dom:   1
Dom(): 0

--begin aaa.as --------------------------------------------
#include "aldor"
#include "aldorio"

Cat: Category == Join(ArithmeticType, OutputType) with;
Dom: Cat == Integer add;
Dom(): Cat == Integer add {
     Rep == Integer;
     import from Rep;
     1: % == per 0;
}
main(): () == {
     import from Dom, Dom();
     stdout << "Dom:   " << 1$Dom << newline;
     stdout << "Dom(): " << 1$Dom() << newline;
}
main();
--end aaa.as

shows that Dom and Dom() need not be identical and one can still have a 
consistent type system.

I would even call it functional (if Dom() always produces the same 
value). It is only that things of type Cat and things of type ()->Cat 
are not identified even if they happen to have the same name.

But of course, I could live with that identification if it is clearly 
documented that ()->Cat can be identified with Cat. Where are our 
category experts? I believe there is a distinction here, n'est pas?

\start
Date: Thu, 11 May 2006 19:02:59 -0400
From: Bill Page
To: Tim Daly
Subject: re: Emacs + input syntax

Tim,

On  Thursday, May 11, 2006 6:23 PM you wrote:
> Bill Page wrote:
> >Can either of you give any objective argument about why
> >you prefer to write in a serialized one-dimensional manner,
> >encoding nested structures with the bracket (or even a
> >parenthesis) notation, instead of using the natural two
> >dimensional nature of the display media to express this
> >structure more succinctly?
>
> yep. i can't count what i can't see. i can balance parens
> over thousands of lines but i can't balance spaces. parens
> give proper nesting no matter how i mangle the source.
> spaces don't.

I have no trouble seeing the visual organization of a few
pages of indented code. In fact, in my experience the lack
of proper indentation has sometimes hidden logical errors
in my programs. Reviewing the indentation (forgetting about
the brackets) has sometimes revealed the error.

I suppose you are arguing that the parens notation contains
some redundant information because it contains matched "begin"
symbols and "end" symbols while in the "pile" notation the
beginning of an indented block is marked by the first initial
white space greater than the line that precedes it, while
any line with less initial white space ends all proceeding
blocks with greater white space. So therefore the serialized
linear notation is perhaps inherently less fragile?

But I do not think this is the case.

> try carefully balancing spaces over 5 pages of code (e.g.
> large nested conditional statements). one missing space and
> the meaning of the program SILENTLY changes.
>
> my "hack" for doing this is to globally replace spaces
> following a newline by a period and count periods. then,
> before compiling the program, replace them by spaces.
>

Have you ever tried turning your head 90% to the page? :)
Apparently most humans have greater visual acuity in the
horizontal plane that in the vertical.

It seems to me that balanced miss-placed parens can be even
more SILENT than a missing space. The error could be anywhere
from the first character of the program to the last and more
over it can be obscured by the fact that the programmer may
have also inconsistently indented the code to exhibit the
structure she expects rather than what she coded.

> oh, and you can easily screw the whole world over with an
> editor that likes to replace spaces by tabs. no end of
> puzzlement and grief follows.

My solution: use a proper text editor.

>
> > If not, my label of "linguist prejudice" must surely apply.
>
> prejudice is pre-judging a decision.
> experience is post-judging a decision.
> the decision to pile is flawed.
> based on experience.
>

I was amused to see the following headline at

http://www.tiobe.com/tpci.htm

"May Headline: Eventual recognition for Visual FoxPro and Lisp
(approaching A status)"

Wow, lisp finally beat out Cobol this year! Hooray.

\start
Date: 12 May 2006 01:13:36 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Ralf Hemmecke writes:

[...]

| But of course, I could live with that identification if it is clearly
| documented that ()->Cat can be identified with Cat. Where are our
| category experts? I believe there is a distinction here, n'est pas?

>From Category Theory point of view, a constant x of type T is the same
as the (unique) morphism x : 1 -> T, where 1 is the one-point set.

Now, I also understand that beyond the name, Aldor's catagories are
not mathematical categories; so....


My practice of functional programming suggests that the identification
is useful in many cases, than keeping the artifice.  But YMMV.

\start
Date: Fri, 12 May 2006 01:43:14 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: Emacs + input syntax

On 05/11/2006 11:46 PM, Page, Bill wrote:
> On Thursday, May 11, 2006 1:01 PM Ralf Hemmecke wrote:
>> I would always suggest to forget about the #pile mode when 
>> you program in Aldor ...

> Why? Your suggestion seems to me only a kind of
> linguist prejudice.

> I much prefer this notation. I think it is a strong
> point of both SPAD and Aldor that they support it
> (SPAD requires it). It is briefer, cleaner and easier
> to read.

I don't like it since when I started my first programs in SPAD several 
years ago I had no Axiom book available. The only source that I could 
learn from was the source code that I could access through hyperdoc.

Can you imagine how hard it was to figure out how to parse something like

ListAggregate(S:Type): Category == Join(StreamAggregate S,
    FiniteLinearAggregate S, ExtensibleLinearAggregate S) with
       list: S -> %
	++ list(x) returns the list of one element x.
  add
    cycleMax ==> 1000
    ....

I still do not completely understand that pile syntax. Let me add braces 
to the code above...

ListAggregate(S:Type): Category == Join(StreamAggregate S, {
    FiniteLinearAggregate S, ExtensibleLinearAggregate S) with {
       list: S -> %
	++ list(x) returns the list of one element x.
}
  add {
    cycleMax ==> 1000
    ....
}

Well, my braces must be wrong, since it goes ... (...{ ... ) ...}.
There is more to indentation than just starting a new block.
Yes, I probably haven't read the documentation about the spad 
indentation. And even if I read Section 5.2 of the Axiom book, I would 
come to the same result (perhaps using parentheses instead of braces).

 > What purpose does the extra bracket { ... }
> syntax serve if we all agree that "good" programming
> practice demands consistent indentation? 

My programming experience with SPAD is that I had to compile too many 
times in order to find out that my indentation was wrong (at exactly 
such places as above).

I was so relieved when I could switch to braces in Aldor.
And I do indent code, I even wrote an aldor-mode for emacs to help with 
such indentation. But that mode relies on parentheses, brackets, and 
braces. It automatically indents to the right amount and I see when 
there is a forgotten brace, because pressing TAB lead to the wrong 
indentation.

Can you have automated indentation with #pile mode?

Well, anyone has his preferences...

However, in order to make code readable for future programmers (why 
should they learn to syntaxes?), we should introduce some coding 
conventions. And as long as programming the axiom library is concerned, 
I will fight for braces. ;-)

For the command line of Axiom I don't care at the moment, because that 
is a task for a good user interface.

\start
Date: Fri, 12 May 2006 01:50:48 +0200
From: Ralf Hemmecke
To: Francois Maltey
Subject: Re: Emacs + input syntax

> Perhaps (*)
>   glue lines with a _ at the end to the next one.             (inline s=
yntax)
>   glue lines with a space at beginning to the pr=C3=A9vious one.   (inp=
ut syntax)
>   but cut all the others lines.

I hope you also consider an error message of Axiom if the expression is
syntactically incorrect. In that case I would like the axiomacs mode to
jump to the error position (if possible).

\start
Date: Thu, 11 May 2006 19:52:38 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

On Thursday, May 11, 2006 7:14 PM Gabriel Dos Reis wrote:
> 
> Ralf Hemmecke writes:
> 
> [...]
> 
> | But of course, I could live with that identification if it 
> | is clearly documented that ()->Cat can be identified with Cat.
> | Where are our category experts? I believe there is a distinction
> | here, n'est pas?
> 
> From Category Theory point of view, a constant x of type T 
> is the same as the (unique) morphism x : 1 -> T, where 1 is
> the one-point set.

The relevant object here is the initial object 0 in a complete
Cartesian closed category (CCCC), not the terminal object 1.

http://en.wikipedia.org/wiki/Initial_object

It is quite reasonable I think to let () denote the initial
object in the CCCC associated with the categorical semantics
of Aldor.

The definition of initial is that: there exists precisely one
morphism () $B"*(J X for each object X. So in a sense any "categorical"
distinction between the morphism and co-domain object is not
likely to be of much interest.

> 
> Now, I also understand that beyond the name, Aldor's categories
> are not mathematical categories; so...

I think that is an over statement. There is a considerable
similarity between categories in Aldor and mathematical
categories. But that is irrelevant. Any "sufficiently complex"
programming language must have the structure of a complete
Cartesian closed category.

> 
> My practice of functional programming suggests that the
> identification is useful in many cases, than keeping the
> artifice.  But YMMV.
> 

I think this identification can be justified from a mathematical
point of view.

\start
Date: 12 May 2006 02:10:58 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Bill Page writes:

| On Thursday, May 11, 2006 7:14 PM Gabriel Dos Reis wrote:
| >
| > Ralf Hemmecke writes:
| >
| > [...]
| >
| > | But of course, I could live with that identification if it
| > | is clearly documented that ()->Cat can be identified with Cat.
| > | Where are our category experts? I believe there is a distinction
| > | here, n'est pas?
| >
| > From Category Theory point of view, a constant x of type T
| > is the same as the (unique) morphism x : 1 -> T, where 1 is
| > the one-point set.
|
| The relevant object here is the initial object 0 in a complete
| Cartesian closed category (CCCC), not the terminal object 1.

Oh well, I should have written

   x : tartempion -> T.

Now, buy a time machine, go and tell Mac Lane that wikipedia will use
0 for initial objects, so he should not write his units, one-point set
as 1.  :-) :-)

But, yes, you're right that mathematical notation is highly ambiguous,
let alone categorial notation.

[...]

| The definition of initial is that: there exists precisely one
| morphism () =A2=AA X for each object X. So in a sense any "categorical"
| distinction between the morphism and co-domain object is not
| likely to be of much interest.

Indeed.

[...]

| > Now, I also understand that beyond the name, Aldor's categories
| > are not mathematical categories; so...
|
| I think that is an over statement. There is a considerable
| similarity between categories in Aldor and mathematical
| categories.

Quantify "considerable".

| But that is irrelevant. Any "sufficiently complex"
| programming language must have the structure of a complete
| Cartesian closed category.

That, I believe, is a statement I would like to see more evidence for.

| > My practice of functional programming suggests that the
| > identification is useful in many cases, than keeping the
| > artifice.  But YMMV.
| >
|
| I think this identification can be justified from a mathematical
| point of view.

Not only from mathematical point of view; from practical point of view
too.  That is the most important aspect for me.  The fact that no one
has given proof that Aldor's type system is sound (it most probably
isn't) does not prevent you from using it to write useful programs.
Sorry if I sound blunt, but I tend to put practice before theory --
yes, and I do value useful theories :-)

\start
Date: Fri, 12 May 2006 02:22:52 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: Emacs + input syntax

Hello Bill,

On 05/12/2006 12:09 AM, Page, Bill wrote:
> Can either of you give any objective argument about why
> you prefer to write in a serialized one-dimensional manner,
> encoding nested structures with the bracket (or even a
> parenthesis) notation, instead of using the natural two
> dimensional nature of the display media to express this
> structure more succinctly?

That everyone who is using brackets is using indentation is clear.

But from my work in ALLPROSE and discussion with Norman Ramsey, I also 
have a objective argument against #pile. Well, it's not too objective, 
since the Aldor compiler is not yet working properly in handling #line 
directives.

My intention in ALLPROSE was to start the make process within emacs. In 
case of an error emacs would be able to jump to the source position of 
the error. But, hey, it would jump to the .as file and not to the noweb 
source. So I added code to ALLPROSE that produces #line directives into 
the .as file so that emacs would correctly jump to the .as.nw file. 
(Unfortunately, the Aldor compiler does not handle #line directives 
correctly. BIG MINUS.)

Now, you all know that if I write...

<<Dom>>=
Dom: with
   <<exports: Dom>>
  == add
   <<implementation Dom>>
@

and somewhere else I provide the appropriate chunks, then notangle 
correctly indents the chunks.

HOWEVER, if I give the command line switch -L to notangle as in

%.as: %.as.nw
	$(NOTANGLE) -L'--#line %L "$<"%N' $< > $@

the code will NOT be indented.

Norman Ramsey refused to change that behaviour. And I think he is right.
Compilers sometimes spit out an error position like ----------------^
and that would point to the wrong position if the code were indented in 
the .as file differently from the .as.nw file.

So you have to decide, either you could have "jump to error" or "right 
indentation" (a must for #pile code). You cannot have both.

\start
Date: Thu, 11 May 2006 20:51:03 -0400
From: Tim Daly
To: list
Subject: re: Emacs + input syntax

>I suppose you are arguing that the parens notation contains
>some redundant information because it contains matched "begin"
>symbols and "end" symbols while in the "pile" notation the
>beginning of an indented block is marked by the first initial
>white space greater than the line that precedes it, while
>any line with less initial white space ends all proceeding
>blocks with greater white space. So therefore the serialized
>linear notation is perhaps inherently less fragile?

open your program text in a proportional font editor.
parens work. piling doesn't.

\start
Date: Thu, 11 May 2006 20:53:20 -0400
From: Tim Daly
To: list
Subject: re: Emacs + input syntax

>I suppose you are arguing that the parens notation contains
>some redundant information because it contains matched "begin"
>symbols and "end" symbols while in the "pile" notation the
>beginning of an indented block is marked by the first initial
>white space greater than the line that precedes it, while
>any line with less initial white space ends all proceeding
>blocks with greater white space. So therefore the serialized
>linear notation is perhaps inherently less fragile?

and if you print it you, even in fixed font, the only way to
make sure things line up across pages is with a ruler. 
double sided pages are more problematic.

\start
Date: Thu, 11 May 2006 21:01:16 -0400
From: Bill Page
To: Tim Daly
Subject: re: Emacs + input syntax

Tim wrote:
> ...
> open your program text in a proportional font editor.
> parens work. piling doesn't.
>

??? Works for me. Spaces are small but fixed in size.
But why would you want to use proportional font when
editing a program?

\start
Date: Thu, 11 May 2006 21:32:09 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: re: Emacs + input syntax

Hi Ralf, Cliff,

Although I have not participated on this list in some time, I still
read it most days.  I really should start contributing again.

On Thu, May 11, 2006 at 10:39:07PM +0200, Ralf Hemmecke wrote:
> Another aldor-mode has been written by Stephen Wilson 
> <Stephen Wilson>. That is more proper elisp-ish than mine, but 
> it's not a literate program and I am not aware of a place where this is 
> distributed.

I still have the code on my hard drive.  I'll send it out to anyone
who would like a copy.  Perhaps it could be posted on the wiki
somewhere.

\start
Date: Thu, 11 May 2006 21:38:11 -0400
From: Bill Page
To: Stephen Wilson
Subject: re: Emacs + input syntax

On Thursday, May 11, 2006 9:32 PM Stephen Wilson wrote:
>
> Although I have not participated on this list in some time,
> I still read it most days.  I really should start contributing
> again.

Yes, please do. I greatly appreciated your comments and previous
work on Axiom and Aldor. :)

>
> On Thu, May 11, 2006 at 10:39:07PM +0200, Ralf Hemmecke wrote:
> > Another aldor-mode has been written by Stephen Wilson
> > <Stephen Wilson>. That is more proper elisp-ish
> > than mine, but it's not a literate program and I am not
> > aware of a place where this is  distributed.
>
> I still have the code on my hard drive.  I'll send it out to
> anyone who would like a copy.  Perhaps it could be posted on
> the wiki somewhere.
>

If you would like help, I would be glad to post it to the

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

page on the Axiom Wiki for you. Really you just need to click
'edit' and 'Browse' to upload the file.

Or if you would prefer we could create an 'AldorInEmacs' page
(add this as a "WikiWord" to the AxiomInEmacs page, save and
then click the blue ?).

If you could also provide some brief descriptive paragraph to
go along with it, I think that would be great. I think this
aldor-mode is likely of interest to a lot of people.

\start
Date: Thu, 11 May 2006 22:28:15 -0400
From: Stephen Wilson
To: Bill Page
Subject: re: Emacs + input syntax

Hello Bill,

On Thu, May 11, 2006 at 09:38:11PM -0400, Page, Bill wrote:
> On Thursday, May 11, 2006 9:32 PM Stephen Wilson wrote:
> > 
> > Although I have not participated on this list in some time,
> > I still read it most days.  I really should start contributing
> > again.
> 
> Yes, please do. I greatly appreciated your comments and previous
> work on Axiom and Aldor. :)

Thanks for the encouragement!  I enjoyed the prior collaboration very
much.  I will attempt to regroup and get a sense of direction.
 
> If you would like help, I would be glad to post it to the
> 
> http://wiki.axiom-developer.org/AxiomInEmacs
> 
> page on the Axiom Wiki for you. Really you just need to click
> 'edit' and 'Browse' to upload the file.
> 
> Or if you would prefer we could create an 'AldorInEmacs' page
> (add this as a "WikiWord" to the AxiomInEmacs page, save and
> then click the blue ?).
> 
> If you could also provide some brief descriptive paragraph to
> go along with it, I think that would be great. I think this
> aldor-mode is likely of interest to a lot of people.

OK.  I will explore this and upload the code and some sort of
description within the next day or two.

\start
Date: Fri, 12 May 2006 10:16:17 +0700 (NOVST)
From: Andrey G. Grozin
To: Gabriel Dos Reis
Subject: re: Emacs + input syntax

On Fri, 11 May 2006, Gabriel Dos Reis wrote:
> Bill Page writes:
> | On Thursday, May 11, 2006 1:01 PM Ralf Hemmecke wrote:
> | > I would always suggest to forget about the #pile mode when
> | > you program in Aldor ...
> | Why? Your suggestion seems to me only a kind of
> | linguist prejudice.
> I think I'm with Ralf here.  I find the pile notation highly
> confusing and irritating when editing.  It is one of the downsides I
> find with Python, Haskell, Axiom, etc.  For me, it isn't different
> those infamous "tabs" in Makefiles.  It is a relic from stone ages we
> should not carry over.
> Your mileage may vary.
I like python exactly because of indentation-based syntax. It is so 
natural and easy to read.

Comparing it with an unreadable perl, I'd say that { } ; are relics from 
stone age :-)

\start
Date: Fri, 12 May 2006 12:17:02 +0200
From: Christian Aistleitner
To: Ralf Hemmecke, Gabriel Dos Reis
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Hello,

>> Do you really want a type system whose language is not functional?
>
> Actually, I haven't thought about this. I somehow have the feeling tha=
t
> the Aldor compiler implements such a functional type language. But I
> don't know whether this is on purpose.

I do not have this feeling. Quite on the contrary. (Note: we are talking=
  =

about the Aldor compiler, not about the Aldor language)

I came across several situations, where the Aldor compiler gave me error=
  =

messages like:

Dom is of type Cat(Param), but a type Cat(Param) is expected.

So at several places, the compiler did not act functional. However, I  =

cannot recollect an example, as such problems occur very rarely, and  =

typically you try to get rid of such situations.

Long ago, I discussed these matters with Manuel Bronstein and he said th=
e  =

compiler would actually _not_ "know" that Cat(Param) is the same as  =

Cat(Param). It would "guess" so by caching. This would at least explain =
 =

why Cat(Param) is mostly equal to Cat(Param) -- "cache hit", but also  =

sometimes not equal "cache miss".
However, we did not get too much into the details, as we were discussing=
  =

about garbage collection back then.

Maybe things changed.
Maybe I failed to correctly remember, what Manuel told me.
But from my experience I can tell this pictures suits me well.

So I assume from the compiler point of view, Aldor is not functional.


>> | BTW, I would rather say, Integer is a type constant. If Integer() i=
s
>> | defined and works in Axiom then please show me a definition of the
>> | language that makes it clear that if one defines
>>
>> Please, first, show me how you meaningfully work with a type system
>> where the type language is not functional.

I could give lots of examples, were non-determinism comes into play  =

(Randomness of all sorts. Also System specific values -- increasing  =

timestamps from real-time clocks, id's of attached USB devices, ...).
But you could possibly always answer "This is poor design, convert this =
 =

into a function within a package. Then the undeterministic part is hidde=
n  =

in a function within a domain. So the Domain itself can act functional."=


But maybe I do not want to hide those things for whatever reasons?

Additionally, from a language (not compiler!) point of view, I would  =

consider
Dom( Param ): Cat == add { ... }
a function. A function of type Param -> Cat whose value is add { ... }.
Nothing else.
Just a plain function -- nothing special about it.

In that manner, it would be pointless to argue that indeterministic part=
s  =

would have to be hidden inside a function of a package. Because a functi=
on  =

is a function.

To underpin, that the given Dom is a function, look at the attached  =

test.as file. It gives you a a domain in the usual domain syntax and the=
  =

usual function syntax. Introducing DomVar in the variant is necessary,  =

sinc the compiler causes troubles otherwise. But i'd consider that a  =

compiler problem.

To sum it up. From a language point of view, I'd consider a function a  =

function in the computer science sense. No need to restrict to the  =

mathematical interpretation of a functional relation.

However, I agree that the mathematical sense would sometimes be useful.
In an ideal language, I would probably wish for two different function  =

construction mechanisms. One for functional relations, one for functions=
  =

in the computer science sense.
Or at least some marking of functional relations.

> [...]
> shows that Dom and Dom() need not be identical and one can still have =
a
> consistent type system.

I totally agree.

> I would even call it functional (if Dom() always produces the same
> value). It is only that things of type Cat and things of type ()->Cat
> are not identified even if they happen to have the same name.

And at least I am more than happy with that.

> But of course, I could live with that identification if it is clearly
> documented that ()->Cat can be identified with Cat.

I would not. In a fully typed system, I would not be happy with a thing =
 =

having two types.

\start
Date: Fri, 12 May 2006 14:19:19 +0200
From: Ralf Hemmecke
To: Christian Aistleitner
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Christian,

> To underpin, that the given Dom is a function, look at the attached 
> test.as file. It gives you a a domain in the usual domain syntax and the 
> usual function syntax. Introducing DomVar in the variant is necessary, 
> sinc the compiler causes troubles otherwise. But i'd consider that a 
> compiler problem.

Christian is right the following

f(a: A): B == ...

is just syntactic sugar for defining a constant.

f: (a: A) -> B == (a: A): B +-> ...

That is explained in Section 6.5 of http://www.aldor.org/docs/aldorug.pdf

But let's look at Christian's code again. This is now slightly modified.
As you realise from the output, the domain Dom(0) is instantiated only 
once. But this is in accordance to the specification in Section 7.3 of 
the Aldor User Guide. And thus Dom behaves functional.

Maybe it is possible to instantiate Dom(0) twice. I don't have an 
example yet. An anyway this only explains what the compiler does and not 
whether the language specifies a "functional type (sub-)language".

Ralf

--Domtest.as
#include "aldor"
import from Integer;
import from TextWriter, String, Character;

Dom( a: Integer ): with {
     f: () -> Integer
} == {
	import from RandomNumberGenerator, MachineInteger;
	stdout << "Dom " << a << ": " << randomInteger() << newline;
	add {f(): Integer == { next a }}
}

stdout << f()$Dom(0) << newline;
stdout << f()$Dom(0) << newline;

#if OUTPUT
 >aldor -grun -laldor -mno-mactext Domtest.as
#1 (Warning) The file `Domtest' will now be out of date.
Dom 0: 1107506637
1
1
#endif

\start
Date: Fri, 12 May 2006 07:12:52 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke, Francois Maltey
Subject: Re: Emacs + input syntax

--- Ralf Hemmecke wrote:

> > Perhaps (*)
> >   glue lines with a _ at the end to the next one.            
> (inline syntax)
> >   glue lines with a space at beginning to the prvious one.  
> (input syntax)
> >   but cut all the others lines.
> 
> I hope you also consider an error message of Axiom if the expression
> is  syntactically incorrect. In that case I would like the axiomacs 
> mode to jump to the error position (if possible).

Hmm.  That would require either a) Axiom jumping to that location or b)
Emacs somehow being able to identify the error location.  Neither is
simple, but I agree it is very desirable.

A slightly easier alternative might be found with the syntax
highlighting abilities of Emacs - if it is obvious that something is
wrong due to odd syntax highlighting that might prevent the problem
before it starts.  Ralf, I definitely intend to look at your Aldor mode
(and Dr. Watt's if it is available) but I haven't yet gotten to the
Aldor part of the Emacs mode.  I had intended to have the command line
mode support ONLY command-line syntax - there seems to be a demand for
more than that, which is fine, but it's going to be a while since I
myself am still in the process of learning :-/.  I'm grateful for the
bug reports already provided, and I have fixed a few of them already
(upcoming email about that), but there are many more to deal with and
some are not so simple.

The best thing for something like this is to provide some examples I
can use as test cases, but unfortunately I can't promise a quick
response :-/.

\start
Date: Fri, 12 May 2006 07:18:12 -0700 (PDT)
From: Cliff Yapp
To: Stephen Wilson, Ralf Hemmecke
Subject: re: Emacs + input syntax

--- Stephen Wilson wrote:

> Hi Ralf, Cliff,
> 
> Although I have not participated on this list in some time, I still
> read it most days.  I really should start contributing again.
> 
> On Thu, May 11, 2006 at 10:39:07PM +0200, Ralf Hemmecke wrote:
> > Another aldor-mode has been written by Stephen Wilson 
> > <Stephen Wilson>. That is more proper elisp-ish than mine,
> > but  it's not a literate program and I am not aware of a place
> > where this is distributed.
> 
> I still have the code on my hard drive.  I'll send it out to anyone
> who would like a copy. 

Yes please!  Would it be OK to incorporate it/build off of it in a GPL
Axiom mode?

> Perhaps it could be posted on the wiki somewhere.

There is an AxiomInEmacs page here: 
http://wiki.axiom-developer.org/AxiomInEmacs

<red face>  Sorry I called you Dr. Watt - I'm afraid I'm still not
fully awake.

\start
Date: Fri, 12 May 2006 07:36:57 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Emacs updates, fixes

OK, I have tried to address as many of the "low hanging fruit" in the
much-appreciated bug reports as I can.  Here's the current roundup:

Concerns:

1.  second axiom-mode command destroys old keyboard layout
    -  fixed by making the axiom-mode call a function instead
       of a derived mode.  run-axiom and the use-local-map
       set up the mode for the actual terminal - all the other
       does is override the buffer being launched from.  I do
       need to check that emacs -f axiom-mode will work - can
       somebody check that for me?
       
2.  axiom buffer after quit cannot be tweaked
    -  buffer now ends up as text file, but I had to ditch the
       confirmation of quit - it was proving difficult to deal
       with.  Anyway, more fancy options for post-quit can be
       arranged later, but this should suffice for now.
    
3.  line history for multi-line inputs
    -  Multi-line history is not part of comint's default 
       functionality. Perhaps this is already handled by
       someone somewhere - if not, comint's history mechanism
       must be upgraded somehow.
    
4.  First history call from latest input produces an error
    -  just forgot to check for a specific case in some
       cleanup code - fixed

5.  (output 1; output nextPrime (10^280); output 2)
    (output 1; output nextPrime (10^280); output 2)
    Major mess if arrow keys used.
    - This was due to an overly simplistic eval setup - I wasn't
      waiting like I should have for a completed output before
      allowing editing.  Whoops.  I think this is fixed now.
      Basically, the arrow keys shouldn't be ABLE to move.

I haven't attempted anything to do with )read yet, since that's
actually a fairly significant change.

As far as the pile debate is concerned, if they are functionally the
same is it possible to convert from one to the other?  Or maybe a
better question - if you were to add brackets to pile code, would the
indenting still be the "desired" indenting for well written and
formatted code?  If so, it might be possible to have Emacs
automatically convert between the two of them.   I have one or two
ideas of interest concerning pile code, but those are for later.

One comment which might touch on pile code - if you have to get heavily
nested at any point, the default pamphlet latex rendering style is
EXTREMELY narrow.  I know I have problems with that now, and I'm going
to have to manually go back and fix them, but I can do so since I'm not
using pile syntax.   I don't know what I'd do if indentation was
significant.

The latest and greatest is here:  
http://wiki.axiom-developer.org/SandBoxAxiomEmacsMode

\start
Date: Fri, 12 May 2006 17:41:12 +0200
From: Gregory Vanuxem
To: Ralf Hemmecke
Subject: re: Emacs + input syntax

Hi,

Le jeudi 11 mai 2006 =E0 22:39 +0200, Ralf Hemmecke a =E9crit :

> I don't lknow whether you are aware of my aldor-mode
> (http://www.hemmecke.de/aldor) and whether it could be relevant for wha=
t
> you are trying to achieve. (It's a noweb file...)

For information a lot of links on the "Emacs Support for Aldor" page are
incorrect...

\start
Date: Fri, 12 May 2006 17:42:29 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: PATCH: #291 small typo in docs

Hi,


Here is the patch (author unknown):

--- src/doc/book.pamphlet.old 2006-05-12 15:08:27.519363500 +0200
+++ src/doc/book.pamphlet 2006-05-12 15:16:38.822068000 +0200
@@ -1231,11 +1231,11 @@

the result is stored as the fraction 2/1 but is displayed as the integer
2.
This fraction could be converted to type {\tt Integer} with no loss of
-informatin but Axiom will not do so automatically.
+information but Axiom will not do so automatically.

\subsection{Type Conversion}
-To obtain the floating point value of a fraction one must convert (
-{\bf conversions} are applied by the user and 
+To obtain the floating point value of a fraction one must convert
+({\bf conversions} are applied by the user and 
{\bf coercions} are applied automatically by the interpreter) the result
to type {\tt Float} using the ``::'' operator as follows: 

\start
Date: Fri, 12 May 2006 11:45:13 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: PATCH: #291 small typo in docs

patch applied. available in the next release -- t

\start
Date: 12 May 2006 18:58:12 +0200
From: Francois Maltey
To: Cliff Yapp, Francois Maltey
Subject: Re: Emacs updates, fixes

Hello,

I test the axiommode again.

You correct main bugs. The display is much better.

Even if you rewrite arrows functions there are others cursor command,
as [meta >], [meta <], [ctrl N], [ctrl F].

// 1 //
The first axiom-output before (1) -> isn't write-protect.
You may write-protect it.

// 2 //
Can you detect the real pair (input-command, output-command) ?

So I test
[axiom-mode]
123 [return]
[key up]  the cursor is on 123
999 [return]
I get

(1) -> 999123
[result] (2) 999123
(3) -> [input line]
[result] (1) 123
(2) ->

Is it possible to get
(1) -> 123 [the old input]
[result] (1) 123 [the old result]
(2) -> 999123 [the corrected input, with the good prompt]
[result] (2) 999123
(3) -> [axiom is now waiting]

Remember the real input (123 before modification) is possible
if every input is put in a property of a read-only text, by example
in the prompt :

(put-text-property [beginning-of-the-prompt] [end-of-the-prompt]
 'data-for-axiom "the-string 1+23")

When you want to recall the initial display you get it by
(get-text-property [beginning-of-the-prompt] 'data-for-axiom)
  Before you save the new command-line
  then you display the initial command-line.
  You go to the end of the current output
  Move the current prompt to this place
  Insert and save with put-text-property the new command
  Compute-it

// 3 //
The left key is right in all input area, but the right-key go outside
the input area inside the prior calculus.

// 4 //
You disallow the selection of output-data. A great idea.
So the [return] key must do nothing when you aren't between a prompt
(n) -> and an empty-line. (or over read-only area)

But :
[axiom-mode] 123 [return]
[ctrl-p]
Then the cursor is inside the last line (Type: PositiveInteger)
and the return key accept it.
Axiom-mode may reject a command copyed from this output area.

// 5 //
I don't understand the aim of the sit-for functions.
Are they necessary ?

In my emacs programs (for mupad), sit-for allows recursive calls during
inserting results and I get currious error.

// 6 //
Must I get the same result
with commint-mode / commint-run / axiom and axiom-mode ?

\start
Date: Fri, 12 May 2006 14:28:34 -0700 (PDT)
From: Cliff Yapp
To: Francois Maltey
Subject: Re: Emacs updates, fixes

--- Francois Maltey wrote:

> Hello,
> 
> I test the axiommode again.
> 
> You correct main bugs. The display is much better.

Ah, good.  Thanks.
 
> Even if you rewrite arrows functions there are others cursor command,
> as [meta >], [meta <], [ctrl N], [ctrl F].

Do they cause problems?

I never intended to restrict ALL keys - in fact, Jay suggested that
some people interact with Emacs entirely without the mouse.  So I have
tried to make things convenient without being overly restrictive.

> // 1 // 
> The first axiom-output before (1) -> isn't write-protect.
> You may write-protect it.

Probably a good idea - I wasn't sure about that.

> // 2 // 
> Can you detect the real pair (input-command, output-command) ?

Sorry, I don't understand what you are asking here.

> So I test 
> [axiom-mode]
> 123 [return]
> [key up]  the cursor is on 123
> 999 [return]
> I get 
> 
> (1) -> 999123
> [result] (2) 999123
> (3) -> [input line]
> [result] (1) 123
> (2) -> 

What should happen if you do that (if I follow you correctly) is
something like the following:

From:

(1) -> 123
     (1) 123
(2) -> [cursor]

to

(1) -> <red 999[cursor]123 red>
     (1) 123
(2) -> 

to

(2) -> 999123
     (2) 999123
(3) -> [cursor]


> Is it possible to get 
> (1) -> 123 [the old input]
> [result] (1) 123 [the old result]
> (2) -> 999123 [the corrected input, with the good prompt]
> [result] (2) 999123
> (3) -> [axiom is now waiting]

You mean the following?

(1) -> 123
     (1) 123
(2) -> 999123
     (2) 999123
(3) -> [cursor]

Right now it is not.  I specifically wanted to overwrite old
input-output combinations, like most modern notebook interfaces.  Are
you saying you want to be unable to overwrite any input-output
combination?  In my experience that usually leads to messy workspaces. 
The commands are present in the history if you wish to recall them - is
something more needed?

> Remember the real input (123 before modification) is possible
> if every input is put in a property of a read-only text, by example
> in the prompt :
> 
> (put-text-property [beginning-of-the-prompt] [end-of-the-prompt] 
>  'data-for-axiom "the-string 1+23")

What do you mean by "real input?"  (1) is gone, except perhaps
somewhere in Axiom's memory.  Why do you want to view it again?  The
whole point of being able to re-evaluate old inputs, in my view, is to
overwrite them.  Otherwise, why not use the new input prompt at the
end?

I'm not sure how to capture a string from the buffer and put it in a
variable - is "the-string 1+23" a way to do this?  

> When you want to recall the initial display you get it by
> (get-text-property [beginning-of-the-prompt] 'data-for-axiom)
>   Before you save the new command-line
>   then you display the initial command-line.
>   You go to the end of the current output
>   Move the current prompt to this place
>   Insert and save with put-text-property the new command
>   Compute-it

Yes, that might be a way to do it, but personally I prefer NOT to have
that behavior.  I might be able to work out something as an option, but
can I ask why you want this?

> // 3 //
> The left key is right in all input area, but the right-key go outside
> the input area inside the prior calculus.

That was at Jay's suggestion, actually.  I used to confine it to the
input only, but he pointed out that for those who don't use the mouse
such a restriction wasn't terribly useful.  The read-only protection
handles preventing any changes.

> // 4 //
> You disallow the selection of output-data. A great idea.
> So the [return] key must do nothing when you aren't between a prompt 
> (n) -> and an empty-line. (or over read-only area)

Point. Hmm...

> But : 
> [axiom-mode] 123 [return]
> [ctrl-p] 
> Then the cursor is inside the last line (Type: PositiveInteger) 
> and the return key accept it. 
> Axiom-mode may reject a command copyed from this output area.

Really.  Another thing I don't think I tried.  I'll see if I can
duplicate what you describe.

> // 5 // 
> I don't understand the aim of the sit-for functions.
> Are they necessary ?

Don't know.  They came from Jay, and I hesitate to monkey too much with
them.

> In my emacs programs (for mupad), sit-for allows recursive calls
> during inserting results and I get currious error.
> 
> // 6 //
> Must I get the same result 
> with commint-mode / commint-run / axiom and axiom-mode ?

Um - what were you hoping for?  Do you mean you WANT the same result? 
I can link axiom and axiom-mode together perhaps, but comint-mode is a
separate mode altogether and is used by more than just Axiom.

\start
Date: 13 May 2006 17:24:34 +0200
From: Francois Maltey
To: Cliff Yapp
Subject: Re: Emacs updates, fixes

Cliff Yapp writes:

> I never intended to restrict ALL keys
I agree, it's the right way, because it's almost impossible 
to lock ALL emacs keys.

So axiom-mode MUST be able to recognize that the cursor is 
outside an input area. 

> > // 2 // 
> > Can you detect the real area (input-command, output-command) ?
> Sorry, I don't understand what you are asking here.
I speak about the buffer-region from one prompt to the next one.

> What should happen if you do that (if I follow you correctly) is
> something like the following:

> You mean the following?
> 
> (1) -> 123
>      (1) 123
> (2) -> 999123
>      (2) 999123
> (3) -> [cursor]

Yes 

> Right now it is not.  I specifically wanted to overwrite old
> input-output combinations, like most modern notebook interfaces.  
> Are you saying you want to be unable to overwrite any input-output
> combination?  

Yes.
I prefer to keep previous commands on the terminal because I really see 
what I (and students) type before the last correction.
So I find the errors more quickly.

> In my experience that usually leads to messy workspaces. 
> The commands are present in the history if you wish to recall them - is
> something more needed?

> What do you mean by "real input?"  (1) is gone, except perhaps
> somewhere in Axiom's memory.  Why do you want to view it again?  

It's nice to see it always because it's perhaps somewhere in
Axiom's memory.
So I find the bugs of my students if I see the history.

With maple my students do :
 k := 3 ;
 [q[k] $ k=1..4] ; 
Maple gives an error, and I find it much more quickly 
if I see the old line k := 3.

> The whole point of being able to re-evaluate old inputs, in my view, is to
> overwrite them.  Otherwise, why not use the new input prompt at the
> end?
> 
> I'm not sure how to capture a string from the buffer and put it in a
> variable - is "the-string 1+23" a way to do this?  

(buffer-substring 1 122) get the beginning of the buffer.
(setq var (buffer-substring 1 122))

> Yes, that might be a way to do it, but personally I prefer NOT to have
> that behavior.  I might be able to work out something as an option, but
> can I ask why you want this?

I understand your point of view.

If you want short workspace, it's also possible to hide only the output
with a delete-region, and put the substring of the deleted region 
in the prompt with put-text-property. And get it back again with a
(insert (get-text-property...)) if the user wants to make it visible again.

I use maple too often and I disapprove interfaces with re-evaluate.

And for my use I prefer buffer where nothing can be change
after the computation, as a typewriter.

> Yes, that might be a way to do it, but personally I prefer NOT to have
> that behavior.

I accept your point of view, but try to keep the _possibility_ to 
have an axiom-mode where re-evaluate is impossible.
 
> > // 6 //
> > Must I get the same result 
> > with commint-mode / commint-run / axiom and axiom-mode ?
> 
> Um - what were you hoping for?  Do you mean you WANT the same result? 

I have no hope, I only want to know if I can compare
axiom-mode result and comint result in order to understand 
how axiom-mode is working.

You make a really big work.
Continue to send new versions, I try to understand axiom-mode.el 
with the diff command.

\start
Date: Sat, 13 May 2006 15:06:02 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: re: Emacs + input syntax

On Fri, May 12, 2006 at 07:18:12AM -0700, C Y wrote:
> Yes please!  Would it be OK to incorporate it/build off of it in a GPL
> Axiom mode?

Of course.  The code is in fact under the GPL.  If you have any
questions about it feel free to ask.

I just created a new page `AldorInEmacs' on the wiki which contains a
link to the code.

\start
Date: Sat, 13 May 2006 15:56:55 -0700 (PDT)
From: Cliff Yapp
To: Francois Maltey
Subject: Re: Emacs updates, fixes

--- Francois Maltey wrote:

> Cliff Yapp writes:
> 
> > I never intended to restrict ALL keys
> I agree, it's the right way, because it's almost impossible 
> to lock ALL emacs keys.
> 
> So axiom-mode MUST be able to recognize that the cursor is 
> outside an input area. 

That's a bit difficult but I think it can be managed.  I suspect
mmm-mode might be of some service there, if I can ever figure it out
:-/.  Rather than piling on lots of tricks I would prefer to do so once
per "environment" to identify input prompts, output regions, etc and
then all special commands can be part of "sub-modes".  (syntax
highlighting, for example).

> > > // 2 // 

> > You mean the following?
> > 
> > (1) -> 123
> >      (1) 123
> > (2) -> 999123
> >      (2) 999123
> > (3) -> [cursor]
> 
> Yes 
> 
> > Right now it is not.  I specifically wanted to overwrite old
> > input-output combinations, like most modern notebook interfaces.  
> > Are you saying you want to be unable to overwrite any input-output
> > combination?  
> 
> Yes.
> I prefer to keep previous commands on the terminal because I really
> see what I (and students) type before the last correction.
> So I find the errors more quickly.

Hmm.  OK, I can see that.  I should be able to do it as an option.

> > In my experience that usually leads to messy workspaces. 
> > The commands are present in the history if you wish to recall them
> > - is something more needed?
> 
> > What do you mean by "real input?"  (1) is gone, except perhaps
> > somewhere in Axiom's memory.  Why do you want to view it again?  
> 
> It's nice to see it always because it's perhaps somewhere in
> Axiom's memory. So I find the bugs of my students if I see the
> history.

OK.
 
> (buffer-substring 1 122) get the beginning of the buffer.
> (setq var (buffer-substring 1 122))

Ah, excellent.  Thanks!
 
> > Yes, that might be a way to do it, but personally I prefer NOT to
> > have that behavior.  I might be able to work out something as an
> > option, but can I ask why you want this?
> 
> I understand your point of view.
> 
> If you want short workspace, it's also possible to hide only the
> output with a delete-region, and put the substring of the deleted 
> region in the prompt with put-text-property. And get it back again
> with a (insert (get-text-property...)) if the user wants to make it 
> visible again.

I'm not after short so much as I'm after neat - at the end I have only
the commands I need to achieve the result I'm after.  Of course, you
have a point about losing things you might need later - or at least,
making them harder to track down.

> I use maple too often and I disapprove interfaces with re-evaluate.

OK.  That's a reasonable end user request, particularly from someone
who took the trouble to create their own Axiom mode ;-).  I'll see what
I can do about adding it.

One other possible option would be a "sticky prompt" - rather than
having the up arrow return to the previous input lines, it could
instead take the current prompt and insert it back further in the
document.  

> And for my use I prefer buffer where nothing can be change
> after the computation, as a typewriter.

OK.

> > Yes, that might be a way to do it, but personally I prefer NOT to
> > have that behavior.
> 
> I accept your point of view, but try to keep the _possibility_ to 
> have an axiom-mode where re-evaluate is impossible.

I'll plan to add it as an option that can be triggered via a .emacs
file, if that's acceptable.

> > > // 6 //
> > > Must I get the same result 
> > > with commint-mode / commint-run / axiom and axiom-mode ?
> > 
> > Um - what were you hoping for?  Do you mean you WANT the same
> > result? 
> 
> I have no hope, I only want to know if I can compare
> axiom-mode result and comint result in order to understand 
> how axiom-mode is working.

Uh.  comint mode doesn't really do anything by itself - it's just an IO
framework, pretty much.  I'm basically using it without delving any
deeper into its guts than I need to.

> You make a really big work. Continue to send new versions, I try to
> understand axiom-mode.el with the diff command.

That will just point out all of my dumb mistakes :-).  I'm trying to
get to a "regrouping" point where I can leave the "working" version
alone for a while and re-structure based on what I have learned thus
far.  I can feel the "literate" quality of this code getting away from
me as things like the eval command expand in size, so I need to put the
brakes on and get it back under control.

\start
Date: 14 May 2006 02:44:22 +0200
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: PATCH: #291 small typo in docs

Vanuxem Gr=E9gory Gregory Vanuxem writes:

| Hi,
|
|
| Here is the patch (author unknown):

In the silver branch as of revision 37.

\start
Date: Sun, 14 May 2006 20:04:51 +0200
From: Christian Aistleitner
To: Ralf Hemmecke
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Hello,

On Fri, 12 May 2006 14:19:19 +0200, Ralf Hemmecke wrote:
> Maybe it is possible to instantiate Dom(0) twice.

you will probably not have any luck with 0. It is too small. But what  
about 1073741824?
For those who cannot convert dec to hex on the fly: "But what about  
0x40000000?" :)

The upcoming part is not clearly an example in favor of Ralf's requirement.
However, it is pretty close and shows some nasty things.
I do not understand how these things work, so anybody having _any_  
information on this, please share.
(Hopefully, I did not make an obvious mistake in the code again ...)


Executing the compiled test2.as (I attached this test2.as to the mail), I  
get:

(i)Domain ( param : 1073741824) -- r: 336495754
(i)(d)(i)Domain ( param : 1073741824) -- r: 2058543685
inc            : 336495754
inc dec inc    : 2058543685
----
(i)(i)(d)(i)
----
a              : 336495754
b              : 2058543685

(You will most likely get different numbers)
Since the code is not too straight forward, let me explain what happens.

(i)Domain ( param : 1073741824) -- r: 336495754
(i)(d)(i)Domain ( param : 1073741824) -- r: 2058543685

We get two different (see the different r) instantiations of Dom, both  
with the parameter "param" being 1073741824.

If now you are thinking that this behaviour is obvious, as the parameter  
"param" is computed two times and is therefore stored two times, then you  
are right.
They are two different representations for the same number. No doubt. (We  
could discuss what "functional" really means in the context of data  
representations. But I guess its ok to get different instantiations for  
different representations of the same number)
So the two parameters are equivalent (they store the same number), but not  
equal (they store the information differently--at least at different  
positions in memory).

However, Aldor *magically* knows something, about 1073741824 and its  
representations.
Why? Because of the lines:
a              : 336495754
b              : 2058543685

For these lines, 1073741824 is derived again in two different forms.  
However, no new instantiation of Dom is made. So we have four equivalent,  
but different representations and Aldor "knows" that two of them are  
equivalent.
Aldor "knows" that "a" is equivalent to the first inc NUM.
Aldor "knows" that "b" is equivalent to the first inc dec inc NUM.

We are tempted to think that this is some effect from recycling or  
preinitializing the constants.
But I oppose by referring to the lines
----
(i)(i)(d)(i)
----
. There, the increase and decrease functions are called again in order to  
actually compute the values again.

Does not look like reusing values to me.

How to explain this behaviour?
I am not sure.
However, recollecting what Manuel told me, the use of caching might  
explain things a bit.
But maybe its just some caching on BInt?
Do BInts have a sense for history? -- This would explain the whole thing.

Some further remarks:
Try to introduce a third representation of 1073741824 and the compiler  
produces segfaulting code.

For example: Add
stdout << "inc inc dec   : " << f()$Dom( inc inc dec NUM ) << newline;
or
stdout << "1073741824    : " << f()$Dom( 1073741824 ) << newline;

Since I am somehow puzzled but the whole thing, I would like to close this  
mail by a big questionmark.

   ****
  **  **
  **  **
      **
     **
    **
    **

    **
    **

\start
Date: 14 May 2006 20:56:09 +0200
From: Gabriel Dos Reis
To: Christian Aistleitner
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Christian Aistleitner writes:

[...]

| Does not look like reusing values to me.
| 
| How to explain this behaviour?

Please, guys explain clearly you're after.  

I do not take the compiler's behaivour as "God given".  I need clear
semantics.  If you're after a non-functional type system, please explain
clearly what they are useful for, with clear examples.  Explain also
how one reasons with such type system, how one writes relaible program
with such a type system.

\start
Date: Mon, 15 May 2006 03:36:11 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt, Christian Aistleitner

> Please, guys explain clearly you're after.

Trying to clarify what the Aldor compiler does and what it should do.

> I do not take the compiler's behaivour as "God given".

Of course.

> I need clear semantics.

Of course. But what Christian's program from

http://lists.nongnu.org/archive/html/axiom-developer/2006-05/msg00181.html

does is to exhibit a bug either in the Aldor compiler or the 
documentation. I don't think that one can find any better documentation 
than Section 7.3 "Type context" in http://www.aldor.org/AldorUserGuide/.

Interestingly, if the documentation where better, I would even say that 
despite the lines

local a == inc NUM;
local b == inc dec inc NUM;
stdout << "a              : "; stdout << f()$Dom(a); stdout << newline;
stdout << "b              : "; stdout << f()$Dom(b); stdout << newline;

give different output in Christian's program, the compiler still behaves 
  functional. The problem is that the documentation should be more 
precise of what "a equals b" in the above context actually means.

If we replace Integer by TextWriter in Christian's program and do 
something like

stdout << f()$Dom(stdout);
stdout << f()$Dom(stderr);

of course most people would say that it is clear that the output might 
be different because

"stdout is not equal to stderr".                                 (*)

But how can one say that? stdout and stderr are of type TextWriter and 
that type does not export any equality. So the only chance one has to 
give meaning to (*) is to mean pointer equality. I cannot remember that 
I have ever read this in the Aldor User Guide.

 > If you're after a non-functional type system, please explain
> clearly what they are useful for, with clear examples.  Explain also
> how one reasons with such type system, how one writes relaible program
> with such a type system.

I, for my part, did never claim that I want a non-functional type 
system. I actually learned through this thread that a functional one 
would be a good thing.

I am sure you could give a reference to illustrative examples that show 
serious problems. Not everyone has studied those things in his/her career.

Ralf

PS: Apart from clarification of functionality of the type system 
Christian's program also shows that its behaviour depends on the 
implementation of AldorInteger. One might get different results on 32 
and 64 bit machines. It's already interesting that one has to take quite 
big integers to make a and b into "different" things.

\start
Date: 15 May 2006 06:21:52 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt, Christian Aistleitner


Ralf --

   Many thanks for the explanation.  You message helped me understand
better Christian's.  Now, I think I see what he was getting at.
Thanks.

\start
Date: Mon, 15 May 2006 13:19:02 +0200
From: Ralf Hemmecke
To: Gregory Vanuxem
Subject: re: Emacs + input syntax

Thank you Greg,

I've corrected the broken links.

Ralf

On 05/12/2006 05:41 PM, Vanuxem Gr=E9gory wrote:
> Hi,
>
> Le jeudi 11 mai 2006 =E0 22:39 +0200, Ralf Hemmecke a =E9crit :
>
>> I don't lknow whether you are aware of my aldor-mode
>> (http://www.hemmecke.de/aldor) and whether it could be relevant for what
>> you are trying to achieve. (It's a noweb file...)
>
> For information a lot of links on the "Emacs Support for Aldor" page are
> incorrect...

\start
Date: Mon, 15 May 2006 16:58:13 +0200
From: Christian Aistleitner
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Hello Gaby,

On Sun, 14 May 2006 20:56:09 +0200, Gabriel Dos Reis  
Gabriel Dos Reis wrote:

> If you're after a non-functional type system,

I think, we all agree that for any programming language, it is good to  
have _non_ functional functions.
Just think about a system call time() behaving functional.

Besides, I am looking for a language, where same formalisms are treated in  
the same way.
For example all functions should be treated equal.
If one function is allowed to behave non-functional, all functions should  
be allowed to do so.

I'd like to model parametric categories and parametric domains by  
functions, as I described before -- it just seems natural.
Since there are non-functional functions, I'd allow all functions to be  
non-functional.

So finally, I am maybe after a non-functional type system.

> please explain
> clearly what they are useful for, with clear examples.

My previous examples in this directlions were probably not explicit enough:

System(): with {
   timestamp: Integer;
   cpuTemperature: Integer;
} == add {
   timestamp: Integer == { obtain the timestamp somehow }
   cpuTemperature: Integer == { obtain the timestamp somehow }
}

Of course, you can rewrite it to

System: with {
   grabData: () -> %
   timestamp: % -> Integer;
   cpuTemperature: % -> Integer;
} == add {
   macro Rep == Record( ts: Integer, temp: Integer );

   grabData(): % == {
      per record( obtain the timestamp somehow, obtain the temperature  
somehow );
   }

   timestamp( a: % ): Integer == { (rep a) . ts; };
   cpuTemperature( a: % ): Integer == { (rep a) . temp; };
}

, but would that be better? The latter version is the one we are more used  
to, but is it really better?
To determine the given temperature and timestamp for the system involves 1  
Function call for non functional Domains and 3 for functional Domains.

Of course, you can do a lot of rewriting tricks to say "non functionality"  
is not needed.
Of course, you can introduce a lot of "this is bad design" axioms to say  
"non functionality" is not needed.

But I think, non functionality would not be the baddest thing in the world.
As I said before, to me it looks like the compiler behaves non-functional,  
but uses fancy techniques to get functionality, wherever "this might me  
nice". I am sorry that I cannot give a more precise definition, since I do  
not have access to the compiler sources.

But consider, we had a completely non functional Aldor compiler (which we  
do not have). Would this compiler really lead to problems. I suppose not.  
Because in most cases, we have the types of interest in a constant form  
(e.g.: as parameter to a domain) and do not have to instantiate at all.

For example re-consider the SparseUnivariatePolynomial Integer example  
 from Ralf
http://www.aldor.org/pipermail/aldor-l/2006-May/000198.html

Ralf> Surely, it would sound strange if I say:
Ralf>
Ralf> a: SparseUnivariatePolynomial Integer := ...
Ralf> b: SparseUnivariatePolynomial Integer := ...
Ralf>
Ralf> and the compiler would reject
Ralf>
Ralf> a + b
Ralf>
Ralf> because it could not figure out that a and b are of the same type

What Ralf wanted to have is that the two invokations of  
SparseUnivariatePolynomial refer to the same value.
For several reasons, it is important to tell the compiler everything you  
know about your code. But Ralf did not. If he would, the code would look  
like:

Poly == SparseUnivariatePolynomial Integer
a: Poly := ...
b: Poly := ...
and of course, the compiler would correctly recognize the + in
a+b

Furthermore, I the two approaches (functionality and non-functionality)  
are not completely different.
A functional type system can be used to "simulate" a non-functional one by  
adding the current time as parameter.
E.g.:
List( T: Type, timestamp: Integer == getCurrentTimestamp() ): with {
   ...
} == add {
}

So, calling List( Integer ) twice gives two different Instances, as the  
timestamp changed.

A non-functional type system can be used as a functional one by using  
constants.

ListInteger == List( Integer );
local a: ListInteger := empty$ListInteger;
local b: ListInteger := (insert!$ListInteger)( ... );

So you can get more or less the same behaviour ... If you want to.

> Explain also
> how one reasons with such type system, how one writes relaible program
> with such a type system.

Could you give an example in the functional world of what you mean by  
"reason"?

\start
Date: 15 May 2006 18:05:29 +0200
From: Gabriel Dos Reis
To: Christian Aistleitner
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Christian Aistleitner writes:

| Hello Gaby,
| 
| On Sun, 14 May 2006 20:56:09 +0200, Gabriel Dos Reis  
| Gabriel Dos Reis wrote:
| 
| > If you're after a non-functional type system,
| 
| I think, we all agree that for any programming language, it is good to  
| have _non_ functional functions.
| Just think about a system call time() behaving functional.

Indeed.  I'm not saying the whole language should be functional.  I'm
converned with the type system.

The type system allows for checking that expectations of functions are
met by their arguments.  That checking, and reasoning in general,
requires that we can replace equals for equals. If I defined a
function with a given type (the type is evaluated to some type value), an
later defined a variable or value of the same type (but this time, it
gets evaluated to another type value), how can I even call the
function with that variable?  And if the system let me do it, how can
I prove that the call and the result are sound?

| Besides, I am looking for a language, where same formalisms are treated in  
| the same way.
| For example all functions should be treated equal.

The troubel is terms and types are generally of the "kind".  This
whole point get back the Russell paradox, and solving it is what
prompted Russell to ivnent type theory.  
Even in the Calculus of Construction (of Thierry Coquand), there is a
sort of hierarchy.  It does seem like suppressing those differences
lead back directly to a form of Russell paradox.

| If one function is allowed to behave non-functional, all functions should  
| be allowed to do so.

I suspect there are functions, and functions :-)

| I'd like to model parametric categories and parametric domains by  
| functions, as I described before -- it just seems natural.

I understand the desire. However, my point is that if you have the
notion of terms and types (types are inhabited by terms), then there
must be a distinguishing property.  I suspect that the difference of
"functions" is close to it.

| Since there are non-functional functions, I'd allow all functions to be  
| non-functional.
| 
| So finally, I am maybe after a non-functional type system.
| 
| > please explain
| > clearly what they are useful for, with clear examples.
| 
| My previous examples in this directlions were probably not explicit enough:
| 
| System(): with {
|    timestamp: Integer;
|    cpuTemperature: Integer;
| } == add {
|    timestamp: Integer == { obtain the timestamp somehow }
|    cpuTemperature: Integer == { obtain the timestamp somehow }
| }

If this must be a type, what are the terms that inhabit it?

| 
| Of course, you can rewrite it to
| 
| System: with {
|    grabData: () -> %
|    timestamp: % -> Integer;
|    cpuTemperature: % -> Integer;
| } == add {
|    macro Rep == Record( ts: Integer, temp: Integer );
| 
|    grabData(): % == {
|       per record( obtain the timestamp somehow, obtain the temperature  
| somehow );
|    }
| 
|    timestamp( a: % ): Integer == { (rep a) . ts; };
|    cpuTemperature( a: % ): Integer == { (rep a) . temp; };
| }
| 
| , but would that be better? The latter version is the one we are more used  
| to, but is it really better?

I would claim is it better.  However, I would challenge the claim that
the former is a function that define types.

| To determine the given temperature and timestamp for the system involves 1  
| Function call for non functional Domains and 3 for functional Domains.
| 
| Of course, you can do a lot of rewriting tricks to say "non functionality"  
| is not needed.
| Of course, you can introduce a lot of "this is bad design" axioms to say  
| "non functionality" is not needed.

My objections are not at the level of rewriting or "this is bad
design" argument.  They are more fundamental. 

[...]

| > Explain also
| > how one reasons with such type system, how one writes relaible program
| > with such a type system.
| 
| Could you give an example in the functional world of what you mean by  
| "reason"?

By "reason", I meant essentially proof as in.

    http://www.nuprl.org/
    http://coq.inria.fr/
    http://www4.in.tum.de/~nipkow/LNCS2283/


If I do not have a functional type system, how am I supposed to do 
"separate compilation"?  How am I supposed to do calls?

\start
Date: Tue, 16 May 2006 00:35:36 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt, Christian Aistleitner

> | System(): with {
> |    timestamp: Integer;
> |    cpuTemperature: Integer;
> | } == add {
> |    timestamp: Integer == { obtain the timestamp somehow }
> |    cpuTemperature: Integer == { obtain the timestamp somehow }
> | }
> 
> If this must be a type, what are the terms that inhabit it?

In Aldor there are packages and domains. Their only difference is that 
the latter exports something involving %. The above code doesn't do this 
so it is a package. In oo-speak its a class that only exports static 
constants. There are no instantiations of elements of that package.

> | Of course, you can rewrite it to
> | 
> | System: with {
> |    grabData: () -> %
> |    timestamp: % -> Integer;
> |    cpuTemperature: % -> Integer;
> | } == add {
> |    macro Rep == Record( ts: Integer, temp: Integer );
> | 
> |    grabData(): % == {
> |       per record( obtain the timestamp somehow, obtain the temperature  
> | somehow );
> |    }
> | 
> |    timestamp( a: % ): Integer == { (rep a) . ts; };
> |    cpuTemperature( a: % ): Integer == { (rep a) . temp; };
> | }
> | 
> | , but would that be better? The latter version is the one we are more used  
> | to, but is it really better?

> I would claim is it better.  However, I would challenge the claim that
> the former is a function that define types.

I would also claim the second is better. Christian, if you call the 
first System() only once then you wouldn't make it a function, but you 
certainly like to call System() several times.

> | To determine the given temperature and timestamp for the system involves 1  
> | Function call for non functional Domains and 3 for functional Domains.

I guess you are wrong.

In the first case, each time you want a time-temperature pair you must 
do like...

S == System();
t := timeStamp$S;
T := cpuTemperature$S;

in the second case it is

d := grabData()$System;
t := timeStamp(d)$System;
T := cpuTemperature(d)$System;

So what do you gain?

> If I do not have a functional type system, how am I supposed to do 
> "separate compilation"?  How am I supposed to do calls?

I first thought you make a point, but

Cat1: Category == with {..}

Cat1 is a constant. Fine.


Cat2(R: Sometype): Category == with {...}

is equivalent to

Cat2: (R: SomeType) -> Category =   (R: SomeType): Category +-> with {...}

Again Cat2 is a constant. Also fine.

Dom1: Cat2(blah) == add {...}

That is a constant. But it should not be defined that way. In order to 
avoid complications it should be done via

Cat2BLAH == Cat2(bla);
Dom1: Cat2BLAH == add {...}

because later you might want to ask

if Dom1 has Cat2(blah) then ...

Of course, with a non-functional type system that might turn out to be 
false.

So, for every domain whose category involves a parameter one has to 
introduce a constant category with exactly that parameter. The same 
happens one level down. For every element of a parametrised domain, one 
has to introduce a constant domain (without parameter) before the 
element can be defined.

I have the impression that soon becomes unhandy. So I feel more on 
Gaby's side. Non-functional language at the element level, functional at 
type level.

But it has to be discussed what "equality of arguments" actually means 
in order to be able to speak about the functionality property, since not 
every type exports "=: (%, %) -> %".

\start
Date: 16 May 2006 10:13:17 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt, Christian Aistleitner

Dear all,

I find it quite hard to follow your discussion, but maybe you can help me out:

Ralf Hemmecke writes:

> Interestingly, if the documentation where better, I would even say that
> despite the lines
> 
> local a == inc NUM;
> local b == inc dec inc NUM;
> stdout << "a              : "; stdout << f()$Dom(a); stdout << newline;
> stdout << "b              : "; stdout << f()$Dom(b); stdout << newline;
> 
> give different output in Christian's program, the compiler still behaves
> functional. The problem is that the documentation should be more precise of
> what "a equals b" in the above context actually means.
> 
> If we replace Integer by TextWriter in Christian's program and do something
> like
> 
> stdout << f()$Dom(stdout);
> stdout << f()$Dom(stderr);
> 
> of course most people would say that it is clear that the output might 
> be different because
> 
> "stdout is not equal to stderr".                                 (*)

Where does it say that Dom(x) and Dom(y) should be the same, even if x and y
are equal in some sense?

I would imagine that Dom(x) and Dom(y) are the same, (i.e., instantiated only
once) if x and y are the same, i.e., if (eq x y) as opposed to (equal x y), but
I'd be interested to find something about this in the documentation.

I'd leave it unspecified.

\start
Date: Tue, 16 May 2006 12:09:52 +0200
From: Christian Aistleitner
To: Gabriel Dos Reis
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Hello,

> I'm
> converned with the type system.
>
> The type system allows for checking that expectations of functions are
> met by their arguments.  That checking, and reasoning in general,
> requires that we can replace equals for equals. If I defined a
> function with a given type (the type is evaluated to some type value), an
> later defined a variable or value of the same type (but this time, it
> gets evaluated to another type value), how can I even call the
> function with that variable?  And if the system let me do it, how can
> I prove that the call and the result are sound?

I designed the some really bad case for functional type systems and  
implemented it assuming Aldor would be functional (function.as) and  
assuming it is not functional (not_functional.as).

I do not see any problems with reasoning in both examples. As I already  
explained in my previous mail:
You can use a functional type system to simulate a non functional one.
And you claim it is possible to reason in a functional type system (which  
I do not doubt).

So, using your method of reasoning and my method of expressing non  
functionality by a functional type system allows you to reason in a non  
functional type system.

You can reason in a system with List( Integer ) and List( Character )  
being different. So it should not be a problem to reason in a system with  
List( Integer, timestamp ) and List( Integer, different timestamp ).

> | Besides, I am looking for a language, where same formalisms are  
> treated in
> | the same way.
> | For example all functions should be treated equal.
>
> The troubel is terms and types are generally of the "kind".

Sorry, but I am not familiar with the word "term" in this context. You  
probably do not mean terms as used for polynomials and probably also not  
term as in "mathematical expression" or as used in formal grammars.

Since large parts of your mail deal with "term" I'd better postpone the  
rest of my answer until I understand what you mean by "term".

\start
Date: Tue, 16 May 2006 14:46:31 +0200
From: Christian Aistleitner
To: Ralf Hemmecke, Gabriel Dos Reis
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Hello,

On Tue, 16 May 2006 00:35:36 +0200, Ralf Hemmecke  
Ralf Hemmecke wrote:

>> | System(): with {
>> |    timestamp: Integer;
>> |    cpuTemperature: Integer;
>> | } == add {
>> |    timestamp: Integer == { obtain the timestamp somehow }
>> |    cpuTemperature: Integer == { obtain the timestamp somehow }
>> | }
[...]
>> | | System: with {
>> |    grabData: () -> %
>> |    timestamp: % -> Integer;
>> |    cpuTemperature: % -> Integer;
>> | } == add {
>> |    macro Rep == Record( ts: Integer, temp: Integer );
>> | |    grabData(): % == {
>> |       per record( obtain the timestamp somehow, obtain the  
>> temperature  | somehow );
>> |    }
>> | |    timestamp( a: % ): Integer == { (rep a) . ts; };
>> |    cpuTemperature( a: % ): Integer == { (rep a) . temp; };
>> | }
>
> I would also claim the second is better. Christian, if you call the  
> first System() only once then you wouldn't make it a function, but you  
> certainly like to call System() several times.

Yes, certainly. Consider the following piece of code:

printSystemStats(): () == {
	import from System(), ...;
	stdout << cpuTemperature << "  " << timestamp << newline;
}

monitor(): () == {
	repeat {
		printSystemStats();
		some code to sleep 10 seconds
	}
}

There, System() would get called again and again. Every ten seconds a new  
instance.

>> | To determine the given temperature and timestamp for the system  
>> involves 1  | Function call for non functional Domains and 3 for  
>> functional Domains.
>
> I guess you are wrong.
>
> In the first case, each time you want a time-temperature pair you must  
> do like...
>
> S == System();
> t := timeStamp$S;
> T := cpuTemperature$S;
>
> in the second case it is
>
> d := grabData()$System;
> t := timeStamp(d)$System;
> T := cpuTemperature(d)$System;
>
> So what do you gain?

Again: The first piece of code has one function call ... namely System().  
Then obtaining timeStamp and cpuTemperature is getting constants and not  
calling functions.
1 function call.

In the second case, grabData() is "calling a function". Same holds for  
timeStamp(d) and cpuTemperature.
3 function calls.

In a general setting, calling functions is slow, so we do not want to do  
it often.

Again. I am not saying, this is the way to go ... It is just an example,  
where non functionality might be usefull.

>> If I do not have a functional type system, how am I supposed to do  
>> "separate compilation"?  How am I supposed to do calls?
>
> [ Ralf clairifying how it can be done ]

Also have in mind, that "with" statements are a anonymous. You can check  
whether

Dom: with {
  f:() -> ();
  g:() -> ();
}

has the f function by

Dom has with { f:() -> (); }

Note that these are two completely different with statements!

> But it has to be discussed what "equality of arguments" actually means  
> in order to be able to speak about the functionality property, since not  
> every type exports "=: (%, %) -> %".

This is the main point to the whole discussion and the main drawback of  
functionality. "How to check equality"?
Even and if everything exports "=", we do not know about the semantics of  
"=". We would have to bind them :(.
The interesting part is that with in a purely functional setting we will  
also run into troubles soon, when using pointer comparison:

DomA( a: List Integer ):with {...} == add {...}

a: List Integer := [ 1, 2, 3 ];
R == DomA( a );
a . 2 := 300;
S == DomA( a );

a still refers to the same memory location, but it is different. Would R  
equal S?

\start
Date: Tue, 16 May 2006 15:08:16 +0200
From: Ralf Hemmecke
To: Christian Aistleitner
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

> DomA( a: List Integer ):with {...} == add {...}
> 
> a: List Integer := [ 1, 2, 3 ];
> R == DomA( a );
> a . 2 := 300;
> S == DomA( a );
> 
> a still refers to the same memory location, but it is different. Would R 
> equal S?

Well, here I would comment the following.

a.2 := 300

is the same as

set!(a, 2, 300)

Everyone sees the exclamation mark? This exclamation mark is a 
_convention_ in Aldor to say that a function is destructive, ie it 
destroys one of its parameters.

And the comment is: If you use destructive functions, you might earn 
speed but you have to take care of correctness yourself. Basically, by 
using destructive functions one can introduce as nasty things as one 
wants. The above code snippet is just such an example of such a nasty thing.


\start
Date: Tue, 16 May 2006 16:56:44 +0200
From: Christian Aistleitner
To: Ralf Hemmecke
Subject: functional type system using pointer comparisons to check equality 
Cc: Stephen Watt

Hello,

On Tue, 16 May 2006 15:08:16 +0200, Ralf Hemmecke wrote:

>> DomA( a: List Integer ):with {...} == add {...}
>>  a: List Integer := [ 1, 2, 3 ];
>> R == DomA( a );
>> a . 2 := 300;
>> S == DomA( a );
>>  a still refers to the same memory location, but it is different. Would  
>> R equal S?
>
> Well, here I would comment the following.
>
> a.2 := 300
>
> is the same as
>
> set!(a, 2, 300)
>
> Everyone sees the exclamation mark? This exclamation mark is a  
> _convention_ in Aldor to say that a function is destructive,

Yes.

> ie it destroys one of its parameters.

No. It may destroy _all_ of its parameters. But thats not the point.

Since it is hard -- or rather impossible -- for a developer to deceide  
whether or not a value he returns will be or has been used in a type  
constructing function, you'd practically forbid using destructive  
functions at all.
You'd not even be allowed to act destructivly on a value you just copied:

SomeDom: with {
   CopyableType;
   ...
} == add {
   copy( a: % ): % == {
     local copiedValue: %;
     ...
     copiedValue := ...;
     ...
     assert( hasBeenProperlyCopied $ ProperlyCopiedHelperDomain( a,  
copiedValue ) );
     copiedValue;
   }
   ...
}

local a: SomeDom := ...
local b: SomeDom := copy a;
destructiveFunction!( b ); -- b has already been used in via copiedValue  
in ProperlyCopiedHelperDomain( a, copiedValue ).

So practically no destructive functions...
I wouldn't want to have a functional-type system performing equality  
checks by comparing pointers.
Besides, huge Integers representing the same number most likely do not  
share the same memory.
Besides, Lists of the same integers most likely do not share the same  
memory.
Most "elements of domains", which represent the same value most likely do  
not share memory. However, they can be used as parameters to domain  
constructing functions. What would be the worth of "functionality" if it  
stops there?

\start
Date: Tue, 16 May 2006 19:36:25 +0200
From: Gregory Vanuxem
To: axiom-developer <list>
Subject: space in ++ description

Hi,

Can someone explain me why
 
      myfunc1: Z -> Boolean
      ++ myfunc1(z) computes a wonderful thing.
      ++                  SIDE = 'L'     SIDE = 'R'
      ++  TRANS = 'N':      Q * C          C * Q
      ++  TRANS = 'T':      Q**T * C       C * Q**T

is correctly displayed in hyperdoc but not

      myfunc2: Z -> Boolean
      ++ myfunc2(z) computes another wonderful thing.
      ++  A * P = Q * [ R11 R12 ]
      ++              [  0  R22 ]

?

So, how can I write the myfunc2 description such that it is correctly
displayed in an editor (and in verbatim environment) and in hyperdoc ?
Is there some special commands ?


Cheers,

Greg

PS : Attached is a test package if you want to experiment with this.
Description is available via "Browse"->`type the name of the operation`
->"Operations"

--=-80Sib68yfLCb8x4tKomZ

)abbrev package MYTEST MyTest
MyTest() : Exports == Implementation where 
  Z ==> Integer
  Exports == with
      myfunc1: Z -> Boolean
      ++ myfunc1(z) computes a wonderful thing.
      ++                  SIDE = 'L'     SIDE = 'R'
      ++  TRANS = 'N':      Q * C          C * Q
      ++  TRANS = 'T':      Q**T * C       C * Q**T
      myfunc2: Z -> Boolean
      ++ myfunc2(z) computes another wonderful thing.
      ++  A * P = Q * [ R11 R12 ]
      ++              [  0  R22 ]

  Implementation == add

      myfunc1(n)== one? n
      myfunc2(n)== zero? n

\start
Date: Tue, 16 May 2006 22:16:59 +0200
From: Ralf Hemmecke
To: Gregory Vanuxem
Subject: Re: space in ++ description

Hi Greg,

very nice that you have trouble with that. ;-)

No, you are not alone. I have NEVER seen a clear explanation of how
++ comments should be written. And that was one of the reasons why I
finally decided to introduce my own syntax (which is just a set of 5 TeX 
commands

\adtype \adthistype  (markup for types)
\adname \adthisname  (markup for constants and functions)
\adcode              (markup for code pieces)

and the following environments

adusage
adparameters
addescription
adexception
adremarks
adseealso
adsnippet  (for longer pieces of code)

and additionally the WHOLE power of LaTeX.

If you want to find out more look at the section about aldordoc.sty in
ALLPROSE. And if you follow some simple and natural conventions in
ALLPROSE, you will even get all things hyperlinked (in pdf, dvi, and
html). No way, however, to help you to produce nice things for hyperdoc.

I hope some day the aldordoc.sty way of typesetting +++ comments becomes 
standard.

Anyway, you should write in a literate programming style. Your code
looks as if you are doing something else. ;-)

On 05/16/2006 07:36 PM, Vanuxem Gr=E9gory wrote:
> Hi,
>
> Can someone explain me why
> 
>       myfunc1: Z -> Boolean
>       ++ myfunc1(z) computes a wonderful thing.
>       ++                  SIDE = 'L'     SIDE = 'R'
>       ++  TRANS = 'N':      Q * C          C * Q
>       ++  TRANS = 'T':      Q**T * C       C * Q**T
>
> is correctly displayed in hyperdoc but not
>
>       myfunc2: Z -> Boolean
>       ++ myfunc2(z) computes another wonderful thing.
>       ++  A * P = Q * [ R11 R12 ]
>       ++              [  0  R22 ]
>
> ?

\start
Date: Tue, 16 May 2006 14:57:31 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Of pamphlets, volumes, and algebra

Back in November, Tim gave the following as an overall "structure"
within which we will be working to define, describe, and document the
Axiom system.

vol 1:  tutorial
vol 2:  programming
vol 3:  reference
vol 4:  developers guide
vol 5:  interpreter
vol 6:  compiler
vol 7:  browser
vol 8:  hyperdoc
vol 9:  algebra
vol 10: numerics

1-4 are not literate documents in the sense of being both documentation
and source code, so they pose no serious complications and can be
handled without difficulty as normal latex documents.

5+ are more complex, because they involve literate programming in its
true sense.  Fortunately, the interperter and compiler are both well
defined conceptually, and we have sufficient tools and mechanisms in
place to make this workable.  I'm thinking vol 6 will be postponed
until Aldor becomes Free (if it does) but Tim has already started on
vol. 5.

7 and 8 I am slightly less clear on - is hyperdoc the current graphical
environment for interacting with Axiom?  Is the browser a pamphlet
browser, or the wiki environment?  will the hyperdoc volume become the
UI volume if a new "standard" graphical interface/environment is
created?  Would graphing techniques be part of one of these volumes? 
That's far enough in the future that these questions are premature -
just curious.

Volumes 9 and 10 are my real concern.  I agree algebra and numerical
categories are a logical breakdown from a user standpoint, but they are
both so incredibly huge as categories that each one might in itself
consititute several large volumes.

Is the plan to simply not publish these volumes as printed works?  I
suppose that might be logical but it would be a shame - if the Axiom
project realizes its full ambition and reaches a "stable" configuration
I would rate it as a must for any serious university library.  It is
true that it changes frequently but the same might be said of the
Oxford Unabridged dictionary (assuming it is kept current with the
living language) and that is a staple of most large libraries.

Also, most algebra work exists as discrete pamphlets which concentrate
on a single subject - these will need to be integrated into volumes and
as of now our automatic mechanisms cannot achieve this.  And if people
write papers as pamphlets and publish them, those too will need to be
incorporated while remaining available as individual entities.

Wouldn't it make sense to organize the algebraic and numerical volumes
of Axiom according to accepted mathematical cagetories, insofar as this
can be done?  I have no idea how many that would prove to be or what
the form of it would take, beyond the vague notion of building logicly
from a foundation to "high level" math, but it seems to me that we
might want to organize along some such lines.  We have discussed in the
past the need for some kind of organized mapping of mathematical fields
and how they inter-relate - as we develop this map, couldn't we use it
to break down "algebra" into more useful chuncks?  Maybe (just as an
example, I'm sure this is wrong:)

Volume 9.1  Category Theory
Volume 9.2  Numbers - Integers, Floats, Reals, Complex, etc.
Volume 9.3  Polynomial Equations
Volume 9.4  Matricies, Arrays, Vectors and Operations on Them
Volume 9.5  Series, Limits, etc.
Volume 9.6  Special Functions
Volume 9.7  Calculus - Differentiation and Integration
Volume 9.8  Differential Equations
etc. etc. etc.
Volume 10.1 Fundamental Numerical Methods
Volume 10.2 <insert logical topics here>
Volume 11.1 Fundamentals of Descriptive Systems - Physical, Economic,
etc.
Volume 11.2 Physics
Volume 11.3 Chemistry
Volume 11.4 Economics

etc. etc. etc.

Then we can assign each pamphlet a "category" from the list of volumes,
and (maybe) establish coding standards such that each pamphlet written
on a particular subject is ready to be plugged into the file defining
the volume in question.  I don't have a clear idea how to do that yet
(or rather a clear idea that would be accepted, since the most obvious
way involves a separation of content from preambles.)

One advantage of this would be that it would make it relatively simple
for a specialist to judge Axiom's abilities within a particular field,
and what is needed.  Also, the bibliography included with each volume
of this nature would be far more useful as an overview of the field,
because it would be separate from the huge core bibliography.  Indeed,
my favorite idea is a per-chapter (or per-pamphlet) bibliography style,
with a per-volume bibliography at the end if comprehensiveness is need
or required.  We might want a "last edited" date in each pamphlet as
well, so we know how current the work on a particular subject is and
where to start looking for research not yet considered.

Sorry if I'm not terribly focused, but I started considering the
bibliography problem again today and it brought a lot of issues to
mind.  Clearly we will need to standardize reference names and
accomidate DOI, arXiv, and other citation styles whenever possible, but
that's just a beginning.  The potential scope of Axiom suggests it must
organize virtually all mathematics into a coherent structure which is
understandable and extendable.  So I guess my real question is - inside
Vol 9, how are we planning to organize?

\start
Date: Tue, 16 May 2006 21:21:46 -0400
From: Tim Daly
To: Christian Lynbech
Subject: Re: Literate programming

(note that this part of my reply is copied to the axiom mailing list)

> Would you care to share some insights as to why you are thinking about
> redoing noweb in lisp?

five reasons. 
(well "reasons" might be a bit strong except in a religious sense)


first, noweb is slow. my current document (for work) has about 60k
bytes so far.  it takes about 20 seconds to make a change, save it,
and then run the makefile to extract the code, run the test cases, and
update the dvi file.

of the 20 seconds about 18 are spent in noweb. it is not scaling.

noweb uses the old byte-at-a-time model with pipes, awk, sed, etc.

in lisp i'd use read-sequence which can read the whole file in subsecond
time and the lisp processing won't take much longer. you could use mmap
in C but that won't work with the C/sed/awk pipe scripts.

axiom source is slowly dissolving into fully literate documents 
and these documents are getting larger and more complex. we MUST scale.



second, if lisp could manipulate literate documents directly it would
greatly increase the ways we could integrate literate documents into
the interpreter/compiler/browser/graphics. it would be possible to
directly (read) from a chunk in a file so that program and data files
don't need to be notangled. which eliminates the need for notangle and
makes literate documents fundamental.



third, axiom is mostly lisp. noweb adds requirements for 
sed/C/[gawk|nawk|awk]. it's been argued that these exist already
but that's hardly a reason for continuing. a uniform implementation
language increases function (see above) and reduces developer knowledge 
requirements. if i can just type (read (find-chunk "chunkname")) it is
much easier and more useful than starting a separate process to run a
C/sed/awk function and then opening a stream to read the result.



fourth, since all of my literate work uses latex it makes sense to 
limit the noweb functionality to be pure latex. so instead of
defining a chunk as

<<anything>>@

we would write 

\begin{chunk}{anything}
\end{chunk}

this would eliminate the noweave step completely. all of the
power of latex is available. it would be possible to make 
the chunk-environment sensitive to things like fonts or other 
latex commands like bold-font, arrays, etc. chunks need not
be raw quoted code but could include hyperlinks. these could be
eliminated in the notangle process.



fifth, i can't leave "good enough" alone. i see axiom growing by
a factor of 10 or more and i'm constantly gnawing on the problem
of scaling and integration. unifying chunks and latex with lisp
gives me a whole new realm of ideas for unifying the idea of 
literate documents and computational math. 

i want the distinction to disappear. i want computational math to just
be published as literate documents containing theory and code where
the running code is considered the "proof". i want the standard of
academic interchange to require running code much as standard
mathematics requires a proof. i want a literate journal that referees
literate computational mathematics papers. (for academics, programs
are a loss at the moment because they are not considered for tenure)

noweb is a wart on the whole process. it exposes mechanism.
you should be able to just "run" a computational mathematics paper.
no mechanism, no machinery. 

it should "just work".

\start
Date: Wed, 17 May 2006 09:51:49 +0200
From: Christian Aistleitner
To: Martin Rubey, Ralf Hemmecke
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Hello Martin,

On Tue, 16 May 2006 10:13:17 +0200, Martin Rubey  
Martin Rubey wrote:

> Where does it say that Dom(x) and Dom(y) should be the same, even if x  
> and y
> are equal in some sense?

I guess nowhere. But typically, you'd expect it.

Consider
a: List Integer := [ 1 ];
b: List Integer := [ 2 ];
you want to be able to call append!( a, b ), won't you?

But actually, you invoke the function List two times. Each time with the  
same argument (namely Integer).
If calling a function two times with the same argument yields the same  
(not the equivalent, but really the same) result, we call it "functional"  
in the discussion. Otherwise, we call it non functional. Just as with  
(functional) relations.

> I would imagine that Dom(x) and Dom(y) are the same, (i.e., instantiated  
> only
> once) if x and y are the same, i.e., if (eq x y) as opposed to (equal x  
> y), but
> I'd be interested to find something about this in the documentation.

That's the main point ... what kind of "equals" does Aldor apply?
I do not know. Just look at the Dom example I gave.

> I'd leave it unspecified.

Leaving compiler behaviour unspecified is a bad thing. No user would be  
allewed to rely on calling List( Integer ) two times would give an  
identical result.
Why would no user be able to rely on it, if its unspecified?
Because it might change in future :(

\start
Date: 17 May 2006 10:24:13 +0200
From: Martin Rubey
To: Christian Aistleitner
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Christian Aistleitner writes:

> Hello Martin,
> 
> On Tue, 16 May 2006 10:13:17 +0200, Martin Rubey  
> Martin Rubey wrote:
> 
> > Where does it say that Dom(x) and Dom(y) should be the same, even if x  
> > and y
> > are equal in some sense?

I should have been more precise: with "equal in some sense" I meant "not
exactly equal". In german it is easier: I meant "nicht dasselbe sondern nur das
gleiche".

> I guess nowhere. But typically, you'd expect it.

if x and y are "dasselbe" yes, otherwise no.
> 
> Consider
> a: List Integer := [ 1 ];
> b: List Integer := [ 2 ];
> you want to be able to call append!( a, b ), won't you?

yes, since (eq Integer Integer)

> But actually, you invoke the function List two times. Each time with the same
> argument (namely Integer).  If calling a function two times with the same
> argument yields the same (not the equivalent, but really the same) result, we
> call it "functional" in the discussion. Otherwise, we call it non
> functional. Just as with (functional) relations.

OK, I see now. It could be -- in the non functional setting -- that 

a: NonFunctionalDomainConstructor Integer := something
b: NonFunctionalDomainConstructor Integer := otherthing

and NonFunctionalDomainConstructor exports an operation f(%, %), but I still
*shouldn't* be able to call f(a, b), since a and b come from different
instantiations of NonFunctionalDomainConstructor Integer?

(Not currently, since it seems that Aldor instantiates a Domain only another
time, if the argument has changed.)

> > I would imagine that Dom(x) and Dom(y) are the same, (i.e., instantiated
> > only once) if x and y are the same, i.e., if (eq x y) as opposed to (equal
> > x y), but I'd be interested to find something about this in the
> > documentation.
> 
> That's the main point ... what kind of "equals" does Aldor apply?
> I do not know. Just look at the Dom example I gave.

which one? By the way: please include output of your aldor programs. It's
always a hassle for me to reproduce it.

> > I'd leave it unspecified.
> 
> Leaving compiler behaviour unspecified is a bad thing. 

No, not necessarily. Maybe I should have said "undefined". In Lisp this is the
case for many things. It's basically saying: "in principle it is an error, but
don't expect that I throw an error message".

> No user would be allowed to rely on calling List( Integer ) two times would
> give an identical result.

I agree that I wouldn't leave *this* unspecified, but I could imagine saying:

* domains are "compatible" (i.e., you may use append in the example you gave
  above), if their arguments were identical. In this case, the domain is
  instantiated only once.

* if their arguments were not identical, the behaviour is unspecified


thanks for getting me into the boat again,

\start
Date: 17 May 2006 11:10:03 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: space in ++ description

Ralf Hemmecke writes:

> No way, however, to help you to produce nice things for hyperdoc.

I think this is not completely true. If you restrict yourself between

\begin{+++}

and

\end{+++}

to the subset of latex commands hyperdoc understands, you do get hyperdoc for
free. The only trouble being that it is not completely clear what hyperdoc does
understand.

In your example I simply guess that the font HyperDoc uses is not really fixed
width. Somehow it seems that spaces differ in size from other letters.

I guess the only way to find out is to grep src/algebra to filter all words
\blabla that are contained in a line that contains ++. However, it seems to me
that the only commands used there are \axiom, \spad, \em, and some
others. Another source is doc/hypertex/pages.

I found that you can use verbatim:

)abbrev package MYTEST MyTest
MyTest() : Exports == Implementation where 
  Z ==> Integer
  Exports == with
      myfunc1: Z -> Boolean
      ++ myfunc1(z) computes a wonderful thing.
      ++                  SIDE = 'L'     SIDE = 'R'
      ++  TRANS = 'N':      Q * C          C * Q
      ++  TRANS = 'T':      Q**T * C       C * Q**T
      myfunc2: Z -> Boolean
      ++ myfunc2(z) computes another wonderful thing.
      ++  \begin{verbatim}
      ++   A * P = Q * [ R11 R12 ]
      ++               [ 0   R22 ]
      ++  \end{verbatim}

  Implementation == add

      myfunc1(n)== one? n
      myfunc2(n)== zero? n

\start
Date: Wed, 17 May 2006 15:02:57 +0200
From: Christian Aistleitner
To: Martin Rubey
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Hello,

> OK, I see now. It could be -- in the non functional setting -- that
>
> a: NonFunctionalDomainConstructor Integer := something
> b: NonFunctionalDomainConstructor Integer := otherthing
>
> and NonFunctionalDomainConstructor exports an operation f(%, %), but I  
> still
> *shouldn't* be able to call f(a, b), since a and b come from different
> instantiations of NonFunctionalDomainConstructor Integer?

yes.

> (Not currently, since it seems that Aldor instantiates a Domain only  
> another time, if the argument has changed.)

No. Sometimes, a domain is not re-instantiated, even if the argument  
changed ;)
See my Dom example:
http://www.aldor.org/pipermail/aldor-l/2006-May/000205.html

>> > I would imagine that Dom(x) and Dom(y) are the same, (i.e.,  
>> instantiated
>> > only once) if x and y are the same, i.e., if (eq x y) as opposed to  
>> (equal
>> > x y), but I'd be interested to find something about this in the
>> > documentation.
>>
>> That's the main point ... what kind of "equals" does Aldor apply?
>> I do not know. Just look at the Dom example I gave.
>
> which one?

http://www.aldor.org/pipermail/aldor-l/2006-May/000205.html

>> > I'd leave it unspecified.
>>
>> Leaving compiler behaviour unspecified is a bad thing.
>
> No, not necessarily. Maybe I should have said "undefined". In Lisp this  
> is the
> case for many things. It's basically saying: "in principle it is an  
> error, but don't expect that I throw an error message".

Thereby you specify it. You say the thing of interest is wrong. And you  
specify that an error might be thrown. But you must not rely on it.  
Specified.

>> No user would be allowed to rely on calling List( Integer ) two times  
>> would give an identical result.
>
> I agree that I wouldn't leave *this* unspecified, but I could imagine  
> saying:
>
> * domains are "compatible" (i.e., you may use append in the example you  
> gave
>   above), if their arguments were identical. In this case, the domain is
>   instantiated only once.
>
> * if their arguments were not identical, the behaviour is unspecified

Such a definition would be contradicting the current implementation of the  
Aldor compiler :)
And what do you mean by "identical"? The whole thing is terribly  
complicated (at least for me).

\start
Date: Wed, 17 May 2006 07:58:36 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Organization of Mathematics

Tim, my apologies for not having done my homework - I poked around and
found the MSC, and then found you had already mentioned this back in
2005.  Talk about slow on the uptake!

Has anybody taken any steps to organize Axiom according to this system?
This strikes me as a very useful system to put in place.  Not only does
it make Axiom documents more readily accessible to the general
mathematical academic community, it provides us a detailed framework to
organize around and makes it simpler to determine Axiom's strength (or
lack thereof) in a particular subfield.  Indeed, when we begin making
source-code-only documents into TRUE literate documents, such
categorizations might actually be a handy way to know where to start
looking for papers documenting the key theories on the subject. 
Ideally, the wiki interface to the source code could provide a search
for MSC categorizations (optionally including both primary and
secondary) and return a list of documents in Axiom pertaining to a
given subject.

I myself don't even begin to be competent enough to sort all of Axiom's
pamphlets into such categories, but if a start could be made it might
attract more interest.  For documents not dealing strictly with
mathematics (e.g. if Feyncalc gets ported, for example) there are
probably other useful classifications to add.  For physics and
astronomy there is http://www.aip.org/pacs/, for example.

Is there any feeling in the community, either support or opposition, to
using the MSC system to organize Axiom's mathematical pamphlets into a
coherent whole?  Either a directory structure (crude but effective), a
couple of lines in each Latex document identifying its categorization
(maybe creating a standard template with header and footer identifying
key info...  hmm...), or both?

\start
Date: Wed, 17 May 2006 20:12:37 +0200
From: Gregory Vanuxem
To: Martin Rubey
Subject: Re: space in ++ description

Hi,

Le mercredi 17 mai 2006 =E0 11:10 +0200, Martin Rubey a =E9crit :

[...]

> I guess the only way to find out is to grep src/algebra to filter all words
> \blabla that are contained in a line that contains ++. However, it seems to me
> that the only commands used there are \axiom, \spad, \em, and some
> others. Another source is doc/hypertex/pages.

Yes, I have found many commands in doc/hypertex/pages/ht.db but they are
not documented :-(

Someone knows what the \spad command do ? It's heavily used in the axiom
library but it seems that hyperdoc doesn't use it.

> I found that you can use verbatim

Thanks, I'll use this environment.

\start
Date: Wed, 17 May 2006 09:56:05 -0400
From: Stephen Watt
To: Christian Aistleitner
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.
Cc: Stephen Watt

Dear Christian et al,

I've been following your discussion with interest.

The way things are intended to be in the Aldor *language* is as follows.

Expressions in type context (e.g. T in  a: T := ...) must be formed from 
names that are constant in that scope.  These names may be of any type 
and so may refer to domains, domain-constructing functions, integers, 
lists or other things.

The constant-valued names may have definitions that are public or private.
In principle, public constant definitions are expanded in the type expression.
This produces a potentially infinite tree (that can be represented as a finite
graph),  e.g. R == Record(a: A, b: Union(s: S, r: R)).  Additionally, names
in a type expression are resolved to their full form (indicating their origin,
e.g. +$Integer).  This gives the _expanded type expression_.

Two types are statically equivalent if their expanded type expressions
are syntactically equal.

As noted earlier in this thread, the language definition leaves undefined
the number of times expressions in type context are evaluated.  This allows
a wide range of code transformations.

The Aldor *compiler* provides an implementation which approximates this.


The fact that the symbols in type expressions are constant in the scope of
the type's use allows programmers to adopt a functional style for type
expressions.   

There are ways to circumvent this, however, if the programmer makes an 
explicit effort:

-- Aliasing of values and "pretend" can be used to update values pointed
   to by constant names.

-- A constant-valued name may have a side-effecting function as its value
   so a domain constructor that depends on side effects can be written.

-- A constant-valued name may have an updatable data object as its value.

Forcing type expressions to be purely functional and terminating would
of course have been a possibility, but that would have required introducing
a number of new concepts into the langauge.

-- Stephen


On Wed, May 17, 2006 at 03:02:57PM +0200, Christian Aistleitner wrote:
> Hello,
> 
> >OK, I see now. It could be -- in the non functional setting -- that
> >
> >a: NonFunctionalDomainConstructor Integer := something
> >b: NonFunctionalDomainConstructor Integer := otherthing
> >
> >and NonFunctionalDomainConstructor exports an operation f(%, %), but I  
> >still
> >*shouldn't* be able to call f(a, b), since a and b come from different
> >instantiations of NonFunctionalDomainConstructor Integer?
> 
> yes.
> 
> >(Not currently, since it seems that Aldor instantiates a Domain only  
> >another time, if the argument has changed.)
> 
> No. Sometimes, a domain is not re-instantiated, even if the argument  
> changed ;)
> See my Dom example:
> http://www.aldor.org/pipermail/aldor-l/2006-May/000205.html
> 
> >>> I would imagine that Dom(x) and Dom(y) are the same, (i.e.,  
> >>instantiated
> >>> only once) if x and y are the same, i.e., if (eq x y) as opposed to  
> >>(equal
> >>> x y), but I'd be interested to find something about this in the
> >>> documentation.
> >>
> >>That's the main point ... what kind of "equals" does Aldor apply?
> >>I do not know. Just look at the Dom example I gave.
> >
> >which one?
> 
> http://www.aldor.org/pipermail/aldor-l/2006-May/000205.html
> 
> >>> I'd leave it unspecified.
> >>
> >>Leaving compiler behaviour unspecified is a bad thing.
> >
> >No, not necessarily. Maybe I should have said "undefined". In Lisp this  
> >is the
> >case for many things. It's basically saying: "in principle it is an  
> >error, but don't expect that I throw an error message".
> 
> Thereby you specify it. You say the thing of interest is wrong. And you  
> specify that an error might be thrown. But you must not rely on it.  
> Specified.
> 
> >>No user would be allowed to rely on calling List( Integer ) two times  
> >>would give an identical result.
> >
> >I agree that I wouldn't leave *this* unspecified, but I could imagine  
> >saying:
> >
> >* domains are "compatible" (i.e., you may use append in the example you  
> >gave
> >  above), if their arguments were identical. In this case, the domain is
> >  instantiated only once.
> >
> >* if their arguments were not identical, the behaviour is unspecified
> 
> Such a definition would be contradicting the current implementation of the  
> Aldor compiler :)
> And what do you mean by "identical"? The whole thing is terribly  
> complicated (at least for me).

\start
Date: 18 May 2006 11:00:24 +0200
From: Martin Rubey
To: list
Subject: Re: Lisp may not be dead, but...
Cc: Peter Broadbery

The following message is a courtesy copy of an article
that has been posted to comp.lang.lisp as well.

Dear all,

I just read Kenny Tiltons mail that LispNyc is still looking for mentors, and I
was thinking...

Well, as you all know, I still hope that someone is going to improve the
interpreter currently available in Axiom to make it understand at least some
parts of the Aldor improvements: treat types truly as first class objects,
allow dependent types, ...

To be honest, I think that given that Aldor becomes free, I think that Spad
should die as soon as possible. In fact, it will die pretty soon. The Aldor
libraries are by far superiour. I'm not going to write any more spad code and
I'm just about to port my stuff to Aldor.

Although currently Axiom is quite lispy, this will change dramatically when
Aldor becomes truly open source. Aldor is written mainly in C, I believe. Yes,
it is able to compile to lisp, so why not keep the Axiom interpreter in Lisp?

PLEASE! (I know it's a difficult job, I cannot do it, but maybe there is
somebody out there with the appropriate knowledge...)

\start
Date: Thu, 18 May 2006 11:40:50 +0200
From: Christian Aistleitner
To: Stephen Watt
Subject: Re: [Aldor-l] [Axiom-math] Are Fraction and Complex domains.

Hello Stephen,

first of all, thank you for sharing some insight about Aldor.

I love the approach that domain-constructing functions are _not_ treated  
special, but the speciality is hidden in the context.
Awesome!
Although this can be found in the Aldor User Guide, I could not find it  
before reading your mail.
You now have changed my perspective on Aldor a bit, and I love that even  
more.

It explains an aspect of Aldor, that has been quite fuzzy for me before.


However, domain-constructing functions may also occur in non-Type context.  
There the domain-constructing function is called again and again. Consider  
the following piece of code:

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

Dom( param: Integer ): with {
     f: () -> Integer
} == {
	import from RandomNumberGenerator;
	local r: Integer := randomInteger() :: Integer;
	stdout << "Domain ( param : " << ( param ) << ") -- r: " << r << newline;	
	add {
             --f yields a domain's r
	    f(): Integer == { r }
	}
}

macro NUM == ( max::Integer quo 2 );

stdout << "call         : " << f()$Dom( next NUM ) << newline;
stdout << "call         : " << f()$Dom( next NUM ) << newline;

local t1: Type := Dom( next NUM );
local t2: Type := Dom( next NUM );
local t3: Type := Dom( next NUM );



The Dom(...) at the 2 "stdout" lines is in type context. So these line are  
responsible for one instantiation of Dom. However, the Dom for t1, t2, and  
t3 are not in type context. Therefore, The domain constructing function  
Dom is actually called.

To verify my claims, let me give you the output:

Domain ( param : 1073741824) -- r: 2039368176
call         : 2039368176
call         : 2039368176
Domain ( param : 1073741824) -- r: 881855875
Domain ( param : 1073741824) -- r: 1363117465
Domain ( param : 1073741824) -- r: 11671655


This kind of writing code may lead to incompatible types (well... simply  
by non functional behaviour of domain-constructing functions), as can be  
seen in this example:

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

Dom(): with {
     coerce: Integer -> %;
     coerce: % -> Integer;
     (+): ( %, % ) -> %;
} == add {
     Rep == Integer;
     coerce( a : Integer ): % == { per a };
     coerce( a : % ): Integer == { rep a };
     (+)( a : %, b : % ): % == { per( rep a + rep b ) };
}

macro NUM == ( max::Integer quo 2 );


T0 == Dom();
T1 == Dom();
local t2: Type := Dom();
T2 == t2;

import from T0, T1, T2;
--T0 and T1 refer to the same domain.
stdout << "( T0 + T0 ) -> T0 :  " << (coerce$T0)( (coerce$T0)( 1 )  
+ (coerce$T0)( 1 ) ) << newline;
stdout << "( T1 + T0 ) -> T0 :  " << (coerce$T0)( (coerce$T1)( 1 )  
+ (coerce$T0)( 1 ) ) << newline;
stdout << "( T1 + T0 ) -> T1 :  " << (coerce$T1)( (coerce$T1)( 1 )  
+ (coerce$T0)( 1 ) ) << newline;
stdout << "( T1 + T1 ) -> T0 :  " << (coerce$T0)( (coerce$T1)( 1 )  
+ (coerce$T1)( 1 ) ) << newline;




The output of the example is
( T0 + T0 ) -> T0 :  2
( T1 + T0 ) -> T0 :  2
( T1 + T0 ) -> T1 :  2
( T1 + T1 ) -> T0 :  2


However, T2 does not refer to T0 or T1, as adding the line
stdout << "( T2 + T0 ) -> T0 :  " << (coerce$T0)( (coerce$T2)( 1 )  
+ (coerce$T0)( 1 ) ) << newline;
shows by yielding

"test2.as", line 32:
stdout << "( T2 + T0 ) -> T0 :  " << (coerce$T0)( (coerce$T2)( 1 )  
+ (coerce$T0)( 1 ) ) << newline;
.........................................................^
[L32 C58] #1 (Error) There are no suitable meanings for the operator  
`coerce$T2'.

at compilation time.



Did this happen by intention, or does the language provide some tricks for  
such cases which are currently not implemented by the compiler?

> [ Expressions in type context ]
> Additionally, names
> in a type expression are resolved to their full form (indicating their  
> origin, e.g. +$Integer).  This gives the _expanded type expression_.

Might this kind of resolvement be a hint, why sometimes renaming a  
variable turns a segfaulting program into a working one -- and vice-versa?

\start
Date: Thu, 18 May 2006 22:22:50 -0400
From: Tim Daly
To: list
Subject: (no subject)

Subject: Doyen, Magnus distribution
Reply-to: Tim Daly
--text follows this line--
(copy to the mailing lists of a Doyen email...)

oh, and while i've got you on the phone, so to speak, here's another
thing to consider.

both axiom and magnus use custom front-end software for most of their
help and user interface. Bill has been making the point that we should
consider using a standard browser instead.

i've been looking at this in some depth for replacing the axiom browser.
axiom's browser allows you to input equations which can be passed to the
back end and the results displayed inline. it also allows both inline
and standalone graphics.

i've been studying AJAX (asynchronous Javascript and XML). I recommend
the books AJAX Hacks and AJAX In Action.

the basic idea is very simple. Any web page can include javascript.
javascript has an object called XMLHttpRequest. If you set some
properties on this object and call a method you can send an http
request (GET or POST) back to the host without changing the current
page. you can then process the reply without changing the current page.

google uses this technique in google maps and gmail. it is now possible
to write a fully interactive client program in the browser. i've been
rewriting the axiom browser pages to use this machinery.

perhaps you want to consider ways to use it in the Doyen CD to 
interact with the browser. you're especially well suited for the
task as you're also running a web server locally so you can process
and modify local files.

it is also a useful long-term direction for the Magnus interface.
this would allow magnus to be used over the web. it would be simple
to open a second browser window with a different page so you could
have the two-window desktop Gilbert prefers.

\start
Date: Sun, 21 May 2006 23:56:12 +0200
From: Ralf Hemmecke
To: list
Subject: domain containers in the axiom interpreter

Hello,

I've just found out that Axiom cannot handle what I believe would be 
trivial. Look at the following code in domcont.as. CCDP is basically 
nothing else than an array of objects of type CC. But CC is a category, 
so that domain will contain a collection of domains not of usual 
elements. Of course, for Aldor something like that causes no problem at 
all, but as you read from the output at the end of this mail, Axiom 
yields an error in connection with "LIST" althoug my code does not 
involve List at all.

This current weakness of Axiom is VERY dramatic for the aldor-combinat 
project. Or is someone able to build something like an array that 
contains the *domain* Atom (see below).

Ralf


----domcont.as
#include "axiom"
macro Z == Integer;
macro I == NonNegativeInteger;
macro machine i == i;
macro prev i == (i-1)::Z;
import from Z;
CC: Category == with {count: Z -> Z;}
Atom: CC == add {count(i: Z): Z == if i=1 then 1 else 0;}
CCDPC: Category == with {
         #: % -> Integer;
	apply: (%, Integer) -> CC;
	set!: (%, Integer, CC) -> CC;
	ccdp: Tuple CC -> %;
	data: % -> PrimitiveArray CC;
	coerce: % -> OutputForm;
}
CCDP: CCDPC == add {
         Rep == Record(len: I, arr: PrimitiveArray CC);
         import from Rep;
         #(x: %): Z == ((rep x).len) :: Z;
         data(x: %): PrimitiveArray CC == rep(x).arr;
         ccdp(t: Tuple CC): % == {
		-- The length of a tuple is SingleInteger. :-(
		-- That is different from what ")sh Tuple" says.
                 len: SingleInteger == length t;
                 p: PrimitiveArray CC == new(len::I, Atom);
                 for i in 1..len repeat p.(prev i) := element(t, i);
                 per [len::I, p];
         }
         apply(x: %, i: Z): CC == {
                 data(x).(prev machine i);
         }
         set!(x: %, i: Z, C: CC): CC == {
                 data(x).(prev machine i) := C;
         }
	coerce(x: %): OutputForm == (1$Integer)::OutputForm
}
--end domcont.as

(1) -> )co domcont.as
    Compiling AXIOM source code from file domcont.as using AXIOM-XL
       compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y 
$AXIOM/algebra
       Use the system command )set compiler args to change these
       options.
#1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
"domcont.as", line 30:         apply(x: %, i: Z): CC == {
                        ..............^
[L30 C15] #2 (Warning) Function returns a domain that might not be 
constant (which may cause problems if it is used in a dependent type).

"domcont.as", line 33:         set!(x: %, i: Z, C: CC): CC == {
                        .............^
[L33 C14] #3 (Warning) Function returns a domain that might not be 
constant (which may cause problems if it is used in a dependent type).

    Compiling Lisp source code from file ./domcont.lsp
    Issuing )library command for domcont
    Reading /home/hemmecke/scratch/Aistleitner/domcont.asy
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/bc-matrix.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/bc-misc.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/bc-solve.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/bc-util.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/ht-util.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/htsetvar.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/ht-root.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/br-con.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/br-data.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/showimp.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/br-op1.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/br-op2.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/br-search.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/br-util.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/topics.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/br-prof.
    Loading /home/hemmecke/software/Axiom/mnt/linux/autoload/br-saturn.
    CCDP is now explicitly exposed in frame frame0
    CCDP will be automatically loaded when needed from
       /home/hemmecke/scratch/Aistleitner/domcont
    CCDPC is now explicitly exposed in frame frame0
    CCDPC will be automatically loaded when needed from
       /home/hemmecke/scratch/Aistleitner/domcont
    CC is now explicitly exposed in frame frame0
    CC will be automatically loaded when needed from
       /home/hemmecke/scratch/Aistleitner/domcont
    Atom is now explicitly exposed in frame frame0
    Atom will be automatically loaded when needed from
       /home/hemmecke/scratch/Aistleitner/domcont
(1) -> ccdp(Atom, Atom);
    Loading /home/hemmecke/software/Axiom/mnt/linux/algebra/PRIMARR.o
       for domain PrimitiveArray

    >> System error:
    #<vector 094cbf18> is not of type LIST.

\start
Date: Mon, 22 May 2006 06:34:26 -0700
From: Ed Borasky
To: Tim Daly
Subject: re: Literate programming
Cc: Christian Lynbech

I'm in violent agreement in principle -- anything that depends on "awk"
and "sed" (and pipes and the shell) needs to be re-implemented. The
question is, "In what language should the re-implementation take place?"

My gut reaction is that the logical choice is not Lisp but C. Rather
than "awk", "sed" and the shell, their descendents Perl, Python and Ruby
are what people write this sort of code in nowadays. But it's foolhardy
to add a language to Axiom -- how many languages are there already in
the Axiom bill of materials?

Perl, Python and Ruby (and GCL) are all implemented in C. And they all
call upon libraries to do regular expression processing. Why not just
use the libraries in C? Eliminate "awk", "sed" and the pipes, but keep C?

root wrote:
> (note that this part of my reply is copied to the axiom mailing list)
>
>   
>> Would you care to share some insights as to why you are thinking about
>> redoing noweb in lisp?
>>     
>
> five reasons. 
> (well "reasons" might be a bit strong except in a religious sense)
>
>
> first, noweb is slow. my current document (for work) has about 60k
> bytes so far.  it takes about 20 seconds to make a change, save it,
> and then run the makefile to extract the code, run the test cases, and
> update the dvi file.
>
> of the 20 seconds about 18 are spent in noweb. it is not scaling.
>
> noweb uses the old byte-at-a-time model with pipes, awk, sed, etc.
>
> in lisp i'd use read-sequence which can read the whole file in subsecond
> time and the lisp processing won't take much longer. you could use mmap
> in C but that won't work with the C/sed/awk pipe scripts.
>
> axiom source is slowly dissolving into fully literate documents 
> and these documents are getting larger and more complex. we MUST scale.
>
>
>
> second, if lisp could manipulate literate documents directly it would
> greatly increase the ways we could integrate literate documents into
> the interpreter/compiler/browser/graphics. it would be possible to
> directly (read) from a chunk in a file so that program and data files
> don't need to be notangled. which eliminates the need for notangle and
> makes literate documents fundamental.
>
>
>
> third, axiom is mostly lisp. noweb adds requirements for 
> sed/C/[gawk|nawk|awk]. it's been argued that these exist already
> but that's hardly a reason for continuing. a uniform implementation
> language increases function (see above) and reduces developer knowledge 
> requirements. if i can just type (read (find-chunk "chunkname")) it is
> much easier and more useful than starting a separate process to run a
> C/sed/awk function and then opening a stream to read the result.
>
>
>
> fourth, since all of my literate work uses latex it makes sense to 
> limit the noweb functionality to be pure latex. so instead of
> defining a chunk as
>
> <<anything>>=
> @
>
> we would write 
>
> \begin{chunk}{anything}
> \end{chunk}
>
> this would eliminate the noweave step completely. all of the
> power of latex is available. it would be possible to make 
> the chunk-environment sensitive to things like fonts or other 
> latex commands like bold-font, arrays, etc. chunks need not
> be raw quoted code but could include hyperlinks. these could be
> eliminated in the notangle process.
>
>
>
> fifth, i can't leave "good enough" alone. i see axiom growing by
> a factor of 10 or more and i'm constantly gnawing on the problem
> of scaling and integration. unifying chunks and latex with lisp
> gives me a whole new realm of ideas for unifying the idea of 
> literate documents and computational math. 
>
> i want the distinction to disappear. i want computational math to just
> be published as literate documents containing theory and code where
> the running code is considered the "proof". i want the standard of
> academic interchange to require running code much as standard
> mathematics requires a proof. i want a literate journal that referees
> literate computational mathematics papers. (for academics, programs
> are a loss at the moment because they are not considered for tenure)
>
> noweb is a wart on the whole process. it exposes mechanism.
> you should be able to just "run" a computational mathematics paper.
> no mechanism, no machinery. 
>
> it should "just work".

\start
Date: 22 May 2006 15:57:05 +0200
From: Martin Rubey
To: Ed Borasky
Subject: re: Literate programming

Ed Borasky writes:

> I'm in violent agreement in principle -- anything that depends on "awk"
> and "sed" (and pipes and the shell) needs to be re-implemented. The
> question is, "In what language should the re-implementation take place?"

I disagree. I think we should concentrate on our main business. Note that we
(Ralf and me) are in *desperate* need for a better interpreter. If that
interpreter is not going to happen, we are going to continue in Aldor. 

\start
Date: Mon, 22 May 2006 18:04:19 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Literate programming

Hello Ed,

I tend to agree with Martin (and you). The main goal of Axiom-developers 
should be to get the mathematics right. Programming tools for speeding 
up the "Mathematics goal" is just here since there are not so many good 
tools around for our purpose. If there are people (like you probably) 
who want to speed up the development process of the tools, then just 
fine. Do it!

I hope you then still keep programming and re-programming the things in 
C if I need a little modification of the tool since it does not exactly 
meet my goals. I could not do it myself, since I am much more fluent in 
Perl than in C and thus would spent ages in achieving the same thing in C.

Actually, I don't quite understand Tim with his problem with noweb.

Tim> First, noweb is slow. my current document (for
Tim> work) has about 60k bytes so far. it takes about
Tim> 20 seconds to make a change, save it, and then run
Tim> the makefile to extract the code, run the test
Tim> cases, and update the dvi file.
Tim>
Tim> of the 20 seconds about 18 are spent in noweb. it
Tim> is not scaling.

Obviously, Tim doen't use the ICON version of noweb. (Why?)
And I have the suspicion that the latex process is so fast, since the 
text does not involve many hyperlinks. (But I maybe wrong.)

For example, in order to get the documentation of ALLPROSE 
(http://www.hemmecke.de/aldor) into a stable form one has to call
latex, bibtex, makeindex, latex, makeindex, latex, makeindex, latex
(of course calling latex once would suffice if previous .aux files are 
taken into account). But on my machine, I have the impression that latex 
is much slower compared to the time that is needed by noweb.

If someone wants to make noweb faster, fine, but please keep ALL its 
functionalities AND its flexibility. Yes, noweb offers a feature to 
hyperlink names in code chunks. (See it in work in ALLPROSE.)

Ralf


On 05/22/2006 03:57 PM, Martin Rubey wrote:
> Ed Borasky writes:
> 
>> I'm in violent agreement in principle -- anything that depends on "awk"
>> and "sed" (and pipes and the shell) needs to be re-implemented. The
>> question is, "In what language should the re-implementation take place?"
> 
> I disagree. I think we should concentrate on our main business. Note that we
> (Ralf and me) are in *desperate* need for a better interpreter. If that
> interpreter is not going to happen, we are going to continue in Aldor. 
> 
> Martin

\start
Date: Mon, 22 May 2006 16:52:13 -0500
From: Jaakko Jarvi
To: list
Subject: Cfp: LCSD'06

I believe this CFP will be of interest to the Axiom developers 
community.
Best,


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

               LIBRARY-CENTRIC SOFTWARE DESIGN - LCSD'06

                     http://lcsd.cs.tamu.edu/2006

              Workshop, on October 22nd or 23rd (exact date TBA), 
2006 at

         Object-Oriented Programming, Systems, Languages and 
Applications
         (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 J=E4rvi, 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=E9 Br=F6nnimann, 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 J=E4rvi 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: Mon, 22 May 2006 21:41:54 -0700
From: Ed Borasky
To: Ralf Hemmecke
Subject: re: Literate programming

I'm just now starting to do "literate programming", so I haven't had a
chance to run into any performance bottlenecks in "noweb" yet. My
approach has been to use TeXmacs or LyX to edit "literate programs."
While both have native formats, both also can read and write files in
TeX. TeXmacs can also import Axiom (and R and Maxima) sessions directly
-- you can use TeXmacs like you would use Emacs.

The R folks are also committed to literate programming and the concept
of an executable document. They call this a compendium, a rather
unfortunate choice of words to me because there is a "dialogue mapping"
tool of the same name. Some links are

http://www.bepress.com/bioconductor/paper2

and

http://www.bepress.com/bioconductor/paper3/

So ... just how does one "get started" doing literate programming in
Axiom? Suppose, for example, I am working on a queuing theory model and
want to mix equations, data, graphs, etc. in a paper? Curiously enough,
LyX interfaces directly to noweb but not to Axiom and TeXmacs interfaces
directly to Axiom but not to noweb. :)

Ralf Hemmecke wrote:
> Hello Ed,
>
> I tend to agree with Martin (and you). The main goal of
> Axiom-developers should be to get the mathematics right. Programming
> tools for speeding up the "Mathematics goal" is just here since there
> are not so many good tools around for our purpose. If there are people
> (like you probably) who want to speed up the development process of
> the tools, then just fine. Do it!
>
> I hope you then still keep programming and re-programming the things
> in C if I need a little modification of the tool since it does not
> exactly meet my goals. I could not do it myself, since I am much more
> fluent in Perl than in C and thus would spent ages in achieving the
> same thing in C.
>
> Actually, I don't quite understand Tim with his problem with noweb.
>
> Tim> First, noweb is slow. my current document (for
> Tim> work) has about 60k bytes so far. it takes about
> Tim> 20 seconds to make a change, save it, and then run
> Tim> the makefile to extract the code, run the test
> Tim> cases, and update the dvi file.
> Tim>
> Tim> of the 20 seconds about 18 are spent in noweb. it
> Tim> is not scaling.
>
> Obviously, Tim doen't use the ICON version of noweb. (Why?)
> And I have the suspicion that the latex process is so fast, since the
> text does not involve many hyperlinks. (But I maybe wrong.)
>
> For example, in order to get the documentation of ALLPROSE
> (http://www.hemmecke.de/aldor) into a stable form one has to call
> latex, bibtex, makeindex, latex, makeindex, latex, makeindex, latex
> (of course calling latex once would suffice if previous .aux files are
> taken into account). But on my machine, I have the impression that
> latex is much slower compared to the time that is needed by noweb.
>
> If someone wants to make noweb faster, fine, but please keep ALL its
> functionalities AND its flexibility. Yes, noweb offers a feature to
> hyperlink names in code chunks. (See it in work in ALLPROSE.)
>
> Ralf
>
>
> On 05/22/2006 03:57 PM, Martin Rubey wrote:
>> Ed Borasky writes:
>>
>>> I'm in violent agreement in principle -- anything that depends on "awk"
>>> and "sed" (and pipes and the shell) needs to be re-implemented. The
>>> question is, "In what language should the re-implementation take
>>> place?"
>>
>> I disagree. I think we should concentrate on our main business. Note
>> that we
>> (Ralf and me) are in *desperate* need for a better interpreter. If that
>> interpreter is not going to happen, we are going to continue in Aldor.
>> Martin

\start
Date: Tue, 23 May 2006 12:37:41 +0200
From: Ralf Hemmecke
To: Ed Borasky
Subject: re: Literate programming

Hi Ed,

> So ... just how does one "get started" doing literate programming in
> Axiom? Suppose, for example, I am working on a queuing theory model and
> want to mix equations, data, graphs, etc. in a paper? Curiously enough,
> LyX interfaces directly to noweb but not to Axiom and TeXmacs interfaces
> directly to Axiom but not to noweb. :)

That sounds to me as if you have slightly different goals from mine.

I wanted an environment that describes theory and the program in 
connection to that theory. I didn't have the need to show output of that 
program. (Well, not yet.)

What you want is basically a running system like Axiom, Maple or 
Mathematica and *use* that system. The code you are going to write will 
probably not be much difficult.

Axiom+TeXmacs, Maple-worksheets and Mma-notebooks provide such an 
environment. But I don't think that is the end of the story. Someone has 
to write the underlying systems. And there is some theory/ideas/etc 
behind the code even if it is not connected with mathematics/physics/etc 
in the first place.

Of course it would be nice to have everything together, but I somehow 
fear that people who primarily _use_ CASs are not well trained 
programmers. I think that makes the code part hard to read even if the 
theory around it is nicely described.

Another point is the integrity of an "interactive" or "computed" 
document. If the underlying system changes (for example Maple modified 
its programming language several times) the results in the document 
might no longer be computable, so the document becomes unusable.

There are lots of problems, that are not yet solved.

I think that TeXmacs is the way to go, but TeXmacs was a bit slow for my 
taste and the wysiwyg thing somehow contradicts TeX. One should 
concentrate on the contents not on its appearance. But of course, having 
CAS command lines integrated into the text is nice.

\start
Date: 23 May 2006 13:39:25 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Literate programming

Ralf Hemmecke writes:

> I wanted an environment that describes theory and the program in connection to
> that theory. I didn't have the need to show output of that program. (Well, not
> yet.)

But that's very similar to my request! Namely, integrate MathAction and
HyperDoc into AllProse. I believe that having only one very powerful yet simple
file format (i.e., LaTeX and noweb) would make it a lot simpler to write
documentation.

> Of course it would be nice to have everything together, but I somehow fear
> that people who primarily _use_ CASs are not well trained programmers. I
> think that makes the code part hard to read even if the theory around it is
> nicely described.

I doubt that, given that it will mainly consist of using already existing
functionality.

> Another point is the integrity of an "interactive" or "computed" document. If
> the underlying system changes (for example Maple modified its programming
> language several times) the results in the document might no longer be
> computable, so the document becomes unusable.

For MathAction, I proposed to have an environment

\begin{axiom}[version]
\end{axiom}

that allows you to specify the patch number that you want to use. It seems
however that it's not straightforward to implement this in the current
framework.

\start
Date: Tue, 23 May 2006 14:10:15 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Literate programming

> But that's very similar to my request! Namely, integrate MathAction and
> HyperDoc into AllProse. I believe that having only one very powerful yet simple
> file format (i.e., LaTeX and noweb) would make it a lot simpler to write
> documentation.

> \begin{axiom}[version]
> \end{axiom}
> 
> that allows you to specify the patch number that you want to use. It seems
> however that it's not straightforward to implement this in the current
> framework.

Currently, I have not yet integrated Axiom or Aldor in the process of 
producing the .dvi file. It basically would mean "make dvi" depends on 
"make" and perhaps "make check" AND some possibility to extract the 
commands inside \begin{axiom}...\end{axiom} into a file ax.input, load 
run "cat ax.input | AXIOMsys > ax.output" and integrate that output into 
the .tex file. (Oh, one should not forget to load the library that was 
created via "make".)

But that means you cannot produce a .dvi file without having Axiom/Aldor 
installed. I somehow don't really like that dependency in the general case.

The next question is whether all axiom environments have to be joined. 
But I guess so.

Martin, I am not just a tool programmer. ;-)

\start
Date: Tue, 23 May 2006 06:27:14 -0700
From: Ed Borasky
To: Ralf Hemmecke
Subject: re: Literate programming

Ralf Hemmecke wrote:
> Hi Ed,
>
>> So ... just how does one "get started" doing literate programming in
>> Axiom? Suppose, for example, I am working on a queuing theory model and
>> want to mix equations, data, graphs, etc. in a paper? Curiously enough,
>> LyX interfaces directly to noweb but not to Axiom and TeXmacs interfaces
>> directly to Axiom but not to noweb. :)
>
> That sounds to me as if you have slightly different goals from mine.
The ultimate goal is to produce an advanced environment for modeling
performance and availability of computing systems and networks. Similar
tools exist, but only two are open source, and those two use Java,
rendering them "impure" in the eyes of many open source advocates. And
neither of them will conveniently handle the semi-Markov and non-Markov
cases that I'm interested in -- they are essentially Markov chain solvers.

I could do this all numerically in R -- that was the original plan until
I discovered Axiom. However, I think Axiom is "smarter" than R -- being
a symbolic and theoretical engine, it's capable of taking on more of the
jobs. For example, Axiom can do a Laplace transform out of the box --
I'd have to code that in R.
>
> I wanted an environment that describes theory and the program in
> connection to that theory. I didn't have the need to show output of
> that program. (Well, not yet.)
>
> What you want is basically a running system like Axiom, Maple or
> Mathematica and *use* that system. The code you are going to write
> will probably not be much difficult.
>
> Axiom+TeXmacs, Maple-worksheets and Mma-notebooks provide such an
> environment. But I don't think that is the end of the story. Someone
> has to write the underlying systems. And there is some
> theory/ideas/etc behind the code even if it is not connected with
> mathematics/physics/etc in the first place.
>
> Of course it would be nice to have everything together, but I somehow
> fear that people who primarily _use_ CASs are not well trained
> programmers. I think that makes the code part hard to read even if the
> theory around it is nicely described.
Something close to what I want to build has been done using Mathematica,
and one of the two open-source packages I mentioned above can interface
to Matlab or Maple. Mathematica, Maple and Matlab are not open source
nor are they low-cost -- serious licenses for corporate users start
somewhere around $1000US as I recall.

I hope I'm not the *only* exception to your conjecture of people who use
CASs not being well-trained programmers. :) I've been both a
programmer/computer scientist and applied mathematician for over 40
years. And of course, given a finite amount of time, people like me must
carefully allocate time between using the tools and working on them.
>
> Another point is the integrity of an "interactive" or "computed"
> document. If the underlying system changes (for example Maple modified
> its programming language several times) the results in the document
> might no longer be computable, so the document becomes unusable.
>
> There are lots of problems, that are not yet solved.
>
> I think that TeXmacs is the way to go, but TeXmacs was a bit slow for
> my taste and the wysiwyg thing somehow contradicts TeX. One should
> concentrate on the contents not on its appearance. But of course,
> having CAS command lines integrated into the text is nice.

\start
Date: Tue, 23 May 2006 06:41:30 -0700
From: Ed Borasky
To: Martin Rubey
Subject: re: Literate programming

Martin Rubey wrote:
> Ralf Hemmecke writes:
>
>   
>> I wanted an environment that describes theory and the program in connection to
>> that theory. I didn't have the need to show output of that program. (Well, not
>> yet.)
>>     
>
> But that's very similar to my request! Namely, integrate MathAction and
> HyperDoc into AllProse. I believe that having only one very powerful yet simple
> file format (i.e., LaTeX and noweb) would make it a lot simpler to write
> documentation.
>   
I'm just now getting down to learning Axiom, and I'm finding HyperDoc
somewhat "counterintuitive" after using Derive heavily, both in the DOS
(character-based) and Windows (GUI) interfaces. As I've noted above, for
my purposes, using TeXmacs as my editor is probably where I'll end up.

Also, when it comes to building products/user interfaces for
non-programmers, some very strict usability considerations apply, and
HyperDoc isn't exactly the sort of interface I'd want to hand to a user
of, say, a performance and availability modeling package. In fact,
building interfaces for *programmers* also has strict usability
considerations. There's a *reason* most interactive development
environments look the same. :)

Contrast HyperDoc with wxMaxima. I downloaded and installed wxMaxima and
within minutes was solving simple equational problems "just like I used
to do in Derive 5". :) The engine is still Maxima, with all its warts
and limitations, but the user interface instantly made sense to me.

\start
Date: Wed, 24 May 2006 20:22:54 -0700
From: Ed Borasky
To: Gabriel Dos Reis
Subject: Re: NOWEB

Gabriel Dos Reis wrote:
> I do not have an answer to your question.  Different people function
> differently. 
>
> But, if the question is directed to me, then the answer is "I do
> play with lots of programming languages, and fluent in quite a few of
> them, with totally different paradigms -- I would not be here, if it
> were otherwise".  Now, if you ask me whether in a large project I
> would recommend that we use all of them, then my first order answer is
> NO! 
>
> Maybe there is a confusion about appreciating diverse programming
> languages and appreciating the set of tools we should use to deliver a
> coherent, attractive, scalable, and maintainable project.
>
> I don't want my scarce resource (time) to be sunk in a black hole.
> When it comes to tenure, the number of languages one appreciates counts
> for exactly zero.  Software *development* counts for zero -- even in
> the area of software.  The number of papers count highly; grants are
> important.  
> I don't want to write about people writing software. I would prefer to 
> write about software, largely based on experience.  For that, I prefer
> invest the "wasted time" in something that can make a difference; that
> people use. I see an opportunity in Axiom.  I would hate it becomes a
> black hole where all sorts of languages get sunk into because of 
> "diverse programming language appreciation."  The reasons why we should
> add new tools to our tool bagage should be their effectiveness to
> solve specific problems we are facing, not just because we want to be
> diverse.  There is something to be said for breath, there is also
> something to be said for depth.   There must be a balance somewhere
> given the limited resources we have.
>   
I will second this. I keep promising myself I'll learn Ruby, because it
looks like a much better scripting language than Perl. But I maintain a
few thousand lines of mostly my own Perl code, and I'm not going to port
that to Ruby. Nor am I going to give up R for Ruby. And I've already
given up Fortran and C and I've nearly given up Lisp.

I intend to learn the highest level of Axiom -- whether or not I ever
get around to any of the underlying languages is an open question, given
that I want Axiom as a scientific applications programming language.
> | I think Icon was a worthy predecessor of the currently very
> | popular web scripting languages like perl and python that came
> | later but did a lot of the same things (not necessarily as
> | well ):
>
> You mean SNOBOL? :-)
>
> [ The whom I work for currently is a long term SNOBOL
>   hacker; yet he invented a different language that will not be suitable
>   for discussion here :-p  And we do work in an environment where we
>   highly appreciate diverse languages and paradigms. ]
>
> | 
> | http://www.cs.arizona.edu/icon/index.htm
> | 
> | Icon has venerable history rather similar to Axiom's, beginning
> | in 1977:
>
> Thanks; not mean to be rude -- but I'm an Icon hacker.  I spent long
> time studying Icon.  For example, I wanted to add generators (not
> co-routines) to C++; among other things I digested Icon's
> implementation.  That was not too long ago.

\start
Date: 25 May 2006 21:05:50 +0200
From: Martin Rubey
To: Peter Broadbery
Subject: re: Lisp may not be dead, but...

Dear Peter,

Peter Broadbery writes:

> > (did you send this in private intentionally?)

> Feel free to forward.

done

> > Peter Broadbery writes:
> > 
> > > Forcing the interpreter to understand dependent types is a bit of an
> > > unknown quantity to me - my sole attempt at trying ended up with the
> > > aldor compiler crashing while creating the .asy file, so I couldn't see
> > > what axiom would do with it.  Having the aldor source would have been
> > > nice at that point.  My suspicion is that it would be possible to fix the
> > > interpreter, at least as far as function lookup.
 
> > > Types as 100% first class objects might be difficult in axiom as is -
> > > there's a lot of stuff in function lookup that works from the name of a
> > > type as opposed to a value.
> > 
> > Well, one thing we currently need for Axiom-Combinat is to be able to have
> > a List of domains, and be able to pick one and use it. I'm afraid that's
> > about as far as first class can get... Still, we really need that.
> > 
> Do these domains have a common category?  

Yes.

> Do you need the precise exports of the domain, or is the category enough? 

I'd guess that the category is enough. Not sure here. But any progress
would be great, of course.

> Boxing the domains within a common one for axiom's purposes might be possible
> - or you've tried that one?

Not sure what you mean here.

> As far as me trying to update axiom - I never had a great deal of exposure to
> how the type handling worked in axiom - that said, if there is an obvious way
> of making dependent types work (and even 1st class domains), I'd be willing
> to have a stab at it, time permitting.

PLEASE do. It seems that you are the only one with the knowledge who is still
around!

\start
Date: Thu, 25 May 2006 15:13:35 -0400
From: Bill Page
To: Martin Rubey
Subject: re:  Lisp may not be dead, but...

Martin,

On Thursday, May 25, 2006 3:06 PM you wrote:
>
> Peter Broadbery writes:
>
> ...
> > Boxing the domains within a common one for axiom's purposes
> > might be possible
> > - or you've tried that one?
>
> Not sure what you mean here.
>

Perhaps what Peter means is described here:

http://wiki.axiom-developer.org/209TheFunctionDomainIsUndefined

See especially:

http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00250.ht
ml

http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00248.ht
ml

\start
Date: Thu, 25 May 2006 20:41:48 +0100
From: Peter Broadbery
To: Martin Rubey
Subject: re: Lisp may not be dead, but...

On Thu, 2006-05-25 at 21:05 +0200, Martin Rubey wrote:
> Dear Peter,
> 
> Peter Broadbery writes:
> 
> > > (did you send this in private intentionally?)
> 
> > Feel free to forward.
> 
> done
> 
> > > Peter Broadbery writes:
> > > 
> > > > Forcing the interpreter to understand dependent types is a bit of an
> > > > unknown quantity to me - my sole attempt at trying ended up with the
> > > > aldor compiler crashing while creating the .asy file, so I couldn't see
> > > > what axiom would do with it.  Having the aldor source would have been
> > > > nice at that point.  My suspicion is that it would be possible to fix the
> > > > interpreter, at least as far as function lookup.
>  
> > > > Types as 100% first class objects might be difficult in axiom as is -
> > > > there's a lot of stuff in function lookup that works from the name of a
> > > > type as opposed to a value.
> > > 
> > > Well, one thing we currently need for Axiom-Combinat is to be able to have
> > > a List of domains, and be able to pick one and use it. I'm afraid that's
> > > about as far as first class can get... Still, we really need that.
> > > 
> > Do these domains have a common category?  
> 
> Yes.
> 
> > Do you need the precise exports of the domain, or is the category enough? 
> 
> I'd guess that the category is enough. Not sure here. But any progress would be
> great, of course.
> 
> > Boxing the domains within a common one for axiom's purposes might be possible
> > - or you've tried that one?
> 
> Not sure what you mean here.
> 

[This may be a bit revolting] Let's suppose that these domains are all
in the category X, exporting f: () -> %.  NB: Untested.


XisADomain: with {
	aDomain(T: X): %;
	f: () -> XD;
} == add {
	Rep ==> X;
	aDomain(T: X): % == per T;
	f(): XD == makeXD(X, f()$T);
	-- and similar for any other nullary exports of X.
}

XD: X with {
	makeXD: (T: X, a: Pointer) -> %;
} == add {
	Rep ==> Record(T: X, a: T);
	makeXD(T: X, a: Pointer): % == per [T, a pretend T];

	-- need to implement all the operations of X here, example:
	g(o: %): % == {
		(T: X, a:T) := per o;
		per [T, g(a)$T];
	}
}

Any functions returning a list of domains should have [aDomain(T) for T
in L] run across them before axiom sees them.  makeXD has the wrong type
- it should be makeXD: (T: X, a: T) -> %, but see comments about .asy
files.  

> > As far as me trying to update axiom - I never had a great deal of
> > exposure to how the type handling worked in axiom - that said, if
> > there is an obvious way of making dependent types work (and even
> > 1st class domains), I'd be willing to have a stab at it, time
> > permitting.
 
> PLEASE do. It seems that you are the only one with the knowledge who is still
> around!

\start
Date: 26 May 2006 12:33:10 +0200
From: Martin Rubey
To: list
Subject: Build failure

I need Help...

[rubey@aquin GoldenAxiom]$ uname -a
Linux aquin.mat.univie.ac.at 2.6.9-34.EL #1 Tue Mar 14 10:34:05 CST 2006 i686
athlon i386 GNU/Linux


[rubey@aquin GoldenAxiom]$ cat /etc/issue
Scientific Linux SL release 4.3 (Beryllium)


make[3]: Leaving directory `/pusers/rubey/GoldenAxiom/src/boot'
25 making /pusers/rubey/GoldenAxiom/src/interp
make[3]: Entering directory `/pusers/rubey/GoldenAxiom/src/interp'
136 making /pusers/rubey/GoldenAxiom/obj/linux/interp/vmlisp.o from /pusers/rubey/GoldenAxiom/int/interp/vmlisp.lisp
/bin/sh: line 1: 32487 Done                    echo '(progn  (compile-file "/pusers/rubey/GoldenAxiom/int/interp/vmlisp.lisp" :output-file "/pusers/rubey/GoldenAxiom/obj/linux/interp/vmlisp.o") (bye))'
     32488 Segmentation fault      | /pusers/rubey/GoldenAxiom/obj/linux/bin/depsys >/pusers/rubey/GoldenAxiom/obj/tmp/trace
make[3]: *** [/pusers/rubey/GoldenAxiom/obj/linux/interp/vmlisp.o] Error 139
make[3]: Leaving directory `/pusers/rubey/GoldenAxiom/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory `/pusers/rubey/GoldenAxiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/pusers/rubey/GoldenAxiom'
make: *** [all] Error 2

\start
Date: 26 May 2006 14:13:24 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: Build failure

Sorry, it seems to work now. Not unlikely that the directory was currupted )no
space left on device...)

Excuse me,

Martin

Martin Rubey writes:

> I need Help...
> 
> [rubey@aquin GoldenAxiom]$ uname -a
> Linux aquin.mat.univie.ac.at 2.6.9-34.EL #1 Tue Mar 14 10:34:05 CST 2006 i686
> athlon i386 GNU/Linux
> 
> 
> [rubey@aquin GoldenAxiom]$ cat /etc/issue
> Scientific Linux SL release 4.3 (Beryllium)
> 
> 
> make[3]: Leaving directory `/pusers/rubey/GoldenAxiom/src/boot'
> 25 making /pusers/rubey/GoldenAxiom/src/interp
> make[3]: Entering directory `/pusers/rubey/GoldenAxiom/src/interp'
> 136 making /pusers/rubey/GoldenAxiom/obj/linux/interp/vmlisp.o from /pusers/rubey/GoldenAxiom/int/interp/vmlisp.lisp
> /bin/sh: line 1: 32487 Done                    echo '(progn  (compile-file "/pusers/rubey/GoldenAxiom/int/interp/vmlisp.lisp" :output-file "/pusers/rubey/GoldenAxiom/obj/linux/interp/vmlisp.o") (bye))'
>      32488 Segmentation fault      | /pusers/rubey/GoldenAxiom/obj/linux/bin/depsys >/pusers/rubey/GoldenAxiom/obj/tmp/trace
> make[3]: *** [/pusers/rubey/GoldenAxiom/obj/linux/interp/vmlisp.o] Error 139
> make[3]: Leaving directory `/pusers/rubey/GoldenAxiom/src/interp'
> make[2]: *** [interpdir] Error 2
> make[2]: Leaving directory `/pusers/rubey/GoldenAxiom/src'
> make[1]: *** [srcdir] Error 2
> make[1]: Leaving directory `/pusers/rubey/GoldenAxiom'
> make: *** [all] Error 2

\start
Date: 28 May 2006 22:43:00 +0200
From: Francois Maltey
To: Francois Maltey
Subject: axiom becomes crazy !

Hello 

Until yesterday I had no problem with 1+2 [return], of corse I get 3.

Today I use axiom in emacs or in a terminal, and I type 1+2 [return] or 1234
I get a fatal error.

I'm sure I do no change in the axiom tree.

I try to erase the ~/.axiom.hist and get the same error.

When I type a [return] I get the right a variable.
But a+a makes an error ! (see bellow)

Can you detect where is my error ?

petoncle:/usr/share/emacs/21.4/lisp$ axiom -noht
                        AXIOM Computer Algebra System
                       Version: Axiom (December 2005)
              Timestamp: Tuesday January 17, 2006 at 16:23:31
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------

   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
(1) ->
(1) -> 1234

   Loading /usr/local/axiom/mnt/linux/algebra/PI.o for domain
      PositiveInteger

   >> System error:
   Caught fatal error [memory may be damaged]


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

(1) -> a

   (1)  a
                                                             Type: Variable a
(2) -> a+a
   Loading /usr/local/axiom/mnt/linux/algebra/INT.o for domain Integer

   >> System error:
   Caught fatal error [memory may be damaged]

\start
Date: Sun, 28 May 2006 18:00:25 -0400
From: Tim Daly
To: Francois Maltey
Subject: Re: axiom becomes crazy !

your AXIOM shell variable is not set properly.

it should read (pathtoinstallation)/mnt/linux

\start
Date: Wed, 31 May 2006 08:54:24 +0200
From: Gernot Hueber
To: list
Subject: Call Foreign C from Aldor/Axiom

Hello,

Due to that I want to call external library functions from within
Aldor/Axiom I did some trials with Aldors "Foreign" and GCL "defentry"
commands.

First of all, an example that work (partly), adapted from the aldor
users guide:

----
#include "axiom.as"

SI ==> SingleInteger;

arigato():PositiveInteger == {
import { printf: (String) -> SI } from Foreign C;
import from SI;
printf("Arigato gozaimasu!");
1;
}
----

This one compiles fine, yet it does not run. Thus I added
--
(defentry |printf| (string) (int "printf"))
--
to the arigato.lsp and recompiled the lisp code. Now the function
returns
--
(4) -> arigato()
Arigato gozaimasu!
   (4)  1
                                                        Type:
PositiveInteger
--

:-)

Second example is more similar to the arigato-example from the Aldor
users guide:
--
#include "axiom.as"

SI ==> SingleInteger;

arigato2():PositiveInteger == {
import { nputs: (SI, String) -> SI } from Foreign C;
import from SI;
nputs(3,"Arigato gozaimasu!");
1;
}
--
If I run this one (with the defentry trick), I get:
--
(4) -> arigato2()
symbol "nputs" is not in base image
   >> System error:
   Caught fatal error [memory may be damaged]
--
Obviously due to that the nputs.o is not loaded (which I have in the
local directory).

Now, my questions:
.) Is there a recommended/better way to call external functions within
Aldor/Axiom?
.) I think, the "defentry" part  could be added with an Aldor "Foreign
Lisp" call?
.) How can I "load", external libraries (e.g. nputs.o)?

\start
Date: Wed, 31 May 2006 11:01:34 -0400
From: Bill Page
To: Gernot Hueber
Subject: RE: Call Foreign C from Aldor/Axiom

On Wednesday, May 31, 2006 2:54 AM Gernot Hueber wrote:

>
> Due to that I want to call external library functions from
> within Aldor/Axiom I did some trials with Aldors "Foreign"
> and GCL "defentry" commands.
>

Great! I am very happy you are looking into this.

> ...
> Now, my questions:
> .) s there a recommended/better way to call external functions
> within Aldor/Axiom?
> .) I think, the "defentry" part  could be added with an Aldor
> "Foreign Lisp" call?
> .) How can I "load", external libraries (e.g. nputs.o)?
>

See:

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

The first section containing

  (defentry |myprintf| (string) (int "printf"))

is compiled as a lisp function but notice that it becomes
part of the BOOT package.

Now we can compile some Aldor code that calls this function
and then call the Aldor function from Axiom.

For loading an external library did you try the usual Axiom
command

 )library nputs.o

Or via lisp like this:

 )lisp (load nputs.o)

?

Can you send me the example code for 'nputs.c'?

\start
Date: Wed, 31 May 2006 20:01:31 -0700
From: Ed Borasky
To: list
Subject: Re: axiom opportunity

Axiom is "easily installable" on Gentoo Linux. It's a standard (testing
level) package in the Gentoo Portage repository. I'm pretty sure it can
be built from source on all major Linux systems. :)

David MENTRE wrote:
> Hello,
>
> 25 Apr 2006 21:40:01 +0200, Gabriel Dos Reis:
>   
>> We should aim at getting Axiom 'easily' installable on all major linux
>> systems -- not just Debian.
>> [ I'm not saying that because I'm a SuSE Linux user :-) ]
>>     
>
> So why don't you package Axiom for SuSE ?

\start
Date: Wed, 31 May 2006 20:05:12 -0700
From: Ed Borasky
To: Camm Maguire
Subject: Re: GCL-2.6.7 and GCC-4.2.0

I've recompiled the Gentoo package of gcl 2.6.7 a couple of times
recently with no problems. Perhaps there are some patches you need to
apply. What version of GCC are you using? I've got it working with both
3.4.5 and 4.1.1.

Camm Maguire wrote:
> Greetings!
>
> Here is your problem:
>
> gcl_cmptop.c: In function 'LI29':
> gcl_cmptop.c:2547: internal compiler error: in merge_alias_info, at tree-ssa-copy.c:235
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>
> i.e. this gcc development snapshot ran into an internal bug when
> compiling the gcl_cmptop.c file.  You might try working around the
> problem by configuring gcl with --enable-debug for the time being, but
> this really should be reported to the gcc people and their bug tracker
> as explained in the instructions referred to above.
>
> Take care, 
>
>
> Gabriel Dos Reis writes:
>
>   
>> Camm Maguire writes:
>>
>> | Greetings!  My apologies -- not the .o file, the log from the
>> | compilation posted to the screen.  Or, if you prefer, your entire
>> | configure and make build log.
>>
>> sorry for having misparsed what you said; here is the
>> (gzip-compressed) log for cnofigure and make.  Hope, it is better this
>> time.   
>>
>> For my curiosity: is it expected that the .o coming from compiling a
>> .lsp actually is NOT a "usual" .o file?
>>
>>     
>
> No, usually the .data file is appended to the .o output by gcc, but
> here the latter is empty.
>
> Take care,
>
>   
>> -- Gaby
>>
>>     
>
>   

-- 
Ed Borasky

http://linuxcapacityplanning.com




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