\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: 01 Jul 2007 02:44:08 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: Re: 2.7.0 reports
Cc: Gabriel Dos Reis

Greetings, and thanks for your very clear, lucid, concise and
extremely helpful reports!  Should be fixed now, a better fix
hopefully in soon.

\start
Date: Sun, 1 Jul 2007 01:55:46 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Fix thinko in src/interp/vmlisp.lisp

On Sat, 30 Jun 2007, Stephen Wilson wrote:

| Hi Gaby,
| 
| Looks like I missed your commit.
| 
| MACERRORCOUNT appears unused and could be taken out as well.  No idea
| what the (setq ... (.. (eval ..))) nonsense is about.  Any idea?

Yes, 

   (case N ...

should be

   (case nargs ...

A rewrite of the whole thing is possible, but in general I would
like to have the minimum change, leaving the general rewite for 
later when I have the right tools at dsiposal.
   
-- Gaby

2007-07-01  Gabriel Dos Reis  Gabriel Dos Reis

	* vmlisp.lisp.pamphlet (MACRO-MISSINGARGS): Fix thinko in case
	statement. 

*** vmlisp.lisp.pamphlet	(revision 22148)
--- vmlisp.lisp.pamphlet	(local)
*************** can be restored.
*** 1858,1864 ****
    (let ((nargs (abs N)))
      (error (concatenate 'string (symbol-name NAME) " requires "
  			(if (minusp N) "at least " "exactly ")
! 			(case N (0 "no") (1 "one") (2 "two") (3 "three")
  			      (4 "four") (5 "five") (6 "six")
  			      (t (princ-to-string nargs)))
  			(if (eq nargs 1) " argument," " arguments,")))))
--- 1858,1864 ----
    (let ((nargs (abs N)))
      (error (concatenate 'string (symbol-name NAME) " requires "
  			(if (minusp N) "at least " "exactly ")
! 			(case nargs (0 "no") (1 "one") (2 "two") (3 "three")
  			      (4 "four") (5 "five") (6 "six")
  			      (t (princ-to-string nargs)))
  			(if (eq nargs 1) " argument," " arguments,")))))


\start
Date: Sun, 1 Jul 2007 02:14:56 -0500 (CDT)
From: Gabriel Dos Reis
To: list
Subject: [silver] Remove executable property

I removed the executable property set on almost all files.  Similar
changes have been made long time ago on build-improvements.

There is diff to look at.

\start
Date: Sun, 1 Jul 2007 03:13:13 -0500 (CDT)
From: Gabriel Dos Reis
To: list
Subject: Build machinery -- an overview


This is a general overview of the build system.  This message contains
no code -- I'm discussing general view, ideas, ideals.
 
  If you don't need a simple working, easily build-able, easily
install-able Axiom for yesterday, then delete this message now.

* Better integration to existing environments

  The build system in trunk isolates itself from existing environments.
This is not good for porting Axiom to other platforms yesterday or today.
We should not ignore Make.  It is not the best possible build tool
one can imagine.  But it is the best almost universally available
build tool we have today.  We must make a good use of Make, now.  This
requires that, for example, tools we built should return meaningful
exit status.

* Modularize, generalize, abstract -- don't over abstract

  The current build system uses long list of special cases, and 
duplication of logic.  That approach cannot scale.  Following
Doug McIlroy [1], we should aim for portability by:

    + modularization
    + generalization

Autoconf has well thought out, widely tested, proven technology to
subsume many of the special casings and guesses found in current
build system.  To master the recalcitrant residue, build-improvements
uses "specializations (freezing certain parameter values)".  This
is accomplished by the Ershovian specializer `configure'.  Concretely,
build-improvements instantiate the actual Makefiles  at configure-time.

* Automate as much as possible

  We should take advantage of tools to systematically carry out
repetitive tasks, ensuring integrity.  Build-improvements improved
Boot to help systematize checking of Boot code dependencies, and generating
type information for Lisp systems that care about proclamation.

[1] http://www.haskell.org/pipermail/hugs-users/2006-January/000621.html

\start
Date: Sun, 1 Jul 2007 04:35:56 -0500 (CDT)
From: Gabriel Dos Reis
To: list
Subject: Build machinery -- support for out of source build

  This message contains no code.  It is a head up.

The current build machinery in silver does not support out of source
build.  

That is wrong.  

We must be able to build Axiom in a directory different from the one
that contain the source code -- for exemple the source code may live on a 
read-only media, such as a CD.

Also, I suggest the elimination of the "int/" subdirectory -- I know
what it is there for, but that is the wrong way of achieving what it 
is supposed to do.

Notice that all the changes I propose are already implemented in
build-improvements. 

\start
Date: 01 Jul 2007 11:46:14 +0200
From: Martin Rubey
To: Gabriel Dos Reis, Waldek Hebisch, Tim Daly
Subject: Re: Build machinery -- support for out of source build

Gabriel Dos Reis writes:

> Comments?

Merge the interesting bits from trunk into build-improvements or wh-sandbox,
not the other way round.  Then bless the result to make it trunk.  Most
importantly, get Waldek back into the boat.

Then you will also get myself back into the boat.

Greetings from China, 

\start
Date: Sun, 1 Jul 2007 04:56:54 -0500 (CDT)
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Build machinery -- support for out of source build
Cc: Waldek Hebisch

On Sun, 1 Jul 2007, Martin Rubey wrote:

| Gabriel Dos Reis writes:
| 
| > Comments?
| 
| Merge the interesting bits from trunk into build-improvements or wh-sandbox,
| not the other way round.  Then bless the result to make it trunk.  Most
| importantly, get Waldek back into the boat.
| 
| Then you will also get myself back into the boat.
| 
| Greetings from China, 
| 
| sad Martin

Martin --

   I do hope that despite recent discussions, things will calm down.
I sincerely hope that Waldek would reconsider his well explained
decision.  I would like to see us united around a common source we trust,
and that we work to make better.

   wh-sandbox was branched from build-improvements.  If I succeed in
getting the interesting bits there into trunk, then we should be
in position to consider wh-sandbox improvements.


   build-improvements is not finished, yet.  But I'm following my own
advice to people who believe they have to wait 30 years before
releasing anything to the public.  Not everybody has the same needs.
Some don't need Axiom for yesterday or today.  Some do.  My colleagues
and my students cannot wait 30 years before using Axiom.  They need it
now.  I'm sure many other people are in similar situations.  So, I'm
trying to incrementally release what I have in a state that is usable, 
even if not perfect.  I would like to see basic functionality such as

     ./configure && make && make install

in first, then refine it.


  I hope to see all y'all back to Axiom.

\start
Date: 01 Jul 2007 09:05:56 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: Build machinery -- support for out of source build


Gabriel Dos Reis writes:
> Hi,
> 
>   This message contains no code.  It is a head up.
> 
> The current build machinery in silver does not support out of source
> build.  
> 
> That is wrong.  

Agreed.

> We must be able to build Axiom in a directory different from the one
> that contain the source code -- for exemple the source code may live on a 
> read-only media, such as a CD.
> 
> Also, I suggest the elimination of the "int/" subdirectory -- I know
> what it is there for, but that is the wrong way of achieving what it 
> is supposed to do.

In general I agree, although I do find the segregation between int/
and obj/ helpful.  But thats more ancidotal than anything else, as
other schemes Im sure are just as easy to work with.

Am I correct in assuming the generated .lisp files are still easily
inspected and modified, and share their own component of the
dependency graph for make?

I guess I would like a tad bit more info than saying the current
scheme is bad.  It tells me nothing about the benifits of your change.

\start
Date: 01 Jul 2007 09:12:55 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: Build machinery -- an overview

Hello Gaby,

In general I dont have any problems with the overview.

Two questions.  How have you found your current setup w.r.t autoconf
variabilities?  In my experience autoconf is quite sensitive about
which version is used to build the format, esp when local macros are
used.  Is it at all worth standardizing on a specific autoconf version
among developers?

Im leaving for another fishing trip in a few short hours.  Hopefully
when I return this time I'll actually feel a bit more relaxed.  Wont
be back online till the end of the week.

\start
Date: Sun, 1 Jul 2007 08:50:31 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Build machinery -- an overview

On Sun, 1 Jul 2007, Stephen Wilson wrote:

| Hello Gaby,
| 
| In general I dont have any problems with the overview.
| 
| Two questions.  How have you found your current setup w.r.t autoconf
| variabilities?  In my experience autoconf is quite sensitive about
| which version is used to build the format, esp when local macros are
| used.  Is it at all worth standardizing on a specific autoconf version
| among developers?

Yes, it is worth standardizing on a specific Autoconf version.

I'm not worried about the fined grained variations of generated
configure, than the availability of macros, bugs or non-bugs, 
functionalities.  This is a requirement on developers, not
users.  For a long time we have used Autoconf 2.59, which contained
a bug, now fixed in 2.60.

\start
Date: Sun, 1 Jul 2007 08:57:17 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Build machinery -- support for out of source build

On Sun, 1 Jul 2007, Stephen Wilson wrote:

| Am I correct in assuming the generated .lisp files are still easily
| inspected and modified, and share their own component of the
| dependency graph for make?

If I understand your question correctly, the answer is yes.

| I guess I would like a tad bit more info than saying the current
| scheme is bad.  It tells me nothing about the benifits of your change.

In my experience, the current scheme has led to more problems, complications
than any perceived benefits.  It has many pitfalls when trying to
port to "non-conventional" filesystems, e.g. what you'd find on windows
and unixes with mounted filesystems.  I believe wh-sandbox was
branched before I finished making build-improvements fully workable
on windows.  I believe people have ecncountered amny variations of the
problems there.  On balance, I see the current steup having more
problems than benefits it gives us on daily basis.

\start
Date: 01 Jul 2007 10:34:32 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: Build machinery -- support for out of source build

Gabriel Dos Reis writes:

> On Sun, 1 Jul 2007, Stephen Wilson wrote:
> 
> | Am I correct in assuming the generated .lisp files are still easily
> | inspected and modified, and share their own component of the
> | dependency graph for make?
> 
> If I understand your question correctly, the answer is yes.

Ok.  Just for the sake of clarity, I meant that one can modify the
intermediate lisp, and have those changes picked up by the build
process without them being overwritten by a fesh tangling of a
pamphlet.

> 
> | I guess I would like a tad bit more info than saying the current
> | scheme is bad.  It tells me nothing about the benifits of your change.
> 
> In my experience, the current scheme has led to more problems, complications
> than any perceived benefits.  It has many pitfalls when trying to
> port to "non-conventional" filesystems, e.g. what you'd find on windows
> and unixes with mounted filesystems.  I believe wh-sandbox was
> branched before I finished making build-improvements fully workable
> on windows.  I believe people have ecncountered amny variations of the
> problems there.  On balance, I see the current steup having more
> problems than benefits it gives us on daily basis.

Sure.  Still unclear about how that relates to getting rid of int/, as
its just another directory.  Of course, Im the first to admit I have
near-zero experience with "non-conventional" file systems,
particularly windows.  Regardless, my main concern is the current
property of int/ w.r.t re-make, as mentioned above.

Many thanks for taking the time to respond to my questions!

\start
Date: Sun, 1 Jul 2007 09:37:27 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Build machinery -- support for out of source build

On Sun, 1 Jul 2007, Stephen Wilson wrote:

| Gabriel Dos Reis writes:
| 
| > On Sun, 1 Jul 2007, Stephen Wilson wrote:
| > 
| > | Am I correct in assuming the generated .lisp files are still easily
| > | inspected and modified, and share their own component of the
| > | dependency graph for make?
| > 
| > If I understand your question correctly, the answer is yes.
| 
| Ok.  Just for the sake of clarity, I meant that one can modify the
| intermediate lisp, and have those changes picked up by the build
| process without them being overwritten by a fesh tangling of a
| pamphlet.

In build-improvements, the .lisp files have depenencies on 
.lisp.pamphlet so that when .lisp are newer -- e.g. contained
hand-made changes -- they are not overwritten by the untangling
machinery.  Similarly the result of Boot -> Lisp translation
has careful dependency so that hand-made tweaks are not overwritten.

\start
Date: 01 Jul 2007 10:45:54 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: Build machinery -- support for out of source build

Gabriel Dos Reis writes:

> On Sun, 1 Jul 2007, Stephen Wilson wrote:
> 
> | Gabriel Dos Reis writes:
> | 
> | > On Sun, 1 Jul 2007, Stephen Wilson wrote:
> | > 
> | > | Am I correct in assuming the generated .lisp files are still easily
> | > | inspected and modified, and share their own component of the
> | > | dependency graph for make?
> | > 
> | > If I understand your question correctly, the answer is yes.
> | 
> | Ok.  Just for the sake of clarity, I meant that one can modify the
> | intermediate lisp, and have those changes picked up by the build
> | process without them being overwritten by a fesh tangling of a
> | pamphlet.
> 
> In build-improvements, the .lisp files have depenencies on 
> .lisp.pamphlet so that when .lisp are newer -- e.g. contained
> hand-made changes -- they are not overwritten by the untangling
> machinery.  Similarly the result of Boot -> Lisp translation
> has careful dependency so that hand-made tweaks are not overwritten.

Precisely what I was hoping to hear!

\start
Date: Sun, 1 Jul 2007 15:07:26 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Build machinery -- support for out of source build

Gaby,

On 7/1/07, you wrote:

> ...
> I believe wh-sandbox was branched before I finished making build-improvements
> fully workable on windows.  I believe people have ecncountered amny variations
> of the problems there.

Just a minor point of clarification: wh-sandbox uses a slightly
different approach to satisfying the problems created by the
MSYS/MinGW cross-compilation environment for windows. Even though MSYS
presents a very minimal cross-compilation environment, it still must
distinguish between the directory structure of the host and target
environments more rigorously than when building natively on Linux. The
approach that you took in build-improvements was to ensure that all
paths were relative.

In wh-sandbox we took a different approach by introducing a new
environment variable called $BASE so that absolute and relative build
system paths (used in MSYS utilities) could be augmented with root
path information to create compatible absolute paths for those parts
of the build system that run natively on Windows such as gcl and it's
derivatives. As a result, arguably perhaps, the paths in wh-sandbox
are slightly easier to understand and could (maybe) be appropriate for
other situations in which we might need/want to do cross-compilation..
But I consider the approach take in build-improvements to be equally
valid for the problem at hand.

> On balance, I see the current steup having more problems than benefits it
> gives us on daily basis.
>

I have no question at all about the benefits of the build-improvements
style make files over the current build system in Axiom Gold and
Silver. I am glad that you are finding the time to explain your
rational for these changes.

\start
Date: Sun, 1 Jul 2007 14:13:11 -0500
From: Tim Daly
To: list
Subject: out of source builds

I'm not sure why out of source builds are particularly important. But
there are two points to discuss.

The first point, mentioned in a prior email, is that there is a 
general class of requirements:
  (b) doing it because that's the way everybody does it
and this seems to be of that character. If there is a different
need anyone can point to as a good argument why this is important? I 
understand the CD argument as I put Axiom on the ISSAC CDs.
However this is a rare situation for distributing any open source
software these days. I cannot remember getting sources for an open
source project on CD. 

(Caveat: I had to recreate the whole build subsystem from scratch
so some of these features are not fully tested but they are there
by design. In particular, the newly added literate facilities are
not correct yet (e.g. Makefiles are extracted to "src" instead of
"obj/sys", which is a bug that needs to be fixed))

The second point is about the claim that the current build system
cannot build "out of source".  By design the "src" tree should never
be touched by Make so you should be able to mount the source read-only
and type Make. Any failures are a bug.

The current build system IS designed to do out of source builds. To do
this you need to notice two things. First, the top level Makefile
contains the lines:
  SRC=${SPD}/src
  INT=${SPD}/int
  OBJ=${SPD}/obj
  MNT=${SPD}/mnt

Second, notice that all of the file manipulations in the Makefiles
are prefixed by paths built from these 4 variables. Thus, to do
out of source builds it should suffice to just change these:
  SRC=${SPD}/src
  INT=${MYHOME}/int
  OBJ=${MYHOME}/obj
  MNT=${MYHOME}/mnt

All other Makefiles create IN, MID, OUT, DOC, etc from these. For
example see src/interp/Makefile. At the top you'll see:
  IN=${SRC}/interp
  MID=${INT}/interp
  OUT=${OBJ}/${SYS}/interp
  DOC=${MNT}/${SYS}/doc/src/interp
and the SYS variable is gotten from `basename $AXIOM` which is
a name to distinguish the type of target to build.






There were other issues back in the scratchpad days. Since a build 
could take weeks it was vital to architect the build system so the
  (1) builds need to be done minimizing the re-work.
  (2) builds could be done in parallel, out of source, multiple targets
  (3) builds only built the request parts
The current build system is designed to do all three.

MINIMIZE REWORK

Requirement (1), that builds need to be done minimizing the re-work,
is accomplished by the "int" subdirectory. Because Axiom uses boot
there is a whole translation stage needed to extract the source code.
The "src" source tree gets extracted into the "int" source tree. Many
steps, such as the Boot->Lisp translation are system independent and
only need ever be done once. Unless the boot code is changed there
is no reason to redo the work and waste the time, which is the point
of using Makefiles at all.

The "int" directory represents an Axiom build that considerably
speeds up the build process. The "int" directory
  (1) caches the Boot->Lisp translation (removes the need for 
      running bootsys, thus removing a whole build "pass".)
  (2) caches the .fn files for code optimization (allows optimal
      code to be generated on second compiles which improves the
      execution time of the final system)
  (3) caches the algebra system-independent translations
      (the .nrlibs contain several files including .lsp files
       which are post-algebra compiles. since algebra translation
       is an expensive step this is a huge savings)
  (4) caches the pamphlet weave output and tangle output (removes
      the need to run noweb at all)
  (5) caches the latex aux files so latex need only run once rather
      than twice for every file. (halfs latex time)

In theory you could ship the "int" directory and do a complete build.
With proper caching this could reduce the whole build time considerably,
probably to less than half an hour.

There has been much discussion about how long builds take and this is
a real concern. So careful attention to the system-independent cache
would create a huge savings of time, reducing single-file changes to
just a minute or so.

Make needs to pay close attention to doing rework only if a source
file changes. Otherwise Make can use the cached information in "int"
and reduce the build times by large factors (e.g. no algebra compiles).

I doubt anyone notices this feature because they probably do
   make clean
which destroys the cache. However Axiom is designed to do incremental
changes. You should be able to modify any source file, type 'make'
and have the system only rebuild the parts that are affected. It used
to do this and is designed to do this. Thus the issue about long
system builds should only happen on new systems. If you can't minimize
rework what is the point of using Makefiles?

After the first time you should almost never need to rebuild Axiom
from scratch, at least by design of the current build system. We
rarely did in the scratchpad project because it took weeks.






PARALLEL BUILDS, OUT OF SOURCE, MULTIPLE TARGETS

Requirement (2), that builds be done in parallel, was needed so that
multiple machines could work on the same source tree. Since Scratchpad
was build on wildly different architectures (Symbolics, IBM/RS6000,
IBM PC, SUN, VM/370) and wildly different lisps (Zetalisp, CMUCL,
AKCL, Golden Common Lisp, etc) there was a lot of build time involved.

The solution to this problem was the "obj" directory and NFS. By
design, if you do a build on any one system you will do 2 things:
 (1) you will cache all the rework into the "int" directory
 (2) you will create a new directory (e.g. obj/SUN, obj/RIOS)
     for that particular target system.

Once you have a valid system build life is good. All you have to
do on a new target system, e.g. PC386, is:
  make a new directory, 
      mkdir AX
  use NFS to network mount the old src and int directories readonly
      mount -readonly NFS:/home/daly/AX/src AX/src
      mount -readonly NFS:/home/daly/AX/int AX/int
  set the AXIOM variable
      export AXIOM=AX/mnt/PC386
  and run make
      make

Since the build system knows about int and the int files are newer
than src the build on the new system, PC386, only needs to compile
the lisp files for the interpreter and algebra. It only needs to 
compile the C files for graphics and hyperdoc. All of this work went
into the "obj/sys" directories. If the master source changed all you
had to do on the other systems was simple rebuilds.

This would be very useful if and when we have a compile-farm setup
with many different target architectures and different lisp systems.
All you need to do is a network mount and everybody builds from the
same src/int tree.





BUILD ONLY REQUESTED PARTS

The requirement (3) build only the request parts is partially
re-implemented but not fully. Look at the top level Makefile for
the lines:
   PART= cprogs
   SUBPART= everything

This information is passed in the ENV variable. Using this the
lower level Makefiles can skip whole subdirectories. You used to
be able to specify that you only wanted to build hyperdoc with:
   make PART=hyperdoc
and you could specify subparts, e.g. the hyperdoc pages
   make PART=hyperdoc SUBPART=pages






When I recreated the build system (post NAG) I was not exceptionally
careful to ensure that the "int" directory and "obj" directories
where especially "pure" but that is a trivial fix. It only requires
prefixing the output filenames in the makefiles with the right paths.
This is maybe a day's worth of work. Recovering the "PART" ability
is also reasonably simple since it only requires checks in Makefiles
before calling Make on subdirectories.

Axiom has been built for years and no-one has mentioned out of source
builds before. If this is a real issue then the current system is
designed to do it (modulo Makefile mistakes).

\start
Date: Sun, 1 Jul 2007 15:18:41 -0500
From: Tim Daly
To: list
Subject: out of source builds

That said, I believe the new build system is a useful change to
the system. There are two different issues which seem to be
orthogonal. 

One, addressed by the autoconf system, is the question of what
facilities are available on the current system. It appears that this
is covered quite well by the configure tool. It seems that this tool
created the proper global variables to find and use avaiable tools.

The second issue is what to do with these tools. The current system
mixes the tool configure settings with the `basename $AXIOM` settings
in Makefile.pamphlet. This is clearly wrong and should be fixed.  It
would be possible to use the autoconf configure to set global
variables in the Makefiles in the current system, which would represent
an incremental step along the path to the new build system.

So perhaps the first thing to try is just merge autoconf. This would
be much less work than a complete, monolithic merge and might add
significant benefit immediately. Even if we fully convert to the
whole new Makefile tree this is still a useful intermediate step.

It seems to me that the build system we want is actually a mixture of
the two existing systems. The current architecture is not all bad and
takes into account various axiom-specific needs. But it does not address
modern tools like configure.  I suggest that we discuss design goals
based on real requirements.

One design goal is minimizing build times. This is obviously 
important to developers. It also allows us to push out a patch
that would only take minutes to apply. (Hence, "int")

Another is "incremental rebuilds" (otherwise why use make?). This
is related to the first point. It should be possible to blow away
small portions of the system (e.g. an input file, hyperdoc pages,
the graphics, etc) and do a small rebuild. (Hence "PART="). The
PART= tool is also useful for adding/skipping things like Stephen's
new AXISP parser.

A third would be "axiom (i.e. zips) versions" versus "user (i.e.
/usr/local/bin) versions" of tools like lisp. Even with autoconf
there are times that we want to advise using a "known good" version
of tools. (Hence "zips")

A fourth issue, probably most valuable to me if not others, is the
"debugability" issue. The current build system puts out a unique
number in front of every build line so we can find the exact failing
stanza. This allows us to find and fix bugs rapidly. (Hence "echo #")

A fifth issue is out of source builds. That issue has been raised but
I'm not sure why it is important. I know of no instance where anyone
builds from CD sources for any open source project. CD readers are
much too slow compared to hard disks so that would seriously impact
the build times. I obviously agree that it should work since the
current build system is designed to do it. (Hence "SRC=")

What other design goals are there? 
How does the current system succeed or fail at achieving those goals? 
How does autoconf succeed or fail at achieving these goals?

\start
Date: Sun, 01 Jul 2007 16:22:04 -0400
From: William Sit
To: Cliff Yapp
Subject: Why did Axiom fail in the 1990s? (was: Paper usage policy (for authors))

C Y wrote (Re: Paper usage policy (for authors)):
> 
> Whether pamphlets qualify is probably a question for a lawyer.
> 
> I'm assuming anyone other than the original author has no special
> rights period.

Question for a lawyer means question for the courts? If the
authors have the "residual" rights as you mentioned,
wouldn't it be logical that the authors can assign such
"residual" rights to another entity?

> This is why I think the logical approch to take for pamphlets on
> subjects where we have no legal right to the original source material
> is to write our own review paper in the process, outlining the key
> points and weaving the original papers' ideas together into a whole
> (which is also the point of the CAS code, after all - at least for the
> well established mathematical work that will probably form the focus of
> most of our literate efforts for the first few years.)  What to do
> about original work without a larger body of literate is somewhat less
> clear, although I think in most cases an article appropriate for
> inclusion as a pamphlet will have to be slightly different from a
> typical research article.  (More background, context, etc.)

Writing new material in survey form is certainly alright
(this already is a huge undertaking and will require
constant updating), especially if no literate articles are
available. But overviews and surveys, such as at Wikipedia
or Mathematica sites are, I'm afraid, not what Tim has in
mind. He wants lock, stock, and barrel (all the shebang) *in
one pamphlet* so that one need not hunt for obscure outside
articles or be an expert in the field to follow, maintain
and improve the code. (That's why the COMBINAT code does not
yet pass muster.) That, I think, is kind of an oxymoron and
unattainable ideal (try reading any new algorithm in
symbolic computation and it is an infinite descent if you
are not already an expert *in the particular problem the
algorithm solves.* COMBINAT comes to mind.) Every pamphlet
would eventually be a pretty thick book, even if there are
plenty of literature covering the topic (nothing
fundamentally wrong with that except for lack of
author-power and stretching the 30 year horizon). Perhaps
Gaby's "incremental improvement" idea may work better, but
that is exactly what we have been debating about. I prefer
Ralf's pragmatic approach: get the code working and
stablized, add documentation at places where users or
developers find it lacking in details (that is, let
documentation be "demand driven" rather than "supply
driven"). 

> Hopefully, we can eventually make Axiom a driver for free availability
> of new publications in mathematical research via some sort of Axiom
> journal.  If the goal is truly to spread knowledge and learn, expensive
> commercial journals and their per-article or subscription fees present
> a barrior to that goal.  (Certainly I feel it, not being at a major
> university - there are ways but especially for older papers tracking
> them down can be extremely difficult.  We want knowledge to be easily
> accessible.  It's hard enough to get people to want to learn - why make
> it any harder when they actually do try to learn?)  I view this as a
> secondary goal of pamphlets - if Axiom is structured correctly, the
> pamphlets should eventually constitute a very high quality, complete
> description of the mathematical landscape that is freely available to
> everyone (which just incidently happens to have running CAS code to let
> you immediately apply those same ideas).

I agree with the goal, just not the means. Moreover, for
that vision to be realized, the prerequisite is a very large
user base. In its earlier days, SCRATCHPAD II had a fairly
respectable user base, contributing to hundreds of algebra
packages (the number of build-developers were about the same
as we currently have: a handful). We should perhaps
investigate why so many have abandoned Axiom and so few new
users. Documentation may be one reason, but history suggests
otherwise. Price may be another historic reason, but now it
is free. A steep learning curve? That did not stop the
earlier contributors and surely with so much more support
now, the learning curve should be less steep.
Non-functioning hyperdoc? But hyperdoc was fully working in
the NAG days. Aldor? Well, Aldor is not fairing that well
either. Perhaps the reasons are external to Axiom. Fewer
mathematicians or computer science doctorates? (that seems
to be the trend). Fewer people interested in computation?
(that can't be true! but the entrance level has certainly
gone higher). National Science Foundation (U.S.) no longer
supports Axiom? (that's it!) Any non-U.S. government
stepping in? would forming a non-profit tax-exempt
organization be able to raise sufficient funds for
supporting graduate students? -- that's about $30,000 per
student per year. We need half a million at 6% interest for
one.

Next question: what can we do to increase user base? (Let's
hear yours.)
 
> I think the Axiom project might be a bit like the Free Software
> Foundation in that respect - to me at least it's about more than just a
> working CAS.  It's about changing the landscape itself.  Not replacing
> the academic institutions and their work as they exist today, but
> making them more visible and more readily applicable to the rest of the
> world.  That's a more ambitious project than just a working CAS, but
> the potential rewards are even greater.

Great vision! Would you outline some plans and actions? (I
share with you that the journal and publishers in the math
and cs areas at least are exploiting academics: authors and
researchers do all the work (writing, reviewing, editing,
proofreading) and get *nothing* other than a bibliography
item.)
 
> The analogy I have always liked is the advancement of transportation.
> Take traveling west in the US, for example - people started doing it in
> covered wagons because that was quicker and easier for them than
> building anything better.  But soon, people built railways that
> dramatically improved just about everything where travel was concerned.
>  It made all sorts of things possible that were impossible before.
> Same with the US highway system - two lane roads will get you there,
> but superhighways will do it faster and much more quickly.  For an
> individual car, it makes more sense to use what is already there.  When
> many people rely on something, it's worth doing right even at the
> expense of greater up front cost and work.  Hopefully Axiom will prove
> to be an enabler for new types of mathematical research and and new
> levels of rigor and speed.  That's worth doing right, even if we have
> to spend the time to make the infrastructure to make it possible first.

Note that the building of superhighways was historically
demand-driven (national security, commerce, mobility, and
lots of drivers).

\start
Date: Sun, 1 Jul 2007 22:22:33 +0200
From: Juergen Weiss
To: Tim Daly
Subject: RE: out of source builds

My 5 cents worth of advice:

When I had a look at the build system of Scratchpad maybe
15 years ago, I got the clear impression, that it did
not follow best practice at that time -- it certainly
does not follow best practice today. So we should be
glad, that some people took the challenge to rebuild
it according to methods (autoconf et al.) which are
best practice today. We should move to the new build
system as soon as possible.

Regards

Juergen Weiss

P.S.: We should adopt best practice in other areas as well, namely
the way source code control systems are used. Use one (SVN) in
a way, that the hassle of other contributors is not
maximized, but minimized. And we should certainly do
EVERYTHING to keep developers like Gaby and Waldek. I value
their contribution higher than all the LP stuff of the
last 5 or so years.

> -----Original Message-----
> From: axiom-developer-bounces+weiss=uni-mainz.de@nongnu.org
>  On Behalf Of Tim Daly
> Sent: Sunday, July 01, 2007 9:13 PM
> To: list
> Subject: out of source builds
>
> I'm not sure why out of source builds are particularly important. But
> there are two points to discuss.
>
> The first point, mentioned in a prior email, is that there is a
> general class of requirements:
>   (b) doing it because that's the way everybody does it
> and this seems to be of that character. If there is a different
> need anyone can point to as a good argument why this is important? I
> understand the CD argument as I put Axiom on the ISSAC CDs.
> However this is a rare situation for distributing any open source
> software these days. I cannot remember getting sources for an open
> source project on CD.
>
> (Caveat: I had to recreate the whole build subsystem from scratch
> so some of these features are not fully tested but they are there
> by design. In particular, the newly added literate facilities are
> not correct yet (e.g. Makefiles are extracted to "src" instead of
> "obj/sys", which is a bug that needs to be fixed))
>
> The second point is about the claim that the current build system
> cannot build "out of source".  By design the "src" tree should never
> be touched by Make so you should be able to mount the source read-only
> and type Make. Any failures are a bug.
>
> The current build system IS designed to do out of source builds. To do
> this you need to notice two things. First, the top level Makefile
> contains the lines:
>   SRC=${SPD}/src
>   INT=${SPD}/int
>   OBJ=${SPD}/obj
>   MNT=${SPD}/mnt
>
> Second, notice that all of the file manipulations in the Makefiles
> are prefixed by paths built from these 4 variables. Thus, to do
> out of source builds it should suffice to just change these:
>   SRC=${SPD}/src
>   INT=${MYHOME}/int
>   OBJ=${MYHOME}/obj
>   MNT=${MYHOME}/mnt
>
> All other Makefiles create IN, MID, OUT, DOC, etc from these. For
> example see src/interp/Makefile. At the top you'll see:
>   IN=${SRC}/interp
>   MID=${INT}/interp
>   OUT=${OBJ}/${SYS}/interp
>   DOC=${MNT}/${SYS}/doc/src/interp
> and the SYS variable is gotten from `basename $AXIOM` which is
> a name to distinguish the type of target to build.
>
>
>
>
>
>
> There were other issues back in the scratchpad days. Since a build
> could take weeks it was vital to architect the build system so the
>   (1) builds need to be done minimizing the re-work.
>   (2) builds could be done in parallel, out of source,
> multiple targets
>   (3) builds only built the request parts
> The current build system is designed to do all three.
>
> MINIMIZE REWORK
>
> Requirement (1), that builds need to be done minimizing the re-work,
> is accomplished by the "int" subdirectory. Because Axiom uses boot
> there is a whole translation stage needed to extract the source code.
> The "src" source tree gets extracted into the "int" source tree. Many
> steps, such as the Boot->Lisp translation are system independent and
> only need ever be done once. Unless the boot code is changed there
> is no reason to redo the work and waste the time, which is the point
> of using Makefiles at all.
>
> The "int" directory represents an Axiom build that considerably
> speeds up the build process. The "int" directory
>   (1) caches the Boot->Lisp translation (removes the need for
>       running bootsys, thus removing a whole build "pass".)
>   (2) caches the .fn files for code optimization (allows optimal
>       code to be generated on second compiles which improves the
>       execution time of the final system)
>   (3) caches the algebra system-independent translations
>       (the .nrlibs contain several files including .lsp files
>        which are post-algebra compiles. since algebra translation
>        is an expensive step this is a huge savings)
>   (4) caches the pamphlet weave output and tangle output (removes
>       the need to run noweb at all)
>   (5) caches the latex aux files so latex need only run once rather
>       than twice for every file. (halfs latex time)
>
> In theory you could ship the "int" directory and do a complete build.
> With proper caching this could reduce the whole build time
> considerably,
> probably to less than half an hour.
>
> There has been much discussion about how long builds take and this is
> a real concern. So careful attention to the system-independent cache
> would create a huge savings of time, reducing single-file changes to
> just a minute or so.
>
> Make needs to pay close attention to doing rework only if a source
> file changes. Otherwise Make can use the cached information in "int"
> and reduce the build times by large factors (e.g. no algebra
> compiles).
>
> I doubt anyone notices this feature because they probably do
>    make clean
> which destroys the cache. However Axiom is designed to do incremental
> changes. You should be able to modify any source file, type 'make'
> and have the system only rebuild the parts that are affected. It used
> to do this and is designed to do this. Thus the issue about long
> system builds should only happen on new systems. If you can't minimize
> rework what is the point of using Makefiles?
>
> After the first time you should almost never need to rebuild Axiom
> from scratch, at least by design of the current build system. We
> rarely did in the scratchpad project because it took weeks.
>
>
>
>
>
>
> PARALLEL BUILDS, OUT OF SOURCE, MULTIPLE TARGETS
>
> Requirement (2), that builds be done in parallel, was needed so that
> multiple machines could work on the same source tree. Since Scratchpad
> was build on wildly different architectures (Symbolics, IBM/RS6000,
> IBM PC, SUN, VM/370) and wildly different lisps (Zetalisp, CMUCL,
> AKCL, Golden Common Lisp, etc) there was a lot of build time involved.
>
> The solution to this problem was the "obj" directory and NFS. By
> design, if you do a build on any one system you will do 2 things:
>  (1) you will cache all the rework into the "int" directory
>  (2) you will create a new directory (e.g. obj/SUN, obj/RIOS)
>      for that particular target system.
>
> Once you have a valid system build life is good. All you have to
> do on a new target system, e.g. PC386, is:
>   make a new directory,
>       mkdir AX
>   use NFS to network mount the old src and int directories readonly
>       mount -readonly NFS:/home/daly/AX/src AX/src
>       mount -readonly NFS:/home/daly/AX/int AX/int
>   set the AXIOM variable
>       export AXIOM=AX/mnt/PC386
>   and run make
>       make
>
> Since the build system knows about int and the int files are newer
> than src the build on the new system, PC386, only needs to compile
> the lisp files for the interpreter and algebra. It only needs to
> compile the C files for graphics and hyperdoc. All of this work went
> into the "obj/sys" directories. If the master source changed all you
> had to do on the other systems was simple rebuilds.
>
> This would be very useful if and when we have a compile-farm setup
> with many different target architectures and different lisp systems.
> All you need to do is a network mount and everybody builds from the
> same src/int tree.
>
>
>
>
>
> BUILD ONLY REQUESTED PARTS
>
> The requirement (3) build only the request parts is partially
> re-implemented but not fully. Look at the top level Makefile for
> the lines:
>    PART= cprogs
>    SUBPART= everything
>
> This information is passed in the ENV variable. Using this the
> lower level Makefiles can skip whole subdirectories. You used to
> be able to specify that you only wanted to build hyperdoc with:
>    make PART=hyperdoc
> and you could specify subparts, e.g. the hyperdoc pages
>    make PART=hyperdoc SUBPART=pages
>
>
>
>
>
>
> When I recreated the build system (post NAG) I was not exceptionally
> careful to ensure that the "int" directory and "obj" directories
> where especially "pure" but that is a trivial fix. It only requires
> prefixing the output filenames in the makefiles with the right paths.
> This is maybe a day's worth of work. Recovering the "PART" ability
> is also reasonably simple since it only requires checks in Makefiles
> before calling Make on subdirectories.
>
> Axiom has been built for years and no-one has mentioned out of source
> builds before. If this is a real issue then the current system is
> designed to do it (modulo Makefile mistakes).

\start
Date: Sun, 1 Jul 2007 15:43:53 -0500
From: Tim Daly
To: list
Subject: Why did Axiom fail in the 1990s?

There is a constant drumbeat to expand the number of developers.
To quote Chris DiDona, Danese Cooper, and Mark Stone (Open Sources 2.0
ISBN 0-596-00802-3, pXXVIII):
  
  Brooks' Law appears to set a fundamental limit on the optimal
  size of programming teams -- and a rather small limit at that.
  Empirical evidence supports Brooks's Law. For example, since
  its inception SourceForge.net has maintained very close to a
  10:1 ratio of registered users to registered projects, suggesting
  that open source development projects seldom have more than
  10 active developers.

\start
Date: Sun, 01 Jul 2007 17:10:31 -0400
From: William Sit
To: Tim Daly
Subject: Re: Why did Axiom fail in the 1990s?

My emphasis was to have more *USERS* and the question is 
why many former users abandoned Axiom and did not return. 
To clarify, "users" includes people who use Axiom to 
compute and/or contribute new algebra code with 
documentation (who may also be, but not exclusively, 
build-developers or system-developers: people who 
contribute to make, lisp, boot, user-interface, compilers, 
interpreters, packaging, etc.).

On Sun, 1 Jul 2007 15:43:53 -0500
  Tim Daly wrote:
>There is a constant drumbeat to expand the number of 
>developers.
>To quote Chris DiDona, Danese Cooper, and Mark Stone 
>(Open Sources 2.0
>ISBN 0-596-00802-3, pXXVIII):
   
>   Brooks' Law appears to set a fundamental limit on the optimal size
>of programming teams -- and a rather small limit at that.  Empirical
>evidence supports Brooks's Law. For example, since its inception
>SourceForge.net has maintained very close to a 10:1 ratio of
>registered users to registered projects, suggesting that open source
>development projects seldom have more than 10 active developers.

\start
Date: Sun, 1 Jul 2007 16:24:50 -0500
From: Tim Daly
To: list
Subject: Why did Axiom fail in the 1990s?

Scratchpad was a research project, not a commercial project.
The only reason that it became commercial was that Lou Gerstner,
hired from Nabisco to run IBM, set out to commercialize everything.

I'd like to blame Lou for everything but the collapse started
much earlier when the Federal Labs were closed putting an end
to much federally funded research. The trend eventually killed
off such great places as Xerox Labs, Bell Labs, and IBM Research.
(IBM Research exists but "it ain't the same", ask any old-timer)

I worked at IBM Research for years. Once Lou was hired there was
a push to "make research pay for itself". Scratchpad was going to
be sold in the market. We originally tried to sell it thru IBM.
However IBM had a requirement that programs must have extensive
documentation. And the documentation must be readable "at the
eighth grade level". There were programs which read the text and
flagged long words, long phrases, out-of-dictionary words, etc.
Since there was no way to document DistributedMultivariatePolynomials
under this stricture we could not market thru IBM.

We tried several paths. NAG was a logical path as they were well known
for their excellent mathematical tool (the NAG library) and their
ability to support mathematical software. Plus NAG had quality people
in the management team. Thus we managed to sell Scratchpad (as Axiom)
to NAG.

There was a huge cost however. None of the original IBM developers
(including me) were allowed to continue to work on Axiom. So Lou
managed to get money for the software but stripped it of the people.
We all were told to circle our chairs until we found some non-axiom
research that would pay for itself in real customer dollars. So
front-line computational mathematicians were stripped of the one
place where their skill sets could make a difference. (I ended
up working on a voice-recognition system for a bank).

Thus stripped of the people who made Axiom live, NAG had a huge task
on their hands. They could not afford to hire a 10-person support team
and open source did not exist at that time. (Well, it did since I
regularly shipped sources for scratchpad, but there was no "open
source developer network"). Without the people Axiom cannot be a
viable, growing product.

Thus I believe that NAG's only possible path was to use Axiom as a
market driver for their excellent NAG library. Given such a role Axiom
cannot and did not compete. I believe that once NAG connected to Maple
as an external library of choice it was clear that Axiom had to go.

Scratchpad was well ahead of the curve compared to Maple, MMA, etc.
Given the right support it could have been much better than it is
today. However, the IBM Research which Lou Gerstner shaped lacked any
sense of long term vision. What could "the 30 year horizon" mean to a
man who markets cookies (Lou's previous company)?

Scratchpad didn't die a natural death. It was killed by short term,
make it pay, thinking. Notre Dame took 300 years to build. Given the
short term mindset Lou would rather have built it overnight as a
prefab wooden house in a suburb using conventional tools and selling
for a nice markup.

\start
Date: Sun, 01 Jul 2007 17:29:13 -0400
From: William Sit
To: Tim Daly
Subject: Re: Why did Axiom fail in the 1990s?

Tim Daly wrote:
> 
> There is a constant drumbeat to expand the number of developers.
> To quote Chris DiDona, Danese Cooper, and Mark Stone (Open Sources 2.0
> ISBN 0-596-00802-3, pXXVIII):
> 
>   Brooks' Law appears to set a fundamental limit on the optimal
>   size of programming teams -- and a rather small limit at that.
>   Empirical evidence supports Brooks's Law. For example, since
>   its inception SourceForge.net has maintained very close to a
>   10:1 ratio of registered users to registered projects, suggesting
>   that open source development projects seldom have more than
>   10 active developers.
> 

Brooks' law may limit the number of developers, but it did
not say what constitutes a project. For a large project with
many (say 10) subprojects, Brooks' law may apply to
subprojects. Are you advocating one developer per subproject
is sufficient?

\start
Date: Sun, 1 Jul 2007 17:03:13 -0500
From: Tim Daly
To: Juergen Weiss
Subject: out of source builds

> We should adopt best practice in other areas as well, namely
> the way source code control systems are used. Use one (SVN)...

Did you listen to that video talk by Linus Torvalds about Git?  Did
you follow the linux mailing list debate about the relative merits of
Bitkeeper vs other systems?  Have you looked at mercurial?  I would be
hard pressed to claim that there is a clear "best practice" in this
area.  SVN is not considered "best practice" by all concerned since it
lacks several features important for distributed group development.
Indeed, GNU's Savannah server, which hosts Axiom, is the largest
repository of free software. It supports Arch, Git, and CVS but not
SVN. However, SVN works (mostly) and we did decide to use it.

This is all religion the debate will never end. We use what works
and try to accommodate others.

\start
Date: Sun, 1 Jul 2007 17:12:11 -0500
From: Tim Daly
To: William Sit
Subject: Why did Axiom fail in the 1990s?

> My emphasis was to have more *USERS* ...

Axiom has an astonishing number of downloads, given its advertising
budget. And it never ceases to amaze me how many people seem to know
about it. I was recognized in a random bookstore in philadelphia by
two japanese people who use Axiom. I was astonished, to say the least.
I know of no way to measure the number of users.

If we get code/documentation then I'd call them developers.

However, good documentation is clearly vital. Mathematica has dozens
of "for dummy"-level books available and many that have the classroom
as a target. Documentation at all levels is the only way I believe
that Axiom can live.

\start
Date: Sun, 1 Jul 2007 17:22:06 -0500
From: Tim Daly
To: William Sit
Subject: Why did Axiom fail in the 1990s?

> Brooks' law may limit the number of developers, but it did
> not say what constitutes a project. For a large project with
> many (say 10) subprojects, Brooks' law may apply to 
> subprojects. Are you advocating one developer per subproject
> is sufficient?

I wasn't advocating anything. I was commenting on the myth that
sourceforge projects have hundreds of developers.
However, to further quote the same source:

   What are we to make, then, of the thousands of Firefox
   contributors? The key is to recognize that they are not a
   homogeneous mass of contributors, and Firefox is not a monolithic
   piece of software. In fact, the design is highly modular, enabling
   small teams to work on separate components of the code without
   interfering with each other. 

We could easily have developers working on algebra (e.g. Martin) who
do not interfere with developers working on LP (e.g. Cliff).

\start
Date: Mon, 2 Jul 2007 08:28:55 +1000
From: Alasdair McAndrew
To: Tim Daly
Subject: Re: Why did Axiom fail in the 1990s?

Although I am a beginner myself, I agree that documentation is vital, as
well as classroom presence.  I intend to trial Axiom in the current semester
with a cryptography class, but I feel that at the moment Axiom is severely
hampered by lacking a native windows version - with full documentation
(HyperDoc or equivalent) and graphics - and the classy sort of interface
common to Maple,Mathematica, and MuPAD.  TeXmacs is only a stop-gap measure
towards this end, I think.  (I use Axiom in Emacs under linux, using
Martin's axiom.el.)

I think that an introduction to Axiom in book form would be very welcome.
It would have two consequences: it would advertise Axiom, and it would show
Axiom to be serious and useful software, rather than just a hobby for a few
developers.  I have had a little experience in book writing:

http://www.course.com/catalog/product.cfm?isbn=978-0-534-40011-8&CFID=33031138&CFTOKEN=54332257

and if a book project did get underway, I would be be happy to be involved.
Would O'Reilly, or Springer, be interested, do you think?

On 7/2/07, Tim Daly wrote:
>
> > My emphasis was to have more *USERS* ...
>
> Axiom has an astonishing number of downloads, given its advertising
> budget. And it never ceases to amaze me how many people seem to know
> about it. I was recognized in a random bookstore in philadelphia by
> two japanese people who use Axiom. I was astonished, to say the least.
> I know of no way to measure the number of users.
>
> If we get code/documentation then I'd call them developers.
>
> However, good documentation is clearly vital. Mathematica has dozens
> of "for dummy"-level books available and many that have the classroom
> as a target. Documentation at all levels is the only way I believe
> that Axiom can live.

\start
Date: Sun, 1 Jul 2007 18:24:03 -0500
From: Tim Daly
To: Alasdair McAndrew
Subject: Why did Axiom fail in the 1990s?

> Although I am a beginner myself, I agree that documentation is vital,
> as well as classroom presence. I intend to trial Axiom in the current
> semester with a cryptography class, but I feel that at the moment
> Axiom is severely hampered by lacking a native windows version - with
> full documentation (HyperDoc or equivalent) and graphics ...

I've been looking at the User's issue that Martin mentioned but that
won't help on the windows front.

I've also picked up a copy of wxMaxima sources. I've been looking at
making a wxAxiom. It looks reasonably straightforward and might bear
fruit but not likely in the time frame you would like. Looking at
the details is queued behind the current test cycle.

A wxAxiom would give us a completely portable front end that had
a look and feel similar to Maxima.

\start
Date: Sun, 1 Jul 2007 18:32:19 -0500
From: Tim Daly
To: Alasdair McAndrew
Subject: Why did Axiom fail in the 1990s?

> I think that an introduction to Axiom in book form would be very
> welcome. It would have two consequences: it would advertise Axiom,
> and it would show Axiom to be serious and useful software, rather
> than just a hobby for a few developers.

I'd love to see another book project get underway. I think you might
be able to get a few people interested, especially those who are
interested in classroom use. Let me know if I can help.

On the book front there are two primary sources. The first is the
"Jenks Book" (Jenks, Sutor "Axiom, The Scientific Computation System"
ISBN 0-387-97855-0 (EU ISBN 3-540-97855-0)). If you don't have a copy
I have an extra one I'd be willing to mail to you.

There is also the book I published: "Axiom Volume 1: Tutorial", 
available at Lulu.com (self-publish) or Amazon (Daly, Timothy
"Axiom Volume 1: Tutorial" ISBN 1-4116-6597-X). The original sources
are available in src/doc/bookvol1.pamphlet and the original image
in src/doc/bookvol1.pdf. I'd also be willing to mail you a paper
copy if you'll send a mailing address.

\start
Date: 02 Jul 2007 02:40:38 +0200
From: Martin Rubey
To: Constantine Frangos
Subject: Re: Axiom: Installation on suse 9.1, 32 bit and suse 10.1, 64 bit.

C. Frangos Constantine Frangos writes:

> Dear Martin,
> 
> I had axiom installed on a system which has suffered a disk crash and I need 
> to re-install it on a suse 9.1, 32 bit system, and a suse 10.1, 64 bit
> system.
> 
> Any suggestions on how to do this would be much appreciated.

I suggest that you try to install wh-sandbox, details can be found on
"AxiomSources" on MathAction.  Read Readme.wh first!!!  Very importantly, copy
the gcl tree as described in the Readme.wh from build-improvements.  As far as
I know, the standard version of noweb works.

I believe there are some problems for 64 bit, please ask these things on the
list.

> (How do I subscribe to the axiom mailing list ?).

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

(click on, for example "axiom-math", or "axiom-developer" to obtain
instructions)

\start
Date: Sun, 1 Jul 2007 22:41:45 -0500 (CDT)
From: Gabriel Dos Reis
To: list
Subject: Re: Build machinery -- support for out of source build

Tim --

  I'm replying to Bill's message, but really I'm replying to your 
message.  Please CC: me as I do not have "physically" access to 
Axiom mails.

  The CD "argument" is not a rare situation.  Replace CD by
US stick, if you're more modern than CD.

  It is not just because everybody is doing it -- even if it is
a good reason because there is no benefit of refusing to do it.



  The argument that 'by design the "src" tree should never be
touched by Make so you should be able to mount the source read-only
and type Make' is inherently bogus.  "src", "obj" and friends
are created *within* the Axiom source tree.  So if the source tree
is read only, there is no way you make type configure/make and succeed.  Here
is an experiment for you: Check out Axiom silver, make the whole tree
read-only; then try to build Axiom.  Report back.  
Maybe you thought you designed to accomplish out of source build, but there
are all evidence that you never try to see whether the implementation 
meets its goal.  You can just try and see.  There are obvious reasons
why the implementation can never succeed: the design has logical flaws.


* Minimize work.

  Obviously the Boot -> Lisp translation happens only if there is a
need to.  There is a simple straight forward solution to that:  setup
the dependencies correctly

     %.clisp: %.boot

In build-improvements, the dependency is slightly more complicated because
I have added a full bootstrap in three stages:
   (1) build from cached Lisp translation -- boot0
   (2) use boot0 to build from Boot source code -- boot1
   (3) use boot1 to build from Boot source code -- boot2
  
There should be a bootstrap compare between stages 1 and 2 -- not done
at the moment in build-improvements.  To the dependencies take into
account that staged build.  In case, an unnecessary rebuild is done.

The argument that "int/" speeds up the build process almost fallacious.


* Parallel build

  The current setup does not support parallel build -- at least
what most people using Make understand by parallel builds.  That is
a fact.  

  To minimize  user and developer time, Axiom should support parallel
build on the same machine, in the same build tree.  I know you don't care
about developer time, but others do.  I'm not working for an
imperial business machine corporation so I don't own several supercomputers,
many other potential contributors are in similar situation.

  Build-improvements support parallel builds.  Because it supports out of
source build, it also support build on NFS.  Note that parallel build
is supported because build-improvements is carefully in setting up
dependencies on the files -- something the current setup does not do, which
obviously is a fundamental flaw.


* Build only required parts.

  This is supported by modularization and crafting Make target rules.
Obviously build-improvements does support selective builds.  

    make all-boot   
    make all-lib    
    make all-hyper
    make all-axiomsys
    make all-algebra
    ...


The key is in knowing to use the tool we have: Make.

\start
Date: Sun, 1 Jul 2007 23:07:13 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Build machinery -- support for out of source build

Tim --

  The current build setup in sikver is fundamentally flawed.  It
decides to misuse Make by ignoring the notion of proper dependencies 
and building its own notion of dependency.  That should go away.

  int/, sys/ bring nothing beneficial we use on daily basis, that
we don't already have. Minimal rework is done differently -- setting
up proper dependencies.  That also has the by-product of the
clarifying the structure of the components.  

\start
Date: Mon, 2 Jul 2007 01:09:58 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Build machinery -- support for out of source build

On 7/1/07, Gabriel Dos Reis wrote:
> ...
> In build-improvements, the dependency is slightly more complicated
> because I have added a full bootstrap in three stages:
>    (1) build from cached Lisp translation -- boot0
>    (2) use boot0 to build from Boot source code -- boot1
>    (3) use boot1 to build from Boot source code -- boot2
>
> There should be a bootstrap compare between stages 1 and 2 -- not done
> at the moment in build-improvements.  To the dependencies take into
> account that staged build.  In case, an unnecessary rebuild is done.
>

I think this "bootstrap compare" step is very important and should be
added to build-improvements. Previous tests done with the Axiom Gold
sources showed that the "stage 1" (which is the only stage implemented
in Gold) is *not* sufficient to ensure that the generated Lisp is
identical to that generated by a stage 2 build. In particular stage 1
is missing some Lisp code optimizations that are apparently possible
when all of the Axiom library types are known and propagated to
dependent modules.

We had a lot of discussion about this on this email list a few years
ago when it seemed to me most related to the solution of mutual
dependencies across several Axiom source modules. In principle
solution of these mutual dependencies might require a large number of
iterations in order to read a fixed point. But in the case of Gold,
stage 3 always generated identical code as stage 2.

But this view pre-dates the more recent work done by Waldek in
wh-sandbox on the new bootstrap procedure. As I understand it, this
new procedure makes use of a flag built-in to the SPAD compiler but
not previously used (and apparently no where adequately documented),
which allows the complete and consistent type system of the Axiom
library to be compiled directly from the SPAD sources (not using any
bootstrap lisp code), in a single initial pass. After this is done
there are no longer any dependencies between the library modules and
they may be compiled in any convenient order so a subsequent pass
generates the Lisp code and compiles it to object code. I think the
intention here of the original Axiom developers was to solve the
cross-module mutual dependency problems that I referred to above - but
that is really only a guess.

Waldek has included some initial documentation of this new bootstrap
process in the pamphlet files of wh-sandbox and on this list. But I
think more work might be needed to re-assure ourselves that this new
process does indeed solve the problem.

You are certainly right that these changes drastically alter the
nature of the dependencies among the modules in the Axiom algebra
library.

\start
Date: Mon, 2 Jul 2007 00:17:42 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Build machinery -- support for out of source build

Clearly you don't see that a compromise is worth attempting.
That's fine. It was just a suggestion.

> The argument that 'by design the "src" tree should never be
> touched by Make so you should be able to mount the source read-only
> and type Make' is inherently bogus. "src", "obj" and friends
> are created *within* the Axiom source tree.

Ok. I guess I wasn't clear enough. Let me try again.
Suppose the src tree is in /home/daly/axiom
and you would like the build to be in /home/gaby.
I believe it is sufficient to type

  cd /home/daly/axiom
  export AXIOM=`pwd`/mnt/linux
  make INT=/home/gaby/int OBJ=/home/gaby/obj/linux MNT=/home/gaby/mnt/linux

although I've never tried it. Once the current build/test cycle completes
I'll try it. It is an interesting experiment and should uncover some 
simple bugs, I'm sure. However, the design calls for the construction of 

  /home/gaby/int
  /home/gaby/obj/linux
  /home/gaby/mnt/linux

which, as I understand it, is an out-of-source build. There will 
certainly be bugs. But the system should work by design. I'll try
it, fix the bugs, and put this issue to rest.




* Minimize work

> In build-improvements, the dependency is slightly more
> complicated because I have added a full bootstrap in three stages.

That's fine but uninteresting. The goal of making autoconf work in
silver has nothing to do with your boot improvements. Those should
be independent changesets.




> The argument that "int/" speeds up the build process is almost
> fallacious.

I listed 5 ways that "int" speeds up the build process. Why don't those
ways speed up the build? The "int" directory cache doesn't speed up
the build the first time but it doesn't slow it down either. However,
the second build is much, much faster if you retain the cache.

You could argue that the files in "int" and the files in "obj" could
be merged into a single directory with the same speedup result. That
is true in terms of speed. However you lose one major ability when
you merge int and obj. Suppose that we want to build Axiom on several
different platforms, e.g. fedora, debian, ubuntu, solaris, and other
systems that might exist in a compile farm. In the current split the
  
   int directory contains system-independent, machine-generated files
   obj directory contains system-dependent, machine-generated files

so you can
  
  1) do a complete build on one system
    for each different system do:
      2) copy the whole axiom tree to the next system
      3) rm -rf obj mnt
      4) set the AXIOM variable
      5) make

and you get a whole new Axiom for the second system but you never
need run boot, you don't have to run noweave, you need only run
latex once, and you don't have to do the algebra compiles. Seems
like a HUGE saving of time to me. Since we do not yet have a
compile farm this facility isn't heavily used outside my home.

I'm not sure how you might do this if int and obj are merged.



You clearly have a different idea of how autoconf should structure
system builds in silver. That's fine. I'm simply pointing out that
the current build system has features which most people do not 
understand. We can recreate these features in the new build system
after the diff-Naur merge completes if we find them useful.

\start
Date: Mon, 2 Jul 2007 09:44:18 +0200
From: Juergen Weiss
To: Tim Daly
Subject: RE: out of source builds

Sorry for not being clear enough. I meant using ONE source
code control system is best practice - not half a dozen.
Which one you choose is a matter of taste and convenience -
not one of best practice. And I think convenience (current
hosting) suggests using SVN. Besides I do not see any major
deficiency, which would impede our work more than using
several systems.

> -----Original Message-----
>
> > We should adopt best practice in other areas as well, namely
> > the way source code control systems are used. Use one (SVN)...
>
> Did you listen to that video talk by Linus Torvalds about Git?  Did
> you follow the linux mailing list debate about the relative merits of
> Bitkeeper vs other systems?  Have you looked at mercurial?  I would be
> hard pressed to claim that there is a clear "best practice" in this
> area.  SVN is not considered "best practice" by all concerned since it
> lacks several features important for distributed group development.
> Indeed, GNU's Savannah server, which hosts Axiom, is the largest
> repository of free software. It supports Arch, Git, and CVS but not
> SVN. However, SVN works (mostly) and we did decide to use it.
>
> This is all religion the debate will never end. We use what works
> and try to accommodate others.

\start
Date: Mon, 2 Jul 2007 04:55:58 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Build machinery -- support for out of source build

On Mon, 2 Jul 2007, Tim Daly wrote:

| Clearly you don't see that a compromise is worth attempting.
| That's fine. It was just a suggestion.

If you believe I'm not at the compromise table, then we should probably
stop this discussion.

[...]

| > The argument that 'by design the "src" tree should never be
| > touched by Make so you should be able to mount the source read-only
| > and type Make' is inherently bogus. "src", "obj" and friends
| > are created *within* the Axiom source tree.
| 
| Ok. I guess I wasn't clear enough. Let me try again.

Oh no, you were clear.  But you keep saying "I believe", when
you are invited to try for *concrete* an experiment.  Please could you rry the
experiment I suggested before you continue?

[...]

| simple bugs, I'm sure. However, the design calls for the construction of 
| 
|   /home/gaby/int
|   /home/gaby/obj/linux
|   /home/gaby/mnt/linux
| 
| which, as I understand it, is an out-of-source build.

What is out-of-source build is this:

   (1) check out Axiom into ax-src
   (2) mkdir ax-build
   (3) cd ax-build && ../ax-src/configure && make

Report back.

   Try similar experiments with GCC, GDB, Autoconf, Automake, binutils,
fileutils, etc.  Report back.

What are the logical reasons why Axiom should refuse to support that?

[...]

| * Minimize work
| 
| > In build-improvements, the dependency is slightly more
| > complicated because I have added a full bootstrap in three stages.
| 
| That's fine but uninteresting. The goal of making autoconf work in
| silver has nothing to do with your boot improvements.

You are wrong.  A dependency tracking needs to be part of the system,
not just at the Make level, but also the system level.  Otherwise, you get
into obscure contorsions as exemplified by the build of depsys. 

[Please, don't say I don't understand why the build of depsys is the way you
wrote.  However, that is only because you chosed a poor tool to do a poor
implementation]. 


[...]

| > The argument that "int/" speeds up the build process is almost
| > fallacious.
| 
| I listed 5 ways that "int" speeds up the build process. Why don't those
| ways speed up the build? The "int" directory cache doesn't speed up
| the build the first time but it doesn't slow it down either. However,
| the second build is much, much faster if you retain the cache.

Have you tried setting up a dependency of the files at Make level, and try
make -j N, where N is any positive integer of your choice? N=4,8,16
usually gives me bindly fast build on build-improvements.


[...]

| You could argue that the files in "int" and the files in "obj" could
| be merged into a single directory with the same speedup result. That
| is true in terms of speed. However you lose one major ability when
| you merge int and obj. Suppose that we want to build Axiom on several
| different platforms, e.g. fedora, debian, ubuntu, solaris, and other
| systems that might exist in a compile farm. In the current split the
|   
|    int directory contains system-independent, machine-generated files
|    obj directory contains system-dependent, machine-generated files
| 
| so you can
|   
|   1) do a complete build on one system
|     for each different system do:
|       2) copy the whole axiom tree to the next system
|       3) rm -rf obj mnt
|       4) set the AXIOM variable
|       5) make

I do not think I lose that ability; see below.

A note:
Have tried that for a fact  *on today systems* to know that the above scheme
actually speeds up the build compared to what we have in build-improvements?
I have not, but here are a few points:

   (1) I tried separate concurrent builds on many machines since 2005.
   (2) Waiting for one system to complete is a complete waste of valuable
       time, because by the time one completes, it is likely that all
       have already completed -- and I've seen that many times.  Therefore the
       time and effort to copy to other systems are pure waste.  If you have
       30 years before you to build the system, that is fine.  Many 
       potential contributors haven't.

   (3) How often do you need to know that today?  Design for common usage.


Here is why I don't think you lose the ability you mention above: once you
have a complete build, you can just issue make clean-objects [or any make
target of your choice]; that will automaticaly clean all system-dependent
files.   

But above all, the simplest, and probably fastest way on today machines,
is to simply support simple out-of-source build as I outlined above,
parallel make (make -j N)


| I'm not sure how you might do this if int and obj are merged.

Have make target for them.  Simple.

Today on build-improvements, I can step into a subdirectory and issue
make, make clean, etc. and have the specific task I want done by Make.

| You clearly have a different idea of how autoconf should structure
| system builds in silver.

It is wrong to think that I believe Autoconf should structure
system builds in silver.  It does not structure the build.  Its sole
purpose is to collect system-dependent information and generate a few
(source) system dependent code from a single template.  That is all.
The rest of the build is conventional structured Makefiles.  There is
nothing fancy in Axiom that needs any of the unconventional obscure setup we
have in Silver.  

If you want a maintainable system and to facilitate learning of the system by
potential contributors, you don't want to be creative where a simple standard
construct does the job, and better. 

| That's fine. I'm simply pointing out that
| the current build system has features which most people do not 
| understand.

Instead of saying tha people don't understand them, it might be accurate to
say that people understand the ideas but disagree with the implementation.

\start
Date: Mon, 2 Jul 2007 06:53:53 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Build machinery -- support for out of source build

> You are wrong. A dependency tracking system needs to be part of the
> system, not just at the Make level, but also the system
> level. Otherwise you get into obscure contorsions as exemplified by
> the build of depsys.

Depsys exists for a reason. It handles things like macros in lisp
and it removes things that are only needed at compile time from the
final running image. If you miss the depsys dependencies you'll find
that you get "clean" lisp compiles but the generated code is wrong
due to missing macro expansions. This will show up as runtime bugs
much later in the process, perhaps during algebra computations.

Make and lisp have slightly different ideas about what it means to
depend on something. If you actually list all of the dependencies at
the Make level you'll find that you do a lot of unnecessary work.
This only shows up when you begin to change a single file and do
Make again. In theory Make should do the minimum amount of required
work given all the dependencies. In a lisp based system this is very
hard to do.

A simple example is that the algebra code is built in layers. Each
layer is built depending on the layers beneath it. Originally the
algebra Makefile specified this dependency, which worked fine during
the build. Yet if you change a single algebra file and do a second
Make you can end up rebuilding a lot of the algebra needlessly.

The current system dependencies were determined by doing a system
build and then doing a modification to each kind of file, followed
by a Make. In theory Make should only do a small amount of work to
include only changes required. It took a fair amount of testing to
determine the compromises between what Make needs and what lisp needs.

Getting this right is important and requires a lot of testing.

\start
Date: Mon, 2 Jul 2007 07:44:34 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Build machinery -- support for out of source build

On Mon, 2 Jul 2007, Tim Daly wrote:

| > You are wrong. A dependency tracking system needs to be part of the
| > system, not just at the Make level, but also the system
| > level. Otherwise you get into obscure contorsions as exemplified by
| > the build of depsys.
| 
| Depsys exists for a reason.

I know why it exists.  I was not discussing its exitence -- which can be
made obsolete, I'm saying that because I've done it this week-end.
Rather, I'm talking of *the way* it is constructed.

| It handles things like macros in lisp
| and it removes things that are only needed at compile time from the
| final running image. 

Make appropriate uses of 

    (eval-when (:compile-toplevel) ...

or

    (eval-when (:compile-toplevel :load-toplevel) ...


Plus, there are Lisp systems that some of us would like to support
(e.g. ECL, which shares a common ancestry with GCL) where the way you build
depsys is simply not possible: There is no notion of saving a current
Lisp image.  Yet, I succefully bootstrapped bootsys and depsys.  The
only thing that stopped me from building the whole system is that ECL insists
on ANSI Lisp compliance whereas Axiom silver insists on ANSI Lisp defiance.
   

To build depsys with such systems, you need to have a clear picture
of the dependency *expressed in the code*  -- not just outside in a comment,
separated from the code.  For example, I extended Boot with a macro
"import-module" which has the effect of tracking dependencies.  Much
like C-#include, except that it is not as brittle as C's -- it is
idempotent for, no special include guard etc, augment the compile and
load time environments as necessary.

| If you miss the depsys dependencies you'll find
| that you get "clean" lisp compiles but the generated code is wrong
| due to missing macro expansions. 

Not, if you have the system keep track of the dependency, not just
at Make level, but at the system level.  For example, with the
"import" construct I added to Boot, I can use bootsys to generate
the Make dependency, and at the same time have the Lisp system keep
track of the dependency at load time.  I've completed that work this
week-end while I was trying to finish something I promised
Ralf (have Axiom build standalone programs).

The way I use bootsys to generate dependency is not a novel idea.
Automake uses GCC to automate dependency tracking; GCC has a switch 
for generating Make dependencies.


| Make and lisp have slightly different ideas about what it means to
| depend on something. If you actually list all of the dependencies at
| the Make level you'll find that you do a lot of unnecessary work.

That is not the case of the Axiom components I've tried so far.

| This only shows up when you begin to change a single file and do
| Make again.

I've done that many times -- I did not suffer any of your predictions.

| A simple example is that the algebra code is built in layers. Each
| layer is built depending on the layers beneath it. Originally the
| algebra Makefile specified this dependency, which worked fine during
| the build. Yet if you change a single algebra file and do a second
| Make you can end up rebuilding a lot of the algebra needlessly.

If the dependencies are properly written and the system the properly
modularized, there is not need to.  There already exist a first 
approximation that works very well in build-improvements -- look into
src/alegbra/Makefile.  Please try it and tell me which aspects of it gets into
your way in everyday things you do.


I have no doubt that you have encountered many issues.  However, after
spending a fair amount of resources studying Axiom's current build setup it
appears to me that many ideas were flawed and many concrete realizations of
ideas were ill-advised and wrong headed.  So, one should be listening to your
reports on this issue; but only to be sure to move away from the current
setting, to be sure NOT to perpetuate the current build.  The setup should
have been done using best practice at time -- it apparantly didn't.  Now is an
opportunity to correct that path.

Similarly, I hope we do not lose Waldek's rework of the algebra bootstrap.
We should get it and improve it.

\start
Date: Mon, 02 Jul 2007 07:29:35 -0700
From: Simon Michael
To: list
Subject: Re: axiom wiki spam

Bill Page wrote:
> Yes, planned but no time and no one hounding me to do it.  :-(
Monday: consider this one hound. :) It's every other day now, I think 
something must be done. Chat me for help.

\start
Date: Mon, 2 Jul 2007 14:51:28 -0400
From: Bill Page
To: William Sit
Subject: Re: Why did Axiom fail in the 1990s?

On 7/1/07, William Sit wrote:
> My emphasis was to have more *USERS* and the question is
> why many former users abandoned Axiom and did not return.
> To clarify, "users" includes people who use Axiom to
> compute and/or contribute new algebra code with
> documentation (who may also be, but not exclusively,
> build-developers or system-developers: people who
> contribute to make, lisp, boot, user-interface, compilers,
> interpreters, packaging, etc.).
>

I think we need to face the fact one possible reason why previous
Axiom users have abandoned Axiom and why there are so few new people
who identify themselves as Axiom users is simply because Axiom is too
hard to use. We may have a strong belief and commitment to the
strongly-typed object-oriented programming environment offered by
Axiom but when you get right down to it - even after 5 years of
working with Axiom fairly intensively! - when I sit down to do
something new in Axiom I still find it enormously more difficult to
get started in Axiom than in Maple, Mathematica or Maxima. I think the
Axiom interpreted does a heroic job of trying to isolate the user from
the intricacies of the Axiom type system, but unfortunately it is not
nearly enough. After a few minutes of working on some new problem you
are almost certain to run into some expected behavior involving type
inference - some quite difficult to solve. I think this is often
deadly to all but the most die-hard Axiom novice users.

Even the original Axiom developers where aware how difficult it is for
new users to use Axiom and so started on a path to develop a new
interpreter called B# (BNatural). Unfortunately this was only towards
the end of the research project at IBM and the mean time both
Mathematica and Maple had started to make major in-roads with computer
algebra users. In spite of a major development effort by NAG,
realistically Axiom never really had a chance against this
competition.

I could be that as an experiment, the failure of Axiom as a viable
computer algebra system shows that there is something wrong with the
concepts of strong typing and object-orientation when it comes to the
design of computer algebra systems. After all most mathematics is not
conducted in anywhere near a rigorously typed manner as required by
even the simplest Axiom program.

Oddly however, the Axiom library with over 1,300 algebra modules is
strong evidence to the contrary. As an library of mathematical
routines, Axiom is a phenomenal success. Apparently a lot was done
right in the design of the SPAD (and Aldor) compilers.

Maybe Axiom was just a little too far ahead of it's time (again).
Maybe languages like Haskell with full type inference show a possible
way forward. Maybe dynamically types scripting languages like Python
(such as used by Sage), show a way to develop a user accessible
interpreter. But unfortunately for Axiom, it might be too late. :-(

\start
Date: Mon, 02 Jul 2007 21:13:16 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Why did Axiom fail in the 1990s?

> I could be that as an experiment, the failure of Axiom as a viable
> computer algebra system shows that there is something wrong with the
> concepts of strong typing and object-orientation when it comes to the
> design of computer algebra systems. After all most mathematics is not
> conducted in anywhere near a rigorously typed manner as required by
> even the simplest Axiom program.

I think it is clear to everyone that there are two things to achieve 
with Axiom

1) write a good an maintainable library
2) call that library (being an ordinary mathematician)

I agree that 1) is hard, but without types that will end up in code 
nobody understands. Look at today's Maple and Mathematica languages, 
they add type information and check that at runtime. I think the 
direction is pretty clear and Aldor is still miles ahead of the big M's.

Point 2) is a hard nut. I agree that if a mathematician (or however 
wants to use Axiom) tries to understand his own field with the help of a 
  CAS doesn't want to be bothered with types. It should be possible to 
add them, but initially it might not be very clear to the user. Think of 
someone exploring a completely new field where perhaps no algorithm is 
known to achieve some task. It is usually impossible to give a type.

However, I don't think it is a hard task to implement ExpressionTrees in 
Aldor/SPAD as they exist in other CAS. With that domain everything is 
basically typeless. The next task then would be to add properties to 
things like "+", "*", "diff", "int", etc. That can be done as in Maple.

The biggest problem is to connect the typeless and the typed worlds. 
That I consider as a research project.

\start
Date: Mon, 2 Jul 2007 15:34:32 -0500 (CDT)
From: Gabriel Dos Reis
To: list
Subject: re: Build machinery -- support for out of source build

On Mon, 2 Jul 2007, Ralf Hemmecke wrote:

| Hi Gaby,
| 
| > I've completed that work this week-end while I was trying to finish
| > something I promised Ralf (have Axiom build standalone programs).
| 
| Actually, I am more interested in Axiom without Algebra or better to say in a
| clear cut specification of things that could be used to build the Axiom
| library.

Yes, we agree on that.  It is just that it was easier to attempt to
get Axiom produce standalone executable than untangle the whole mess :-)

Your point is well taken.

\start
Date: Mon, 2 Jul 2007 21:14:18 -0500
From: Tim Daly
To: list
Subject: SVN failure

Ok, I need help here.

I did an update
  svn update

Then I downcased the filename FAQ to faq by doing:
  svn mv FAQ faq
and got the result
  A faq
  D FAQ
The local filename was changed.

After doing all of the other changes I did
  svn commit -m"20070701 merge downcase branch to master"

The SVN commit blows up immediately with:
  Deleting FAQ
  svn: Commit failed (details follow):
  svn: Item 'trunk/axiom/FAQ' is out of date

I downloaded a new copy of the whole repository and did:
  diff -Naur old/faq new/FAQ
and they are exactly the same. So there are no changes to the files.
Update also did not see any changes.

So (a) what went wrong and (b) how do I fix it.

\start
Date: Mon, 2 Jul 2007 23:03:38 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: SVN failure

http://subversion.tigris.org/faq.html#wc-out-of-date

On 7/2/07, Tim Daly wrote:
> Ok, I need help here.
>
> I did an update
>   svn update
>
> Then I downcased the filename FAQ to faq by doing:
>   svn mv FAQ faq
> and got the result
>   A faq
>   D FAQ
> The local filename was changed.
>
> After doing all of the other changes I did
>   svn commit -m"20070701 merge downcase branch to master"
>
> The SVN commit blows up immediately with:
>   Deleting FAQ
>   svn: Commit failed (details follow):
>   svn: Item 'trunk/axiom/FAQ' is out of date
>
> I downloaded a new copy of the whole repository and did:
>   diff -Naur old/faq new/FAQ
> and they are exactly the same. So there are no changes to the files.
> Update also did not see any changes.
>
> So (a) what went wrong and (b) how do I fix it.

\start
Date: Mon, 2 Jul 2007 23:23:58 -0500
From: Tim Daly
To: Alfredo Portes
Subject: SVN failure

Well, the only solution I see at that site you recommended is to run
  svn update

which I did before making my changes. So I just ran svn update and it
destroyed my work. I'll follow the standard practice, blow away
everything, and redo the work.

Why didn't the svn update bring my copy up to date? I ran it before
making changes. I did nothing clever. Just update, mv, rm, and commit.

Source code contol systems should never lose work. Never.
What a waste.

\start
Date: Tue, 03 Jul 2007 08:18:07 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: SVN failure

On 07/03/2007 04:14 AM, Tim Daly wrote:
> Ok, I need help here.
> 
> I did an update
>   svn update

In the root directory of your tree? Did the update succeed? What did it 
tell you?

\start
Date: Tue, 3 Jul 2007 03:15:42 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: SVN failure

Hi Tim,

Sorry to hear about that. It was not my intention for you to loose your work,
I just pointed out the link for what svn faq says about this error.

I do no understand how svn update could have written on top of your
modified files.

Sorry again, maybe somebody in the list has an explanation to what happened.

On 7/3/07, Tim Daly wrote:
> Well, the only solution I see at that site you recommended is to run
>   svn update
>
> which I did before making my changes. So I just ran svn update and it
> destroyed my work. I'll follow the standard practice, blow away
> everything, and redo the work.
>
> Why didn't the svn update bring my copy up to date? I ran it before
> making changes. I did nothing clever. Just update, mv, rm, and commit.
>
> Source code contol systems should never lose work. Never.
> What a waste.

\start
Date: Tue, 03 Jul 2007 10:56:07 +0200
From: Ralf Hemmecke
To: Alfredo Portes
Subject: re: SVN failure

> On 7/3/07, Tim Daly wrote:
>> Well, the only solution I see at that site you recommended is to run
>>   svn update
>>
>> which I did before making my changes. So I just ran svn update and it
>> destroyed my work. I'll follow the standard practice, blow away
>> everything, and redo the work.

>> Why didn't the svn update bring my copy up to date? I ran it before
>> making changes. I did nothing clever. Just update, mv, rm, and commit.
>>
>> Source code contol systems should never lose work. Never.
>> What a waste.

Tim, next time before you do anything with svn, could you try to log 
your session. Maybe someone can then better guess what the error is.
Do you happen to have a log for your last SVN attempt?

\start
Date: Tue, 03 Jul 2007 11:45:01 +0200
From: Ralf Hemmecke
To: Klaus Grue
Subject: Re: LogiWeb

Hi Klaus,

> But if you explain what you are doing (e.g. giving an URL I should
> start with), then I would be able to say something about whether or
> not Logiweb would be helpful to you and, if it is, how it could be
> used.

Well I am terribly sorry that I forgot to point you to the homepage of
the open source computer algebra system AXIOM.

http://axiom-developer.org/

But I guess, the information there is not organized enough for everyones
taste. So if you don't understand something, it's probably better to ask
on the axiom-dev list.

Maybe a good start would be to download the Axiom book (it's free) or 
try out AXIOM online inside the WIKI.

> Yes. It is an infrastructure more than anything else. One can publish
>  'pages' (or 'papers' or 'pamflets' if you like) on it. Such pages
> can be flat TeX, but they may also contain programs, lemmas, proofs,
> and similar. A page can also define what to do with formal contents
> (e.g.: compile the programs, run programs on specified data, render
> the output, invoke particular proof systems on particular proofs, and
> much more).

Oh, that sounds even more interesting that you can already compile
programs that are hidden in papers. In fact, currently a pamphlet file
is nothing else than an ordinary input file for noweb
(http://www.eecs.harvard.edu/~nr/noweb/). They contain the programs and
Makefiles are used to extract and build the program. In fact, one
pamphlet contains only a part of the whole AXIOM CAS.

BTW, what tool to you use to translate TeX into HTML?

>> Think of the Axiom Journal idea.

That idea is still a dream. But basically, I would like to be able to
take a paper and a system then grabs all the references in it and builds
the underlying AXIOM CAS as the author of the paper used it. So I should
be able to get back in time to get to the same situation as the author.
Maybe lamda calculus is abstract enough to make porting to future
platforms a non-issue. I really think your LogiWeb idea should be
exploited in our computer algebra context. In fact, I am happy to see
already connections to proof systems since joining CAS and theorem
provers is the future.

>> LogiWeb is GPL. The only drawback I see is that it is basically a 
>> one-man-project.

> That is a decision I made. I have led several small and big software
>  development projects in academia as well as the industry. But
> Logiweb is made the Knuth way: if you cannot program it yourself, it
> is too complicated. There not one character in the source code that I
> have not typed myself. The Knuth approach takes time, but the result
> tends to be small and coherent.

I completely understand your decision, but now it might be time to open
it up. Which means more people than just you need to understand the
scary details. LogiWeb would be dead immediately if there happens
something dragically to you. How much is LogiWeb already in use
somewhere? What would be a good start to read about the overall
infrastructure and the internals? Any linearly readable text available?

> But from now on, anyone can continue the developement of the system 
> without touching the source code: Anyone can add facilities to
> Logiweb by publishing Logiweb pages containing the facilities. I
> intend to continue doing bugfixes, minor updates, and porting (and I
> would not mind getting help on that:-)

Does LogiWeb have some features like WEB, i.e. change files by which one
can modify the originally published program? (Honestly, I don't really
understand the details of Knuth's .ch files, but it sounds to me like a
necessary feature to remove bugs without touching the original sources.

>> And I am still not clear about what it really means to program in
>> pure lambda calculus.
> 
> It means that if you want to define e.g. the factorial function, you
>  would reference a page (typically the 'base' page at logiweb.eu)
> which defines numbers, Booleans, pairs, exceptions, addition,
> multiplication, etc. in lambda calculus, and then you would write
> e.g.
> 
> x ! == if x = 0 then 1 else x * ( x - 1 ) !

> Other programming languages can be supported. In particular, I will 
> support Pascal if the Mizar sources are released. And anyone can add
>  support for any language by publishing a Logiweb page which tells 
> Logiweb how to do.

Fine. But before anyone can add something as complicated as Aldor, it
would be necessary to understand the principles of how a language
specification can be written in LogiWeb.

> But, on Logiweb, anything ultimately compiles to lambda calculus (at
> least in principle).

I probably need more understanding of the internals for that. But it is
not my main concern now. I'd rather like to investigate how LogiWeb
could be good for AXIOM.

>> It sounds a bit scary to me, ...
> 
> It is, for the one who has to implement the low level details. You 
> should not bother.

Maybe not now. But somebody has to bother in 50 years or earlier if we
get new supercomputers on which LogiWeb does not run.

> Could you give a good starting URL to Aldor/SPAD (maybe www.aldor.org
> for Aldor?).

Yes. You find the Aldor User Guide at
http://www.aldor.org/mediawiki/index.php/User_Guides_for_Compiler_and_Libraries
(Note that the HTML and .pdf versions slightly differ.)

Thank you for your mail. I very much hope that this will become a 
fruitful cooperation.

\start
Date: Tue, 3 Jul 2007 03:24:25 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Why did Axiom fail in the 1990s? 


--- William Sit wrote:

> C Y wrote (Re: Paper usage policy (for authors)):
> > 
> > Whether pamphlets qualify is probably a question for a lawyer.
> > 
> > I'm assuming anyone other than the original author has no special
> > rights period.
> 
> Question for a lawyer means question for the courts?

I meant it's a question for someone familiar with the actual laws on
the books which would pertain to this type of agreement.  I am not
personally familiar with them

> If the authors have the "residual" rights as you mentioned,
> wouldn't it be logical that the authors can assign such
> "residual" rights to another entity?

It probably depends on the wording of the actual signed agreement. 
Perhaps the rights retained by the author are non-transferable - it
would most likely depend.

> Writing new material in survey form is certainly alright
> (this already is a huge undertaking and will require
> constant updating), especially if no literate articles are
> available.

I also think it is a good fit to what Axiom actually needs - pamphlets
covering already well established areas should include the best points
from all available research.

> But overviews and surveys, such as at Wikipedia
> or Mathematica sites are, I'm afraid, not what Tim has in
> mind. He wants lock, stock, and barrel (all the shebang) *in
> one pamphlet* so that one need not hunt for obscure outside
> articles or be an expert in the field to follow, maintain
> and improve the code.

The point about hunting for obscure articles, I agree - if there is
knowledge contained in that article relevant to the pamphlet, it should
be in there - many people simply will not be able to locate that
article.  As much as is reasonably possible an introduction should be
provided, but there are limits - the art is finding the correct ones.

> (That's why the COMBINAT code does not
> yet pass muster.) That, I think, is kind of an oxymoron and
> unattainable ideal (try reading any new algorithm in
> symbolic computation and it is an infinite descent if you
> are not already an expert *in the particular problem the
> algorithm solves.* COMBINAT comes to mind.)

The way to handle this, in my estimation, is to have the "basic"
pamphlet in the subject provide the introduction and have subsequent
pamphlets build on it.  I don't think every pamphlet should have all
introductory material, but there should be a "basics" pamphlet that
both lays out the basics of the subject in Axiom and introduces them to
the developer.  Units and Dimensions is intended to (eventually) serve
this purpose for that subfield - new algorithms in dimensional analysis
would reference the basic Units and Dimensions framework and build from
it.

> Every pamphlet
> would eventually be a pretty thick book, even if there are
> plenty of literature covering the topic (nothing
> fundamentally wrong with that except for lack of
> author-power and stretching the 30 year horizon).

Indeed, even 30 years may not be enough to do this as it should be
done.  However, I don't see that as a reason not to try - if the
foundation is strong enough it's worth the time and effort.

> Perhaps
> Gaby's "incremental improvement" idea may work better, but
> that is exactly what we have been debating about. I prefer
> Ralf's pragmatic approach: get the code working and
> stablized, add documentation at places where users or
> developers find it lacking in details (that is, let
> documentation be "demand driven" rather than "supply
> driven"). 

I don't see any reason people can't work from "both ends" and meet "in
the middle", so to speak.

In my particular case, the effort required to go from where I am now to
a position where I would regard myself able to make non-trivial algebra
contributions takes me through a lot of areas that may not have a lot
of immediate user demand but I think are worth paying attention to. 
But that's just me.

> I agree with the goal, just not the means. Moreover, for
> that vision to be realized, the prerequisite is a very large
> user base.

Right.  So we have a bit of a chicken-egg problem, in two ways - to get
a user base we need a working program, but to attract users away from
current systems (already very good) we must offer something compelling
enough to warrant the switch.  So we must be working soon, but we must
also be designing for the long term.  Two goals, with (IMHO) two
different approaches needed.

> Next question: what can we do to increase user base? (Let's
> hear yours.)

My suggestions?  The only thoughts I have on the subject are that we
must offer something compelling enough and unique enough that people
are drawn to Axiom from other, working systems.  The only feature I see
that I would estimate desirable enough to accomplish this is formal
proof logic trust integrated with CAS results.  (I.e. the hard road.)

Obviously, we might implement field specific packages (e.g. Feyncalc)
that would appeal to specific problem domains, but we need to first
convince everyone to trust the results.
  
> > I think the Axiom project might be a bit like the Free Software
> > Foundation in that respect - to me at least it's about more than
> > just a working CAS.  It's about changing the landscape itself.
> > Not replacing the academic institutions and their work as they
> > exist today, but making them more visible and more readily 
> > applicable to the rest of the world.  That's a more ambitious 
> > project than just a working CAS, but
> > the potential rewards are even greater.
> 
> Great vision! Would you outline some plans and actions?

Well, thoughts anyway:

1.  Implement a framework flexible enough and powerful enough to enable
most features expected of a modern CAS and support interaction with
formal proof assistants.

2.  Build (or re-build) Axiom's Algebra based upon modern Category
Theory.  I think we are close, but we should make things feel as
natural as possible to a mathematician (who are the ones we are hoping
will extend the system in the end, after all.)

3.  Reproduce several known results of famous problems inside the CAS
itself, demonstrating its power on known, verifiable problems.

4.  Tackle new problems, looking for solutions to as yet unsolved but
interesting problems.  Use the effort to refine the tools in the CAS
for solving such problems.

5.  Once #4 begins to show results that are significant to the
mathematical community, attention should begin to shift towards Axiom
in a positive way as a tool for new research work.  As that happens,
the Axiom Journal can begin to organize as a serious publication.

Essentially, it's up to us to make our case.  If we can demonstrate
with real results that Axiom is a uniquely effective tool for new work,
that will be the most powerful possible tool to drive its use.

> (I share with you that the journal and publishers in the math
> and cs areas at least are exploiting academics: authors and
> researchers do all the work (writing, reviewing, editing,
> proofreading) and get *nothing* other than a bibliography
> item.)

I hear periodic rumblings about this from the scientific community, but
I'm not sure about mathematics per say.

> Note that the building of superhighways was historically
> demand-driven (national security, commerce, mobility, and
> lots of drivers).

Correct - so if we can demonstrate with some non-trivial examples the
practicality of the superhighway, we may begin to get a lot more people
interested.  (Hence the need for good tools - e.g. a car that performs
better than a horse.)

\start
Date: Tue, 3 Jul 2007 09:19:41 +0200 (CEST)
From: Klaus Grue
To: Ralf Hemmecke
Subject: Re: LogiWeb
Cc: Christian Aistleitner

>>> http://logiweb.eu/
>
>>> That seems to be a very interesting project.
>
>> Yes it does seem both interesting and relevant to Axiom but I hope
>> that the talk was easier to navigate and to understand than the above
>> website! It took me a long time to decide that this was indeed
>> something interesting.
>
> I am sorry that I did not write more.

So am I :-)

The fundamental problem of constructing a web-site for Logiweb is that 
Logiweb can suit more than one need. It is difficult to target a 
web-site since there is more than one possible audience.

But if you explain what you are doing (e.g. giving an URL I should start 
with), then I would be able to say something about whether or not Logiweb 
would be helpful to you and, if it is, how it could be used.

>> When you have a chance, could you try to (briefly) summarize the talk?
>> Or do you have a link to a more readable introduction?
>
> In fact, I was at the talk more by accident than actually planned.
>
> What I got from the talk is that LogiWeb is actually more of an 
> infrastructure than anything else. But it does seem to have some connections 
> to proof systems.

Yes. It is an infrastructure more than anything else. One can publish 
'pages' (or 'papers' or 'pamflets' if you like) on it. Such pages can be 
flat TeX, but they may also contain programs, lemmas, proofs, and similar. 
A page can also define what to do with formal contents (e.g.: compile the 
programs, run programs on specified data, render the output, invoke 
particular proof systems on particular proofs, and much more).

But instead of explaining everything the system can do, it would probably 
be more efficient if I understood your needs first and then targeted the 
explanations to your needs.

> Think of the Axiom Journal idea. From the talk I thought that LogiWeb 
> implements a lot of that idea. It is, in fact, a revision control system (I 
> would say very much like GIT, but maybe Klaus Grue can say more about it).

I would be happy to. Could you give me the optimal URL (http://git.or.cz/ 
?) to start with.

> LogiWeb allows to write and publish papers that contain formal mathematics 
> and a way to specify a proof system that actually checks the correctness of 
> the paper (including the referenced papers). There is no connection to CAS 
> yet, but maybe that can be changed.

Which CAS do you mean? Maybe, again, an URL would be the right thing to 
start with.

> An Axiom Journal for me is like LogiWeb only that the papers are our 
> pamphlets and that we need a compiler that actually compiles the referenced 
> pamphlets into a running Axiom with an appropriate library that is relevant 
> for the paper you are currently interested in.
>
> There are questions like how to make sure that a paper that is runnable 
> today would run also on some computer in 5 years. I still don't know how to 
> achieve this properly, but Klaus Grue seemed to have ideas about it.

There are two ways to do that in Logiweb:

(1) Since Logiweb can publish programs and since proof systems are 
programs, Logiweb can publish proof systems. In that way the proof systems 
get under version control of Logiweb (that is why I bugged Andrzej 
Trybulec to release the Pascal sources of Mizar). Once a proof checker 
gets under version control of Logiweb, each Logiweb 'page' can specify 
which version of which proof checker should check the proofs. When a 
program is published on Logiweb, that program can be run as long as 
Logiweb itself is ported to future systems. But it requires the program 
to be expressed in a way Logiweb can understand.

(2) A poor mans version is to register one version or a small number of 
versions of a proof checker as external programs which can be invoked by 
Logiweb. That is quick to do and a good way to get started, but I am not 
sure it would be a good idea in the long run.

> LogiWeb is GPL. The only drawback I see is that it is basically a 
> one-man-project.

That is a decision I made. I have led several small and big software 
development projects in academia as well as the industry. But Logiweb is 
made the Knuth way: if you cannot program it yourself, it is too 
complicated. There not one character in the source code that I have not 
typed myself. The Knuth approach takes time, but the result tends to be 
small and coherent.

But from now on, anyone can continue the developement of the system 
without touching the source code: Anyone can add facilities to Logiweb by 
publishing Logiweb pages containing the facilities. I intend to continue 
doing bugfixes, minor updates, and porting (and I would not mind getting 
help on that:-)

> And I am still not clear about what it really means to 
> program in pure lambda calculus.

It means that if you want to define e.g. the factorial function, you would 
reference a page (typically the 'base' page at logiweb.eu) which defines 
numbers, Booleans, pairs, exceptions, addition, multiplication, etc. in 
lambda calculus, and then you would write e.g.

   x ! == if x = 0 then 1 else x * ( x - 1 ) !

Other programming languages can be supported. In particular, I will 
support Pascal if the Mizar sources are released. And anyone can add 
support for any language by publishing a Logiweb page which tells Logiweb 
how to do. But, on Logiweb, anything ultimately compiles to lambda 
calculus (at least in principle).

> It sounds a bit scary to me, ...

It is, for the one who has to implement the low level details. You should 
not bother.

> but maybe it's
> a good thing.

The benefit of having everything compile to lambda calculus is 
that then one can, at least in principle, reason about any published 
program just by reasoning about lambda calculus.

> PS For Klaus Grue: A pamphlet is a file that apart from mathematics and 
> design decisions etc. also contains code that can be compiled. I somehow have 
> the suspicion that a pamphlet could be seen as a logiweb paper if our 
> underlying programming language were pure lambda calculus. But we want to use 
> some higher level language like Aldor/SPAD.

It sounds like very much the same. Could you give a good starting URL to 
Aldor/SPAD (maybe www.aldor.org for Aldor?). Then I will take a look at 
it and see if it would be easy to support. Programming languages can 
always be supported the 'poor mans way' of course, having the compiler for 
the language as an external tool.

\start
Date: 03 Jul 2007 15:36:41 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: directory/truename transition

Greetings!

I am prepared to backport the clisp-style directory/truename behavior,
but this breaks current axiom, and I do not want to leave the project
even temporarily without a gcl to build it.  Please advise.  

2.7.0 (with the commits to go in shortly) appears to build wh-sandbox
    save for this issue.

gcl
GCL (GNU Common Lisp)  2.6.7 CLtL1    Oct 29 2006 02:32:45
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

>(truename "AHYP.erlib")

#p"/fix/t1/camm/wh-sandbox/src/algebra/AHYP.erlib"

>
GCL_ANSI=t gclcvs
GCL (GNU Common Lisp)  2.7.0 ANSI    Jul  2 2007 22:02:18
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

Temporary directory for compiler files set to /tmp/

>(truename "AHYP.erlib")

Error: 
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by TRUENAME.
Condition in TRUENAME [or a callee]: INTERNAL-SIMPLE-FILE-ERROR: File error on #P"AHYP.erlib": File does not exist

Broken at TRUENAME.  Type :H for Help.
 1 (Continue) Return to top level.
>>
clisp
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006

[1]> (truename "AHYP.erlib")

*** - TRUENAME: "/fix/t1/camm/wh-sandbox/src/algebra/AHYP.erlib" names a
      directory, not a file
The following restarts are available:
ABORT          :R1      ABORT
Break 1 [2]> 

Take care,


Gabriel Dos Reis writes:

> On Thu, 24 May 2007, Camm Maguire wrote:
> 
> | Greetings!
> | 
> | Gabriel Dos Reis writes:
> | 
> | > Camm --
> | > 
> | >   I believe GCL-2.6.8pre is missing the ANSI Lisp function 
> | > 
> | >       ensure-directories-exist
> | > 
> | 
> | among many others, but is in 2.7.0.  Do you need a backport?  It is
> | simple. 
> 
> Yes, I would need a backport to 2.6.8pre.
> For the moment, Axiom.build-improvements (and the next official release
> of Axiom) is still using that version of GCL.
> 
> Mant thanks!
> 
> | > 
> | > As a subsidiary question, how do you delete a directory in ANSI Lisp?
> | 
> | I see no such function in the standard, but am cc'ing Paul Dietz.
> | 
> | I therefore would suggest (system (format nil "rm -rf ~s" x))
> 
> Thanks!
> 
> | Just to repeat, 2.7.0 is moving to the following usage of 'directory
> | akin to clisp unless someone objects:
> | =============================================================================
> | COMPILER>>(directory "/tmp")
> | 
> | NIL
> | COMPILER>>(directory "/tmp/")
> | 
> | (#P"/tmp/")
> | COMPILER>>(directory "/tmp/*")
> | 
> | (#P"/tmp/#gazonk_27762_21.c#" #P"/tmp/#ii#" #P"/tmp/#q.h#")

\start
Date: Tue, 3 Jul 2007 14:41:38 -0500
From: Tim Daly
To: Camm Maguire
Subject: directory/truename transition

Camm,

All versions of Axiom have a local copy of GCL cached
so it should be fine to do the transition.

\start
Date: Tue, 3 Jul 2007 14:43:49 -0500
From: Tim Daly
To: Camm Maguire
Subject: directory/truename transition

Camm,

Sorry, sent this to enhanced.com, which bounces.

All versions of Axiom have a local copy of GCL cached
so it should be fine to do the transition.

\start
Date: Tue, 3 Jul 2007 14:46:47 -0500
From: Tim Daly
To: Camm Maguire
Subject: directory/truename transition

Camm,

Is therea conditional flag #+(and :GCL :xxx) we can use?

\start
Date: Tue, 03 Jul 2007 15:51:48 -0400
From: Camm Maguire
To: Richard Harke
Subject: Re: Axiom ia64

Greetings!  Just wondering if you've made any headway on native object
relocation for axiom on this platform.

\start
Date: Tue, 03 Jul 2007 21:55:31 +0200
From: Gregory Vanuxem
To: Camm Maguire
Subject: Re: directory/truename transition
Cc: Gabriel Dos Reis

Hello,

Le mardi 03 juillet 2007 =E0 15:36 -0400, Camm Maguire a =E9crit :

[...]

> clisp
>   i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
>   I I I I I I I      8     8   8           8     8     o  8    8
>   I  \ `+' /  I      8         8           8     8        8    8
>    \  `-+-'  /       8         8           8      ooooo   8oooo
>     `-__|__-'        8         8           8           8  8
>         |            8     o   8           8     o     8  8
>   ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8
>
> Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
> Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
> Copyright (c) Bruno Haible, Sam Steingold 1999-2000
> Copyright (c) Sam Steingold, Bruno Haible 2001-2006
>
> [1]> (truename "AHYP.erlib")
>
> *** - TRUENAME: "/fix/t1/camm/wh-sandbox/src/algebra/AHYP.erlib" names =
a
>       directory, not a file
> The following restarts are available:
> ABORT          :R1      ABORT
> Break 1 [2]>
>
> Take care,

Yes, but


clisp
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006

[1]> (truename "Axiom")

*** - TRUENAME: "/home/greg/Axiom" names a directory, not a file
The following restarts are available:
ABORT          :R1      ABORT
Break 1 [2]>
[3]> (truename "Axiom/")
#P"/home/greg/Axiom/"

(just in case)

\start
Date: 03 Jul 2007 16:01:27 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: A modest proposal

Greetings!

Yes, I would be happy to upload a new version.  But please be advised
that it is not a light task.  We managed to get axiom working on all
12 Debian platforms, a feat which easily could take several months.
So it would be great if there was a clear slow-moving official release
target somewhere.

Of course, it could be argued that portability to all these machines
is not all that important, in which case we can configure the package
accordingly.

Take care,

Tim Daly writes:

> Ondrej,
> 
> As noted, Camm both did the prior port and sponsored Axiom.
> If we can do the port I believe he can be asked to sponsor it.

\start
Date: 03 Jul 2007 16:04:23 -0400
From: Camm Maguire
To: Gregory Vanuxem
Subject: Re: directory/truename transition
Cc: Gabriel Dos Reis

Greetings!

Yes, and thanks!

(hopefully this is just a one line patch to the axiom sources
somewhere.  Would be great to finish the test build with 2.7.0 ...)


GCL_ANSI=t gclcvs
GCL (GNU Common Lisp)  2.7.0 ANSI    Jul  2 2007 22:02:18
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

Temporary directory for compiler files set to /tmp/

>(truename "AHYP.erlib/")

#P"/fix/t1/camm/wh-sandbox/src/algebra/AHYP.erlib/"

>

Gregory Vanuxem writes:

> Hello,
>
> Le mardi 03 juillet 2007 =E0 15:36 -0400, Camm Maguire a =E9crit :
>
> [...]
>
> > clisp
> >   i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
> >   I I I I I I I      8     8   8           8     8     o  8    8
> >   I  \ `+' /  I      8         8           8     8        8    8
> >    \  `-+-'  /       8         8           8      ooooo   8oooo
> >     `-__|__-'        8         8           8           8  8
> >         |            8     o   8           8     o     8  8
> >   ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8
> >
> > Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
> > Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> > Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
> > Copyright (c) Bruno Haible, Sam Steingold 1999-2000
> > Copyright (c) Sam Steingold, Bruno Haible 2001-2006
> >
> > [1]> (truename "AHYP.erlib")
> >
> > *** - TRUENAME: "/fix/t1/camm/wh-sandbox/src/algebra/AHYP.erlib" names a
> >       directory, not a file
> > The following restarts are available:
> > ABORT          :R1      ABORT
> > Break 1 [2]>
> >
> > Take care,
>
> Yes, but
>
>
> clisp
>   i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
>   I I I I I I I      8     8   8           8     8     o  8    8
>   I  \ `+' /  I      8         8           8     8        8    8
>    \  `-+-'  /       8         8           8      ooooo   8oooo
>     `-__|__-'        8         8           8           8  8
>         |            8     o   8           8     o     8  8
>   ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8
>
> Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
> Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
> Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
> Copyright (c) Bruno Haible, Sam Steingold 1999-2000
> Copyright (c) Sam Steingold, Bruno Haible 2001-2006
>
> [1]> (truename "Axiom")
>
> *** - TRUENAME: "/home/greg/Axiom" names a directory, not a file
> The following restarts are available:
> ABORT          :R1      ABORT
> Break 1 [2]>
> [3]> (truename "Axiom/")
> #P"/home/greg/Axiom/"
>
> (just in case)

\start
Date: Tue, 3 Jul 2007 16:27:40 -0400
From: Bill Page
To: Camm Maguire
Subject: Re: A modest proposal

On 03 Jul 2007 16:01:27 -0400, Camm Maguire wrote:
>
> Yes, I would be happy to upload a new version.  But please be advised
> that it is not a light task.  We managed to get axiom working on all
> 12 Debian platforms, a feat which easily could take several months.
> So it would be great if there was a clear slow-moving official release
> target somewhere.
>

I am confident that it will be *much* easier to get working versions
Axiom based on the new build system in the build-improvements and
wh-sandbox branches. Both of these versions use an approach very
similar to the one that you used for Debian.

> Of course, it could be argued that portability to all these machines
> is not all that important, in which case we can configure the package
> accordingly.
>

I think the presence of an up to date version of Axiom on the Debian
platforms would be a very good thing. The wh-sandbox branch has many
critical fixes to both the algebra and to hyperdoc.

\start
Date: Tue, 3 Jul 2007 23:15:52 +0200
From: Ondrej Certik
To: Camm Maguire
Subject: Re: A modest proposal

> Of course, it could be argued that portability to all these machines
> is not all that important, in which case we can configure the package
> accordingly.

I am just curious - isn't it a problem for Debian build servers, that
the package builts for 12 hours or even more?

\start
Date: 03 Jul 2007 17:41:28 -0400
From: Camm Maguire
To: Ondrej Certik
Subject: Re: A modest proposal

Greetings!

Ondrej Certik writes:

> > Of course, it could be argued that portability to all these machines
> > is not all that important, in which case we can configure the package
> > accordingly.
> 
> I am just curious - isn't it a problem for Debian build servers, that
> the package builts for 12 hours or even more?
> 

Were it only that simple.  Typically, many, many failures are required
to get a working build on a lesser known machine.  gcl/axiom flushes
out instabilities in gcc, binutils, and several other very low-level
parts of the toolchain.  That said, getting all the builds working
flushes out bugs in gcl too.

Witness the issues at present: gcl switch statements apparently
generate bogus jump table assembler on mips, gcc-object-inserted
symbols __divq/__remq on alpha are apparently uwrappable (*), new
GPREL_32 relocs in the new .rodata section needed support on alpha,
new GNU_HASH section types required binutils patches, etc.

(*) As you know, GCL loads object (.o) files into a running image,
which can then be dumped and executed later.  It therefore needs the
ability to relocate all symbols in the .o file.  Relocating to
addresses in external shared libraries is dangerous, as the lib may
not be in the same place on image restart.  2.6.x had a plt mechanism,
which attempted to force gcc to provide local addresses by compiling
in functions using the addresses of the external functions.  This
broke with subsequenct gcc developements, so even with the plt,
relocations were being set to shared library addresses on some
machines.  Now, 2.7.0 redirects all such calls through a pointer in
the C source which is reset on image startup.  __divq and the like,
alas, have no representative in the C source, and cannot be handled
thus.  Ideally, we can define a wrapper function and relocate to that,
but this procedure has been problematic with mcount (for example) on
s390 and ppc.  (just a taste ... :-)

\start
Date: Wed, 4 Jul 2007 04:12:03 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: Re: directory/truename transition
Cc: Gabriel Dos Reis

> Greetings!
> 
> I am prepared to backport the clisp-style directory/truename behavior,
> but this breaks current axiom, and I do not want to leave the project
> even temporarily without a gcl to build it.  Please advise.  
> 
> 2.7.0 (with the commits to go in shortly) appears to build wh-sandbox
>     save for this issue.
> 

wh-sandbox builds using clisp.  We need 21 clisp specific conditionals.
9 of those conditionals is due to file and directory handling.  In some
cases current code uses gcl specific method that will work regardless of
the change, but in some cases gcl specific section will need update. So
one can estimate that change in gcl will require about between 10 to 60
lines of extra code (extra conditionals + code to handle extra case).

I belive that truename change affects only one place in wh-sandbox,
namely the 'axiom-probe-file' function in 'src/lisp/axiom-lisp.lisp.pamphlet'.
clisp variant needs 4 lines of code + 1 line for conditional, but
since different gcl versions work differently, gcl will probably
need 6-8 lines of extra code here.

Directory change also is problematic: in 'src/interp/daase.lisp.pamphlet'
in the function 'localdatabase' we need list of files matching
'*.NRLIB/index.KAF'.  With all other Lisps we just use this pattern.
But gcl on Windows cannot handle it.  So we use '*.NRLIB' and
append '/index.KAF' using string concatenation.  We will have to
change this to '*.NRLIB/' for the new version (which is trivial)
and add proper conditional.  How complex test is need will depend
on gcl -- in the worst case we will have to run a test program
from configure and propagate results to the Lisp, which will
take probably about 20 lines of code. 

Important thing is that clisp file handling can loose some functionality
-- currently I do not know how to rename directory using clisp
(apparently clisp 'rename-file' does not work on directories).
Similarly, I do not not how to delete empty directory using clisp.

Another question is how to detect which version of functions is
present -- the old one or the new one.  Note that for testing we
want Axiom sources to work with different gcl versions, so we
need automatic way to choose correct variant.

I would suggest that gcl _first_ adds nonstandard functions that
implement Posix style file handling and only later changes Ansi Lisp
functions to clisp semantic.  That way users that want Posix
semantics can use Posix functions if presesnt and otherwise be assured
that they get old gcl semantics (which is closer to Posix than the
clisp way) from standard Lisp functions.

Some functions were added to gcl, but I am affraid that some
functions that Axiom needs are still missing.  Let me try to
enumerate functions that Axiom uses:

change directory
make directory (done via C)
get current directory name
get absolute name of a directory
delete file or directory
rename file or directory
find all files matching pattern "*.NRLIB/index.KAF"
recursively copy directory with content (currently invokes the 'cp' program)
copy file (likewise)

\start
Date: 03 Jul 2007 23:25:17 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: Re: directory/truename transition
Cc: Gabriel Dos Reis

Greetings!

Waldek Hebisch writes:

> > Greetings!
> > 
> > I am prepared to backport the clisp-style directory/truename behavior,
> > but this breaks current axiom, and I do not want to leave the project
> > even temporarily without a gcl to build it.  Please advise.  
> > 
> > 2.7.0 (with the commits to go in shortly) appears to build wh-sandbox
> >     save for this issue.
> > 
> 
> wh-sandbox builds using clisp.  We need 21 clisp specific conditionals.
> 9 of those conditionals is due to file and directory handling.  In some
> cases current code uses gcl specific method that will work regardless of
> the change, but in some cases gcl specific section will need update. So
> one can estimate that change in gcl will require about between 10 to 60
> lines of extra code (extra conditionals + code to handle extra case).
> 
> I belive that truename change affects only one place in wh-sandbox,
> namely the 'axiom-probe-file' function in 'src/lisp/axiom-lisp.lisp.pamphlet'.
> clisp variant needs 4 lines of code + 1 line for conditional, but
> since different gcl versions work differently, gcl will probably
> need 6-8 lines of extra code here.
> 
> Directory change also is problematic: in 'src/interp/daase.lisp.pamphlet'
> in the function 'localdatabase' we need list of files matching
> '*.NRLIB/index.KAF'.  With all other Lisps we just use this pattern.
> But gcl on Windows cannot handle it.  So we use '*.NRLIB' and
> append '/index.KAF' using string concatenation.  We will have to
> change this to '*.NRLIB/' for the new version (which is trivial)
> and add proper conditional.  How complex test is need will depend
> on gcl -- in the worst case we will have to run a test program
> from configure and propagate results to the Lisp, which will
> take probably about 20 lines of code. 
> 
> Important thing is that clisp file handling can loose some functionality
> -- currently I do not know how to rename directory using clisp
> (apparently clisp 'rename-file' does not work on directories).
> Similarly, I do not not how to delete empty directory using clisp.
> 

This is all quite depressing.  It appears the clspec is quite
deficient in this regard.  Hence, I think the proper goal for GCL is
to be as close to posix and "intuition" in this regard while still
passing the spec.  

The whole goal was 1) to support pathnames with spaces, ala mingw, and
2) to provide some natural means within the spec for distinguishing a
directory from a file.  clisp seems appropriate for this, but does not
allow one to overlay delete-file et. al. for directories.  This does
seem a good tradeoff on reflection, as any general overlay is going to
run afoul of all sorts of problems trying to #'open a directory and
#'read therefrom.  If this perspective is the right one, all the spec
functions but #'directory should work only on files, and GCL should
provide functions in 'si to do the directory manipulations outside the
spec.

As they are outside the spec, is there any reason not to implement
these where possible with #'system?  The bourne shell is likely at
least as portable as GCL is.  I was worried about the following
directory implementation:

	sprintf(command, "shopt -s dotglob; "
		         "IFS='' j=\"%s\"; for i in $j ; do ! [ -e \"$i\" ] || %c [ -d \"$i\" ] || echo \"$i\" ; done", filename, ch);

but I think it likely that this will even work on mingw.

> Another question is how to detect which version of functions is
> present -- the old one or the new one.  Note that for testing we
> want Axiom sources to work with different gcl versions, so we
> need automatic way to choose correct variant.
> 
> I would suggest that gcl _first_ adds nonstandard functions that
> implement Posix style file handling and only later changes Ansi Lisp
> functions to clisp semantic.  That way users that want Posix
> semantics can use Posix functions if presesnt and otherwise be assured
> that they get old gcl semantics (which is closer to Posix than the
> clisp way) from standard Lisp functions.
> 
> Some functions were added to gcl, but I am affraid that some
> functions that Axiom needs are still missing.  Let me try to
> enumerate functions that Axiom uses:
> 
> change directory
> make directory (done via C)
> get current directory name
> get absolute name of a directory
> delete file or directory
> rename file or directory
> find all files matching pattern "*.NRLIB/index.KAF"
> recursively copy directory with content (currently invokes the 'cp' program)
> copy file (likewise)
> 

Thanks for this list.  Will get these in.

\start
Date: Tue, 3 Jul 2007 23:44:07 -0400
From: Bill Page
To: Camm Maguire
Subject: re: directory/truename transition
Cc: Gabriel Dos Reis

On 03 Jul 2007 23:25:17 -0400, Camm Maguire wrote:
> ...
> This is all quite depressing.  It appears the clspec is quite
> deficient in this regard.  Hence, I think the proper goal for GCL is
> to be as close to posix and "intuition" in this regard while still
> passing the spec.
>

+1 for supporting posix.

> The whole goal was 1) to support pathnames with spaces, ala mingw, and
> 2) to provide some natural means within the spec for distinguishing a
> directory from a file.  clisp seems appropriate for this, but does not
> allow one to overlay delete-file et. al. for directories.  This does
> seem a good tradeoff on reflection, as any general overlay is going to
> run afoul of all sorts of problems trying to #'open a directory and
> #'read therefrom.  If this perspective is the right one, all the spec
> functions but #'directory should work only on files, and GCL should
> provide functions in 'si to do the directory manipulations outside the
> spec.
>

Yes.

> As they are outside the spec, is there any reason not to implement
> these where possible with #'system?  The bourne shell is likely at
> least as portable as GCL is.  I was worried about the following
> directory implementation:
>
>         sprintf(command, "shopt -s dotglob; "
>                          "IFS='' j=\"%s\"; for i in $j ; do ! [ -e \"$i\" ] || %c [ -d \"$i\" ] || echo \"$i\" ; done", filename, ch);
>
> but I think it likely that this will even work on mingw.
>

Well, that depends on what you mean by "work". At the present time gcl
builds on MSYS/mingw as a *native* Windows application. MSYS/mingw is
only required to build gcl from source. Standard native windows does
not have any of these unix-oriented #system tools. Doing what you
suggest would result in gcl only working from within the MSYS/mingw
shell.

Of course there is also the issue of gcc on Windows which is needed
when compiling. In the case of installing a native Windows Axiom, the
install program includes the bare minimum mingw gcc components in a
separate directory along with Axiom. Installation of mingw is not a
prerequisite.

Although it requires a little more knowledge of Windows internals, I
strongly recommend that gcl on windows continue to call the windows
API instead of relying on external support for posix/unix commands in
a particular shell that is not native to Windows. For similar reasons
I also would not recommend trying to utilize the Windows non-posix
command interpreter for this purpose.

\start
Date: Tue, 3 Jul 2007 23:59:37 -0500
From: Tim Daly
To: Camm Maguire
Subject: GCL/Windows

Camm,

Do you know if GCL compile under tcc? 

\start
Date: Wed, 4 Jul 2007 09:49:44 +0200 (CEST)
From: Klaus Grue
To: Ralf Hemmecke
Subject: Re: LogiWeb

Hi Ralf,

> http://axiom-developer.org/
>
> But I guess, the information there is not organized enough for everyones
> taste. So if you don't understand something, it's probably better to ask
> on the axiom-dev list.
>
> Maybe a good start would be to download the Axiom book (it's free) or try out 
> AXIOM online inside the WIKI.

Thanks. I printed out (part of) the Axiom book and will take a look at it.

> Oh, that sounds even more interesting that you can already compile
> programs that are hidden in papers. In fact, currently a pamphlet file
> is nothing else than an ordinary input file for noweb
> (http://www.eecs.harvard.edu/~nr/noweb/). They contain the programs and
> Makefiles are used to extract and build the program. In fact, one
> pamphlet contains only a part of the whole AXIOM CAS.

I just took a quick look at noweb. Maybe if you have an example of a 
pamphlet file, then I could run acrosss that also.

> BTW, what tool to you use to translate TeX into HTML?

I don't. After considering lots of alternatives, including MathML, I ended 
up translating TeX to PDF. At the time I investigated the alternatives, a 
latex|dvipdfm pipeline was the only combination of programs which (1) 
could reliably mix TeX and http-references and (2) gave rise to acceptable 
response times. There is a bug in dvipdfm which has the effect that some 
pages get magnified so that one has to click fit-to-width to get them back 
in reasonable size. I have complained to the dvipdfm maintainers about 
this, but I don't think anything will happen. I suppose there are many 
more options than latex|dvipdfm today, but until further I stick to that 
solution.

> I completely understand your decision, but now it might be time to open
> it up. Which means more people than just you need to understand the
> scary details. LogiWeb would be dead immediately if there happens
> something dragically to you. How much is LogiWeb already in use
> somewhere? What would be a good start to read about the overall
> infrastructure and the internals? Any linearly readable text available?

The decision on making Logiweb a one-man project has fulfilled its 
purpose (to make Logiweb small and coherent), so I have no problems 
opening the sources. Actually, I am in the process of documenting the 
system to a degree where others could implement it from scratch. As a 
first step, the internal protocol is documented in

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/
draft-grue-logiweb-protocol-1-00.txt

But that is not a good place for starting to learn about Logiweb.

> How much is LogiWeb already in use
> somewhere?

The release of Logiweb is rather new. Right now it is only installed three 
places. I hope to add Bialystok soon.

> What would be a good start to read about the overall
> infrastructure and the internals? Any linearly readable text available?

A good start is the 'Logiweb base page' which is the page which 
'bootstraps' Logiweb. It is at
http://logiweb.eu/logiweb/page/base/fixed/body/tex/page.pdf

Section 2 in principle tells all there is to tell about programming in 
lambda calculus. Section 3 defines addition, exceptions, and so on. 
Section 4 defines a self-evaluator and, as a side effect, explains some of 
the central data structures. Section 5 defines macro expansion. Without
macros, Logiweb is difficult to live with. Macros are not used much on the 
base page itself, but if you replace 'base' by 'check' in the URL above, 
you get to the page which defines Logiwebs 'own' proof checker. Section 6 
explains how to compile Logiweb programs into stand-alone programs.

Another linear source could be 
http://logiweb.eu/logiweb/doc/browser/loading.html

That reference is *much* shorter than the base page, and more technical 
in nature. I think it is a good place to get information for anyone who 
already has a picture of what Logiweb looks like.

>> But from now on, anyone can continue the developement of the system 
>> without touching the source code: Anyone can add facilities to
>> Logiweb by publishing Logiweb pages containing the facilities. I
>> intend to continue doing bugfixes, minor updates, and porting (and I
>> would not mind getting help on that:-)
>
> Does LogiWeb have some features like WEB, i.e. change files by which one
> can modify the originally published program? (Honestly, I don't really
> understand the details of Knuth's .ch files, but it sounds to me like a
> necessary feature to remove bugs without touching the original sources.

No. The sources of Logiweb are never touched when changing Logiweb. 
New features are published on Logiweb pages and are available to anyone 
who reference them. That should work since Logiweb itself is rather 
neutral and just allows people to publish features. Logiwebs 'own' proof 
checker is an example: it is just a feature published on a Logiweb page, 
and those who want to use it, reference it, and those who don't, don't. In 
that way I avoid forcing my own proof checker upon other people.

> I very much hope that this will become a fruitful 
> cooperation.

The same to you. I have taken the liberty to sign up to the 
axiom-developer mailing list. I hope that is ok.

\start
Date: Wed, 4 Jul 2007 09:57:36 +0200 (CEST)
From: Klaus Grue
To: Ralf Hemmecke
Subject: PS. Re: LogiWeb

>> Does LogiWeb have some features like WEB, i.e. change files by which one
>> can modify the originally published program? (Honestly, I don't really
>> understand the details of Knuth's .ch files, but it sounds to me like a
>> necessary feature to remove bugs without touching the original sources.
>
> No. The sources of Logiweb are never touched ...

Sorry, I didn't see you were talking about bugs. Bugs are corrected in the 
sources. So the sources *are* touched (hopefully not too often:-)

\start
Date: Wed, 04 Jul 2007 11:10:16 +0200
From: Ralf Hemmecke
To: list
Subject: trunk/axiom/src/share/algebra/libaxiom.al

Can somebody explain why libaxiom.al is currently in the archive?
Yes, I have seen it before, but thinking a bit, then I would say it is 
not at all used in Axiom (without Aldor). Am I wrong?

Doesn't the Broadbery's Java-Script as described on 
http://wiki.axiom-developer.org/AldorForAxiom (re-)generate libaxiom.al 
from (whatever?)?

Ralf

On 07/04/2007 07:37 AM, daly@users.sourceforge.net wrote:
> Revision: 655
>           http://svn.sourceforge.net/axiom/?rev=655&view=rev
> Author:   daly
> Date:     2007-07-03 22:37:32 -0700 (Tue, 03 Jul 2007)
> 
> Log Message:
> -----------
> propdel svn:eol-style src/share/algebralibaxiom.al
> 
> Modified Paths:
> --------------
>     trunk/axiom/src/share/algebra/libaxiom.al
> 
> Property Changed:
> ----------------
>     trunk/axiom/src/share/algebra/libaxiom.al
> 
> Modified: trunk/axiom/src/share/algebra/libaxiom.al
> ===================================================================
> (Binary files differ)
> 
> 
> Property changes on: trunk/axiom/src/share/algebra/libaxiom.al
> ___________________________________________________________________
> Name: svn:eol-style
>    - native

\start
Date: Wed, 04 Jul 2007 11:33:09 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: backslash missing in configure.ac.pamphlet

Hi Gaby,

there is a small latex bug.

Ralf

woodpecker:~/SVK/axiom/branches/build-improvements>svk diff 
configure.ac.pamphlet
=== configure.ac.pamphlet
==================================================================
--- configure.ac.pamphlet       (revision 739)
+++ configure.ac.pamphlet       (local)
@@ -758,7 +758,7 @@
  @

  We may be presented with incoherent options if
-begin{itemize}
+\begin{itemize}
  \item \verb!--disable-gcl! is used without specifying a Lisp image, or
  \item \verb!--with-lisp! is used but we are also told to build \Tool{GCL}.
  \end{itemize}

\start
Date: Wed, 04 Jul 2007 13:39:27 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: configure.ac.pamphlet

Dear Gaby,

I'm just trying to learn a bit of autoconf by going through your 
BI/configure.ac.pamphlet. I haven't used autoconf before and have not 
yet read its documentation, but your doumentation in the configure file 
helped me quite a lot to get a first impression what autoconf can do for 
Axiom and how it is done in BI. Thank your for all this explanations.

In section "Doc util" you test for latex and makeindex. Probably all 
latex distributions contain latex/pdflatex, bibtex, makeindex, but is 
there a reason that you include makeindex and don't test for bibtex? 
pdflatex might not yet be used by Axiom, I don't know.

\start
Date: Wed, 04 Jul 2007 13:46:27 +0200
From: Ralf Hemmecke
To: Norman Ramsey, Gabriel Dos Reis
Subject: Noweb and \usepackage[T1]{fontenc}

Dear Norman,

The output of << and >> inside code chunks is not typewriter font.

noweave -n -delay aaa.nw > aaa.tex
latex aaa

Gaby, you use \usepackage[T1]{fontenc} in configure.ac.pamphlet. Is 
there any reason why you need it? That file compiles perfectly without 
the fontenc package.

---BEGIN aaa.nw
\documentclass[12pt]{article}
\usepackage[T1]{fontenc}
\usepackage{noweb}

\begin{document}
Blah blah
<<*>>=
   Ooops that does not look like typewriter text @<< here.
   echo "abc" >> blah
@
More blah blah.
\end{document}
---END aaa.nw

\start
Date: 04 Jul 2007 10:27:02 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: GCL/Windows

Greetings!

Tim Daly writes:

> Camm,
> 
> Do you know if GCL compile under tcc? 
> 

Don't know, though Boyer and others got a build atop icc with a 20%
improvement.  I suspect the sse instructions in the gc, which gcc
should now also emit with the appropriate switches.

In any case, I can only justify my time spent on truly open systems.
Should others want to commit changes to support other systems, I can
arrange cvs access.

\start
Date: Wed, 4 Jul 2007 10:15:31 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: directory/truename transition
Cc: Camm Maguire

On Wed, 4 Jul 2007, Waldek Hebisch wrote:

| Important thing is that clisp file handling can loose some functionality
| -- currently I do not know how to rename directory using clisp
| (apparently clisp 'rename-file' does not work on directories).

I believe that is OK by ANSI spec.

| Similarly, I do not not how to delete empty directory using clisp.

There is nothing in ANSI spec for deleting directories -- you
can create them, but you can't remove them using only ANSI spec.

I believe Camm recently offered to provide an extension if sufficient
interest is expressed.

[...]

| change directory
| make directory (done via C)
| get current directory name
| get absolute name of a directory
| delete file or directory
| rename file or directory
| find all files matching pattern "*.NRLIB/index.KAF"
| recursively copy directory with content (currently invokes the 'cp' program)
| copy file (likewise)

\start
Date: Wed, 4 Jul 2007 10:22:39 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: re: directory/truename transition
Cc: Camm Maguire

On Tue, 3 Jul 2007, Bill Page wrote:

| > As they are outside the spec, is there any reason not to implement
| > these where possible with #'system?  The bourne shell is likely at
| > least as portable as GCL is.  I was worried about the following
| > directory implementation:
| >
| >         sprintf(command, "shopt -s dotglob; "
| >                          "IFS='' j=\"%s\"; for i in $j ; do ! [ -e \"$i\" ]
| >                          || %c [ -d \"$i\" ] || echo \"$i\" ; done",
| >                          filename, ch);
| >
| > but I think it likely that this will even work on mingw.
| >
| 
| Well, that depends on what you mean by "work". At the present time gcl
| builds on MSYS/mingw as a *native* Windows application. MSYS/mingw is
| only required to build gcl from source. Standard native windows does
| not have any of these unix-oriented #system tools. Doing what you
| suggest would result in gcl only working from within the MSYS/mingw
| shell.

Note however that mingw/msys support for paths with embeeded space
is very limited -- this is not a suggestion that it should not be done 
in GCL; rather it is a warning about what is be assumed.

| Of course there is also the issue of gcc on Windows which is needed
| when compiling. In the case of installing a native Windows Axiom, the
| install program includes the bare minimum mingw gcc components in a
| separate directory along with Axiom. Installation of mingw is not a
| prerequisite.

The Haskell distribution for windows ships with a build of gcc.  
This is a general problem/nuisance on windows platforms for programs 
that generate C codes and assumes availability of a C compiler.

\start
Date: Wed, 4 Jul 2007 11:56:48 -0500 (CDT)
From: Gabriel Dos Reis
To: list
Subject: Fix to configure.ac.pamphlet

Ralf --

  Your fix to configure.ac.pamphlet is OK.

Please CC: me at my address at TAMU.

\start
Date: Wed, 4 Jul 2007 12:00:37 -0500 (CDT)
From: Gabriel Dos Reis
To: list
Subject: configure test for bibtext

Ralf --

  There is no intrinsic logical reasons why I did not check for all
other tools that may be bundled with a LaTeX distribution.  
The only reason why I tested only for latex and makeindex is because
those seemed to be the only LaTeX-releated tools used by the current
build system.  Patches that extend the tests to pdflatex, bibtex and friends
are welcome.

\start
Date: 04 Jul 2007 13:24:32 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: directory/truename transition

Greetings!

Gabriel Dos Reis writes:

> On Wed, 4 Jul 2007, Waldek Hebisch wrote:
> 
> | Important thing is that clisp file handling can loose some functionality
> | -- currently I do not know how to rename directory using clisp
> | (apparently clisp 'rename-file' does not work on directories).
> 
> I believe that is OK by ANSI spec.
> 
> | Similarly, I do not not how to delete empty directory using clisp.
> 
> There is nothing in ANSI spec for deleting directories -- you
> can create them, but you can't remove them using only ANSI spec.
> 
> I believe Camm recently offered to provide an extension if sufficient
> interest is expressed.
> 
> [...]
> 
> | change directory
> | make directory (done via C)
> | get current directory name
> | get absolute name of a directory
> | delete file or directory
> | rename file or directory
> | find all files matching pattern "*.NRLIB/index.KAF"
> | recursively copy directory with content (currently invokes the 'cp' program)
> | copy file (likewise)
> 

Question 1) -- as there are workarounds for mingw now with 2.6.x, does
it make sense to implement this transition only in 2.7.x and above?
No need for conditionals, etc.  I only went down this road re: 2.6.x
as Gaby said he needed a backport of ensure-directories-exist.

Proposal:

Functionality                      Function     Origin Portable  Implemented

change directory                   si::chdir    libc   Yes?      Yes

make directory (done via C)        si::mkdir    libc   Yes?      >=2.7

get current directory name         si::getcwd   libc   Yes?      Not yet

get absolute name of a directory   truename     GCL    Hopefully Yes,
                                                                   different
                                                                   semantic
                                                                   in
                                                                   >=2.7
                                                                   (trailing
                                                                   slash required)

delete file or directory           delete-file  GCL    Hopefully Yes
                                   si::rmdir    libc   Yes?      Not yet 

rename file or directory           rename-file  GCL    Hopefully Yes
                                   si::rename   libc   Yes?      Not yet 

find all files matching pattern    directory    GCL    Not yet   Partial(1)
  "*.NRLIB/index.KAF"

recursively copy directory with    si::cp-a     GCL    Should be Not yet
  content (currently invokes the                                   to be 
           'cp' program                                            built on 
                                                                   directory and si::cp. 
copy file (likewise)               si::cp       GCL    Should be Not yet
                                                                   to be 
                                                                   built on 
                                                                   si::copy-stream and open.

(1) To be decided -- reimplement shell globbing in C ontop of openddir
    and readdir, or ship mingw shell along with gcc in Windows
    installer (verifying that the "limited" space support is adequate.)
(2) perhaps put new functions in a posix:: package, though that name
    would be quite misleading given the contents.


Once this is nailed down, the rest should not be too hard.

\start
Date: 04 Jul 2007 13:28:04 -0400
From: Camm Maguire
To: Bill Page
Subject: re: directory/truename transition
Cc: Gabriel Dos Reis

Greetings!

Bill Page writes:

> On 03 Jul 2007 23:25:17 -0400, Camm Maguire wrote:
> > ...
> > This is all quite depressing.  It appears the clspec is quite
> > deficient in this regard.  Hence, I think the proper goal for GCL is
> > to be as close to posix and "intuition" in this regard while still
> > passing the spec.
> >
> 
> +1 for supporting posix.
> 
> > The whole goal was 1) to support pathnames with spaces, ala mingw, and
> > 2) to provide some natural means within the spec for distinguishing a
> > directory from a file.  clisp seems appropriate for this, but does not
> > allow one to overlay delete-file et. al. for directories.  This does
> > seem a good tradeoff on reflection, as any general overlay is going to
> > run afoul of all sorts of problems trying to #'open a directory and
> > #'read therefrom.  If this perspective is the right one, all the spec
> > functions but #'directory should work only on files, and GCL should
> > provide functions in 'si to do the directory manipulations outside the
> > spec.
> >
> 
> Yes.
> 
> > As they are outside the spec, is there any reason not to implement
> > these where possible with #'system?  The bourne shell is likely at
> > least as portable as GCL is.  I was worried about the following
> > directory implementation:
> >
> >         sprintf(command, "shopt -s dotglob; "
> >                          "IFS='' j=\"%s\"; for i in $j ; do ! [ -e \"$i\" ] || %c [ -d \"$i\" ] || echo \"$i\" ; done", filename, ch);
> >
> > but I think it likely that this will even work on mingw.
> >
> 
> Well, that depends on what you mean by "work". At the present time gcl
> builds on MSYS/mingw as a *native* Windows application. MSYS/mingw is
> only required to build gcl from source. Standard native windows does
> not have any of these unix-oriented #system tools. Doing what you
> suggest would result in gcl only working from within the MSYS/mingw
> shell.
> 
> Of course there is also the issue of gcc on Windows which is needed
> when compiling. In the case of installing a native Windows Axiom, the
> install program includes the bare minimum mingw gcc components in a
> separate directory along with Axiom. Installation of mingw is not a
> prerequisite.
> 

How big is the mingw-ex-gcc?  Is it unreasonable to include the full
environment in the installer?  Even macosx has bash.

Speaking of which, does anyone know how to make the mingw installer
for the next GCL release?

> Although it requires a little more knowledge of Windows internals, I
> strongly recommend that gcl on windows continue to call the windows
> API instead of relying on external support for posix/unix commands in
> a particular shell that is not native to Windows. For similar reasons
> I also would not recommend trying to utilize the Windows non-posix
> command interpreter for this purpose.
> 

I'm happy to go along with this, though I'm not sure what benefit the
user would see other than a little less disk space usage.  I can only
justify minimal time learning anything windows specific for this
purpose, but of course will eagerly accept all offers of assistance in
this regard. 

Now perhaps there is just a lower level api to which I could write
that would transparently be portable.  E.g. implementing directory via
readdir and opendir.  Re-implementing all the shell pattern matching
from scratch is certainly doable, but there should be some clear
benefit visible that would justify the work.  Its hard for me to see
at the moment.

Please see related post regarding an extra-spec posix support function
proposal. 

\start
Date: 04 Jul 2007 13:34:40 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: directory/truename transition

Greetings!

Tim Daly writes:

> Camm,
> 
> Is therea conditional flag #+(and :GCL :xxx) we can use?
> 
> Tim
> 

Given the discussion, it appears best to limit the transition to 2.7.x
-- no need for conditionals.  If axiom needs
ensure-directories-exist/mkdir in 2.6.x, then perhaps 2.6.9 is
warranted.  This appears likely to break more than I had thought.

\start
Date: 04 Jul 2007 13:36:18 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: directory/truename transition

Greetings!

Tim Daly writes:

> Camm,
> 
> All versions of Axiom have a local copy of GCL cached
> so it should be fine to do the transition.
> 

So if an external GCL with the new semantics is present, will this
break any of the axiom branches?

\start
Date: 04 Jul 2007 13:38:16 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: A modest proposal

Greetings!

Bill Page writes:

> On 03 Jul 2007 16:01:27 -0400, Camm Maguire wrote:
> >
> > Yes, I would be happy to upload a new version.  But please be advised
> > that it is not a light task.  We managed to get axiom working on all
> > 12 Debian platforms, a feat which easily could take several months.
> > So it would be great if there was a clear slow-moving official release
> > target somewhere.
> >
> 
> I am confident that it will be *much* easier to get working versions
> Axiom based on the new build system in the build-improvements and
> wh-sandbox branches. Both of these versions use an approach very
> similar to the one that you used for Debian.
> 
> > Of course, it could be argued that portability to all these machines
> > is not all that important, in which case we can configure the package
> > accordingly.
> >
> 
> I think the presence of an up to date version of Axiom on the Debian
> platforms would be a very good thing. The wh-sandbox branch has many
> critical fixes to both the algebra and to hyperdoc.
> 

I would love Tim's and all the other developers' blessing as to which
snapshot of which branch is worthy to represent axiom in Debian.  Do
we have consensus yet?  I can work with either, new or old.

\start
Date: Wed, 04 Jul 2007 14:15:14 -0400
From: Norman Ramsey
To: Ralf Hemmecke
Subject: Re: Noweb and \usepackage[T1]{fontenc} 

 > Dear Norman,
 > 
 > The output of << and >> inside code chunks is not typewriter font.

Only in the presence of \usepackage[T1]{fontenc}.
I'm completely ignorant of this package and so don't even know whether
the behavior should be considered a bug.  It looks as if maybe a
ligature is being introduced for << here.

Norman

\start
Date: Wed, 4 Jul 2007 13:19:31 -0500
From: Tim Daly
To: Camm Maguire
Subject: directory/truename transition

Camm,

>> All versions of Axiom have a local copy of GCL cached
>> so it would be fine to do the transition

> So if an external GCL with the new semantics is present, will this
> break any of the windows branches?

Well that was the basis of my question about a conditional flag for
old/new semantics. A conditional flag would make it possible to
customize the compile-time code for GCL-2.6.8 vs GCL-2.7.0. Even
without this an Axiom branch can handle this case by using a
known-good cached version or using the built-in zips/patch mechanism
against Axiom sources.

As far as I'm aware all of the branches have cached versions of GCL
which are guaranteed to work.

Axiom can be configured to work with any version of the GCL via a
GCLVERSION flag. Based on the setting of this flag the axiom build
is patched as follows.

Axiom has a directory called zips which keeps a couple cached versions
of GCL, usually the current and previous versions. It also has patch
files which are applied for each specific GCL version. Thus if someone
chooses GCL-2.6.8
  the GCL-2.6.8.tgz is expanded in a subdirectory,
  axiom-specific patches are applied, 
  the patched GCL is built
  Axiom builds on the patched version.

So without a conditional flag the "coping mechanism" is to create
GCL-2.7.0 specific patch files against GCL and Axiom sources which
would be applied if the GCLVERSION chosen is GCL-2.7.0.

So, in general, I don't see that your changes will cause a problem.
We have dealt with this before and have machinery in place to cope.

\start
Date: Wed, 4 Jul 2007 13:40:31 -0500
From: Tim Daly
To: Camm Maguire
Subject: directory/truename transition

Camm,

> I would love Tim's and all the other developers' blessings as to
> which snapshot of which branch is worthy to represent axiom in
> Debian. Do we have consensus yet? I can work with either, new or
> old. 

I don't think you're going to ever get consensus. 
But you can have my opinion. :-)

In order to understand my response better let me rephrase your
question in terms of GCL. If there were several branches of GCL which
one should be "published" as "GCL"? My opinion is that it should be
the stable version of the trunk. Special needs people can always fetch
from a CVS latest trunk or branch. Both GCL-2.6.8pre and GCL-2.7.0
have features but are still changing.

Based on that I believe that the Debian version should be based on the
last stable version of the system which is available everywhere
else. Thus I believe that we should "publish" as "Axiom" the version
from CVS@Savannah, CVS@Sourceforge, or ARCH@axiom-developer, all of
which are identical. Thus, Axiom@Debian would also be identical.

When we promote silver to the gold version I will be pushing out a
new stable release to all of the sites. If Ondrej and you are able
to help we can also bring the Debian version up to date at that time.

\start
Date: Wed, 4 Jul 2007 20:52:55 +0200
From: Ondrej Certik
To: Tim Daly
Subject: Re: directory/truename transition

> When we promote silver to the gold version I will be pushing out a
> new stable release to all of the sites. If Ondrej and you are able
> to help we can also bring the Debian version up to date at that time.

We can put the axiom debian things into the svn.debian.org, so that we
can both access it and I am willing to help to make it compile, but
only from the Debian side, because I am busy. Unfortunately I don't
have time to fix bugs that are not related to Debian.

\start
Date: Wed, 4 Jul 2007 21:01:33 +0200
From: Ondrej Certik
To: Camm Maguire
Subject: Re: A modest proposal

> Were it only that simple.  Typically, many, many failures are required
> to get a working build on a lesser known machine.  gcl/axiom flushes
> out instabilities in gcc, binutils, and several other very low-level
> parts of the toolchain.  That said, getting all the builds working
> flushes out bugs in gcl too.

At least the bugs in the toolchain are discovered.

> Witness the issues at present: gcl switch statements apparently
> generate bogus jump table assembler on mips, gcc-object-inserted
> symbols __divq/__remq on alpha are apparently uwrappable (*), new
> GPREL_32 relocs in the new .rodata section needed support on alpha,
> new GNU_HASH section types required binutils patches, etc.
>
> (*) As you know, GCL loads object (.o) files into a running image,
> which can then be dumped and executed later.  It therefore needs the
> ability to relocate all symbols in the .o file.  Relocating to
> addresses in external shared libraries is dangerous, as the lib may
> not be in the same place on image restart.  2.6.x had a plt mechanism,
> which attempted to force gcc to provide local addresses by compiling
> in functions using the addresses of the external functions.  This
> broke with subsequenct gcc developements, so even with the plt,
> relocations were being set to shared library addresses on some
> machines.  Now, 2.7.0 redirects all such calls through a pointer in
> the C source which is reset on image startup.  __divq and the like,
> alas, have no representative in the C source, and cannot be handled
> thus.  Ideally, we can define a wrapper function and relocate to that,
> but this procedure has been problematic with mcount (for example) on
> s390 and ppc.  (just a taste ... :-)

So the problem is actually in GCL, that it is still not stable enough
to do some serious work on top of it?

I am just surprised, how many problems there are just with compiling.
I myself use Python/C/C++/Fortran and never had experienced any
problems like that. So maybe the lisp is not a mature platform for
larger projects? My naive opinion is that one should try to stick to
ways of doing programs that everyone does, so that such low-level bugs
are already fixed.

\start
Date: Wed, 4 Jul 2007 14:49:53 -0500
From: Tim Daly
To: Camm Maguire, Ondrej Certik
Subject: directory/truename transition

Ondrej, Camm,

I'm willing to fix Axiom problems, help with GCL and the Debian port.

> So the problem is actually in GCL, that it is still not stable
> enough to do some serious work on top of it?

GCL is stable enough for Axiom in the versions we are using.

The current Gold version of Axiom uses GCL-2.6.8pre2 which works
fine everywhere. The current Debian version uses GCL-2.6.7 which
will still work for Axiom. So I don't believe that GCL on Debian
will be an issue at all.

\start
Date: Wed, 4 Jul 2007 22:01:46 +0200
From: Ondrej Certik
To: Tim Daly
Subject: Re: directory/truename transition

> GCL is stable enough for Axiom in the versions we are using.
>
> The current Gold version of Axiom uses GCL-2.6.8pre2 which works
> fine everywhere. The current Debian version uses GCL-2.6.7 which
> will still work for Axiom. So I don't believe that GCL on Debian
> will be an issue at all.

Great. So there should be an official tar.gz of Axiom, and if Camm
agrees, I'll create the debian modifications (only) in svn.debian.org
and I am suggesting to use svn-buildpackage, that will apply the
debian changes to the orig.tar.gz.

\start
Date: Wed, 4 Jul 2007 16:21:06 -0400
From: Bill Page
To: Tim Daly
Subject: Re: directory/truename transition

On 7/4/07, Tim Daly wrote:
> ...
> The current Gold version of Axiom uses GCL-2.6.8pre2 which works
> fine everywhere.

What is 'GCL-2.6.8pre2'? I cannot find this tag in the gcl cvs. Did
you really mean 'GCL-2.6.8pre'?

http://cvs.savannah.gnu.org/viewvc/gcl/?root=gcl

I believe that gcl-2.6.8pre is still officially unreleased and subject
to change. Shouldn't this (finally!) be frozen as release 'gcl-2.6.8'
before building an official release of Axiom on it?

In the case of Debian isn't the policy that Axiom must be built using
only a separately released version of gcl as a dependency? I think
'gcl-2.6.7' is still the official release on Debian, right?

\start
Date: Wed, 4 Jul 2007 15:54:57 -0500
From: Tim Daly
To: Bill Page,	Ondrej Certik, Camm Maguire
Subject: directory/truename transition

Bill,

GCL-2.6.8pre2 is an Axiom internal version number. 
It contains fixes to GCL that Camm made for Axiom.
It differs from GCL-2.6.8pre because of these fixes.

Gold zips include GCL-2.6.7, GCL-2.6.8pre, and GCL-2.6.8pre2 tgz files
and their associated patches. Since GCL-2.6.8pre has been the working
version for so long there have been intermediate fixes of interest.
Each cached version is a "known good" snapshot for building Axiom.

Axiom should build properly (albeit lacking fixes) by setting
GCLVERSION to any one of the three choices. As Axiom steps up to
the next version of GCL the prior working version is in the cache.
This allows A-B testing of Axiom and failure recovery. Older versions
are removed from the cache but their associated axiom-only patch 
files are retained. 

\start
Date: Wed, 4 Jul 2007 16:00:58 -0500
From: Tim Daly
To: Bill Page, Ondrej Certik, Camm Maguire
Subject: directory/truename transition

Bill,

> In the case of Debian isn't the policy that Axiom must be built
> using only a separately released version of gcl as a dependency? I
> think gcl-2.6.7 is still the official release on Debian, right?

Technically, Axiom doesn't depend on "a separately released version of
gcl" since, as I read it a "dependency" implies that someone needs to
do an apt-get for gcl and have the dependency listed in the rpm. We
don't need to do this since Gold, at least, cannot use an external gcl.

If Camm and Ondrej want to use GCL-2.6.7 they only need to set the
GCLVERSION variable in the top level makefile or to type:
 
   make GCLVERSION=gcl-2.6.7

and it should build using that version.

\start
Date: Wed, 4 Jul 2007 23:12:35 +0200
From: Ondrej Certik
To: Tim Daly
Subject: Re: directory/truename transition
Cc: Bill Page, list

> Technically, Axiom doesn't depend on "a separately released version of
> gcl" since, as I read it a "dependency" implies that someone needs to
> do an apt-get for gcl and have the dependency listed in the rpm. We
> don't need to do this since Gold, at least, cannot use an external gcl.
>
> If Camm and Ondrej want to use GCL-2.6.7 they only need to set the
> GCLVERSION variable in the top level makefile or to type:
>
>    make GCLVERSION=gcl-2.6.7
>
> and it should build using that version.

Yes, but generally it is a good philosophy to let each particular
distribution to handle all external programs (be it Debian, Ubuntu,
Gentoo, Suse or Mac OS X). Because otherwise axiom is just duplicating
the job that the distribution should do.

\start
Date: Wed, 4 Jul 2007 17:23:55 -0400
From: Bill Page
To: Camm Maguire
Subject: re: directory/truename transition
Cc: Gabriel Dos Reis

On 04 Jul 2007 13:28:04 -0400, Camm Maguire wrote:

> ...
> How big is the mingw-ex-gcc?  Is it unreasonable to include the full
> environment in the installer?  Even macosx has bash.
>

Well first of all you need to distinguish between MinGW and MSYS.

See: http://www.mingw.org

 What is MinGW?

MinGW ("Minimalistic GNU for Windows") refers to a set of runtime
headers, used in building a compiler system based on the GNU GCC and
binutils projects. It compiles and links code to be run on Win32
platforms... providing C, C++ and Fortran compilers plus other related
tools. If you see references to "mingw32" instead of "MinGW", they are
referring to the same compiler system. The project's name changed from
mingw32 to MinGW is to prevent the implication that MinGW will only
works on 32 bit systems (as 64 and higher bit machines become more
common, MinGW will evolve to work with them). MinGW uses the Microsoft
runtime libraries, distributed with the Windows operating system.
Unlike other ports of GCC to Windows, the runtime libraries are not
distributed using Gnu's General Public License (GPL). You, therefore,
do not have to distribute your source code with your programs unless,
of course, you use a GPL library in your programs..

 What is MSYS?

MSYS or Minimal SYStem is a POSIX and Bourne shell environment use
with MinGW. It provides a hand picked set of tools to allow a typical
configuration script with Bourne syntax to execute. This allows most
of the GNU packages to create a Makefile just from executing the
typical configure script which can then be used to build the package
using the native MinGW version of GCC.

The POSIX layer used by MSYS is a fork of the 1.3.3 version of Cygwin
. Cygwin is a full POSIX layer and UNIX-like environment for Win32
providing both server and client utilites.

-------

So in short MinGW is the gcc compiler system for windows and MSYS is
the rest of a simple posix-compliant development environment (unix
tools like ls, rm, mv and optionally bash). It is quite possible to
use MinGW without MSYS by relying on the Windows command line
environment or from an IDE that supports MinGW.

On my Windows system MinGW is 90 Mbytes and MSYS is 40 Mbytes. So, yes
I think it would be unreasonable to include all of this in a gcl
installer. The part of MinGW that is included with the Axiom on
Windows installer is only about 4 Mbytes. This provides only the gcc C
compiler and the necessary libraries required to compile code
generated by GCL. It does not include any of the MSYS components.

> Speaking of which, does anyone know how to make the mingw installer
> for the next GCL release?
>

I forget exactly what installer Mike Thomas used for the last gcl
binary for Windows but there are seveal good open source ones to
choose from. We used NSIS for Axiom on Windows.

> > Although it requires a little more knowledge of Windows internals, I
> > strongly recommend that gcl on windows continue to call the windows
> > API instead of relying on external support for posix/unix commands in
> > a particular shell that is not native to Windows. For similar reasons
> > I also would not recommend trying to utilize the Windows non-posix
> > command interpreter for this purpose.
> >
>
> I'm happy to go along with this, though I'm not sure what benefit the
> user would see other than a little less disk space usage.  I can only
> justify minimal time learning anything windows specific for this
> purpose, but of course will eagerly accept all offers of assistance in
> this regard.
>

Although MSYS can access the full Windows file system, it does so in a
way that would be  unfamilar and somewhat unnatural to a Windows user.
It is better to think of MSYS as a porting environment rather than a
replacement posix shell for Windows users. Of course this probably
could be hidden by some clever programming in gcl but a fear that it
might also be a source of problems.

I understand your reluctance to spend much time learning windows
specific API details. In spite of limited available time, I am willing
to help with this where/when I can, but my only real experience is
that gained while working with Mike Thomas for a few months a few
years ago on the previous version Axiom on Windows. I do not think I
know enough about either Windows or GCL internals.

> Now perhaps there is just a lower level api to which I could write
> that would transparently be portable.  E.g. implementing directory via
> readdir and opendir.  Re-implementing all the shell pattern matching
> from scratch is certainly doable, but there should be some clear
> benefit visible that would justify the work.  Its hard for me to see
> at the moment.
>

Some of these things might be available in an MSYS library but I do
not know how accessible or adaptable to gcl it would be. In any case I
seriously doubt that it would end up being "transparently portable".

> Please see related post regarding an extra-spec posix support function
> proposal.
>

Yes, I think that's good. Now we just need to find resources to help
implement this for gcl-2.7 on windows. I am also a little worried that
because of the extensive differences in 2.7 memory management and
other deep changes, there may be some more issues besides the file
system waiting to be discovered in the windows port. :-( Has anyone
actually attempted to build gcl-2.7 on Windows yet?

\start
Date: 04 Jul 2007 17:22:54 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: directory/truename transition

Greetings!

I agree 2.6.8 has taken way too long -- my apologies.  

Comments like this:

http://lists.gnu.org/archive/html/gcl-devel/2007-05/msg00036.html

have kept me back, together with lack of time and volunteers, of
course, to address it.

GCL is quite stable, (at least 2.6.x), but is very low-level and
novel, and as such is subject to the same issues confronting atlas,
lapack, etc -- "bit rot".

At the moment, I'm using the Debian package version number and
autobuilders to verify that gcl and all applications build atop the
current toolchain.  I'm about to release 2.6.7-34, which is a current
2.6.8pre snapshot.

As you can see, in Debian stable, we have 2.6.7-32.

2.6.7-33 is failing to build on some platforms due to an ld segfault:

http://buildd.debian.org/build.cgi?pkg=gcl

I'm hoping this is temporary.

Here are the changelog entries through -34:

gcl (2.6.7-34) unstable; urgency=low

  * add read-byte,read-sequence,write-byte,write-sequence support
  * fix some float parsing inaccuracies
  * support GNU_HASH sections, Closes: #426135
  * safety 2 for certain low level functions in gcl_listlib.lsp, CLoses:
    #415266

 -- Camm Maguire  Wed,  4 Jul 2007 16:23:25 -0400

gcl (2.6.7-33) unstable; urgency=low

  * Fix leading underscore behavior of my_plt
  * add sqrt to plttest.c
  * disable-nls added to the binutils subconfigures to avoid msgfmt
    dependency
  * remove -lintl from powerpc-macosx.defs
  * update to make-user-init from cvs head to support hol88, fix link on
    mingw
  * solaris-i386 support
  * fix read-char-no-hang on mingw
  * fast compile without wrap-literals
  * sigaltstack support
  * fix cerror

 -- Camm Maguire  Wed, 16 May 2007 12:45:40 -0400


The only thing absolutely critical is the GNU_HASH section support,
without which GCL .o file loading is broken by the latest gcc output. 

In addition, it is likely that the sparc compiler will ICE:

http://buildd.debian.org/fetch.cgi?pkg=gclcvs;ver=2.7.0-75;arch=sparc;stamp=1183559393

meaning that gcl and axiom and maxima and hol88 will not enter testing
until this is fixed or we drop sparc support.

My only plans for 2.6.8 prior to release were:

build verification across all 12.
ensure-directories-exist if and only if axiom must have it
intel mac support
satisfy vadim on mingw.

If axiom would prefer, I can drop the second and third to accelerate a
2.6.8 official .tar.gz

Once everything works, we need 10 days after the slowest machine
completes the build for migration into testing.  We may get some
speedup with high priority, but this setting is routinely ignored if
the package is new in any way.

I for one agree with Tim's definition of what should go in, but dearly
hope we can pull together and incorporate the best ideas into one
place.  As far as Debian goes, one typically needs a .tar.gz released
officially somewhere before one begins.  

So my suggestions:

1) While I iron out the gcl build issues in Debian, Tim hopefully in
   consultation with the other axiom developers finalize a .tar.gz
2) Depending on how long this takes, axiom decides whether to use
   2.6.8 or 2.7.0. (I still have hope that this will be seen as
   preferable soon and I can consolidate and only support one tree.
   But I imagine that it will be at least September should 2.7.0 be
   desired. )
3) I'm hoping the existing contents of debian/ will need little
   change, and only simplification.  I of course welcome any
   suggestions/patches thereto from Ondrej or others interested.
   Is there any reason it won't just work as is?
4) help with bug reports, build issue workarounds, etc. from all most
   appreciated.  There will likely be a period of at least a few weeks
   during which we need to monitor the buildd web pages daily and
   follow up on problems.  If any of you have access to rare machines
   (esp arm, alpha -- several of these are no longer available to
   ordinary Debian devlopers) and have gdb skills, this is most
   useful. 

In any case, I do not think axiom uploads to Debian should occur until
at least gcl and maxima migrate into testing.

Just my quick thoughts -- pardon the incoherence.

Take care,

Bill Page writes:

> On 7/4/07, Tim Daly wrote:
> > ...
> > The current Gold version of Axiom uses GCL-2.6.8pre2 which works
> > fine everywhere.
> 
> What is 'GCL-2.6.8pre2'? I cannot find this tag in the gcl cvs. Did
> you really mean 'GCL-2.6.8pre'?
> 
> http://cvs.savannah.gnu.org/viewvc/gcl/?root=gcl
> 
> I believe that gcl-2.6.8pre is still officially unreleased and subject
> to change. Shouldn't this (finally!) be frozen as release 'gcl-2.6.8'
> before building an official release of Axiom on it?
> 
> In the case of Debian isn't the policy that Axiom must be built using
> only a separately released version of gcl as a dependency? I think
> 'gcl-2.6.7' is still the official release on Debian, right?

\start
Date: Wed, 4 Jul 2007 17:32:44 -0400
From: Bill Page
To: Tim Daly
Subject: Re: directory/truename transition

On 7/4/07, Tim Daly wrote:
> Bill Page wrote:
> > In the case of Debian isn't the policy that Axiom must be built
> > using only a separately released version of gcl as a dependency? I
> > think gcl-2.6.7 is still the official release on Debian, right?
>
> Technically, Axiom doesn't depend on "a separately released version of
> gcl" since, as I read it a "dependency" implies that someone needs to
> do an apt-get for gcl and have the dependency listed in the rpm. We
> don't need to do this since Gold, at least, cannot use an external gcl.
>
> If Camm and Ondrej want to use GCL-2.6.7 they only need to set the
> GCLVERSION variable in the top level makefile or to type:
>
>    make GCLVERSION=gcl-2.6.7
>
> and it should build using that version.
>

That is not how the current release of Axiom is built on Debian. Camm
patches the build system to do things in a very different way so that
among other things it uses an externally installed version of gcl
(like build-improvements and wh-sandbox but without all the autoconf
magic).

I understood that it was necessary for Camm to do this in order to
conform to Debian packaging standards. Of course it was also more
convenient for him to do this since he is also the Debian maintainer
for gcl.

Perhaps I should just shut-up and let Camm address this issue ...

\start
Date: Wed, 4 Jul 2007 16:50:05 -0500
From: Tim Daly
To: Bill Page, Ondrej Certik, Camm Maguire
Subject: directory/truename transition

Ondrej,

> Yes, but generally it is a good philosophy to let each particular
> distribution to handle all external programs (be it Debian, Ubuntu,
> Gentoo, Suse or Mac OS X). Because otherwise axiom is just duplicating
> the job that the distribution should do.

This has been debated extensively on this list and there are other 
people here who agree with you, most notably Bill Page, which is why
he asked the question. This view implicitly assumes that users have
tools like apt-get and yum which can resolve dependencies. At least
one of my systems is still RedHat 9 and all dependencies in rpm files
have to be searched and resolved by hand, a daunting task at best.

Consider the current case, that there are several fixes in GCL that
Axiom uses but they are still in GCL-2.6.8pre. In fact, there are
different, unmarked versions of GCL-2.6.8pre which contain additional
fixes.

If a user gets a copy of Axiom and tries to build it they would be
immediately confronted with the task of installing GCL. They would
naturally install GCL-2.6.7 since that is the released version. They
would then find that the Axiom build would fail, either because
    (a) it had the bug that GCL-2.6.8pre (some snapshot) fixes
or  (b) axiom needed GCL-2.6.8pre to build, not GCL-2.6.7

Reporting the bug (a) would get the reply "that's been fixed".
Reporting the bug (b) would get the reply "get the CVS GCL".

In either case the potential Axiom user is confronted with a
non-working Axiom system. Thus we lose a potential Axiom user.

My philosophy is that Axiom should "just work". From this it 
follows that we need to extensively test Axiom on a single
known-good version of GCL, which we cache. That way the end
user gets Axiom, sets a shell variable, and types 'make'.
People who want a specific GCL can specify that on the make:
   make GCLVERSION=gcl-2.6.7

If you've followed the recent discussion there have been some
excellent advances in the "just work" department, most notably
Gaby's Build Improvements change for autoconf.

There is also some effort to use an external GCL but there have
been issues related to dynamic linking and Axiom-specific 
modifications which Gold statically links. All of these will
eventually be worked out.

In the mean time it seems to me that the struggles which concern
developers on internal builds and branches should not become
concerns of external users. Axiom should "just work".

As noted, however, there is much disagreement about the means,
if not the goal, of "just works".

\start
Date: Wed, 4 Jul 2007 18:21:00 -0400
From: Bill Page
To: Tim Daly
Subject: Re: directory/truename transition

On 7/4/07, Tim Daly wrote:
> ...
> This has been debated extensively on this list and there are other
> people here who agree with you, most notably Bill Page, which is why
> he asked the question. This view implicitly assumes that users have
> tools like apt-get and yum which can resolve dependencies. At least
> one of my systems is still RedHat 9 and all dependencies in rpm files
> have to be searched and resolved by hand, a daunting task at best.
>

Both build-improvements and wh-sandbox allow these dependencies to be
satisfied by downloading the addtional gcl and/or noweb sources. If
they are present in the source tree, then local versions of these are
built and used in turn to build Axiom. In fact build-improvements
still includes a gcl directory containing a recent snapshot of
gcl-2.6.8pre which is only used if an externally installed gcl is not
present or if specifically requested by a configure option.

> Consider the current case, that there are several fixes in GCL that
> Axiom uses but they are still in GCL-2.6.8pre. In fact, there are
> different, unmarked versions of GCL-2.6.8pre which contain additional
> fixes.

I would think that in this case neither Axiom nor GCL are ready for an
official release.

>
> If a user gets a copy of Axiom and tries to build it they would be
> immediately confronted with the task of installing GCL. They would
> naturally install GCL-2.6.7 since that is the released version. They
> would then find that the Axiom build would fail, either because
>     (a) it had the bug that GCL-2.6.8pre (some snapshot) fixes
> or  (b) axiom needed GCL-2.6.8pre to build, not GCL-2.6.7
>
> Reporting the bug (a) would get the reply "that's been fixed".
> Reporting the bug (b) would get the reply "get the CVS GCL".
>

>From what Camm just wrote:

> At the moment, I'm using the Debian package version number
> and autobuilders to verify that gcl and all applications build atop
> the current toolchain.  I'm about to release 2.6.7-34, which is a
> current 2.6.8pre snapshot.

So it seems that Camm is currently treating 2.6.8pre as a sub-release
fix to 2.6.7. This would mean for Debian users that all they would
need to do is

  apt-get update axiom*

and they would have the necessary version of GCL required to build the
the Debian modified sources for Axiom as well as the wh-sandbox and
build-improvements branches.

Perhaps the official Axiom release should also use gcl-2.6.7-34
sources as released on Debian?

> ...
> As noted, however, there is much disagreement about the means,
> if not the goal, of "just works".
>

Indeed. I think that it is only practical to aim for "just works" in
the case of binary distributions tested and certified for specific
environments. Compiling Axiom from source is a completely different
issue in which "just works" is very often unlikely.

\start
Date: Thu, 5 Jul 2007 00:25:59 +0200
From: Ondrej Certik
To: Tim Daly
Subject: Re: directory/truename transition
Cc: Bill Page

> This has been debated extensively on this list and there are other
> people here who agree with you, most notably Bill Page, which is why
> he asked the question. This view implicitly assumes that users have
> tools like apt-get and yum which can resolve dependencies. At least
> one of my systems is still RedHat 9 and all dependencies in rpm files
> have to be searched and resolved by hand, a daunting task at best.

Yes, that's why those distributions that cannot handle dependecies are
receding. But I think if someone is still using those, he already
knows how to do these things by hand.

> Consider the current case, that there are several fixes in GCL that
> Axiom uses but they are still in GCL-2.6.8pre. In fact, there are
> different, unmarked versions of GCL-2.6.8pre which contain additional
> fixes.

Yep, these needs to get to Debian first and then Axiom.

> If a user gets a copy of Axiom and tries to build it they would be
> immediately confronted with the task of installing GCL. They would
> naturally install GCL-2.6.7 since that is the released version. They
> would then find that the Axiom build would fail, either because
>     (a) it had the bug that GCL-2.6.8pre (some snapshot) fixes
> or  (b) axiom needed GCL-2.6.8pre to build, not GCL-2.6.7
>
> Reporting the bug (a) would get the reply "that's been fixed".
> Reporting the bug (b) would get the reply "get the CVS GCL".
>
> In either case the potential Axiom user is confronted with a
> non-working Axiom system. Thus we lose a potential Axiom user.

I agree, the patches should be accepted to GCL and the GCL should get
into distributions, so that Axiom works out of the box.

> My philosophy is that Axiom should "just work". From this it
> follows that we need to extensively test Axiom on a single
> known-good version of GCL, which we cache. That way the end
> user gets Axiom, sets a shell variable, and types 'make'.
> People who want a specific GCL can specify that on the make:
>    make GCLVERSION=gcl-2.6.7
>
> If you've followed the recent discussion there have been some
> excellent advances in the "just work" department, most notably
> Gaby's Build Improvements change for autoconf.
>
> There is also some effort to use an external GCL but there have
> been issues related to dynamic linking and Axiom-specific
> modifications which Gold statically links. All of these will
> eventually be worked out.
>
> In the mean time it seems to me that the struggles which concern
> developers on internal builds and branches should not become
> concerns of external users. Axiom should "just work".
>
> As noted, however, there is much disagreement about the means,
> if not the goal, of "just works".

I agree it need to just work, that's why the current version should be
in Debian. I have nothing against preparing some easy environment with
all the sources of all packages needed (like SAGE is doing), because
it has some advantages as mentioned in that former discussion, but in
my opinion this is not a systematic work. One should try to propagate
all patches upstream (and in the meantime use the patched version) and
use the distribution to do the work.

I for example have my own debian repository, where I have all the
packages, that are either not yet in Debian, or need some patching. I
make sure everything works for me nicely (and it then looks like if
everything was in Debian), and then I just try to get my packages or
updates to Debian, which takes time of course, but it doesn't matter,
because I (and the users) can use my own patched packages in the
meantime in exactly the same way as if it was already in Debian (only
they need to add another repository to their sources.list). I believe
the same can be done for any linux distribution.

> Indeed. I think that it is only practical to aim for "just works" in
> the case of binary distributions tested and certified for specific
> environments. Compiling Axiom from source is a completely different
> issue in which "just works" is very often unlikely.

What didn't occur to me for a long time is that the Debian source
package always builds if the build dependecies are satisfied, so it
can be used as a reference implementation of the compilation.

\start
Date: Wed, 4 Jul 2007 19:53:30 -0500 (CDT)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: directory/truename transition

On Wed, 4 Jul 2007, Camm Maguire wrote:

| Question 1) -- as there are workarounds for mingw now with 2.6.x, does
| it make sense to implement this transition only in 2.7.x and above?
| No need for conditionals, etc.  I only went down this road re: 2.6.x
| as Gaby said he needed a backport of ensure-directories-exist.

If the backport to 2.6.8 is not as straighfoward as it shuld have been,
then I'm happy to wait for gcl-2.6.9.  Thanks!

\start
Date: Wed, 4 Jul 2007 20:06:25 -0500 (CDT)
From: Gabriel Dos Reis
To: list
Subject: Axiom build dependency

All --

  Axiom currenty depends on GCL (among other dependencies).  Period.

  Axiom should NOT forcefully try to build its own GCL when the system
version should be OK.  Anything else should be considered a bug, not a
feature.  That bug has been fixed in build-improvements and wh-sandbox.
Hopefully, the fixes will find their way to stable Axiom.

\start
Date: Thu, 5 Jul 2007 03:51:27 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Axiom and ANSI Lisp -- SBCL

> 
> Waldek --
> 
>   In a local tree, I've added a warpper to compile-file so that
> it aborst build when the tertiary return value of compile-file (failure-p) is
> true.  I consider that a minimum trust for sane build of Axiom -- which means
> neither silver nor build-improvements is sane with respect to that 
> notion.  When I do that I see lots of failures.  Did you try that?
> 

No, I did not try this.  By my reading of Ansi spec is that 'failure-p'
is true if there is any warning during compile.  Currently we get a lot
of warnings.  ATM it would be more useful to stop on errors.

\start
Date: Wed, 4 Jul 2007 20:56:46 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Axiom and ANSI Lisp -- SBCL

On Thu, 5 Jul 2007, Waldek Hebisch wrote:

| > 
| > Waldek --
| > 
| >   In a local tree, I've added a warpper to compile-file so that
| > it aborst build when the tertiary return value of compile-file (failure-p) is
| > true.  I consider that a minimum trust for sane build of Axiom -- which means
| > neither silver nor build-improvements is sane with respect to that 
| > notion.  When I do that I see lots of failures.  Did you try that?
| > 
| 
| No, I did not try this. 

OK, thanks!

| By my reading of Ansi spec is that 'failure-p'
| is true if there is any warning during compile.  Currently we get a lot
| of warnings.

No, only warnings other than style-warning.  And Using SBCL, I've found
it very useful to stop when failure-p is true.  There was no single
occasion where I got a false positive.  Many times, it indicated
a sloppy logic in the program formulation, an dit helped me to build
something digestible by ECL -- ECL, unfortunatel will generate garbage.

|  ATM it would be more useful to stop on errors.

On error, the primary value is nil.  However, it is also very useful
to stop on failure-p.

\start
Date: Wed, 4 Jul 2007 22:52:28 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: defintrf.spad

Waldek,

I see the following change to defintrf.spad.
Can you tell me why? 
The code seems to be logically equivalent.


--- ../silver/src/algebra/defintrf.spad.pamphlet	2007-04-27 04:44:35.000000000 -0400
+++ wh-sandbox/src/algebra/defintrf.spad.pamphlet	2007-04-27 21:29:46.000000000 -0400
@@ -182,7 +182,10 @@
           ["min"/[t.left for t in l], i.halfinf.endpoint]
         l := [u::REC for t in l | (u := refine(p, t, bounds)) case REC]
         incl? => l
-        select_!(keeprec?(i.halfinf.endpoint, #1), l)
+        -- greg, FIXME dirty workaround
+        -- select_!(keeprec?(i.halfinf.endpoint, #1), l)
+        ep := i.halfinf.endpoint
+        select_!(keeprec?(ep, #1), l)
       error "findRealZero: should not happpen"
 
     checkBudan(p, a, b, incl?) ==

\start
Date: Thu, 5 Jul 2007 03:17:04 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re: Problem kTuple wish 2.
Cc: Christian Aistleitner

On 6/26/07, Ralf Hemmecke wrote:
> ...
> Suppose you want a constructor like
>
> M(T: Tuple Cat): MCat(T) == add {...}
>
> for some given category Cat (For simplicity, lets say
>
>    define Cat: Category == with {=:(%,%)->Boolean}
>
> . The question now is how do I define MCat and the corresponding add
> {...} in such a way that I am able to generate an element of M in a
> simple form.
> ...

I tried to see how far I could get with this problem in Aldor. The
result is shown at:

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

The code compiles and is apparently type correct but it does not
exactly produce the expected output. This code seems to work best
compiled to Lisp and iinked into Axiom. When I try the same thing with
the Aldor stand alone compiler I get some peculiar and unexpected
error messages. Perhaps this is pushing the limits of what the
compiler can do but I seems to be almost there... Perhaps a bug report
is in order?

\start
Date: Thu, 5 Jul 2007 11:22:35 +0200 (CEST)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: defintrf.spad

> Waldek,
> 
> I see the following change to defintrf.spad.
> Can you tell me why? 
> The code seems to be logically equivalent.
> 
> 
> 
> --- ../silver/src/algebra/defintrf.spad.pamphlet	2007-04-27 04:44:35.000000000 -0400
> +++ wh-sandbox/src/algebra/defintrf.spad.pamphlet	2007-04-27 21:29:46.000000000 -0400
> @@ -182,7 +182,10 @@
>            ["min"/[t.left for t in l], i.halfinf.endpoint]
>          l := [u::REC for t in l | (u := refine(p, t, bounds)) case REC]
>          incl? => l
> -        select_!(keeprec?(i.halfinf.endpoint, #1), l)
> +        -- greg, FIXME dirty workaround
> +        -- select_!(keeprec?(i.halfinf.endpoint, #1), l)
> +        ep := i.halfinf.endpoint
> +        select_!(keeprec?(ep, #1), l)
>        error "findRealZero: should not happpen"
>  
>      checkBudan(p, a, b, incl?) ==
> 
> 

This is a workaround for bug in the Spad compiler -- first version
produced wrong Lisp code, the second works.  It showed up first in
sbcl port.  This fix is due to Greg Vanuxem (as noted in the comment). 

\start
Date: Thu, 05 Jul 2007 12:03:18 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Problem kTuple wish 2.

> http://wiki.axiom-developer.org/SandBoxAldorTuples

Thank you, Bill. I think, I love the idea with

   get: % -> T

But that is only a tiny bit and actually does not solve the problem that 
  I finally would like to return something like

(F Integer, F String)

for some domain constructor F if the input T is (Integer,String).

> The code compiles and is apparently type correct but it does not
> exactly produce the expected output. This code seems to work best
> compiled to Lisp and iinked into Axiom. When I try the same thing with
> the Aldor stand alone compiler I get some peculiar and unexpected
> error messages. Perhaps this is pushing the limits of what the
> compiler can do but I seems to be almost there... Perhaps a bug report
> is in order?

To make that error message clearer I realized to following:

woodpecker:~/scratch>aldor -fx -laldor aaa.as
woodpecker:~/scratch>aaa
Looking in M((AldorInteger, String)) for m with code 111396431
Unhandled Exception: RuntimeError()
Export not found

for the program given below. To me that looks like a compiler bug.

To be honest, I am not sure whether the compiler should actually compile 
that code without complaint.

If one writes

   m(4, "a)                             (*)

then what is

   (4, "a")                             (**)

? A multi-value. But m cannot be applied to multivalues. It needs a tuple.

Maybe the compiler applies courtesy conversions???
http://www.aldor.org/docs/HTML/chap7.html

If (**) is a tuple, then what is its type? Since we want it to be a 
tuple, it must be

   Tuple SOMETHING

. Well, now we have a problem to get SOMETHING from Integer and String.
Union(Integer, String) would work. But that looks totally ugly and would 
allow (4, 4711) instead of (4, "a").

Now the only thing that comes to my mind would be to use Cross instead 
of Tuple. But writing

extend Cross(T: Tuple Type): with {...} == add {...}

instead of

M(T: Tuple Type): with {...} == add {...}

and then

   import from Cross(Integer, String).

gives the same problems.

Ralf

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

M(T: Tuple Type): with {
     m: T -> %;
     get: % -> T;
} == add {
     m(x:T):% == (x) pretend %;
     get(x:%):T == x pretend T;
}

main(): () == {
	import from Integer, String, Boolean;
	import from M(Integer, String);
	import from M(String, String, Boolean);
	a := m(4, "a");
	b := m("x", "y", true);
	--
	-- type error:
	--c := m(1, "x", false)
	--
	(x, y) := get(a);
	stdout << "(x,y) = (" << x << "," << y << ")" << newline;

	(i,j,k) := get(b);
	stdout << "(i,j,k) = (" << i << "," << j << "," << k << ")" << newline;
}
main();
---END aaa.as

\start
Date: Thu, 5 Jul 2007 05:04:07 -0500 (CDT)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: directory/truename transition

On Tue, 3 Jul 2007, Camm Maguire wrote:

| This is all quite depressing.  It appears the clspec is quite
| deficient in this regard.  Hence, I think the proper goal for GCL is
| to be as close to posix and "intuition" in this regard while still
| passing the spec.  

Hi Camm,

  Indeed, I believe that where ANSI Common Lisp is silent and or
deficient in terms of system programming, it makes sense for GCL
to borrow from POSIX specification.  Mainstream proramming languages
that support system building either borrow from POSIX or have bindings
to POSIX.  

  [There is also an ongoing effort to have a POSIX binding for C++, and
the C++ committee is also considering adding support for POSIX thread, 
independently of whatever the binding group does. ]

\start
Date: Thu, 5 Jul 2007 12:41:35 -0500
From: Tim Daly
To: Gregory Vanuxem
Subject: defintrf.spad

Greg,

Attached is a diff of defintrf. Waldek points out that this code
change was due to a spad compiler bug. 

Is there a mailing list discussion on this?
Do you have the bad code.lsp file?
This could cause problems elsewhere.
I'd really like to find out why the compiler failed
so we can fix the root cause of the problem.

Tim

--- ../silver/src/algebra/defintrf.spad.pamphlet	2007-04-27 04:44:35.000000000 -0400
+++ wh-sandbox/src/algebra/defintrf.spad.pamphlet	2007-04-27 21:29:46.000000000 -0400
@@ -182,7 +182,10 @@
           ["min"/[t.left for t in l], i.halfinf.endpoint]
         l := [u::REC for t in l | (u := refine(p, t, bounds)) case REC]
         incl? => l
-        select_!(keeprec?(i.halfinf.endpoint, #1), l)
+        -- greg, FIXME dirty workaround
+        -- select_!(keeprec?(i.halfinf.endpoint, #1), l)
+        ep := i.halfinf.endpoint
+        select_!(keeprec?(ep, #1), l)
       error "findRealZero: should not happpen"
 
     checkBudan(p, a, b, incl?) ==

\start
Date: 05 Jul 2007 16:33:40 -0400
From: Camm Maguire
To: Mark Murray
Subject: Re: [Gcl-devel] Re: gcl-2.7.0 on FreeBSD

Greetings!

BSD appears to start the shared library loading relatively low:

checking for shared library/C stack ceiling to heap... 0x280ad000

(Linux starts at 0x40000000)

This will cut available memory in half on bsd.

Is there a workaround?

\start
Date: Thu, 5 Jul 2007 23:58:09 +0200
From: Ondrej Certik
To: Camm Maguire
Subject: Re: directory/truename transition

> 3) I'm hoping the existing contents of debian/ will need little
>    change, and only simplification.  I of course welcome any
>    suggestions/patches thereto from Ondrej or others interested.
>    Is there any reason it won't just work as is?

Do you have the Debian repository somewhere? (The one which we will be
using for testing, before you upload it to Debian) I'll try to send
patches or test, only I don't know what the current way of doing
things is.

\start
Date: Thu, 05 Jul 2007 23:55:46 +0100
From: Mark Murray
To: Camm Maguire
Subject: Re: [Gcl-devel] Re: gcl-2.7.0 on FreeBSD 

Camm Maguire writes:
> Greetings!
> 
> BSD appears to start the shared library loading relatively low:
> 
> checking for shared library/C stack ceiling to heap... 0x280ad000
> 
> (Linux starts at 0x40000000)
> 
> This will cut available memory in half on bsd.
> 
> Is there a workaround?

I haven't a clue, but I know where to ask. Gimme a day or three.

\start
Date: 05 Jul 2007 19:16:30 -0400
From: Camm Maguire
To: Ondrej Certik
Subject: Re: directory/truename transition

Greetings!

Just update /etc/apt/sources.list accordingly and

apt-get source axiom

Ondrej Certik writes:

> > 3) I'm hoping the existing contents of debian/ will need little
> >    change, and only simplification.  I of course welcome any
> >    suggestions/patches thereto from Ondrej or others interested.
> >    Is there any reason it won't just work as is?
> 
> Do you have the Debian repository somewhere? (The one which we will be
> using for testing, before you upload it to Debian) I'll try to send
> patches or test, only I don't know what the current way of doing
> things is.

\start
Date: Thu, 5 Jul 2007 18:59:21 -0500
From: Tim Daly
To: list
Subject: Version Control

The SBCL group is considering using git. They've found a windows port.
For those who care there appears to be a mingw port of git at:
<http://lilypond.org/git/binaries/mingw>. There you'll find
git-1.5.2.1-1.mingw.exe

This might also install sufficient tools to help the Axiom
windows port. There is a good writeup of the mingw effort at
<http://git.or.cz/gitwiki/WindowsInstall>

\start
Date: Thu, 5 Jul 2007 20:33:49 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: Version Control

> This might also install sufficient tools to help the Axiom
> windows port. There is a good writeup of the mingw effort at
> <http://git.or.cz/gitwiki/WindowsInstall>

Seems like this page has been hacked/spammed.

\start
Date: Fri, 6 Jul 2007 09:17:59 +0200
From: Juergen Weiss
To: Mark Murray, Camm Maguire
Subject: re: [Gcl-devel] Re: gcl-2.7.0 on FreeBSD 

I think in /boot/loader.conf you can set the maximum data segment
size to a higher value (default is 512 MBytes), for
example to 1 GByte by

kern.maxdsiz=1073741824

You have to reboot the system.

> -----Original Message-----
>
> Camm Maguire writes:
> > Greetings!
> >
> > BSD appears to start the shared library loading relatively low:
> >
> > checking for shared library/C stack ceiling to heap... 0x280ad000
> >
> > (Linux starts at 0x40000000)
> >
> > This will cut available memory in half on bsd.
> >
> > Is there a workaround?
>
> I haven't a clue, but I know where to ask. Gimme a day or three.
>
\start
Date: Fri, 06 Jul 2007 12:42:34 +0100
From: Mark Murray
To: Juergen Weiss
Subject: re: [Gcl-devel] Re: gcl-2.7.0 on FreeBSD 
Cc: Camm Maguire

"Weiss, Juergen" writes:
> I think in /boot/loader.conf you can set the maximum data segment
> size to a higher value (default is 512 MBytes), for
> example to 1 GByte by
> 
> kern.maxdsiz=1073741824
> 
> You have to reboot the system.

Will do this in about 8 hours.

\start
Date: Fri, 6 Jul 2007 16:07:02 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: FriCAS started

I wrote:
> I plan to created a new project called FriCAS

FriCAS is now started -- you can see the SVN repository at:

http://fricas.svn.sourceforge.net/

To check out a copy do:

svn co https://fricas.svn.sourceforge.net/svnroot/fricas/trunk fricas

FriCAS revision 6 is identical to a subset of wh-sandbox branch revision 646.
Subset, because I decided to do a major cleanup -- FriCAS source tree
(withoout .svn files) takes 21 Mb, while wh-sandbox needs 74 Mb.
Checked out FriCAS tree is 62 Mb compared to 180 Mb for wh-sandbox.

I have removed Nag library support, doc subdirectory, cached viewport,
cached databases and libaxiom.al.  There are also few other removals.
Due to removals revision 6 is completly broken -- it is useful only
for the purpose of monitoring changes.

The current revision, that is revision 11 corrected most of the
breakage.  In particular algebra should now bootstrap from
empty databases.  To make graphic examples in HyperDoc one
has to invoke extra command in X windows (the rest of the build
works fine in text mode).  I know of some uncorrected breakage on
HyperDoc pages (due to Nag routines), and of course more breakage can
show up.

FriCAS prints a different banner:

GCL (GNU Common Lisp)  2.6.7 CLtL1    Oct 13 2006 23:36:27
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
                 FriCAS (AXIOM fork) Computer Algebra System
                         Version: FriCAS 2007-05-31
                 Timestamp: Friday July 6, 2007 at 06:18:56
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------

(1) ->

but otherwise identifies itself as Axiom.  Let me know more distinction.
Also, ATM I am not setting up a separate mailnig list -- let me know
if you do not want FriCAS traffic on Axiom maining list.

\start
Date: 06 Jul 2007 10:18:21 -0400
From: Camm Maguire
To: Tim Daly
Subject: debugging
Cc: Bill Page

Greetings!  How does one enable lisp debugging in axiom, and get more
than 

   >> System error:

\start
Date: Fri, 6 Jul 2007 09:34:20 -0500
From: Tim Daly
To: Camm Maguire
Subject: debugging

Camm,

Any lisp command can be executed with 
  )lisp (any sexpr)

also you can have axiom fall into lisp on error with
  )set break break
or not fall into lisp with
  )set break resume

\start
Date: Fri, 6 Jul 2007 10:38:20 -0400
From: Bill Page
To: Camm Maguire
Subject: Re: debugging

On 06 Jul 2007 10:18:21 -0400, Camm Maguire wrote:
> Greetings!  How does one enable lisp debugging in axiom, and get more
> than
>
>    >> System error:
>

?? Do you mean gcl --enable-debug? I have previously used this option
without an problems. Could you describe how and when you get this
message? I will try to reproduce.

\start
Date: Fri, 6 Jul 2007 10:48:24 -0400
From: Bill Page
To: Waldek Hebisch
Subject: Re: FriCAS started

On 7/6/07, Waldek Hebisch wrote:
> ...
> FriCAS is now started -- you can see the SVN repository at:
>
> http://fricas.svn.sourceforge.net/
>
> To check out a copy do:
>
> svn co https://fricas.svn.sourceforge.net/svnroot/fricas/trunk fricas
>

Thank you for taking this bold step. I am very much in favor of the
action you are taking even though I know that it might make some
people worried about the future of the Axiom project. To me this seems
like a very positive development and I am greatly encouraged that you
decided to proceed with the plans you announced last week.

Personally I plan to remain active in *both* the original Axiom
project and also to help where and when I can with FriCAS. (Still
think that is a terrible name. :-)

> ...
> The current revision, that is revision 11 corrected most of the
> breakage.  In particular algebra should now bootstrap from
> empty databases.  To make graphic examples in HyperDoc one
> has to invoke extra command in X windows (the rest of the build
> works fine in text mode).  I know of some uncorrected breakage on
> HyperDoc pages (due to Nag routines), and of course more breakage
> can show up.
>

How shall we report errors? Do you want to set up a different
reporting system (e.g. via SourceForge) or should FriCAS be simply
recognized in the Axiom project as a separate "parallel" version? If
the consensus is in favor of the latter, I can make appropriate
adjustments to the IssueTracker on Axiom Wiki to support this.

> FriCAS prints a different banner:
> ...
>
> but otherwise identifies itself as Axiom.  Let me know more distinction.
> Also, ATM I am not setting up a separate mailnig list -- let me know
> if you do not want FriCAS traffic on Axiom maining list.
>

My personal opinion is that FriCAS can and should be accomodated
within the current Axiom project infrastructure.

\start
Date: 06 Jul 2007 11:08:47 -0400
From: Camm Maguire
To: Mark Murray
Subject: re: [Gcl-devel] Re: gcl-2.7.0 on FreeBSD
Cc: Mark Murray

Greetings!  OK, the bsd issues are almost ironed out.

GCL has made extensive use of unboxed complex arithmetic.  Does BSD
have this function somewhere?

Error: ERROR "dlsym lookup failure on \"cexpf\": \"Undefined symbol \\\"cexpf\\\"\""
Fast links are on: do (si::use-fast-links nil) for debugging


Take care,

Mark Murray writes:

> "Weiss, Juergen" writes:
> > I think in /boot/loader.conf you can set the maximum data segment
> > size to a higher value (default is 512 MBytes), for
> > example to 1 GByte by
> > 
> > kern.maxdsiz=1073741824
> > 
> > You have to reboot the system.
> 
> Will do this in about 8 hours.

\start
Date: Fri, 6 Jul 2007 11:03:13 -0500
From: Tim Daly
To: Waldek Hebisch
Subject: friCAS

Waldek,

You've decided that you'd rather not contribute to Axiom. You prefer
to create your own project to achieve your own goals. I have no
opinion about that except that there are some implications of that
choice.

I'd asked only one thing of anyone who created a fork. I'll ask again.
Please stop using the name Axiom, anywhere. Your fork does not support
the goals of the Axiom project or the Axiom community. It supports
your goals, whatever they may be. Trading on the name of the Axiom
effort is unwelcome.

Since you see fit not to contribute your work to the Axiom community
there doesn't seem to be much point in your use of Axiom resources.
You now have your own project. You can set up your own mailing list,
your own SVN, your own bug tracking, your own website. You can attract
anyone who wishes to contribute to your project. 

Good luck in your new venture. I wish you success.

\start
Date: Fri, 6 Jul 2007 09:49:45 -0700
From: Richard Harke
To: Camm Maguire
Subject: Re: Axiom ia64

On Tue July 3 2007 12:51, you wrote:
> Greetings!  Just wondering if you've made any headway on native object
> relocation for axiom on this platform.
>
> Take care,
Sorry. No progress. I'll try to take another look at this in the near future.
Richard

\start
Date: Fri, 06 Jul 2007 12:58:02 -0400
From: Camm Maguire
To: list
Subject: gcl inlining policy
Cc: Robert Boyer, Robert Dodier, Matt Kaufmann,

Greetings!  If you would be so kind, I'd appreciate some direction on
the desired inlining policy fro gcl 2.7.0.

GCL has always inlined certain functions, e.g. mapcar, member, etc.
Without this, performance would be noticeably worse.

Traditionally, this has been accomplished though ad-hoc 'c1 functions
in the compiler, or C-snippet inline attributes in cmpopt.lsp.  Thus
one had not only to write the function, but its inline support in the
compiler as well.  Support for these remain, but thanks to Boyer's
suggestion to carry the original source around in the image, automatic
inlining is now possible.  Support for this is in place in 2.7 with
notable improvements in performance.

The question is, what functions should be inlined by default?
Currently, symbols external to the lisp package are automatically
considered. Explicitly declared or declaimed functions are also.
inlining may decline if the inline is too large, using a heuristic
function using the *space* setting as input, though in many cases,
inlined code is smaller.  The real cost of inlining is compiler speed,
and tracing support.

Boyer recently posted a benchmark which would benefit greatly from
automatic inlining of user functions.

Separately, should inlining be allowed at safety 3?

\start
Date: Fri, 06 Jul 2007 13:03:56 -0400
From: Camm Maguire
To: list
Subject: gcl safety definition
Cc: Robert Boyer, Robert Dodier, Matt Kaufmann,

Greetings!  2.7 has a much faster safety mode.  I'd like to get some
consensus on how to define it.

Proposal:

safety 1 -- compiled functions and macros check their argument numbers
            and types

safety 2 -- inlined function calls in compiled functions and macros
	    check their argument numbers and types

safety 3 -- all variables and function args of type t, no source inlining, no
            branch-elimination, no type propagation.  fast-linking is
            still permitted.

Separately, which of these should be goverened as well by
compilation-speed and/or speed settings?

Separately, can GCL compilation be considered fast enough if GCL
proper is kept to a small fraction of gcc compilation time?

real time       :     71.680 secs
run-gbc time    :     15.810 secs
child run time  :     48.320 secs
gbc time        :      5.640 secs

\start
Date: Fri, 6 Jul 2007 12:09:16 -0500
From: Matt Kaufmann
To: Camm Maguire
Subject: Re: gcl inlining policy
Cc: Robert Boyer, Robert Dodier

Hi, Camm --

That's exciting that GCL, which is already the fastest Lisp I know of
for running ACL2, may become even faster!  Thank you.

I don't have any opinions about defaults or heuristics, but:

It might be *very* useful to have a user-settable special variable
that controls inlining.  I'm imagining that by default, ACL2 would
inline all built-in and user-defined function calls that GCL allows,
but that when one wants to trace, then it would be nice to be able to
rebuild with inlining turned down or off.

Thanks --
-- Matt
   cc: Robert Boyer, Matt Kaufmann,
	   Tim Daly, list,
	   Robert Dodier,
	   Maxima mailing list <Maxima@math.utexas.edu>
   From: Camm Maguire
   Date: Fri, 06 Jul 2007 12:58:02 -0400
   X-SpamAssassin-Status: No, hits=-2.5 required=5.0
   X-UTCS-Spam-Status: No, hits=-280 required0

   Greetings!  If you would be so kind, I'd appreciate some direction on
   the desired inlining policy fro gcl 2.7.0.

   GCL has always inlined certain functions, e.g. mapcar, member, etc.
   Without this, performance would be noticeably worse.

   Traditionally, this has been accomplished though ad-hoc 'c1 functions
   in the compiler, or C-snippet inline attributes in cmpopt.lsp.  Thus
   one had not only to write the function, but its inline support in the
   compiler as well.  Support for these remain, but thanks to Boyer's
   suggestion to carry the original source around in the image, automatic
   inlining is now possible.  Support for this is in place in 2.7 with
   notable improvements in performance.

   The question is, what functions should be inlined by default?
   Currently, symbols external to the lisp package are automatically
   considered. Explicitly declared or declaimed functions are also.
   inlining may decline if the inline is too large, using a heuristic
   function using the *space* setting as input, though in many cases,
   inlined code is smaller.  The real cost of inlining is compiler speed,
   and tracing support.

   Boyer recently posted a benchmark which would benefit greatly from
   automatic inlining of user functions.

   Separately, should inlining be allowed at safety 3?

\start
Date: 06 Jul 2007 13:19:22 -0400
From: Camm Maguire
To: Richard Harke
Subject: Re: Axiom ia64

Greetings!

Richard Harke writes:

> On Tue July 3 2007 12:51, you wrote:
> > Greetings!  Just wondering if you've made any headway on native object
> > relocation for axiom on this platform.
> >
> > Take care,
> Sorry. No progress. I'll try to take another look at this in the near future.
> Richard
> 

Thanks!  Do you have any refs to concise documentation for the
gcc-emitted reloc types?

\start
Date: Fri, 6 Jul 2007 12:20:05 -0500
From: Tim Daly
To: Camm Maguire
Subject: gcl inlining policy
Cc: Robert Boyer, Robert Dodier, Matt Kaufmann

The first issue is correct behavior but a second priority is clearly
speed. I'm not worried about compiler speed but the speed of the 
final generated code. At speed 3 all effort should be made to maximize
speed. If you have the original sources cached and can do compiler time
type propagation that's an even better win. Final execution speed of
Axiom is very important.

At safety 3 I'd expect no inlining and full type checking of arguments.
Choosing this setting I'm clearly more interested in catching bugs than
I am with speed. But I only use this setting while debugging.

As for space optimization I'm not sure it matters. I can't think of a
case where inlining will happen so many times that space is an issue.
Who writes a function with 50 mapcars? For space optimization it might
be better to throw away the cached sources.

\start
Date: 06 Jul 2007 13:21:51 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: debugging

Greetings!

Bill Page writes:

> On 06 Jul 2007 10:18:21 -0400, Camm Maguire wrote:
> > Greetings!  How does one enable lisp debugging in axiom, and get more
> > than
> >
> >    >> System error:
> >
> 
> ?? Do you mean gcl --enable-debug? I have previously used this option
> without an problems. Could you describe how and when you get this
> message? I will try to reproduce.
> 

This was in furthering the GCL 2.7/axiom test build -- I'm at the
truename/directory syntax step.  Already patched axiom-probe-file.

\start
Date: 06 Jul 2007 13:37:36 -0400
From: Camm Maguire
To: Bill Page
Subject: re: directory/truename transition
Cc: Gabriel Dos Reis

Greetings!

Bill Page writes:

> I understand your reluctance to spend much time learning windows
> specific API details. In spite of limited available time, I am willing
> to help with this where/when I can, but my only real experience is
> that gained while working with Mike Thomas for a few months a few
> years ago on the previous version Axiom on Windows. I do not think I
> know enough about either Windows or GCL internals.

Many thanks for the kind offer.  It is much appreciated.  I can step
you through any issue with GCL internals, as I did Mike Thomas when he
was first starting.  But I do not wish to lay too great a burden here
as I'm sure you are quite busy.

My proposal is as follows -- if you can help here it would be great!

1) help debug read-char-no-hang to satisfy Vadim on 2.6.8
2) test mkdir et.al. auxiliary directory functions for axiom possibly
   to be ported to 2.6.8.
3) generate a 2.6.8 installer.

4) ignore 2.7.0 for mingw until someone shows real interest in it, at
   which time I'd be most happy to help.  2.6.8 will always be there
   to suffice, and decoupling 2.7.0 from mingw will liberate
   development.   Who knows, with any luck, Windows itself will go the
   way of histories dustbin by the time this is ever an issue.

Take care,

> 
> > Now perhaps there is just a lower level api to which I could write
> > that would transparently be portable.  E.g. implementing directory via
> > readdir and opendir.  Re-implementing all the shell pattern matching
> > from scratch is certainly doable, but there should be some clear
> > benefit visible that would justify the work.  Its hard for me to see
> > at the moment.
> >
> 
> Some of these things might be available in an MSYS library but I do
> not know how accessible or adaptable to gcl it would be. In any case I
> seriously doubt that it would end up being "transparently portable".
> 
> > Please see related post regarding an extra-spec posix support function
> > proposal.
> >
> 
> Yes, I think that's good. Now we just need to find resources to help
> implement this for gcl-2.7 on windows. I am also a little worried that
> because of the extensive differences in 2.7 memory management and
> other deep changes, there may be some more issues besides the file
> system waiting to be discovered in the windows port. :-( Has anyone
> actually attempted to build gcl-2.7 on Windows yet?
> 

Mike Thomas did briefly, and the major issues were worked out at some
point.  But unless you know someone willing to put in the time at some
fraction of his level, I think the proposal above is the most sound.

\start
Date: Fri, 6 Jul 2007 11:55:06 -0700
From: Richard Harke
To: Camm Maguire
Subject: Re: Axiom ia64

On Fri July 6 2007 10:19, you wrote:
> Greetings!
>
> Richard Harke writes:
> > On Tue July 3 2007 12:51, you wrote:
> > > Greetings!  Just wondering if you've made any headway on native object
> > > relocation for axiom on this platform.
> > >
> > > Take care,
> >
> > Sorry. No progress. I'll try to take another look at this in the near
> > future. Richard
>
> Thanks!  Do you have any refs to concise documentation for the
> gcc-emitted reloc types?
>
The simple answer is no. I have the Intel docs but they are hardly concise. In 
fact one issue for me is the large number of relocs defined by Intel while
ld and dl-open support only a small number. likewise the loader in
Xorg/XFree86. If you know of any other refs, please let me know.
Richard

\start
Date: Fri, 06 Jul 2007 19:08:50 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: Re: defintrf.spad

Le jeudi 05 juillet 2007 =E0 12:41 -0500, Tim Daly a
=E9crit :
> Greg,
>
> Attached is a diff of defintrf. Waldek points out that this code
> change was due to a spad compiler bug.
>
> Is there a mailing list discussion on this?

No, I posted some times ago an url to a port of part of Axiom to
SBCL/Clisp/CMUCL. This patch comes from this port.

> Do you have the bad code.lsp file?

It is already buggy. Lisp load int/algebra/DFINTTLS.NRLIB/code.lsp and
try to read mapleok.input, you'll end up with an error: |dir| is not
bound. In fact |dir| is just a selector of a Record. The wrong Lisp
generated code is:

           (EXIT
            (COND (|incl?| |l|)
                  ('T
                   (SPADCALL
                    (CONS #'|DFINTTLS;findRealZero!1|
                          (VECTOR $ |dir| |endpoint| |i|))
                                    ^^^^^ ^^^^^^^^^^
|dir| and |endpoint| are not variables so they have nothing to do here.
There are apparently some collisions in the Spad compiler however when
the code is compiled with low level safety the execution seems correct,
in other words you can replace |dir| and |endpoint| with nil without
problem.


> This could cause problems elsewhere.
> I'd really like to find out why the compiler failed
> so we can fix the root cause of the problem.

Yes me too, it's on my TODO list but right now I haven't the time nor
the knowledge to fix it.

Greg

PS : If you apply this workaround please remove my name, I use it, among
others, to grep the code.

>
> Tim
>
> --- ../silver/src/algebra/defintrf.spad.pamphlet	2007-04-27 04:44:35.00=
0000000 -0400
> +++ wh-sandbox/src/algebra/defintrf.spad.pamphlet	2007-04-27 21:29:46.0=
00000000 -0400
> @@ -182,7 +182,10 @@
>            ["min"/[t.left for t in l], i.halfinf.endpoint]
>          l := [u::REC for t in l | (u := refine(p, t, bounds)) case=
 REC]
>          incl? => l
> -        select_!(keeprec?(i.halfinf.endpoint, #1), l)
> +        -- greg, FIXME dirty workaround
> +        -- select_!(keeprec?(i.halfinf.endpoint, #1), l)
> +        ep := i.halfinf.endpoint
> +        select_!(keeprec?(ep, #1), l)
>        error "findRealZero: should not happpen"
> 
>      checkBudan(p, a, b, incl?) ==

\start
Date: Fri, 6 Jul 2007 15:06:36 -0500
From: Matt Kaufmann
To: Raymond Toy
Subject: Re: [Maxima] gcl inlining policy
Cc: Robert Boyer, Robert Dodier, Camm Maguire

Good point; thanks!

-- Matt
   Date: Fri, 06 Jul 2007 13:36:39 -0400
   From: Raymond Toy
   CC: Camm Maguire, Robert Boyer, Robert Dodier,
	   gcl-devel@gnu.org, Tim Daly, Maxima@math.utexas.edu,
	   list
   X-OriginalArrivalTime: 06 Jul 2007 17:36:40.0324 (UTC) FILETIME=[360F3440:01C7BFF4]
   X-SpamAssassin-Status: No, hits=-2.6 required=5.0
   X-UTCS-Spam-Status: No, hits=-272 required0

   Matt Kaufmann wrote:
   > 
   > It might be *very* useful to have a user-settable special variable
   > that controls inlining.  I'm imagining that by default, ACL2 would
   > inline all built-in and user-defined function calls that GCL allows,
   > but that when one wants to trace, then it would be nice to be able to
   > rebuild with inlining turned down or off.

   Isn't this what (declaim (inline foo)) is supposed to do?  Granted, it's 
   tedious to specify this for every function foo that you want inlined, 
   but that seems to me the right thing to do too.  I can't imagine wanting 
   to inline every single function! :-)

\start
Date: Fri, 6 Jul 2007 22:48:29 +0200
From: Ondrej Certik
To: Camm Maguire
Subject: Re: directory/truename transition

> Greetings!
>
> Just update /etc/apt/sources.list accordingly and
>
> apt-get source axiom

Yes, but that is the one, which is already in Debian, which is old. I
meant the one we will be working on. Or do you have some private
repository?

\start
Date: Fri, 6 Jul 2007 14:21:44 -0700
From: Richard Fateman
To: Raymond Toy, Tim Daly
Subject: RE: [Maxima] gcl inlining policy
Cc: Robert Boyer, 'Robert Dodier' Robert Dodier, Matt Kaufmann

It seems to me that in-lining a function of any significant length is very
likely to be a mistake, though I suppose it depends on the memory cache
management.  If the in-lining is done to remove consing, then perhaps the
solution is to address the consing itself.  I don't know the exact
circumstances of the needed optimization, but if it is arithmetic-related,
perhaps this can be done by stack allocation of temporary numbers.  I
haven't tried timing of ACL2 in Allegro Common Lisp, but it might be
revealing to do so.  It is my understanding that Allegro mostly, if not
entirely, ignores inline declarations of user-defined functions.
I have been told that this was a deliberate decision after a careful
consideration of the semantic consequences of inlining to the CL standard
versus the expected gain in performance.

RJF


> -----Original Message-----
> From: maxima-bounces@math.utexas.edu 
> [mailto:maxima-bounces@math.utexas.edu] On Behalf Of Raymond Toy
> Sent: Friday, July 06, 2007 1:55 PM
> To: Tim Daly
> Cc: Robert Boyer; Camm Maguire; Robert Dodier; Matt 
> Kaufmann; Maxima@math.utexas.edu; list
> Subject: Re: [Maxima] gcl inlining policy
> 
> Tim Daly wrote:
> >> As for space optimization I'm not sure it matters. I can't 
> think of a
> > case where inlining will happen so many times that space is 
> an issue.
> > Who writes a function with 50 mapcars? For space 
> optimization it might
> > be better to throw away the cached sources.
> 
> Here is an example where there is LOTS of inlining.  CMUCL supports 
> double-double floats and has support for unboxed 
> double-double floats. 
> However, to make things fast, the code that implements the basic 
> arithmetic operations is inlined.  So the routine that 
> calculates log(x) 
> via rational approximation has inlined lots of routines, 
> perhaps 50 or 
> more arithmetic operations.  A double-double add takes about 
> 200 bytes. 
>   The space used is a lot.
> 
> I also have a quad-double implementation.  That is even 
> larger because a 
> quad-double operation is some 1K bytes long.  But if you don't inline 
> the basic arithmetic function and all the internal functions that are 
> needed to implement it, the consing slows down the operation by a 
> significant fraction (half or more?).  To make these inline, I had to 
> increase CMUCL's inlining threshold to 1600 (the  upper limit on the 
> number of inline function calls that will be expanded in any 
> given code 
> object).
> 
> Anyway, this is really way off topic for maxima, so I will 
> refrain from 
> saying more on this list.

\start
Date: 06 Jul 2007 20:29:39 -0400
From: Stephen Wilson
To: Gregory Vanuxem
Subject: re: defintrf.spad

Gregory Vanuxem writes:

> > This could cause problems elsewhere.
> > I'd really like to find out why the compiler failed
> > so we can fix the root cause of the problem.
> 
> Yes me too, it's on my TODO list but right now I haven't the time nor
> the knowledge to fix it.

Perhaps related to this issue:

An expression involving a `selector' such as i.j is parsed into the
form (|i| |j|), which, without further context provided by `in-scope
exports', looks just like any other function application.

This may not be the root cause of the bug per say, but I feel that
throwing away the information quantifying an expression as involving a
`selector' is a bug in and of itself, and fixing it may very well
solve the issue being discussed.


There are some other issues with the AST representation and its
processing which I would be happy to comment on if interested.

\start
Date: Fri, 6 Jul 2007 20:20:21 -0500
From: Tim Daly
To: Gregory Vanuxem, Stephen Wilson
Subject: defintrf.spad

I'm looking thru the sources to see if there are any other instances
of the problem. Hopefully we can isolate the compiler bug and fix it.

Greg, if you've found any other bugs of this type I'd be most interested.

\start
Date: 06 Jul 2007 22:16:14 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: defintrf.spad

I will look into the issue tonight and over the weekend as well.

I have come across a simlar issue in trying to get the algebra to
build with gclcvs-2.7.0.

In this case, the problem is in polycat.spad, FiniteAbelianMonoidRing,
around line 170.  We have:

    if R has IntegralDomain then
       x exquo r ==
          -- probably not a very good definition in most special cases
          zero? x => 0
          ans:% :=0
          t:=leadingCoefficient x exquo r
          while not (t case "failed") and not zero? x repeat
            ans:=ans+monomial(t::R,degree x)
            x:=reductum x
            if not zero? x then t:=leadingCoefficient x exquo r
          t case "failed" => "failed"
          ans

The compiler seems to fail in resolving the coercion of t to R in the
line:
            ans:=ans+monomial(t::R,degree x)

Giving t an explicit type `solves' the problem:

          t:=leadingCoefficient x exquo r
  ==>
          t : Union(R, "failed") := leadingCoefficient x exquo r


\start
Date: Fri, 6 Jul 2007 21:27:16 -0500
From: Tim Daly
To: Gregory Vanuxem, Stephen Wilson
Subject: defintrf.spad, polycat.spad

Is there a difference in the code.lsp file produced with 2.6.8 and 2.7.0
for polycat.spad?

\start
Date: Fri, 6 Jul 2007 22:40:43 -0400
From: Bill Page
To: list
Subject: NSF whitepaper on funding math software

At:

http://aida.homelinux.net/wordpress/2007/07/nsf-whitepaper-on-funding-math-software/

Didier writes:

"I'm all in favor for more funding for computer algebra research
(obvioulsy). Most funding of open-source/free computer algebra
research/development is funded (and hosted) by universities. This is
the case for SAGE, CoCoA, PARI. One notable excepion is AXIOM. It was
originally an IBM project and when it was open-sourced, it found
itself without a reliable source of funding. This is exactly the kind
of project that could benefit from some funding from the NSF."

\start
Date: 06 Jul 2007 22:48:23 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: defintrf.spad, polycat.spad

Tim Daly writes:

> Is there a difference in the code.lsp file produced with 2.6.8 and 2.7.0
> for polycat.spad?

The file refuses to compile unmodified under 2.7.0, so I cannot
compare unfortunately.  There may be options available to capture
intermediate data at key stages of compilation and compare the two
systems.  However, I am only now sitting down to try and figure out
the issues, and have yet to get a handle on a promising strategy.

\start
Date: 06 Jul 2007 23:17:15 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: defintrf.spad, polycat.spad

Tim Daly writes:

> Is there a difference in the code.lsp file produced with 2.6.8 and 2.7.0
> for polycat.spad?

A second thought tells me what you are asking.

At the moment, I do not have a tree built against 2.6.8pre as
available in Silver.  I have a tree built from the latest cvs checkout
of 2.6.8pre, which is quite different than that in Silvers zips.  In
addition, that tree was built in ANSI mode.

In this case, the original and modified spad results in different lisp
code.  Moreover, the differences are not `local' to the function in
question.

I fear the issues are deep and will take a long time to sort out, as
my main development work is getting Axiom to build under GCL with
--enable-ansi.  I have no idea what the generated lisp code looks like
under any other Lisp like SBCL.

I will build Silver tonight and maintain a `canonical tree' for
debugging purposes.  

\start
Date: Fri, 6 Jul 2007 22:40:05 -0500
From: Tim Daly
To: Gregory Vanuxem, Stephen Wilson
Subject: defintrf.spad, polycat.spad

Can you post the POLYCAT.nrlib/code.lsp file from ansi?
I can compare it against my tree.

\start
Date: 07 Jul 2007 00:00:03 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: defintrf.spad, polycat.spad

Tim Daly writes:

> Can you post the POLYCAT.nrlib/code.lsp file from ansi?
> I can compare it against my tree.

I am afraid that I am overtired after a days travel :(.

Looking at the code in more detail tells me that the `differences' are
minor.  Basically, the main change is that under my 2.6.8pre builds we
have copious (PROGN NIL ...) forms, whereas under 2.7.0 these forms
are lacking.  There does not appear to be a semantic difference here,
but I am in no condition to judge until I get a proper nights rest!

For example, in 2.6.8pre, cvs, for the category defaults
FAMR-.NRLIB/code.lsp:

(DEFUN |FAMR-;pomopo!;SRE2S;1| (|p1| |r| |e| |p2| $) (PROG NIL (RETURN (SPADCALL |p1| (SPADCALL |r| (SPADCALL (CONS (FUNCTION |FAMR-;pomopo!;SRE2S;1!0|) (VECTOR $ |e|)) |p2| (QREFELT $ 11)) (QREFELT $ 12)) (QREFELT $ 13)))))

In 2.7.0:

(DEFUN |FAMR-;pomopo!;SRE2S;1| (|p1| |r| |e| |p2| $) (SPADCALL |p1| (SPADCALL |r| (SPADCALL (CONS (FUNCTION |FAMR-;pomopo!;SRE2S;1!0|) (VECTOR $ |e|)) |p2| (QREFELT $ 11)) (QREFELT $ 12)) (QREFELT $ 13)))


And in particular, the code for exquo appears unchanged, save for
gensym names and so-called sharpsign-equal-sign designators.  My
builds are giving:


(DEFUN |FAMR-;exquo;SRU;8| (|x| |r| $) (PROG (#0=#:G1872 |ans| |t|) (RETURN (SEQ (COND ((SPADCALL |x| (QREFELT $ 30)) (CONS 0 (|spadConstant| $ 15))) ((QUOTE T) (SEQ (LETT |ans| (|spadConstant| $ 15) |FAMR-;exquo;SRU;8|) (LETT |t| (SPADCALL (SPADCALL |x| (QREFELT $ 31)) |r| (QREFELT $ 44)) |FAMR-;exquo;SRU;8|) (SEQ G190 (COND ((NULL (COND ((OR (QEQCAR |t| 1) (SPADCALL |x| (QREFELT $ 30))) (QUOTE NIL)) ((QUOTE T) (QUOTE T)))) (GO G191))) (SEQ (LETT |ans| (SPADCALL |ans| (SPADCALL (PROG2 (LETT #0# |t| |FAMR-;exquo;SRU;8|) (QCDR #0#) (|check-union| (QEQCAR #0# 0) (QREFELT $ 7) #0#)) (SPADCALL |x| (QREFELT $ 32)) (QREFELT $ 33)) (QREFELT $ 13)) |FAMR-;exquo;SRU;8|) (LETT |x| (SPADCALL |x| (QREFELT $ 34)) |FAMR-;exquo;SRU;8|) (EXIT (COND ((NULL (SPADCALL |x| (QREFELT $ 30))) (LETT |t| (SPADCALL (SPADCALL |x| (QREFELT $ 31)) |r| (QREFELT $ 44)) |FAMR-;exquo;SRU;8|))))) NIL (GO G190) G191 (EXIT NIL)) (EXIT (COND ((QEQCAR |t| 1) (CONS 1 "failed")) ((QUOTE T) (CONS 0 |ans|)))))))))))


I would be grateful if you can confirm the above is equivalent to
your tree.

\start
Date: Sat, 7 Jul 2007 00:08:46 -0400
From: Bill Page
To: Tim Daly
Subject: Re: friCAS

Tim,

I think your email to Waldek is grossly unfair and inaccurate. I think
Waldek (building on top of the work done by Gaby) has contributed more
to the Axiom project in the last 6 months than any other Axiom
developer has in the last 5 years Your claim that he would "rather not
contribute to Axiom" is ludicrous. I think it is clear from the axiom
developer email archive that Waldek initially did not "prefer to
create his own project", rather it seems obvious to me that the
creation of a separate project was entirely in response to actions and
statements made by you.

About the name "Axiom": I believe that the most accurate statement
would be that this name still "belongs" to NAG through the copyright
statement that NAG insisted on as part of the open source release. To
associate "Axiom" only with this particular open source project as you
have defined it, would be misleading and probably wrong. But of course
it would be inconvenient to have two projects with exactly the same
name so identifying itself as "FriCAS (AXIOM fork) Computer Algebra
System" seems entirely appropriate to me.

I disagree completely that Waldek's work "does not support the goals
of the Axiom community". Since I am a member of that community, I
resent your speaking in this manner. You are completely wrong when you
say Waldek "sees fit not to contribute his work to the Axiom
community". FriCAS is an open source project. Anyone interested in
Axiom is able to access and contribute to this work.

Waldek has already setup a separate project for FriCAS on SourceForge at:

http://sourceforge.net/projects/fricas

I am *very* disappointed that you apparently intend to force the
FriCAS project to remain separate from what you are calling the "Axiom
project". You seem to be unaware of the damage that you are causing.
And I fear that this might force people to "vote with their feet"
rather than collaborating in the manner that one expects in an open
source project. :-(

Bill Page.

On 7/6/07, Tim Daly wrote:
> Waldek,
>
> You've decided that you'd rather not contribute to Axiom. You prefer
> to create your own project to achieve your own goals. I have no
> opinion about that except that there are some implications of that
> choice.
>
> I'd asked only one thing of anyone who created a fork. I'll ask again.
> Please stop using the name Axiom, anywhere. Your fork does not support
> the goals of the Axiom project or the Axiom community. It supports
> your goals, whatever they may be. Trading on the name of the Axiom
> effort is unwelcome.
>
> Since you see fit not to contribute your work to the Axiom community
> there doesn't seem to be much point in your use of Axiom resources.
> You now have your own project. You can set up your own mailing list,
> your own SVN, your own bug tracking, your own website. You can attract
> anyone who wishes to contribute to your project.
>
>
> Good luck in your new venture. I wish you success.

\start
Date: Sat, 7 Jul 2007 01:37:37 -0500
From: Tim Daly
To: Bill Page
Subject: defintrf.spad, polycat.spad

Bill,

I understand how you feel. I had extensive conversations about that
email with several people. It was a carefully crafted statement.

Axiom is no longer an IBM project. It is no longer a NAG project.
It is an open source effort that names a particular savannah and
sourceforge project. When a project forks, the new project needs 
to choose a new name. Otherwise the Axiom project will have to deal
with bug reports, complaints, or other problems over which we have no
control. The "Axiom" name defines our effort and its goals.

Carnegie Mellon University Common Lisp (CMUCL) was a long running
project at CMU under Scott Fahlman. I communicated with that team
while at IBM because we used CMUCL. A fork was created to "improve"
CMUCL. That fork is known as Steel Bank Common Lisp (SBCL). Both works
still exist. Same initial code base, different goals, different name.




> I think your email to Waldek is grossly unfair and inaccurate. I think
> Waldek (building on top of the work done by Gaby) has contributed more
> to the Axiom project in the last 6 months than any other Axiom 
> developer has in the last 5 years Your claim that he would "rather not
> contribute to Axiom" is ludicrous. 

Define contribute. As I defined contribute, which I believe is the
common open source understanding, it involves creating patches
against the main line of work and publishing them. Show me patches.
I asked for a changeset for hyperdoc so the trunk would be fixed.
I see no changeset posted. That is a statement of fact which is not
"unfair and inaccurate".




> ... I think it is clear from the axiom
> developer email archive that Waldek initially did not "prefer to
> create his own project", rather it seems obvious to me that the
> creation of a separate project was entirely in response to actions and
> statements made by you.

As adults we accept responsibilities for our actions. I made the
statements that if you join a project but do not agree with the project
goals, if you create a separate branch and promote it above the main
trunk, and if you fail to publish your work back to the main trunk
then you are creating a fork, not contributing to the project. I stand
by those statements. I believe that several people on this list also
agreed that the Waldek branch looked like a fork. There were two
possible responses. Either contribute by posting patches for individual 
features or create a new project. 

Waldek chose to create a new project. I didn't "make him do anything".
I'm quite curious to see what the new project goals are. He is likely
to fill a gap "in the market" that we don't cover.  I harbor no hard
feelings about his choice. I wish him success.




> About the name "Axiom": I believe that the most accurate statement
> would be that this name still "belongs" to NAG through the copyright
> statement that NAG insisted on as part of the open source release.

Actually, you're wrong about that. First, the license clause never
mentions the word "Axiom" (see license/license.axiom or any file).
The license is a copyright issue, not a trademark issue.

Second, "Axiom" is a trademark issue, not a copyright issue. I had a
discussion with NAG about transferring the trademark. They did not
renew the trademark, at least in the U.S. NAG withdrew the product
from the market and thus their trademark has lapsed.

I paid for an attorney to discuss the trademark issue. I paid for a
trademark search.  I could apply for a trademark on the name Axiom in
the computer algebra area (there are many "Axiom" trademarks) but I'm
under no obligation. I can contest the attempt by anyone else to
trademark Axiom in computer algebra because I have been using the term
continuously and have the association. So in essence I have a common
law trademark on the term Axiom in the computer algebra area despite
it not being federally registered to me. It is quite expensive to
register a trademark and I don't feel like spending that much money
without cause. The actual comment is:

 "Federal registration is not required to establish rights in a
  trademark. Common law rights arise from actual use of a mark. 
  Generally, the first to either use a mark in commerce or file
  an intent to use application with the USPTO has the ultimate
  right to use and registration."

According to the attorney I believe I have the common law right
to assert that Axiom is an unregistered trademark associated with
me and this project. I have asked that it not be used by FriCAS.




> To associate "Axiom" only with this particular open source project
> as you have defined it, would be misleading and probably wrong.

Really? How curious. We've done it for years. Please explain.





> ... But of course
> it would be inconvenient to have two projects with exactly the same
> name so identifying itself as FriCAS (AXIOM fork) Computer Algebra
> System" seems entirely appropriate to me.

But it isn't appropriate. FriCAS is a separate project with different
goals and different code.  By using the Axiom name, the FriCAS code
will trade on the goodwill and extensive effort over the last 7 years
associate with the Axiom name. FriCAS needs to develop its own
goodwill, user base, mind share, developer team, bug reporting, user
set, web site, mailing lists, goals, policy statements, and all of the
other "non-code" portions of this project we've spent years
creating. A project is not "just code".





> I am *very* disappointed that you apparently intend to force the
> FriCAS project to remain separate from what you are calling the "Axiom
> project".

It *IS* a separate project. Check the sourceforge link you sent. 
I believe it has been officially started as a new project.
I didn't create it. Please stop trying to make it "my fault".
I have no association whatever with the FriCAS project.





> You seem to be unaware of the damage you are causing.

Damage? Bill, you seem to think *I* set up the site.  I simply asked
for the professional courtesy not to have the Axiom name associated
with this new project. We have all worked very hard to develop as "Axiom"
a project dedicated to developing correct, well-documented CAS with a 30
year horizon focus that can be the basis of computational mathematics
in the long term. This should NOT be associated with a project that
does not share those goals.

It's a simple request. Change all instances of Axiom to FriCAS.




> And I fear that this might force people to "vote with their feet"
> rather than collaborating in the manner that one expects in an open
> source project.

I stated what I believe is "the manner that one expects in an open
source project" as a means of collaboration. I participate in other
projects, lead other projects, and am on other project mailing lists.
I've been doing open source since the Pinger project in 1997.
I REGULARLY see diff-Naur patches. Several a week. People create a 
branch, develop a feature or fix, and post patches. They contribute.

I have no opinion about the choices other people make. It is perfectly
reasonable to participate in more than one project, even more than one
computer algebra project. I'm also a developer on Magnus, another
computer algebra system. And I started Doyen, which Jose has been
managing quite well for years. I have commit access to the
Common Lisp Cookbook project. People should feel free to participate
in FriCAS if they agree with the project goals. I haven't seen the
project goals so I cannot comment. But you seem to think this is an
"either-or" decision. It isn't.


But I do request one thing. Stop using Axiom in the FriCAS project,
if only as a matter of professional courtesy.


Tim



\start
Date: 07 Jul 2007 02:48:05 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: re: debugging

Greetings!

1) 'boot::|NRTassocIndex| (and others) calls elt on dotted lists of
   the form ('|domain| s . s), whereas the spec says elt must take a
   proper list.  elt is automatically inlined.

2) somewhere in boot (by the depsys stage),
   si::universal-error-handler is redefined to an old call sequence,
   breaking 2.7 error reporting.

Workaround --

SYSTEM>(eval `(defun elt ,@(cdr (subst 'sequence 'proper-sequence (function-src 'elt)))))

Warning: SIMPLE-WARNING: ELT is being redefined.
ELT

SYSTEM>(si::function-src 'elt)

(LAMBDA (SEQ N)
  (DECLARE (OPTIMIZE (SAFETY 1)))
  (CHECK-TYPE N SEQIND)
  (CHECK-TYPE SEQ SEQUENCE)
  (BLOCK ELT
    (BLOCK ELT
      (BLOCK ELT
        (LET ((Q 0) R)
          (IF (IF (LISTP SEQ)
                  (PROGN
                    (BLOCK ()
                      (LET ((L SEQ) (I 0))
                        (TAGBODY
                          #:G32678
                          (IF (NOT (OR (ENDP L) (>= I N)))
                              (PROGN
                                (TAGBODY)
                                (LET* ((#:G32679 (CDR L))
                                       (#:G32680 (+ I 1)))
                                  (SETQ L #:G32679)
                                  (SETQ I #:G32680)
                                  NIL)
                                (GO #:G32678))
                              (RETURN-FROM () (PROGN (SETQ Q I R L)))))))))
              (CAR R)
              (IF (IF (< N (SETQ Q (LENGTH SEQ))) (PROGN (SETQ R SEQ)))
                  (LET* ((#:G32681 R) (#:G32682 (THE SEQIND N)))
                    (COMPILER::CMP-AREF #:G32681 #:G32682))
                  (VALUES (ERROR 'TYPE-ERROR :DATUM N :EXPECTED-TYPE
                                 (LIST 'INTEGER 0 (LIST Q)))))))))))
NIL
ELT

SYSTEM>(compile 'elt)

;; Compiling /tmp/gazonk0.lsp.
; (DEFUN ELT ...) is being compiled.
;; Warning: arg type mismatch in auto-proclamation (PROPER-SEQUENCE
                                                    (INTEGER 0)) -> (SEQUENCE
                                                                     (INTEGER
                                                                      0))

;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=1 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk0.o.
;; Loading /tmp/gazonk0.o
 ;; start address -T 0x102e000 ;; Finished loading /tmp/gazonk0.o
#<compiled-function ELT>
NIL
NIL

SYSTEM>

Note the new debugging functions of interest:

(si::function-src 'symbol)
(si::file 'symbol)
(si::sig 'symbol)
(si::callers 'symbol)
(si::callees 'symbol)

compiled functions can also be disassembled and re-compiled without
redefining from source.

Can we please leave universal-error-handler alone?

Thanks for the report!

I'll try to get compiler::link to propagate the ambient setting of *disable-recompile*. 

Take care,


Waldek Hebisch writes:

> Camm Maguire wrote:
> > This was in furthering the GCL 2.7/axiom test build -- I'm at the
> > truename/directory syntax step.  Already patched axiom-probe-file.
> > 
> 
> I updated 2.7 from cvs and retried build.  gcl build now fine on
> and64 (but still does not install all files).  I am trying to set
> si::*disable-recompile* in the inital image, which is made via
> compiler:link, but it seems that this setting is lost -- I must
> set si::*disable-recompile* to t later.
> 
> After setting si::*disable-recompile* to t interpsys build fine.
> After change to axiom-probe-file first bootstrap stage works
> fine.  But in the second stage I am getting strange failure.
> 
> Top of the backtrace:
> 
>    compiling exported ~= : (S,S) -> Boolean
> 
> Error:
> Signalled by LAMBDA-CLOSURE.
> Condition in SYSTEM::CHECK-TYPE-SYMBOL [or a callee]: INTERNAL-SIMPLE-PROGRAM-ERROR: LAMBDA-CLOSURE [or a callee] requires more than one argument.
> 
> Broken at SYSTEM::CHECK-TYPE-SYMBOL.  Type :H for Help.
>  1 (Continue) supply a new value of SYSTEM::SEQ.
>  2 Return to top level.
> BOOT>>^MBOOT>>:bt
> ^M
> #0   CHECK-TYPE-SYMBOL {symbol=system::seq,value=(|domain| s . s),type=system::proper-sequence,type-str...} [ihs=123]
> #1   NRTassocIndex {loc0=(|Boolean|),loc1=|value|,loc2=(((# # # ...))),loc3=(((# # # ...))),loc4=ni...} [ihs=122]
> #2   NRTgetLocalIndex1 {loc0=(|Boolean|),loc1=nil,loc2=(|##1| (|BasicType|) nil),loc3=t,loc4=t} [ihs=121]
> #3   NRTgetLocalIndex {loc0=(|Boolean|)} [ihs=120]
> #4   genDeltaSig {loc0=(|Boolean|)} [ihs=119]
> #5   genDeltaEntry {loc0=(= (s (|Boolean|) s ...) (t (elt s #))),loc1=#\$} [ihs=118]
> 
> 
> I do not understand what 'system::seq' is doing here:  Axiom extensively
> uses SEQ macro which is defined in "VMLISP" package.  SEQ from system
> package should not be used here -- the axiom-lisp.lisp file tries to
> limit imports to symbols from "COMMON-LISP" package.
> 
> As usual, all this is on 64-bit Debian etch.

\start
Date: Sat, 7 Jul 2007 14:46:54 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: re: debugging

> Greetings!
> 
> 1) 'boot::|NRTassocIndex| (and others) calls elt on dotted lists of
>    the form ('|domain| s . s), whereas the spec says elt must take a
>    proper list.  elt is automatically inlined.
> 
> 2) somewhere in boot (by the depsys stage),
>    si::universal-error-handler is redefined to an old call sequence,
>    breaking 2.7 error reporting.
> 
> Workaround --
> 
> SYSTEM>(eval `(defun elt ,@(cdr (subst 'sequence 'proper-sequence (function-src 'elt)))))
> 

Thanks for finding this error.  Concerning si::universal-error-handler,
this is done by ancient code in spaderror.lisp.  wh-sandbox constains
code to handle errors using Ansi condition system, but for GCL I still
used old handler.  The patch below unconditionally switches error
handling to Ansi way (so it will probably break non-Ansi GCL).
The algebra build should work with no error handler present.

diff -u /home/s/test/tt/axiom2/wh-sandbox/src/interp/bookvol5.pamphlet wh-sandbox/src/interp/bookvol5.pamphlet
--- /home/s/test/tt/axiom2/wh-sandbox/src/interp/bookvol5.pamphlet	2007-06-13 03:16:18.000000000 +0200
+++ wh-sandbox/src/interp/bookvol5.pamphlet	2007-07-07 14:00:38.000000000 +0200
@@ -682,9 +682,6 @@
   (setq |$currentLine| nil)
   (restart0)
   (|readSpadProfileIfThere|)
-  #+(or :GCL :CCL)
-  (|spad|)
-  #-(or :GCL :CCL)
   (handler-bind ((error #'spad-system-error-handler))
      (|spad|))
 )
diff -u /home/s/test/tt/axiom2/wh-sandbox/src/interp/spaderror.lisp.pamphlet wh-sandbox/src/interp/spaderror.lisp.pamphlet
--- /home/s/test/tt/axiom2/wh-sandbox/src/interp/spaderror.lisp.pamphlet	2007-06-14 14:45:05.000000000 +0200
+++ wh-sandbox/src/interp/spaderror.lisp.pamphlet	2007-07-07 13:59:59.000000000 +0200
@@ -48,14 +48,14 @@
 
 ;; this files contains basic routines for error handling
 (in-package "BOOT")
-
+#|
 #+(or :GCL :CCL)
 (defun error-format (message args)
   (let ((|$BreakMode| '|break|))
     (declare (special |$BreakMode|))
    (if (stringp message) (apply #'format nil message args) nil)))
+|#
 
-#-(or :GCL :CCL)
 (defun error-format (c)
   (let ((|$BreakMode| '|break|))
     (declare (special |$BreakMode|))
@@ -79,6 +79,7 @@
 
 ;; following macro evaluates form returning Union(type-of form, "failed")
 
+#|
 #+:GCL
 (defmacro |trapNumericErrors| (form)
   `(let ((|$oldBreakMode| |$BreakMode|)
@@ -87,8 +88,8 @@
      (setq val (catch '|trapNumerics| ,form))
      (if (eq val |$numericFailure|) val
        (cons 0 val))))
+|#
 
-#-(or :GCL :CCL)
 (defmacro |trapNumericErrors| (form)
     `(handler-case (cons 0 ,form)
          (arithmetic-error () |$numericFailure|)))
@@ -99,7 +100,6 @@
 ;;      (setq val (errorset ,form))
 ;;      (if (NULL val) |$numericFailure| (cons 0 (car val)))))
 
-#-(or :GCL :CCL)
 (defun spad-system-error-handler (c)
   (block nil
     (setq |$NeedToSignalSessionManager| T)
@@ -115,7 +115,7 @@
                    (throw '|letPrint2| nil))))))
         
 
-
+#|
 ;; the following form embeds around the akcl error handler
 #+:GCL
 (eval-when
@@ -148,7 +148,7 @@
 		(apply system:universal-error-handler type correctable? op
 		       continue-string error-string args )))))
 
-
+|#
 
 
\start
Date: 07 Jul 2007 16:38:25 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: friCAS

Tim Daly writes:

> I'd asked only one thing of anyone who created a fork. I'll ask again.
> Please stop using the name Axiom, anywhere. Your fork does not support
> the goals of the Axiom project or the Axiom community. It supports
> your goals, whatever they may be. Trading on the name of the Axiom
> effort is unwelcome.

This is simply not true, unless you don't consider myself as part of the
community. In that case, I'll stop contributing to "your" axiom project today.

I find it quite strange that you identify your goals with the goals of the
axiom community.  If you do not answer, and retract this statement (sentence 3
of the quote above), I will quit, although with a bleeding heart.

This is unnegotiable for me.

\start
Date: Fri, 06 Jul 2007 13:36:39 -0400
From: Raymond Toy
To: Matt Kaufmann
Subject: Re: [Maxima] gcl inlining policy
Cc: Robert Boyer, Robert Dodier, Camm Maguire

Matt Kaufmann wrote:
> 
> It might be *very* useful to have a user-settable special variable
> that controls inlining.  I'm imagining that by default, ACL2 would
> inline all built-in and user-defined function calls that GCL allows,
> but that when one wants to trace, then it would be nice to be able to
> rebuild with inlining turned down or off.

Isn't this what (declaim (inline foo)) is supposed to do?  Granted, it's 
tedious to specify this for every function foo that you want inlined, 
but that seems to me the right thing to do too.  I can't imagine wanting 
to inline every single function! :-)

\start
Date: Fri, 06 Jul 2007 16:55:28 -0400
From: Raymond Toy
To: Tim Daly
Subject: Re: [Maxima] gcl inlining policy
Cc: Robert Boyer, Robert Dodier, Matt Kaufmann

Tim Daly wrote:
>> As for space optimization I'm not sure it matters. I can't think of a
> case where inlining will happen so many times that space is an issue.
> Who writes a function with 50 mapcars? For space optimization it might
> be better to throw away the cached sources.

Here is an example where there is LOTS of inlining.  CMUCL supports 
double-double floats and has support for unboxed double-double floats. 
However, to make things fast, the code that implements the basic 
arithmetic operations is inlined.  So the routine that calculates log(x) 
via rational approximation has inlined lots of routines, perhaps 50 or 
more arithmetic operations.  A double-double add takes about 200 bytes. 
  The space used is a lot.

I also have a quad-double implementation.  That is even larger because a 
quad-double operation is some 1K bytes long.  But if you don't inline 
the basic arithmetic function and all the internal functions that are 
needed to implement it, the consing slows down the operation by a 
significant fraction (half or more?).  To make these inline, I had to 
increase CMUCL's inlining threshold to 1600 (the  upper limit on the 
number of inline function calls that will be expanded in any given code 
object).

Anyway, this is really way off topic for maxima, so I will refrain from 
saying more on this list.

\start
Date: Sat, 7 Jul 2007 13:49:00 -0500
From: Tim Daly
To: Martin Rubey
Subject: Axiom community goals

Martin,

> This is simply not true, unless you don't consider myself as part of the
> community. In that case, I'll stop contributing to "your" axoim project
> today.

> I find it quite strange that you identify your goals with the goals of the
> axiom community. 

You do agree that the Axiom community has goals, right?
FriCAS will, and I'm interested to see what they are.

Some of those Axiom goals were defined when the project created, for
example, the goals of correct code, to try to prove programs correct,
and to make the code literate. The Axiom code was released by me as
literate code, not raw code. Thus I defined SOME of the community goals.

Other goals, driven by other people, have arisen over time and they
are compatible. For example, the ALLPROSE effort by Ralf and the drive
to include Aldor by many people. Stephen Wilson is working toward a
new compiler it appears. Bill Page has urged and Gaby has implemented
autoconf. Silver is in SVN.  Cliff has been working on ways to make
Axiom have a native understanding of literate documents. Cliff has
also volunteered to consider a new versioning scheme.  These efforts
are ongoing and have contributed to the breadth and depth of the
project.  They are in no way dividing the group.

However, I find these other events divisive and troubling:

Quoting from:
<http://lists.gnu.org/archive/html/axiom-developer/2007-06/msg00535.html>

Martin: At least here in Austria, most people use wh-sandbox

Cliff: Now, that's true. Eventually, we should reach the point where
       users should be using Gold by default

Martin: Cliff, please stop thinking about the future. Well, one month 
        is OK, but certainly not *now*. ...

Here I see Cliff explicitly supporting two fundamental project goals,
the notion that the Gold version should be the default and the idea
that changes will migrate there. I also see you explicitly state that
Cliff should ignore a fundamental, 30 year horizon view. You then
continue on this exchange with

Martin: .... If you want to implement a versioning scheme, please
        implement one that works with the current situation.
        If you implement one that works for Gold only, forget it.

I find this an odd attitude. If GCL implemented a versioning scheme
that worked for the main trunk but not in a developer sub-branch
you would reject the scheme? 

So I read from the above that if it isn't done by next month or if it
doesn't work in Waldek's branch it isn't worth doing? I will grant you
the point that this "arises from the community" but I hardly see how
this is compatible with the overall project goals. Not every idea
"from the community" is in harmony with the project goals.




Quoting from:
<http://lists.gnu.org/archive/html/axiom-developer/2007-06/msg00399.html>

Jose: Virtual machine http://wiki.axiom-developer.org/DoyenCD (Axiom Gold)

Martin: Hm, but didn't you have a live cd of wh-sandbox also? That's
        much better than Gold, since HyperDoc doesn't really work in
        Gold (dependents, users, etc. crash.)

I'm puzzled why you would ask Jose to do additional work to support
wh-sandbox rather than ask Waldek to hurry up and promote his changes
to the latest trunk. The fact that 
  (a) HyperDoc crashes and 
  (b) Waldek knows how to fix it and 
  (c) we all need those fixes 
all seem to suggest that making a diff-Naur patch available would be
"a good thing". Yet you seem to promote a branch and ask another 
project (Doyen) to support it.



Quoting from:
<http://lists.gnu.org/archive/html/axiom-developer/2007-06/msg00318.html>

Martin: I think, the easiest way to put off people is to discuss what
        great things one will do in the future.

Again you seem to feel that it is unreasonable for us to think or plan
or discuss ideas that are not done by next month. I understand that
you wish to use this work in your classroom and I understand that such
a goal involves a september deadline. I've taught at several schools
so I know the intense pressure. You seem to have lost sight of the 30
year horizon, which is fine. However, chastizing others for trying to
consider things that don't fit your timeframe seems like you're
elevating your needs above the group.

Unlike work, I'm unaware of any deadlines on this project. Things get
done when they get done. It is more important to do it right than it
is to do it fast, at least on this project. For instance,
defintrf.spad has a code sequence that uncovers a compiler bug. The
wh-sandbox branch patches the algebra code to ignore the bug rather
than find the root cause. It seems more important to fix the compiler
so future algebra cannot make the same mistake. This will take more
time but seems to be the correct fix. It is ok to patch a branch but
the trunk should "do it right".

The future is important, it affects today's decisions, and we need
to discuss it.



Quoting from:
<http://lists.gnu.org/archive/html/axiom-developer/2007-06/msg00308.html>

Martin: Use the tools at hand and build something that can actually compete
        with current CAS (plural). We fight with the future and haven't even
        reached the present.

I'd urge you to re-read my response which I won't repeat here. I would
point out that we're going in long term directions different from
other efforts. Perhaps FriCAS can fulfill the "competition" need. To
try to compete with MMA you need to write half-a-hundred
workbook/textbook treatments. You need to convince department heads to
mandate using Axiom. You need to have super-spiffy front-ends. NAG did
not succeed in that competition and I doubt we could do any
better. They had the reputation, the contacts, the company, the money,
and the motivation.  Competition is not an Axiom project goal, at
least not in the direct sense and not in the short term. We'll simply
change the playing field and let them try to catch us.

"A wise general wins a war without fighting a battle" -- Sun Tzu




Quoting from:
<http://lists.gnu.org/archive/html/axiom-developer/2007-06/msg00310.html>

Martin: We need (good) contributors now. I'm working quite hard on that.

I fully agree we need good contributors. Please define what YOU mean by
contributing to the project. I've already said what I feel it means to
contribute to an open source project, which I believe is the generally
accepted definition.

Martin: But I tell you, if we are still less than 20 contributors end 
        of next year, I'll probably  stop with Axiom. 

I sent a quote
<http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00019.html>
from Chris DiBona, et. al. in the Open Sources 2.0 book that points out
that Brooks' Law appears to set a limit of about 10 people. So it is 
unlikely we will have 20 people.



I've seen you make the comment that "you'll quit if ..." on various
occasions. There is nothing anyone can do about that except you.
I'd urge you to stay. We do need you.




Martin, I find that you've done some excellent work for the project.
You've done valuable work with the Emacs effort, along with Cliff and
others. That's quite useful.

You've contributed algebra to the project. It got merged into wh-sandbox
(which is certainly why you find that branch personally interesting).
I've asked for a diff-Naur patch for that extension so it could be used
on the trunk. Your response was to ask Waldek. Waldek did not post a 
patch. I have a local git branch where I'm looking at merging the code.
Yet when I asked you for test cases and further documentation I did
not get any. Since I don't understand the algebra how can I tell if it
works? 

Contributing does not stop when the code is "done". It should not fall
solely on my desk to "make it work", "test it", or "document it". The
fact that you can make it work doesn't mean others can. The fact that
it works in a branch should only give you cause to ask that it be
promoted to the trunk. Holding a branch that includes your code up as
"the best way to go" misses the point of branching in the first place.
I'm surprised you didn't insist on seeing a patch created.




Like Waldek, you can make a choice to continue with Axiom or not.
You can contribute to both Axiom and FriCAS, it isn't "either-or".
But whatever your choice, it is entirely up to you.

Tim

\start
Date: 07 Jul 2007 15:01:34 -0400
From: Camm Maguire
To: Gernot Hueber
Subject: Re: gcl-2.7.0 on FreeBSD

Greetings!  OK, though not fully tested yet, I think bsd will build
now.  I've taken out the fast libc functions in mnum as freebsd does
not seem yet to support the c99 complex math function spec.  Perhaps
we could detect this with configure.  The conditional is #+c99.

Please let me know if problems persist, as they might at this point.

Take care,

Gernot Hueber writes:

> Dear Camm,
> 
> Sorry again: I missed a very detail "dlsym *".
> 
> Thanks for your patience with me.
> 
> Best regards,
> 
> Gernot
> 
> On Tue, 2007-07-03 at 10:26 -0400, Camm Maguire wrote:
> > Greetings!  Could you please post the results of the following?
> > (note the saved_pre_gcl which should be in your unixport directory.)
> > 
> > 
> >  ./saved_pre_gcl
> > GCL (GNU Common Lisp)  2.7.0 CLtL1  profiling  Jun 28 2007 16:12:35
> > Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
> > Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
> > Modifications of this banner must retain notice of a compatible license
> > Dedicated to the memory of W. Schelter
> > 
> > Use (help) to get some basic information on how to use GCL.
> > 
> > Temporary directory for compiler files set to /tmp/
> > 
> > >(si::dlopen "libm.so")
> > 
> > 1074447640
> > 
> > >(si::dlsym * "fabs")
> > 
> > 1094144096
> > 
> > >(si::dlsym 0 "fabs")
> > 
> > 1094144096
> > 
> > >
> > 
> 
> 
> > maxwell# ./saved_pre_gcl
> GCL (GNU Common Lisp)  2.7.0 CLtL1    Jul  2 2007 23:15:12
> Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> 
> Temporary directory for compiler files set to /tmp/
> 
> >(si::dlopen "libm.so")
> 
> 538370304
> 
> >(si::dlsym * "fabs")
> 
> Error: ERROR "dlsym lookup failure on \"fabs\""
> Signalled by SYSTEM:DLSYM.
> ERROR "dlsym lookup failure on \"fabs\""
> 
> Broken at SYSTEM:DLSYM.  Type :H for Help.
> >>(si::dlsym 0 "fabs")
> 
> 539365344
> >>
> 
> > I think the dlopen/dlsym C semantics are likely different on your
> > system.  If you have a manpage for each and can post these, that would
> > be terrific.
> > 
> > Take care,
> > 
> > 
> > Gernot Hueber <ghue@hueber.cc> writes:
> > 
> > > Hi,
> > > 
> > > Thanks for your great help. But still no luck. I added "-lm" to as many
> > > makefiles/makedeps, but missed the proper place ...
> > > Can you advice.
> > > 
> > > Thanks.
> > > 
> > > Gernot
> > > 
> > > 
> > > On Mon, 2007-07-02 at 22:54 +0200, Gernot Hueber wrote:
> > > > Dear Camm,
> > > > 
> > > > 
> > > > On Mon, 2007-07-02 at 11:35 -0400, Camm Maguire wrote:
> > > > > Greetings!
> > > > > 
> > > > > Gernot Hueber writes:
> > > > > 
> > > > > > Dear Camm,
> > > > > > 
> > > > > > On Thu, 2007-06-28 at 23:08 -0400, Camm Maguire wrote:
> > > > > > > Greetings!
> > > > > > > 
> > > > > > > Gernot Hueber writes:
> > > > > > > 
> > > > > > > > Dear Camm,
> > > > > > > > 
> > > > > > > > I have removed all notes on dyn.lib loading until gcl-2.7.0 is running.
> > > > > > > > Well, gcl still does build. See some snippets below.
> > > > > > > > 
> > > > > > > 
> > > > > > > OK
> > > > > > 
> > > > > > Thanks for your update, One more error, I cannot explain?! See below 
> > > > > > 
> > > > > > > 
> > > > > > <error snippet>
> > > > > > ;; Finished compiling ../lsp/gcl_numlib.o.
> > > > > > real time       :      2.000 secs
> > > > > > run-gbc time    :      0.813 secs
> > > > > > child run time  :      0.469 secs
> > > > > > gbc time        :      0.672 secs
> > > > > > ;; Compiling ../lsp/gcl_mnum.lsp.
> > > > > > 
> > > > > > Error: ERROR "dlsym lookup failure on \"fabs\""
> > > > > > Fast links are on: do (si::use-fast-links nil) for debugging
> > > > > > Signalled by DLSYM.
> > > > > > ERROR "dlsym lookup failure on \"fabs\""
> > > > > > 
> > > > > 
> > > > > Is there no symbol "fabs" in libc on your system?  nm --dynamic
> > > > > /lib/libc.so | grep abs
> > > > 
> > > > 
> > > > > maxwell# nm --dynamic /usr/lib/libc.so | grep abs
> > > > 00025164 T abs
> > > > 00033fe0 T fabs
> > > > 00023758 T imaxabs
> > > > 00025144 T labs
> > > > 000235a8 T llabs
> > > > 
> > > > >From the man page, fabs is in libm? At the moment I am looking for the
> > > > right makefile/makedefs for adding -lm.
> > > > 
> > > > Best regards,
> > > > 
> > > > Gernot
> > > > 
> > > > > 
> > > > > Take care,
> > > > > 
> > > > > > Broken at DLSYM.  Type :H for Help.
> > > > > > SYSTEM>>gmake: *** [unixport/saved_gcl] Error 255

\start
Date: Sat, 07 Jul 2007 20:39:00 +0100
From: Mark Murray
To: Camm Maguire
Subject: re: [Gcl-devel] Re: gcl-2.7.0 on FreeBSD 

Camm Maguire writes:
> Greetings!  OK, the bsd issues are almost ironed out.
>
> GCL has made extensive use of unboxed complex arithmetic.  Does BSD
> have this function somewhere?
>
> Error: ERROR "dlsym lookup failure on \"cexpf\": \"Undefined symbol
> \\\"cexpf\\\"\"" Fast links are on: do (si::use-fast-links nil) for
> debugging

No :-(.

And this annoys me, because I'm going to need to do lots of complex
arithmetic fairly soon.

I'll probably end up writing a complex library; can you make do with
something else in the meanwhile?

\start
Date: Sat, 7 Jul 2007 22:52:06 +0200
From: Juergen Weiss
To: Tim Daly
Subject: RE: Axiom community goals

Tim,

in my opinion the Axiom community consists of the people
interested in Axiom as users or developers and taking part
in the discussions on the Axiom-developer mailing list.
Their goals are certainly quite diverse. It is a gross
error to equate their goals with your goals which you described
several times in detail.

I would for example guess that besides you there are not more
than one or two others who believe in literate programming
in general and have made any substantial contribution during
the last years. And if it comes to literate programming as
executed in the project I wonder if there are more than zero.

I would assume that most people on the list did not openly
question your goals in respect for your work and your dedication
to the Axiom project. But you should not assume that
your goals are their goals.

\start
Date: Sat, 7 Jul 2007 23:34:06 +0200 (CEST)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: FriCAS
Cc: Bill Page

> Define contribute. As I defined contribute, which I believe is the
> common open source understanding, it involves creating patches
> against the main line of work and publishing them. Show me patches.
> I asked for a changeset for hyperdoc so the trunk would be fixed.
> I see no changeset posted. That is a statement of fact which is not
> "unfair and inaccurate".
> 

First step to get working hyperdoc is to put correct files in correct
places -- this is a Makefile change.  Original patches were done
with respect to build-improvements.  To make search for
constructors working one needs libdb.text:

http://lists.nongnu.org/archive/html/axiom-developer/2006-10/msg00530.html
http://lists.nongnu.org/archive/html/axiom-developer/2006-10/msg00549.html

(this patch is included in build-improvements).  

One also needs USES and DEPENDENTS info:

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

To see graphics examples one needs to adjust paths to viewports, 
part of this adjustment is done in 2006-10/msg00530.html mail.

There are few other patches.  If you want "full" solution you
need large part of wh-sandbox, because some path adjustments are
done at the time when .pht pages are generated.  In turn to generate
.pht pages you need a bunch of bug fixes and support in Makefiles.
Also wh-sandbox thanks to autoconf can detect and use 'openpty'
function.

The fixes presented in mails above are easy to port to gold.  Why
I have not ported them?  Well, if you look carefully you will
notice that the patch in '2006-10/msg00549.html' is with respect
to silver, which at that time was the best approximation to gold
which were publically visible.  This patch is still not
included in silver...

Also, the patches involve path adjustments, I you adjust patches
to old directory layout you will have to adjust them again when
switching to new layout.  So IMHO the logical thing to do is
to first have new Makefiles and new directory layout is silver
and than merge hyperdoc changes.  Doing things in opposite order
only makes sense if you do not want to adapt new directory layout.

\start
Date: 08 Jul 2007 01:10:01 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: Axiom community goals

Tim Daly writes:

> Martin,
> 
> > This is simply not true, unless you don't consider myself as part of the
> > community. In that case, I'll stop contributing to "your" axoim project
> > today.
> 
> > I find it quite strange that you identify your goals with the goals of the
> > axiom community. 
> 
> You do agree that the Axiom community has goals, right?

Yes, but I do not agree that you set the goals unilaterally, and I do not agree
that you decide unilaterally the path how these goals are reached.

I believe, so far I'm roughly one out of two who contributed documentation.

You did not retract your statement, so I guess I'll quit.

\start
Date: Sat, 7 Jul 2007 18:54:20 -0500
From: Tim Daly
To: Juergen Weiss
Subject: Axiom community goals

Having spend nearly 2 hours drafting a reply I've erased it.
Each of these replies takes hours to draft and craft.

I've tried to make the dirt-obvious point about diff-Naur patching.
Either you get it or you don't.  I give up. Contribute. Don't
contribute. Do whatever you like.  Believe whatever you like. 
Join. Leave. Have a grand time.

I'm going back to tracking a compiler bug. 
I will no longer respond to non-technical emails.

\start
Date: Sat, 7 Jul 2007 18:56:06 -0500
From: Tim Daly
To: Stephen Wilson
Subject: defintrf.spad compiler bug

I've identified 592 potential places where this could occur.
Obviously it does not happen everywhere. I'm reviewing each
code sequence to try to find the nature of the failure.
After that I'll look into the compiler.

\start
Date: Sun, 08 Jul 2007 02:03:29 +0200
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: re: FriCAS
Cc: Bill Page

Hi,

I must say, I don't like all this discussion about patches sent to the 
list or not. It is not about agreeing or not agreeing to the Axiom 
project goals. (BTW, what is the right way to come from 
http://www.axiom-developer.org to a page that describes these goals?)

Note that it took so long until we finally arrived at Silver being the 
Gold-to-be and living in sourceforge axiom trunk. That we agreed on 
Silver=trunk appeared only recently. From then on patches can be against 
the latest trunk. (I never understood why it should be patches against 
Gold.)

Anyway, I believe (and I am probably right) that the branching (which 
started with build-improvements and then wh-sandbox) without sending 
patches (against gold) to the list was because these patches would 
disappear into a (formerly hidden gold-to-be). Up to the day when Tim 
showed his gold-to-be, everyone had to go through the mailing list and 
apply the patches to gold himself to arrive at (nearly) the same version 
that Tim did not want to show. A complete waste of time.

Now gold-to-be=silver=trunk is in the open and developer knows about the 
hottest and latest development. That is good. In my eyes sending patches 
is about to begin. Gaby is preparing. But note, we had no open silver 
(but rather two or three unofficial ones). This chaos has stopped me 
from actually opening a doc-improvements branch. And I will not start 
contributing any code until I see a development model I understand and 
which seems efficient to me.

Sure, it's my decision. But I consider myself new and unexperienced to 
big open source projects. It is really not easy to understand what is 
going on with Axiom. Maybe some people think that it is completely clear 
to every one on the list what it means to "send a diff -Naur patch". 
Nice attitude, but it doesn't decrease the hurdle for new contributors.

\start
Date: Sun, 08 Jul 2007 02:03:45 +0200
From: Ralf Hemmecke
To: Juergen Weiss
Subject: Re: Axiom community goals

On 07/07/2007 10:52 PM, Weiss, Juergen wrote:
> Tim,
> 
> in my opinion the Axiom community consists of the people
> interested in Axiom as users or developers and taking part
> in the discussions on the Axiom-developer mailing list.
> Their goals are certainly quite diverse. It is a gross
> error to equate their goals with your goals which you described
> several times in detail.

Quite right. Actually, out of my head I only know that Axiom should be 
one day a super CAS, well documented by pamphlets and a system that can 
be extended by drag&drop.

I can agree with that. But I don't agree that Axiom should be developed 
by 4 or 5 people. One way to achieve the above mentioned goals is to 
attract more developers. Oh yes, and I believe in order to achieve the 
"Axiom goals" in 30 years, it would be temporarily wise to relax some 
goal like requiring 100% perfect documentation. Look at the code today. 
That are syntactically correct pamphlets, but most of them are nothing 
than actual code files. I say it again, There will never be anything as 
nice as you (Tim) dream of if only 4 developers do it. Axiom desparately 
needs more manpower. That is not a goal. That is a way to achieve the dream.

> I would for example guess that besides you there are not more
> than one or two others who believe in literate programming
> in general and have made any substantial contribution during
> the last years. And if it comes to literate programming as
> executed in the project I wonder if there are more than zero.

Oh, sorry. I now believe in literate programming. And I am grateful to 
Tim that he has repeated that its importance again and again. No LP 
should not be sacrificed as the longterm goal of Axiom. However, as most 
people feel, it is not the easiest task to write a literate program. 
There is no guideline how it should be done. It is an experiment to see 
how good LP can be applied to a living community project.

> I would assume that most people on the list did not openly
> question your goals in respect for your work and your dedication
> to the Axiom project. But you should not assume that 
> your goals are their goals.

It's not about questioning the goals. But I have the impression that one 
person has set the goals and the only choise I have is:
a) follow the goals strictly,
b) leave the project.
Nothing completely fits for me. Poor me.

\start
Date: Sun, 08 Jul 2007 02:04:03 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Axiom community goals

Dear Tim,

very professionally did you quote Martin. Do you also see that the whole 
discussion involves emotions even if you never wanted them involved?

It is not about being right or wrong. We know that different people on 
this list have different goals. Cannot we just accept that and go on in 
the interest of Axiom?

\start
Date: 07 Jul 2007 20:09:31 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: defintrf.spad compiler bug
Cc: list

Tim Daly writes:

> I've identified 592 potential places where this could occur.
> Obviously it does not happen everywhere. I'm reviewing each
> code sequence to try to find the nature of the failure.
> After that I'll look into the compiler.

Im looking at a possible solution, but I am waiting on a build.  I
cannot say at this point if it is workable. 

In short, Im experimenting with querying the environment in
compiler.boot:compWithMappingMode and trying to determine the proper
logic which can reliably mark an identifier as denoting a Record
field.  If this is workable, then I belive that within the same
function we could choose to emit these labels as quoted symbols.

In fact, I am first trying a more general approach first -- If the
identifier does not have a mode in the current environment, assume the
identifier is not bound and quote it.  I hope to refine this if I can
show the basic approach is valid.

\start
Date: Sat, 7 Jul 2007 19:33:09 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: How to create and post a diff-Naur patch

Ralf,

> ... Maybe some people think that it is completely clear
> to everyone on the list what it means to "send a diff -Naur patch"

1) Take a file, say integer.spad.pamphlet
2) Edit the file and save the changed file as integer.spad.pamphlet.ralf
3) diff -Naur integer.spad.pamphlet integer.spad.pamphlet.ralf >integer.patch
4) cat integer.patch | mail -s "integer.patch" list

When you receive a patch, you can say:
1) patch <integer.patch
and it will change integer.spad.pamphlet to include the new changes.

Since the original file is literate the patched file is literate.

\start
Date: 07 Jul 2007 22:59:18 -0400
From: Stephen Wilson
To: Stephen Wilson
Subject: Re: defintrf.spad compiler bug

Tim,

A further update:

My initial experiment appears to work, but it may not be the proper
fix (build still pending, at layer 20 ATM).

This is my analysis thus far.  I belive I have come to a decent theory
as to how this issue can be solved.  Please bear with me as I try to
explain.

In buildom.boot, mkUnionFunList, we have:

	     cdownFun() ==
	       gg:=GENSYM()
	       if p is ['EQCAR,x,n] then
		  ref:=['QCDR,gg]
		  q:= ['QEQCAR, gg, n]
	       else
		  ref:=gg
		  q:= substitute(gg,"#1",p)
	       ['XLAM,["#1"],['PROG2,['LET,gg,"#1"],ref,
		    ['check_-union,q,t,gg]]]


In particular note the variable t.  It is bound to an element of
listOfEntries, which represents the various types of branches in a
Union.

Note that in check-union (macros.lisp), the second argument is used
for error message only (expands into a call to coerce-failure-msg,
again macros.lisp).

Now, t is a sexp denoting a type.  All types I have encountered are
usually self-evaluating within a proper context.  In particular,
(|Record| (|:| |x| (|AType|))) is a macro which expands into
(|Record0| (LIST (CONS (QUOTE |x|) (|AType|)))).  Note well that the
label is quoted here.

OK.  When processing an anonymous function like
keeprec?(i.halfinf.endpoint, #1) in defintrf.spad, we end up
processing a partially the compiled expression which includes the
check-type forms built by mkUnionFunList above.  This processing
happens mainly in compWithMappingMode (compiler.boot).  The goal in
that function is to lambda-lift the anonymous function into a
top-level DEFUN.  To do this this free variables are identified and
lifted into a formal parameter represented as a vector.

My initial thought was to augment the lifting of the free variables by
checking if they are bound.

Now I am considering an explicit call to MACROEXPAND in the
mkUnionFunList code, as in:

          ['check_-union,q, MACROEXPAND t,gg]

This appears to be the proper fix, but it will take another build
cycle to verify and check.  It is a fix because after macroexpansion,
record labels are explicitly quoted -- quoted forms are not considered
candidates by compWithMappingMode as free variables.


Sorry if this rant is not clear.  I can try to answer any questions.

\start
Date: Sat, 7 Jul 2007 22:07:14 -0500
From: Tim Daly
To: Ralf Hemmecke, Stephen Wilson
Subject: Lisp in Small Pieces

Ralf, Stephen,

I think you'll find this book very interesting. Aside from the
subject matter it also clearly illustrates a style worth copying,
at least in my opinion. He gives the complete source code for a
lisp implementation along with a perfectly readable explanation
of all of the issues. I think that ALLPROSE could find a possible
example of a pamphlet/booklet format here.

The compiler chapter (ch 7) goes into great detail in a readable
fashion. Particularly interesting is the handling of continuations.
I'm interested in continuations (or futures) because this would be a
perfect mechanism for handling multi-branching provisos, each branch
in its own continuation. The closest thing in spad seems to be
infinite streams. However an explicit continuation mechanism would be
very nice indeed.

Queinnec, Christian, "Lisp in Small Pieces" ISBN 0-521-54566-8

\start
Date: 07 Jul 2007 23:17:14 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Lisp in Small Pieces

Tim Daly writes:

> Ralf, Stephen,
> 
> I think you'll find this book very interesting. Aside from the
> subject matter it also clearly illustrates a style worth copying,
> at least in my opinion. He gives the complete source code for a
> lisp implementation along with a perfectly readable explanation
> of all of the issues. I think that ALLPROSE could find a possible
> example of a pamphlet/booklet format here.

This is a book I always wanted to purchase.  I have read portions
quite some time ago via library loan.  I recall being impressed.  I
will make it a priority to order a copy.

> The compiler chapter (ch 7) goes into great detail in a readable
> fashion. Particularly interesting is the handling of continuations.
> I'm interested in continuations (or futures) because this would be a
> perfect mechanism for handling multi-branching provisos, each branch
> in its own continuation. The closest thing in spad seems to be
> infinite streams. However an explicit continuation mechanism would be
> very nice indeed.

I find this very interesting.  I wonder what would be involved in
implementing continuations to exploit GCL's multiprocessing
capabilities.

> 
> Queinnec, Christian, "Lisp in Small Pieces" ISBN 0-521-54566-8

\start
Date: Sat, 7 Jul 2007 22:35:11 -0500
From: Tim Daly
To: Ralf Hemmecke, Stephen Wilson
Subject: Lisp in Small Pieces

> I find this very interesting. I wonder what would be involved in
> implementing continuations to exploit GCL's multiprocessing
> capabilities

There have been discussions, some of which are on this list, about using
provisos mapped to multiple processors. Consider an expression that
says something like a function provided x is not zero:

 f := [ function | x != 0 ]

If x is real we can rewrite this in interval notation as 2 distinct branches:

 f := [ function | x \in (-\infinity 0] and x \in [0 \infinity) ]

or in functional notation something like:

 f1 := [ function | x < 0 ] 
 f2 := [ function | x > 0 ]

 f := join(f1,f2)

Since each of the intervals is non-overlapping we can compute each
branch f1 and f2 independently and in parallel. This is a perfect fit
for a multiprocessor system. As the computation proceeds it potentially
branches again and again into distinct regions. Each branch can be a
continuation waiting for an available processor.

Combining these regions after the results amounts to logical or 
expression computations on the provisos.


Similar kind of proviso branching/combining algorithms can be defined
to handle matrix computations, region searching, multiple root finding,
and other algorithms that naturally break into regions. Geometric
algorithms, such as the exterior algebra links I posted, could benefit
greatly from this.

It is also applicable to algorithms such as integration where there
is a potential pole in the path of integration. The integral can be split
and the limits computed from each side to see if they match.

Essentially provisos enable a natural parallel processing mechanism.
They are much more powerful algebraically than an assume facility.

\start
Date: Sun, 08 Jul 2007 12:44:30 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Lisp in Small Pieces

> I'm interested in continuations (or futures) because this would be a
> perfect mechanism for handling multi-branching provisos, each branch
> in its own continuation. The closest thing in spad seems to be
> infinite streams. However an explicit continuation mechanism would be
> very nice indeed.

Oh, do you like to introduce "Generator" into SPAD? Otherwise I don't 
understand why *I* should become interested in LISP contiuations.

For me LISP is an implementation detail. At some (very low) level of 
abstraction (and in particular at the algebra level), I don't want to 
see LISP anymore. SPAD/Aldor should be the way to program. If there is 
any need to switch to LISP then it's probably better to think about the 
corresponding implementation design of the algebra code.

Aldor is sufficiently powerful. And if SPAD is not going to be as 
powerful as Aldor and there would be need to do something in LISP, then 
I consider that a really bad design decision.

\start
Date: Sun, 8 Jul 2007 06:39:48 -0500
From: Tim Daly
To: Ralf Hemmecke, Stephen Wilson
Subject: Literate programming and Provisos

Eh? I sent you the reference to the book so that you could see an
example of what I consider modern literate programming practice that
has been published as a textbook. Stephen is writing a new parser and
possibly a new compiler. I wanted to motivate him to consider using
literate documentation in the style of this excellent book.



The discussion of provisos has ALWAYS been an algebraic discussion
and always related to spad-level programming. I'd like to have a 
proviso domain (or extend the SUCHTHAT domain) so we could form a
continuation/future/closure over all or a portion of a computation
and later evaluate it. I don't believe I mentioned lisp in that
discussion anywhere. Perhaps I should have changed the Subject line.
Clearly such a control mechanism would have to be supported by an
underlying Lisp mechanism but that, as you say, is an implementation
detail. 

I'm not sure how Generators is related to provisos.




For other examples where we might draw inspiration for forms of
programs that have been published in books see:
"Compiler Design in C" which is the complete C compiler source
"Operating Systems Design and Implementation" containing an opsys
"Lions Commentary on Unix" containing the AT&T Unix source
"Linux Core Kernels" containing the Linux kernel source
"Linux IP Stacks" containing the Linux networking source
"TeX: The Program" containing the TeX source code.
All of these mingle complete source code with text albeit not in
an electronic form. It would be trivial to make them literate in
electronic form.

I found "Lisp in Small Pieces" to be the best written of the examples
I reviewed. I think it is worth staring at to consider why it reads
so well. It covers a multitude of deep issues in very clear terms.
And it contains ALL of the source code with a careful explanation of
every little detail. 

Literate Programming can be done. It can be done clearly and simply.
We're way behind the curve. "Lisp in Small Pieces" is from the 1996.  I
taught my compiler course at Vassar using the "Compiler Design in C"
book way back in the 90s, as well as "Anatomy of Lisp" which is
another excellent book worth reviewing.

\start
Date: Sun, 08 Jul 2007 15:12:51 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Literate programming and Provisos

 > The discussion of provisos has ALWAYS been an algebraic discussion
 > and always related to spad-level programming. I'd like to have a
 > proviso domain (or extend the SUCHTHAT domain) so we could form a
 > continuation/future/closure over all or a portion of a computation
 > and later evaluate it. I don't believe I mentioned lisp in that
 > discussion anywhere. Perhaps I should have changed the Subject line.
 > Clearly such a control mechanism would have to be supported by an
 > underlying Lisp mechanism but that, as you say, is an implementation
 > detail.

OK, then we are on the same side. If you add any nice language construct 
to SPAD then fine.

 > I'm not sure how Generators is related to provisos.

You mentioned Streams. I happen to have programmed Streams in 
Aldor-Combinat.
http://www.risc.uni-linz.ac.at/people/hemmecke/AldorCombinat/combinatse12.html#x58-9900012
As you can see, a stream for me is an Array plus a Generator. So that 
was my connection.

I am not so sure that I understand what a "continuation" is. I've 
already read some text about that, but I seem not to get the difference 
to Aldor's Generator concept. Maybe somebody can help. How would a 
continuation in Aldor look like and how would that be different from the 
Generator domain?

...

Thank you for the other references about literate programs.


\start
Date: Sun, 08 Jul 2007 15:30:40 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Literate programming and Provisos

On 07/08/2007 01:39 PM, Tim Daly wrote:
> Eh? I sent you the reference to the book so that you could see an
> example of what I consider modern literate programming practice that
> has been published as a textbook.

Sorry, did you address that to me? Since I don't have that book and 
cannot buy or borrow it on a Sunday I cannot say anything about that 
book. Of course, I will try to have a look at the programming style.

(And by the way, my last mail was about "continuation in LISP" and why 
that would affect algebra programmers.)

\start
Date: Mon, 9 Jul 2007 00:00:52 +1000
From: Alasdair McAndrew
To: list
Subject: Axiom, FriCAS, forks and teeth

------=_Part_12790_28854283.1183903252858

So I go away for an internet-free weekend, and what do I find when I come
back?  A fork of Axiom with its own name, and people on the mailgroup baring
their teeth at each other in a most unseemly manner.  So, so, fork away...
but what I want to know is - where does this leave me, a common-or-garden
user?  Learning a CAS - any CAS - really well, is a non-trivial task, and
after spending much of the last month or so finding my way around Axiom,
this forking business has me feeling very uncertain as to where - or whether
- I should put any more time into these projects.  I have come to like Axiom
very much indeed, but if it and its users are going to split into
acrimonious groups, I shall feel very unsure of where my loyalties lie.
Maybe I should go back to Maxima...

I'm very nervy about all this.

\start
Date: Sun, 8 Jul 2007 20:01:35 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: re: debugging

Camm Maguire wrote:
> Greetings!
> 
> 1) 'boot::|NRTassocIndex| (and others) calls elt on dotted lists of
>    the form ('|domain| s . s), whereas the spec says elt must take a
>    proper list.  elt is automatically inlined.
> 

I tried to redefine elt in the initial image -- it did not work
(I probably made some silly error).  So I changed |NRTassocIndex|
to use nth.  I got a misterous build failure:

------------------------------------------------------------------------
   FunctionSpace is now explicitly exposed in frame initial
   FunctionSpace will be automatically loaded when needed from
      /var/tmp/hebisch/axp7/ax-build4/src/algebra/FS.NRLIB/code

)compile "ACFS.spad"

Segmentation violation: c stack ok:signalling error
   >> System error:
   Condition in $FINDFILE [or a callee]: INTERNAL-SIMPLE-ERROR: Caught fatal error [memory may be damaged]: Segmentation violation.


When I did the compilation by hand it went OK.  However later
I got another error.  AFAICS DFLOAT.spad is miscompiled.  In
the spad file we have:

   base()           == FLOAT_-RADIX(0$%)$Lisp


the resulting Lisp is:

(DEFUN |DFLOAT;base;Pi;7| ($)
  (PROG () (RETURN (FLOAT-RADIX '#<OBJNULL>))))

Also, with Ansi gcl-2.7.0 we get subtly different code, other Lisps
(gcl 2.6.8, sbcl, clisp) just give:

(DEFUN |DFLOAT;base;Pi;7| ($) (FLOAT-RADIX 0.0))

that is the outer PROG and RETURN are missing (I see this difference
for many other functions).

\start
Date: 08 Jul 2007 14:48:27 -0400
From: Stephen Wilson
To: Stephen Wilson
Subject: Re: defintrf.spad compiler bug

--=-=-=

Tim,

This bug is now on Issue Tracker, #370.

The MACROEXPAND fix as detailed in a prior email seems workable.  I
have tested the change but wish to continue with some more tests.  I
propose the attached patches for testing.

The original `fix', checking that a free variable is bound in the
environment, might still be useful.  The compiler is surely lacking in
assertions and self checks.  Will incorporate the change into my own
branches and possibly submit a patch in the future.

Steve


--=-=-=

--- changelog	2007-07-07 20:53:37.000000000 -0400
+++ changelog.sxw	2007-07-08 14:33:16.000000000 -0400
@@ -1,3 +1,4 @@
+20070708 sxw fix issue #370, document
 20070705 wxh src/algebra/draw.spad clip myTrap1, myTrap2 range to SF (545)
 20070705 gdr remove execute bit from files (svn 651)
 20070704 tpd zips/tla-1.1.tar.gz svn propset mime-type binary/data

--=-=-=

--- buildom.boot.pamphlet	2007-07-07 20:53:40.000000000 -0400
+++ buildom.boot.pamphlet.sxw	2007-07-08 14:34:27.000000000 -0400
@@ -9,6 +9,249 @@
 \eject
 \tableofcontents
 \eject
+\section{[[makeFunctionList]] Operations}
+
+In {\tt src/interp/property.lisp.pamphlet} the primitive constructor
+names [[Record]], [[Union]], [[Mapping]] and [[Enumeration]] have
+their plists augmented to include an association between the key
+[[makeFunctionList]] and a function.  These functions are defined
+here, the common goal being to construct a list of exports admitted by
+instances of the given type.
+
+To understand the results, it is useful to simply compare the lists
+generated by the following routines and the output of the
+corresponding interpreter command such as 
+[[)show Union(int: Integer, str: String)]].
+
+\subsection{[[mkNewUnionFunList]] and [[mkUnionFunlist]]}
+
+The exports provided by a Union type differ depending on if the
+branches are labeled (a so-called {\em new union}), or are unlabeled.
+A labeled [[Union]] branch is represented as a binding form
+[[(|:| <tag> <type>)]], where [[<tag>]] is a symbol
+labeling the branch and [[<type>]] denotes the corresponding type.
+When a branch is labeled, the function [[mkNewUnionFunList]] processes
+the forms, otherwise [[mkUnionFunList]] handles the task.
+
+<<check for new union>>=
+first listOfEntries is [":",.,.] => mkNewUnionFunList(op,form,e)
+@
+
+Recall that the general form for a map type is 
+[[(<target> <arg1> ... <argn>)]] where [[<target>]]
+denotes the return type of the map and [[<argk>]] denotes the k'th
+argument type. The general form for an exported function is 
+[[(<name> <type> <body>)]].
+
+A [[Union]] type always exports a equality operator [[=]] and a
+coercion the the type bound by the global variable [[$Expression]].
+It is almost certain that [[$Expression]] is always an alias for
+[[OutputForm]].
+
+<<default old-union exports>>=
+['_=,[['Boolean],g ,g],['ELT,op,6]],
+['coerce,[$Expression,g],['ELT,op,7]]
+@
+
+The remaining exports are dependent on the number of branches in the
+[[Union]].  For each branch, we export four functions.
+\begin{itemize}
+\item [[autoCoerce]], denoting automatic (unchecked) coercions
+too/from the [[Union]] type and the branch type.
+\item [[coerce]], denoting explicit (checked) coercions from the
+[[Union]] type to the branch type.
+\item [[case]], a [[Boolean]] valued infix operator allowing one to
+test if access to a particular branch is valid.
+\end{itemize}
+
+We iterate over each branch component in [[listOfEntries]] and collect
+the four generated exports into the final list.  Note that [[g]] is
+bound to a [[GENSYM]], which is a place-holder for latter substitution
+of the name denoting the [[Union]] type.
+
+<<old-union branch exports>>=
+("append"/
+ [[['autoCoerce,[g,t],upFun],
+   ['coerce,[t,g],cdownFun],
+   ['autoCoerce,[t,g],downFun], --this should be removed eventually
+   ['case,['(Boolean),g,t],typeFun]]
+     for p in predList for t in listOfEntries])
+@
+
+The implementation of the export bodies themselves require more
+documentation.  The implementation is segregated to hopefully ease
+future documentation efforts.
+
+<<old-union export implementations>>=
+<<[[upFun]]>>
+<<[[cdownFun]]>>
+<<[[downFun]]>>
+<<[[typeFun]]>>
+@
+
+[[cdownFun]] implements coercions from a [[Union]] type to a branch
+type.  The generated call to [[|check-union|]] (see {\tt
+src/interp/macros.lisp.pamphlet}) needs special mention.  This call
+simply asserts that its predicate, denoted by [[q]] here, returns
+true.  Otherwise a message is generated indicating the coercion
+failed.  Note in particular the need to call [[MACROEXPAND]] on the
+type form [[t]].  This is required as type expressions are often
+represented as macros. When appearing in generated code, the expansion
+of a type expression is amenable to further analysis by by the
+compiler, but an unexpanded form is not.  Compare the representation
+of a [[Record]] type verses its expansion (see the [[|Record|]] macro
+in {\tt src/interp/macros.lisp.pamphlet}).
+
+<<[[cdownFun]]>>=
+cdownFun() ==
+  gg:=GENSYM()
+  if p is ['EQCAR,x,n] then
+     ref:=['QCDR,gg]
+     q:= ['QEQCAR, gg, n]
+  else
+     ref:=gg
+     q:= substitute(gg,"#1",p)
+  ['XLAM,["#1"],['PROG2,['LET,gg,"#1"],ref,
+       ['check_-union,q,MACROEXPAND t,gg]]]
+@
+
+[[upFun]] handles the auto-coercion from a branch type to the [[Union]]
+type.
+
+<<[[upFun]]>>=
+upFun() ==
+  p is ['EQCAR,x,n] => ['XLAM,["#1"],['CONS,n,"#1"]]
+  ['XLAM,["#1"],"#1"]
+@
+
+[[downFun]] handles the auto-coercion from a [[Union]] type to a branch
+type.
+<<[[downFun]]>>=
+downFun() ==
+   p is ['EQCAR,x,.] =>
+     ['XLAM,["#1"],['QCDR,"#1"]]
+   ['XLAM,["#1"],"#1"]
+@
+
+[[typeFun]] implements the [[case]] operation.
+<<[[typeFun]]>>=
+typeFun() ==
+   p is ['EQCAR,x,n] =>
+     ['XLAM,["#1"],['QEQCAR,x,n]]
+   ['XLAM,["#1"],p]
+@
+
+This is the final implementation of [[mkUnionFunList]].
+
+<<mkUnionFunList>>=
+mkUnionFunList(op,form is ['Union,:listOfEntries],e) ==
+  <<check for new union>>
+  -- following call to order is a bug, but needs massive recomp to fix
+  listOfEntries:= orderUnionEntries listOfEntries
+  --1. create representations of subtypes
+  predList:= mkPredList listOfEntries
+  g:=GENSYM()
+  --2. create coercions from subtypes to subUnion
+  cList:=
+   [<<default old-union exports>>,:
+      <<old-union branch exports>>] where
+            <<old-union export implementations>>
+  op:=
+    op='Rep => '$
+    op
+  cList:= substitute(op,g,cList)
+  [cList,e]
+
+@ 
+
+[[mkNewUnionFunList]] follows effectively the same strategy as
+[[mkUnionFunList]].  The default equality and coercion to
+[[OutputForm]] remain, however the branch specific exports differ.
+For each branch, we generate the following:
+\begin{itemize}
+\item [[construct]], from the branch type to the [[Union]] type,
+denoted in Spad code as the bracket operator `[[[]]]'.
+\item [[elt]], a checked accessor for a tagged branch, denoted in
+Spad code as the `[[.]]' operator.
+\item [[case]], this operator now operates over tags rather than
+types.
+\end{itemize}
+
+<<mkNewUnionFunList>>=
+mkNewUnionFunList(name,form is ['Union,:listOfEntries],e) ==
+  dc := name
+  if name = 'Rep then name := '$
+  --2. create coercions from subtypes to subUnion
+  cList:=
+    [['_=,[['Boolean],name ,name],['ELT,dc,6]],
+     ['coerce,[$Expression,name],['ELT,dc,7]],:
+       ("append"/
+	[[['construct,[name,type],['XLAM,["#1"],['CONS,i,"#1"]]],
+	  ['elt,[type,name,tag],cdownFun],
+	    ['case,['(Boolean),name,tag],
+	       ['XLAM,["#1"],['QEQCAR,"#1",i]]]]
+		 for [.,tag,type] in listOfEntries for i in 0..])] where
+		   cdownFun() ==
+		    gg:=GENSYM()
+		    $InteractiveMode =>
+		      ['XLAM,["#1"],['PROG1,['QCDR,"#1"],
+			['check_-union,['QEQCAR,"#1",i],type,"#1"]]]
+		    ['XLAM,["#1"],['PROG2,['LET,gg,"#1"],['QCDR,gg],
+		      ['check_-union,['QEQCAR,gg,i],MACROEXPAND type,gg]]]
+  [cList,e]
+
+@
+\subsection{[[Record]], [[Mapping]], [[Enumeration]]}
+
+The remaining procedures follow the general style as described for the
+[[Union]] case above.
+
+<<mkMappingFunList>>=
+mkMappingFunList(nam,mapForm,e) ==
+  dc := GENSYM()
+  sigFunAlist:=
+    [['_=,[['Boolean],nam ,nam],['ELT,dc,6]],
+       ['coerce,[$Expression,nam],['ELT,dc,7]]]
+  [substitute(nam,dc,substitute("$",'Rep,sigFunAlist)),e]
+
+@
+<<mkRecordFunList>>=
+mkRecordFunList(nam,['Record,:Alist],e) ==
+  len:= #Alist
+--  for (.,a,.) in Alist do
+--    if getmode(a,e) then MOAN("Symbol: ",a,
+--	  " must not be both a variable and literal")
+--    e:= put(a,"isLiteral","true",e)
+  dc := GENSYM()
+  sigFunAlist:=
+     --:((a,(A,nam),('XLAM,("$1","$2"),('RECORDELT,"$1",i,len)))
+     --	      for i in 0..,(.,a,A) in Alist),
+    [['construct,[nam,:[A for [.,a,A] in Alist]],'mkRecord],
+      ['_=,[['Boolean],nam ,nam],['ELT,dc,6]],
+       ['coerce,[$Expression,nam],['ELT,dc,7]],:
+	[['elt,[A,nam,PNAME a],['XLAM,["$1","$2"],['RECORDELT,"$1",i,len]]]
+	    for i in 0.. for [.,a,A] in Alist],:
+	  [['setelt,[A,nam,PNAME a,A],['XLAM,["$1","$2","$3"],
+	    ['SETRECORDELT,"$1",i, len,"$3"]]]
+	      for i in 0.. for [.,a,A] in Alist],:
+		[['copy,[nam,nam],['XLAM,["$1"],['RECORDCOPY,
+		  "$1",len]]]]]
+  [substitute(nam,dc,substitute("$",'Rep,sigFunAlist)),e]
+
+@
+<<mkEnumerationFunList>>=
+mkEnumerationFunList(nam,['Enumeration,:SL],e) ==
+  len:= #SL
+  dc := nam
+  cList :=
+    [nil,
+      ['_=,[['Boolean],nam ,nam],['ELT,dc,6]],
+        ['_^_=,[['Boolean],nam ,nam],['ELT,dc,7]],
+          ['coerce,[nam, ['Symbol]], ['ELT, dc, 8]],
+            ['coerce,[['OutputForm],nam],['ELT,dc, 9]]]
+  [substitute(nam, dc, cList),e]
+
+@
 \section{License}
 <<license>>=
 -- Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
@@ -42,7 +285,6 @@
 -- NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 -- SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
-@
 <<*>>=
 <<license>>
 
@@ -267,114 +509,11 @@
   cat.(0):= title
   cat
 
---mkMappingFunList(nam,mapForm,e) == [[],e]
-mkMappingFunList(nam,mapForm,e) ==
-  dc := GENSYM()
-  sigFunAlist:=
-    [['_=,[['Boolean],nam ,nam],['ELT,dc,6]],
-       ['coerce,[$Expression,nam],['ELT,dc,7]]]
-  [substitute(nam,dc,substitute("$",'Rep,sigFunAlist)),e]
-
-mkRecordFunList(nam,['Record,:Alist],e) ==
-  len:= #Alist
-
---  for (.,a,.) in Alist do
---    if getmode(a,e) then MOAN("Symbol: ",a,
---	  " must not be both a variable and literal")
---    e:= put(a,"isLiteral","true",e)
-  dc := GENSYM()
-  sigFunAlist:=
-     --:((a,(A,nam),('XLAM,("$1","$2"),('RECORDELT,"$1",i,len)))
-     --	      for i in 0..,(.,a,A) in Alist),
-
-    [['construct,[nam,:[A for [.,a,A] in Alist]],'mkRecord],
-      ['_=,[['Boolean],nam ,nam],['ELT,dc,6]],
-       ['coerce,[$Expression,nam],['ELT,dc,7]],:
-	[['elt,[A,nam,PNAME a],['XLAM,["$1","$2"],['RECORDELT,"$1",i,len]]]
-	    for i in 0.. for [.,a,A] in Alist],:
-	  [['setelt,[A,nam,PNAME a,A],['XLAM,["$1","$2","$3"],
-	    ['SETRECORDELT,"$1",i, len,"$3"]]]
-	      for i in 0.. for [.,a,A] in Alist],:
-		[['copy,[nam,nam],['XLAM,["$1"],['RECORDCOPY,
-		  "$1",len]]]]]
-  [substitute(nam,dc,substitute("$",'Rep,sigFunAlist)),e]
-
-mkNewUnionFunList(name,form is ['Union,:listOfEntries],e) ==
-  dc := name
-  if name = 'Rep then name := '$
-  --2. create coercions from subtypes to subUnion
-  cList:=
-    [['_=,[['Boolean],name ,name],['ELT,dc,6]],
-     ['coerce,[$Expression,name],['ELT,dc,7]],:
-       ("append"/
-	[[['construct,[name,type],['XLAM,["#1"],['CONS,i,"#1"]]],
-	  ['elt,[type,name,tag],cdownFun],
-	    ['case,['(Boolean),name,tag],
-	       ['XLAM,["#1"],['QEQCAR,"#1",i]]]]
-		 for [.,tag,type] in listOfEntries for i in 0..])] where
-		   cdownFun() ==
-		    gg:=GENSYM()
-		    $InteractiveMode =>
-		      ['XLAM,["#1"],['PROG1,['QCDR,"#1"],
-			['check_-union,['QEQCAR,"#1",i],type,"#1"]]]
-		    ['XLAM,["#1"],['PROG2,['LET,gg,"#1"],['QCDR,gg],
-		      ['check_-union,['QEQCAR,gg,i],type,gg]]]
-  [cList,e]
-
-mkEnumerationFunList(nam,['Enumeration,:SL],e) ==
-  len:= #SL
-  dc := nam
-  cList :=
-    [nil,
-      ['_=,[['Boolean],nam ,nam],['ELT,dc,6]],
-        ['_^_=,[['Boolean],nam ,nam],['ELT,dc,7]],
-          ['coerce,[nam, ['Symbol]], ['ELT, dc, 8]],
-            ['coerce,[['OutputForm],nam],['ELT,dc, 9]]]
-  [substitute(nam, dc, cList),e]
-
-mkUnionFunList(op,form is ['Union,:listOfEntries],e) ==
-  first listOfEntries is [":",.,.] => mkNewUnionFunList(op,form,e)
-     -- following call to order is a bug, but needs massive recomp to fix
-  listOfEntries:= orderUnionEntries listOfEntries
-  --1. create representations of subtypes
-  predList:= mkPredList listOfEntries
-  g:=GENSYM()
-  --2. create coercions from subtypes to subUnion
-  cList:=
-   [['_=,[['Boolean],g ,g],['ELT,op,6]],
-    ['coerce,[$Expression,g],['ELT,op,7]],:
-     ("append"/
-      [[['autoCoerce,[g,t],upFun],
-	['coerce,[t,g],cdownFun],
-	['autoCoerce,[t,g],downFun], --this should be removed eventually
-	['case,['(Boolean),g,t],typeFun]]
-	  for p in predList for t in listOfEntries])] where
-	     upFun() ==
-	       p is ['EQCAR,x,n] => ['XLAM,["#1"],['CONS,n,"#1"]]
-	       ['XLAM,["#1"],"#1"]
-	     cdownFun() ==
-	       gg:=GENSYM()
-	       if p is ['EQCAR,x,n] then
-		  ref:=['QCDR,gg]
-		  q:= ['QEQCAR, gg, n]
-	       else
-		  ref:=gg
-		  q:= substitute(gg,"#1",p)
-	       ['XLAM,["#1"],['PROG2,['LET,gg,"#1"],ref,
-		    ['check_-union,q,t,gg]]]
-	     downFun() ==
-		p is ['EQCAR,x,.] =>
-		  ['XLAM,["#1"],['QCDR,"#1"]]
-		['XLAM,["#1"],"#1"]
-	     typeFun() ==
-		p is ['EQCAR,x,n] =>
-		  ['XLAM,["#1"],['QEQCAR,x,n]]
-		['XLAM,["#1"],p]
-  op:=
-    op='Rep => '$
-    op
-  cList:= substitute(op,g,cList)
-  [cList,e]
+<<mkUnionFunList>>
+<<mkNewUnionFunList>>
+<<mkMappingFunList>>
+<<mkRecordFunList>>
+<<mkEnumerationFunList>>
 
 @
 \eject

--=-=-=--

\start
Date: 08 Jul 2007 15:21:52 -0400
From: Stephen Wilson
To: list
Subject: Unions in Spad

*,

During my work figuring out the defintrf.spad bug, I noticed a
shortcoming in the handling of unions.

Spad, internally, has two notions of Unions.  The first variety might
be termed `regular', the other is, not surprisingly, termed `new'.

Regular Unions do not have tags associated with branches. For example:

      Union(Integer, String)

New Unions have tags, as in

      Union(int: Integer, str: String)

The shortcoming is how these two flavors interact.  Currently, Unions
are of one kind or the other.  But this fact is nowhere asserted, and
blending the two types leads to obscure errors.  For example:

     Union(int: Integer, String)

I would appreciate any input if the above `hybrid' Union is useful or
desirable.

If so, I have a strategy to make such Unions usable (but it may be a
while before I find the time to implement it). If not, then there is
an easy fix to assert the uniformity of Union branches.

\start
Date: 08 Jul 2007 16:34:49 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: re: debugging

Greetings, and thanks!

Please be advised that nth at safety 0 will still segfault if you try
to cdr past the dot.  

I'd like to take a look at the below, but I'm not sure my tree is in
sync with yours.  Have you committed everything?  If so, how to I
update with svn?  Anything else I need to reproduce the error below?

Thanks!


Waldek Hebisch writes:

> Camm Maguire wrote:
> > Greetings!
> > 
> > 1) 'boot::|NRTassocIndex| (and others) calls elt on dotted lists of
> >    the form ('|domain| s . s), whereas the spec says elt must take a
> >    proper list.  elt is automatically inlined.
> > 
> 
> I tried to redefine elt in the initial image -- it did not work
> (I probably made some silly error).  So I changed |NRTassocIndex|
> to use nth.  I got a misterous build failure:
> 
> ------------------------------------------------------------------------
>    FunctionSpace is now explicitly exposed in frame initial
>    FunctionSpace will be automatically loaded when needed from
>       /var/tmp/hebisch/axp7/ax-build4/src/algebra/FS.NRLIB/code
> 
> )compile "ACFS.spad"
> 
> Segmentation violation: c stack ok:signalling error
>    >> System error:
>    Condition in $FINDFILE [or a callee]: INTERNAL-SIMPLE-ERROR: Caught fatal error [memory may be damaged]: Segmentation violation.
> 
> 
> When I did the compilation by hand it went OK.  However later
> I got another error.  AFAICS DFLOAT.spad is miscompiled.  In
> the spad file we have:
> 
>    base()           == FLOAT_-RADIX(0$%)$Lisp
> 
> 
> the resulting Lisp is:
> 
> (DEFUN |DFLOAT;base;Pi;7| ($)
>   (PROG () (RETURN (FLOAT-RADIX '#<OBJNULL>))))
> 
> Also, with Ansi gcl-2.7.0 we get subtly different code, other Lisps
> (gcl 2.6.8, sbcl, clisp) just give:
> 
> (DEFUN |DFLOAT;base;Pi;7| ($) (FLOAT-RADIX 0.0))
> 
> that is the outer PROG and RETURN are missing (I see this difference
> for many other functions).

\start
Date: Sun, 08 Jul 2007 22:49:50 +0200
From: Ralf Hemmecke
To: Camm Maguire
Subject: re: debugging

> If so, how to I update with svn?

Go to the top of your checked out tree (the one which still has a .svn 
subdirectory). Then say

svn update

That's it.

If you have locally changed your tree, svn does not override your 
changes but rather merges them with the newest code from the repository.

If you want to make sure that your tree is as the one in the repository say

svn update
svn revert -R .

\start
Date: 08 Jul 2007 17:09:05 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: Re: Literate programming and Provisos

Hi Ralf,

Ralf Hemmecke writes:

> I am not so sure that I understand what a "continuation" is. I've
> already read some text about that, but I seem not to get the
> difference to Aldor's Generator concept. Maybe somebody can help. How
> would a continuation in Aldor look like and how would that be
> different from the Generator domain?

It is difficult to say what the best way to express such things in
Spad/Aldor would be.  This would require a lot of thought.  But there
is an obvious approach.

One can think of a continuation is an abstract object representing the
remainder of a computation.  We normally think about functions
returning values, with continuations we pass the value to the
remainder of the computation.  It is common to have a continuation
represented explicitly as an argument.  In Spad or Aldor, this might
be written as:

 add-cc (c : Continuation(Integer), n : Integer) : Integer ==
    c(n + 1)

There are issues with typing such things, as a function which calls a
continuation `never returns', but is not obliged to call the
continuation at all (and thus can return).  Here I just assumed that
Continuation is a built-in domain which is parametrized over the
argument type it expects.  It is possible to give a sound type to
continuations. ML supports them, for example.

You can represent effectively any control flow construct with
continuations, and as Tim mentioned, they have graceful connections to
multiprocessing.  Coroutines are a special case,  and Aldor style
generators are just a special case of coroutines.  Indeed, if I were
to implement coroutines/generators in Spad, I would seek a
continuation-passing-style (CPS) representation to aid reasoning about
the code.

On the other hand, some say continuations are the functional
equivalent to GOTO.  Its a powerful feature and it can be abused.

Wikipedia has some decent articles about continuations and
coroutines.  You might also consider playing with Scheme to get a feel
for them.

\start
Date: Sun, 08 Jul 2007 23:29:58 +0200
From: Ralf Hemmecke
To: Stephen Wilson
Subject: Re: Unions in Spad

Hello Stephen,

> Regular Unions do not have tags associated with branches. For example:
> 
>       Union(Integer, String)
> 
> New Unions have tags, as in
> 
>       Union(int: Integer, str: String)

SPAD seems to allow

u: Union(Integer, String) := ...
if u case Integer then ...

I am not aware of the fact that Aldor can do this. And in the Aldor User 
Guide I have only found tagged unions.

How does now actually distinguish branches. My code above was actually 
only a guess. I have no idea whether that works in SPAD. In Aldor it 
doesn't.

Ralf

woodpecker:~/scratch>aldor -laldor -fx aaa.as
"aaa.as", line 13:         if u case MachineInteger then {
                    ..................^
[L13 C19] #1 (Error) Argument 2 of `case' did not match any possible 
parameter type.
     The rejected type is Join(
                 PrimitiveType with
                     ....
     Expected one of:
       -- Enumeration(MachineInteger: Type)
       -- Enumeration(String: Type)


---BEGIN aaa.as
#include "aldor"
#include "aldorio"
macro I == MachineInteger;
main(): () == {
	import from I, String;
	U == Union(MachineInteger, String);
	import from U;
	i: I := 2;
	s: String := "I am a string";
	ui: U := union i;
	us: U := union s;
	u: U := if odd? random(10) then ui else us;
	if u case MachineInteger then {
		stdout << "Integer: " << newline;
	} else {
		stdout << "String: " << newline;
	}
}
main();---END aaa.as

\start
Date: Sun, 8 Jul 2007 23:33:00 +0200
From: Ondrej Certik
To: Tim Daly
Subject: Re: Why did Axiom fail in the 1990s?

On 7/1/07, Tim Daly wrote:
> Scratchpad was a research project, not a commercial project.
> The only reason that it became commercial was that Lou Gerstner,
> hired from Nabisco to run IBM, set out to commercialize everything.
>
> I'd like to blame Lou for everything but the collapse started
> much earlier when the Federal Labs were closed putting an end
> to much federally funded research. The trend eventually killed
> off such great places as Xerox Labs, Bell Labs, and IBM Research.
> (IBM Research exists but "it ain't the same", ask any old-timer)
>
> I worked at IBM Research for years. Once Lou was hired there was
> a push to "make research pay for itself". Scratchpad was going to
> be sold in the market. We originally tried to sell it thru IBM.
> However IBM had a requirement that programs must have extensive
> documentation. And the documentation must be readable "at the
> eighth grade level". There were programs which read the text and
> flagged long words, long phrases, out-of-dictionary words, etc.
> Since there was no way to document DistributedMultivariatePolynomials
> under this stricture we could not market thru IBM.
>
> We tried several paths. NAG was a logical path as they were well known
> for their excellent mathematical tool (the NAG library) and their
> ability to support mathematical software. Plus NAG had quality people
> in the management team. Thus we managed to sell Scratchpad (as Axiom)
> to NAG.
>
> There was a huge cost however. None of the original IBM developers
> (including me) were allowed to continue to work on Axiom. So Lou
> managed to get money for the software but stripped it of the people.
> We all were told to circle our chairs until we found some non-axiom
> research that would pay for itself in real customer dollars. So
> front-line computational mathematicians were stripped of the one
> place where their skill sets could make a difference. (I ended
> up working on a voice-recognition system for a bank).
>
> Thus stripped of the people who made Axiom live, NAG had a huge task
> on their hands. They could not afford to hire a 10-person support team
> and open source did not exist at that time. (Well, it did since I
> regularly shipped sources for scratchpad, but there was no "open
> source developer network"). Without the people Axiom cannot be a
> viable, growing product.
>
> Thus I believe that NAG's only possible path was to use Axiom as a
> market driver for their excellent NAG library. Given such a role Axiom
> cannot and did not compete. I believe that once NAG connected to Maple
> as an external library of choice it was clear that Axiom had to go.
>
> Scratchpad was well ahead of the curve compared to Maple, MMA, etc.
> Given the right support it could have been much better than it is
> today. However, the IBM Research which Lou Gerstner shaped lacked any
> sense of long term vision. What could "the 30 year horizon" mean to a
> man who markets cookies (Lou's previous company)?

Is he this one?

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

They say he virtually saved IBM from going out of business. If this is
true (I don't know), then he did more good than bad, in my opinion.

> Scratchpad didn't die a natural death. It was killed by short term,
> make it pay, thinking. Notre Dame took 300 years to build. Given the

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

They say it started in 1160 and ended in 1345, so it's only 185 years
and also it was financed probably by the king and the bishop, but
definitely not by a private company.

> short term mindset Lou would rather have built it overnight as a
> prefab wooden house in a suburb using conventional tools and selling
> for a nice markup.

To save money of IBM. I think it's fair.

\start
Date: 08 Jul 2007 17:51:54 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: Re: Unions in Spad

Ralf Hemmecke writes:

> Hello Stephen,
> 
> > Regular Unions do not have tags associated with branches. For example:
> >       Union(Integer, String)
> > New Unions have tags, as in
> >       Union(int: Integer, str: String)
> 
> SPAD seems to allow
> 
> u: Union(Integer, String) := ...
> if u case Integer then ...
> 
> I am not aware of the fact that Aldor can do this. And in the Aldor
> User Guide I have only found tagged unions.
> 
> How does now actually distinguish branches. My code above was actually
> only a guess. I have no idea whether that works in SPAD. In Aldor it
> doesn't.

Your correct that this would work in Spad.

I have not tried to get any insight from Aldor yet.  I seem to recall
that Aldor's handling of these types is somewhat broken, too.

But I think Aldor's treatment of selectors as elements of type
Enumeration is worth looking at and possibly worth making explicit in
Spad.  Spad seems to follow similar semantics conceptually but I cant
see the direct connection to the type system at this time.


\start
Date: 08 Jul 2007 18:12:51 -0400
From: Stephen Wilson
To: Waldek Hebisch
Subject: re: debugging
Cc: Camm Maguire

Hello Waldek, Camm,

Waldek Hebisch writes:

> When I did the compilation by hand it went OK.  However later
> I got another error.  AFAICS DFLOAT.spad is miscompiled.  In
> the spad file we have:
> 
>    base()           == FLOAT_-RADIX(0$%)$Lisp
> 
> 
> the resulting Lisp is:
> 
> (DEFUN |DFLOAT;base;Pi;7| ($)
>   (PROG () (RETURN (FLOAT-RADIX '#<OBJNULL>))))

This is strange.  My current build using latest gclcvs and a private
tree (a modestly hacked Silver), does not have this issue.

\start
Date: Mon, 9 Jul 2007 00:35:56 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: re: debugging


--ELM1183934156-23305-0_

> Greetings, and thanks!
> 
> Please be advised that nth at safety 0 will still segfault if you try
> to cdr past the dot.  
> 
> I'd like to take a look at the below, but I'm not sure my tree is in
> sync with yours.  Have you committed everything?  If so, how to I
> update with svn?  Anything else I need to reproduce the error below?
> 

I am working still with revision 636, the same tree where I applied
several patches:

1) change to axiom-probe-file
2) spaderror patch
3) in several places I set si::*disable-recompile* to t
4) in NRTassocIndex elt is changed to nth
5) I skip initializing memory parameters

I did not commit those changes because most of patches is ATM
not aproproate in public version: 2 and 3 is 2.7.0 specific
4 will need more analysis/testing, 5 increased safe build time
from 8 hours to 12 hours (measured using 2.6.8 on 1.86 Intel
Core Duo) -- again I feel that effect of parameters needs
more analysis/testing.

The segfault is in safety 1 code -- given your description
I expect that nth may still segfault at safety 1 if the dotted
list is too short.

I suspect that segfault may be non-reproducible: I got segfault
earlier and after restarting make the build went further.

I am somewhat reluctant to redo the step with segfault, as it
took 3 hours to go trough that stage and it seems that I will
be unable to debug the segfault even if I reproduce it

I am now checking if the second problem (miscompilation) is
reproducible.

Attached you will find diff between build tree and revision 636.

-- 
                              Waldek Hebisch
Waldek Hebisch 

--ELM1183934156-23305-0_

Index: src/interp/spaderror.lisp.pamphlet
===================================================================
--- src/interp/spaderror.lisp.pamphlet	(wersja 636)
+++ src/interp/spaderror.lisp.pamphlet	(kopia robocza)
@@ -48,14 +48,14 @@
 
 ;; this files contains basic routines for error handling
 (in-package "BOOT")
-
+#|
 #+(or :GCL :CCL)
 (defun error-format (message args)
   (let ((|$BreakMode| '|break|))
     (declare (special |$BreakMode|))
    (if (stringp message) (apply #'format nil message args) nil)))
+|#
 
-#-(or :GCL :CCL)
 (defun error-format (c)
   (let ((|$BreakMode| '|break|))
     (declare (special |$BreakMode|))
@@ -79,6 +79,7 @@
 
 ;; following macro evaluates form returning Union(type-of form, "failed")
 
+#|
 #+:GCL
 (defmacro |trapNumericErrors| (form)
   `(let ((|$oldBreakMode| |$BreakMode|)
@@ -87,8 +88,8 @@
      (setq val (catch '|trapNumerics| ,form))
      (if (eq val |$numericFailure|) val
        (cons 0 val))))
+|#
 
-#-(or :GCL :CCL)
 (defmacro |trapNumericErrors| (form)
     `(handler-case (cons 0 ,form)
          (arithmetic-error () |$numericFailure|)))
@@ -99,7 +100,6 @@
 ;;      (setq val (errorset ,form))
 ;;      (if (NULL val) |$numericFailure| (cons 0 (car val)))))
 
-#-(or :GCL :CCL)
 (defun spad-system-error-handler (c)
   (block nil
     (setq |$NeedToSignalSessionManager| T)
@@ -115,7 +115,7 @@
                    (throw '|letPrint2| nil))))))
         
 
-
+#|
 ;; the following form embeds around the akcl error handler
 #+:GCL
 (eval-when
@@ -148,6 +148,7 @@
 		(apply system:universal-error-handler type correctable? op
 		       continue-string error-string args )))))
 
+|#
 
 
 
@@ -156,7 +157,6 @@
 
 
 
-
 @
 \eject
 \begin{thebibliography}{99}
Index: src/interp/interp-proclaims.lisp
===================================================================
--- src/interp/interp-proclaims.lisp	(wersja 636)
+++ src/interp/interp-proclaims.lisp	(kopia robocza)
@@ -2,6 +2,8 @@
 (progn
 (eval-when (:execute :compile-toplevel :load-toplevel)
              (proclaim '(optimize (safety 1))))
+(eval-when (:execute :compile-toplevel :load-toplevel)
+           (setf si::*disable-recompile* t))
 (IN-PACKAGE "USER") 
 (PROCLAIM '(FTYPE (FUNCTION (*) (VALUES T T)) BOOT:|ReadLine|)) 
 (PROCLAIM
Index: src/interp/Makefile.pamphlet
===================================================================
--- src/interp/Makefile.pamphlet	(wersja 636)
+++ src/interp/Makefile.pamphlet	(kopia robocza)
@@ -922,6 +922,7 @@
 	@ echo 3 making ${DEPSYS} 
 	@ $(mkinstalldirs) $(axiom_build_bindir)
 	@ echo '${PROCLAIMS}' > makedep.lisp
+	echo '(setf si::*disable-recompile* t)' >> makedep.lisp
 	@ echo '(push :oldboot *features*)' >> makedep.lisp
 	@ echo '(load "nocompil.lisp")' >> makedep.lisp
 	@ echo '(load "bookvol5.lisp")' >> makedep.lisp
Index: src/interp/Makefile.in
===================================================================
--- src/interp/Makefile.in	(wersja 636)
+++ src/interp/Makefile.in	(kopia robocza)
@@ -453,6 +453,7 @@
 	@ echo 3 making ${DEPSYS} 
 	@ $(mkinstalldirs) $(axiom_build_bindir)
 	@ echo '${PROCLAIMS}' > makedep.lisp
+	echo '(setf si::*disable-recompile* t)' >> makedep.lisp
 	@ echo '(push :oldboot *features*)' >> makedep.lisp
 	@ echo '(load "nocompil.lisp")' >> makedep.lisp
 	@ echo '(load "bookvol5.lisp")' >> makedep.lisp
Index: src/interp/bookvol5.pamphlet
===================================================================
--- src/interp/bookvol5.pamphlet	(wersja 636)
+++ src/interp/bookvol5.pamphlet	(kopia robocza)
@@ -682,9 +682,6 @@
   (setq |$currentLine| nil)
   (restart0)
   (|readSpadProfileIfThere|)
-  #+(or :GCL :CCL)
-  (|spad|)
-  #-(or :GCL :CCL)
   (handler-bind ((error #'spad-system-error-handler))
      (|spad|))
 )
@@ -1021,6 +1018,7 @@
 			   (rpages 1000)
 			   (hole 2000) )
   ;; initialize AKCL memory allocation parameters
+  #|
   #+:AKCL
   (progn
     (system:allocate 'cons cons)
@@ -1034,6 +1032,7 @@
     (system:allocate-relocatable-pages rpages)
     (system:set-hole-size hole))
   #-:AKCL
+  |#
   nil)
 
 @
Index: src/interp/nruncomp.boot.pamphlet
===================================================================
--- src/interp/nruncomp.boot.pamphlet	(wersja 636)
+++ src/interp/nruncomp.boot.pamphlet	(kopia robocza)
@@ -224,7 +224,7 @@
   NULL x => x
   x = $NRTaddForm => 5
   k := or/[i for i in 1.. for y in $NRTdeltaList
-            | y.0 = 'domain and y.1 = x and ($found := y)] =>
+            | CAR(y) = 'domain and NTH(1, y) = x and ($found := y)] =>
     $NRTbase + $NRTdeltaLength - k
   nil
 
Index: src/lisp/axiom-lisp.lisp.pamphlet
===================================================================
--- src/lisp/axiom-lisp.lisp.pamphlet	(wersja 636)
+++ src/lisp/axiom-lisp.lisp.pamphlet	(kopia robocza)
@@ -19,8 +19,8 @@
      :use (list (or (find-package "COMMON-LISP")
                     "LISP"))))) 
 
-
 (in-package "AXIOM-LISP")
+;;; (shadow 'elt)
 (do-symbols (x "AXIOM-LISP") (export (list x)))
 
 (export '(quit chdir |getEnv| |load_quietly| get-current-directory
@@ -31,11 +31,17 @@
 (progn
     (import '(LISP::LAMBDA-CLOSURE))
     (export '(LISP::LAMBDA-CLOSURE))
+    (setq si::*disable-recompile* t)
 )
 @
 
 <<*>>=
 (in-package "AXIOM-LISP")
+#|(defun elt(x n)
+    (if (consp x)
+         (nth n x)
+	 (COMMON-LISP::elt x n)))
+|#
 #+:sbcl
 (progn
      (defvar *saved-terminal-io* *terminal-io*)
@@ -271,8 +277,15 @@
            ;;; gcl-2.6.7
            (probe-file file))
 |#
-#+:GCL (if (not (equal (file-kind (namestring file)) -1))
-           (truename file))
+#+:GCL (let* ((fk (file-kind (namestring file)))
+              (fname (trim-directory-name (namestring file)))
+	      (dname (pad-directory-name fname)))
+           (cond
+	      ((equal fk 1)
+                (truename dname))
+	      ((equal fk 0)
+	        (truename fname))
+	      (t nil)))
 #+:sbcl (if (sb-unix::unix-file-kind file) (truename file))
 #+:openmcl (probe-file file)
 #+:clisp(let* ((fname (trim-directory-name (namestring file)))
Index: src/lisp/Makefile.in
===================================================================
--- src/lisp/Makefile.in	(wersja 636)
+++ src/lisp/Makefile.in	(kopia robocza)
@@ -36,16 +36,19 @@
 	echo '(load "axiom-package.lisp")' \
 	     '(setq compiler::*default-system-p* t)' \
 	     '(compile-file "axiom-lisp.lisp")' | $(AXIOM_LISP)
-	echo '(compiler::link (quote ("axiom-package.lisp" "axiom-lisp.$(OBJEXT)")) "lisp" ' \
+	echo '(compiler::link nil "prelisp" ' \
               ' (format nil "(progn (let ((*load-path* (cons ~S *load-path*))'\
                                         ' (si::*load-types* ~S))' \
                                        ' (compiler::emit-fn t))' \
                                   ' (when (fboundp (quote si::sgc-on))' \
-                                        ' (si::sgc-on t))' \
+                                        ' (si::sgc-on nil))' \
                                   ' (setq compiler::*default-system-p* t))"' \
                       ' si::*system-directory* (quote (list ".lsp")))' \
                '  "$(lisp_c_objects) @axiom_c_runtime_extra@")' \
             | $(AXIOM_LISP)
+	echo '(setq si::*disable-recompile* t) (load "axiom-package.lisp") (load "axiom-lisp.$(OBJEXT)")' \
+	     '(in-package "AXIOM-LISP") (save-core "lisp$(EXEEXT)")' \
+	    | ./prelisp$(EXEEXT)
 	$(INSTALL_PROGRAM) lisp$(EXEEXT) $(OUT)
 	$(STAMP) $@
 
Index: src/lisp/Makefile.pamphlet
===================================================================
--- src/lisp/Makefile.pamphlet	(wersja 636)
+++ src/lisp/Makefile.pamphlet	(kopia robocza)
@@ -81,16 +81,19 @@
 	echo '(load "axiom-package.lisp")' \
 	     '(setq compiler::*default-system-p* t)' \
 	     '(compile-file "axiom-lisp.lisp")' | $(AXIOM_LISP)
-	echo '(compiler::link (quote ("axiom-package.lisp" "axiom-lisp.$(OBJEXT)")) "lisp" ' \
+	echo '(compiler::link nil "prelisp" ' \
               ' (format nil "(progn (let ((*load-path* (cons ~S *load-path*))'\
                                         ' (si::*load-types* ~S))' \
                                        ' (compiler::emit-fn t))' \
                                   ' (when (fboundp (quote si::sgc-on))' \
-                                        ' (si::sgc-on t))' \
+                                        ' (si::sgc-on nil))' \
                                   ' (setq compiler::*default-system-p* t))"' \
                       ' si::*system-directory* (quote (list ".lsp")))' \
                '  "$(lisp_c_objects) @axiom_c_runtime_extra@")' \
             | $(AXIOM_LISP)
+	echo '(setq si::*disable-recompile* t) (load "axiom-package.lisp") (load "axiom-lisp.$(OBJEXT)")' \
+	     '(in-package "AXIOM-LISP") (save-core "lisp$(EXEEXT)")' \
+	    | ./prelisp$(EXEEXT)
 	$(INSTALL_PROGRAM) lisp$(EXEEXT) $(OUT)
 	$(STAMP) $@
 

--ELM1183934156-23305-0_--

\start
Date: Mon, 09 Jul 2007 00:53:52 +0200
From: Ralf Hemmecke
To: Stephen Wilson
Subject: Re: Literate programming and Provisos

> One can think of a continuation is an abstract object representing the
> remainder of a computation.  We normally think about functions
> returning values, with continuations we pass the value to the
> remainder of the computation.

Oh, are you trying to say that in order to pass some value to the 
continuation, I don't need to know what the ongoing computation actually 
does? How do you think that fits in a typed environment like Spad/Aldor?

> It is common to have a continuation
> represented explicitly as an argument.  In Spad or Aldor, this might
> be written as:
> 
>  add-cc (c : Continuation(Integer), n : Integer) : Integer ==
>     c(n + 1)

The first think that came to my mind when I saw that was to represent

Continuation(Integer)

by something like

Integer -> Generator(SomeType)

where SomeType for your example above would be Integer, but as you said, 
a continuation is not a function so its return type is rather unclear.
So how could (for your code) the compiler check that c(n+1) is indeed of 
type Integer (as add-cc claims). Continuation(Integer) says something 
about the input argument, but not about some return type.

Anyway, even if I could model some continuation by

INTYPE -> Generator(OUTTYPE)

there is an issue with destructiveness. Aldor/Spad is not a functional 
language. So if c is a continuation and I call

foo(c); bar(c);

then usually bar doesn't get the some "continuation" as foo gets, since 
foo might change that computation destructively (as is usually the case 
for Generator in Aldor).

\start
Date: 08 Jul 2007 19:45:47 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: Re: Literate programming and Provisos

Ralf Hemmecke writes:

> > One can think of a continuation is an abstract object representing the
> > remainder of a computation.  We normally think about functions
> > returning values, with continuations we pass the value to the
> > remainder of the computation.
> 
> Oh, are you trying to say that in order to pass some value to the
> continuation, I don't need to know what the ongoing computation
> actually does? How do you think that fits in a typed environment like
> Spad/Aldor?

The basic issue in terms of typing continuation uses the property
that the continuation does not return (so does not have a type, per
say).  Strongly typed languages take different approaches to dealing
with these types of things.  Consider how Aldor, for example, deals
with goto, return, etc, by declaring the terms to have type Exit with
special rules to unify that type within a local context.

A similar approach may be possible in Spad/Aldor, but there is
certainly work to be done.  Im going to look at `Typing First-Class
Continuations in ML':
 
  http://portal.acm.org/citation.cfm?id=99608

ML most certainly has a strong/static type system with interesting
connections with Spad/Aldor (the module system and functors).  I see
no reason at this point to think that continuations cant play
gracefully with Spads type system.

> > It is common to have a continuation
> > represented explicitly as an argument.  In Spad or Aldor, this might
> > be written as:
> >  add-cc (c : Continuation(Integer), n : Integer) : Integer ==
> >     c(n + 1)
> 
> The first think that came to my mind when I saw that was to represent
> 
> Continuation(Integer)
> 
> by something like
> 
> Integer -> Generator(SomeType)
> 
> where SomeType for your example above would be Integer, but as you
> said, a continuation is not a function so its return type is rather
> unclear.

Even though a continuation does not return, that does not preclude the
possibility of assigning a meaningful type.

Note that a generator is not equivalent to a continuation, it is a
special case of what you can express using continuations as
primitives.  There are several online tutorials about continuations in
various languages.  I think Scheme is a good place to explore the
idea.  Perhaps the following might be a decent place to start:

  http://community.schemewiki.org/?call-with-current-continuation


> So how could (for your code) the compiler check that c(n+1) is indeed
> of type Integer (as add-cc claims). Continuation(Integer) says
> something about the input argument, but not about some return type.

I gave add-cc the type Integer because add-cc is not under any
obligation to call the continuation.  It could return like any other
function.

> Anyway, even if I could model some continuation by
> 
> INTYPE -> Generator(OUTTYPE)
> 
> there is an issue with destructiveness. Aldor/Spad is not a functional
> language. So if c is a continuation and I call
> 
> foo(c); bar(c);
> 
> then usually bar doesn't get the some "continuation" as foo gets,
> since foo might change that computation destructively (as is usually
> the case for Generator in Aldor).

I am not sure I follow.  I would imagine that a continuation in
Spad/Aldor would be an opaque object not subject to any kind of
destructive operation.  The `change in computation' as you witness in
Aldors Generator domain, can be viewed as a result of forming a
closure over some set of continuations, one of which is `current'.  A
generator is not a continuation, its a function+closure over the next
path of computation.


I hope some of this is clear.  Perhaps I can think of a meaningful
syntax for these ideas in Spad/Aldor and give an example of how a
Generator could be defined in terms of continuations, type system
technicalities not withstanding.

\start
Date: Sun, 8 Jul 2007 17:22:24 -0700
From: Richard Harke
To: list
Subject: Re: Why did Axiom fail in the 1990s?

> Is he this one?
>
> http://en.wikipedia.org/wiki/Lou_Gerstner
>
> They say he virtually saved IBM from going out of business. If this is
> true (I don't know), then he did more good than bad, in my opinion.
>
> > Scratchpad didn't die a natural death. It was killed by short term,
> > make it pay, thinking. Notre Dame took 300 years to build. Given the
>
> http://en.wikipedia.org/wiki/Notre_Dame_de_Paris
>
> They say it started in 1160 and ended in 1345, so it's only 185 years
> and also it was financed probably by the king and the bishop, but
> definitely not by a private company.
>
> > short term mindset Lou would rather have built it overnight as a
> > prefab wooden house in a suburb using conventional tools and selling
> > for a nice markup.
>
> To save money of IBM. I think it's fair.
In the nineties, it was my understanding that to get Axiom from IBM, you
had to buy their workstation to run it.They refused to port it. They didn't 
think of it as a software product but rather a help to selling their 
hardware.
Same mistake that Macsyma made.

Richard

\start
Date: 08 Jul 2007 20:42:10 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: Re: 2.7.0 reports
Cc: Gabriel Dos Reis

Hello Camm,

Another issue has come up, again w.r.t the handling of logical
operations.

I hope these reports are not just pointing out known issues!  I only
wish I had the knowledge to fix them myself.


==--- test.lisp ---

(defun test (x) 
  (when (or (and (consp x) (eq (car x) 'X) t)
            (and (consp x) (eq (car x) '|x|) t))
    'OK))

==-----------------

Note that if the T's are dropped from the AND expressions, the
function behaves as expected.


steve:tmp> gcl
GCL (GNU Common Lisp)  2.7.0 ANSI    Jul  7 2007 19:13:09
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

Temporary directory for compiler files set to /tmp/

>(compile-file "test.lisp")

;; Compiling test.lisp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling test.o.
#P"/home/steve/tmp/test.o"
NIL
NIL

>(load "test.o")

;; Loading test.o
 ;; start address -T 0xb4acd8 ;; Finished loading test.o
80

>(test '(X))

OK

>(test '(|x|))

NIL

>(disassemble 'test)

;; Compiling /tmp/gazonk_18523_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_18523_0.o.

#include "gazonk_18523_0.h"
void init_code(){do_init((void *)VV);}
/*      local entry for function TEST   */

static object LI1(V2)

object V2;
{        VMB1 VMS1 VMV1
        goto TTL;
TTL:;
        if(!(consp((V2)))){
        goto T2;}
        /*(CAR X)*/
        {object V4;
        V4= (V2);
        V3= ((V4))->c.c_car;}
        /* END (CAR X)*/
        if(!((V3)==(((object)VV[0])))){
        goto T2;}
        {object V5 = ((object)VV[1]);VMR1
        (V5);}
        goto T2;
T2:;
        {object V6 = Cnil;VMR1
        (V6);}
        return Cnil;
}
#(#(X OK
    (%INIT
     . #((LET ((*DISABLE-RECOMPILE* T))
           (MFSFUN 'TEST 0 1 0)
           (ADD-HASH 'TEST '((T) SYMBOL)
               '((CAR (LIST) T) (EQ (T T) BOOLEAN) (CONSP (T) T))
COMMON-LISP-USER
LISPLAMBDA!
           ,DECLA,OPTIMIZ,SAFETY        ,BLOCK
                                              TEST      ,IF     ,OR
!,AN!,CONSP-    !,E!,CAR!,QUOTE-!,T
/-      12
          x,PROG2
                 OK '/tmp/gazonk_18523_0.lsp))
         (DO-RECOMPILE)))))
static object LI1();
#define VMB1 object  V3;
#define VMS1
#define VMV1
#define VMR1(VMT1) return(VMT1);
#define VM1 0
static void * VVi[3]={
#define Cdata VV[2]
(void *)(LI1)
};
#define VV (VVi)

/tmp/gazonk_18523_0.o:     file format elf32-i386

Disassembly of section .text:

00000000 <init_code>:
   0:   68 00 00 00 00          push   $0x0
   5:   e8 fc ff ff ff          call   6 <init_code+0x6>
   a:   58                      pop    %eax
   b:   c3                      ret    

0000000c <LI1>:
   c:   8b 54 24 04             mov    0x4(%esp),%edx
  10:   81 fa 00 00 00 00       cmp    $0x0,%edx
  16:   74 25                   je     3d <LI1+0x31>
  18:   81 fa ff ff ff bf       cmp    $0xbfffffff,%edx
  1e:   77 1d                   ja     3d <LI1+0x31>
  20:   f6 02 01                testb  $0x1,(%edx)
  23:   74 08                   je     2d <LI1+0x21>
  25:   81 3a ff ff ff bf       cmpl   $0xbfffffff,(%edx)
  2b:   76 10                   jbe    3d <LI1+0x31>
  2d:   a1 00 00 00 00          mov    0x0,%eax
  32:   39 42 04                cmp    %eax,0x4(%edx)
  35:   75 06                   jne    3d <LI1+0x31>
  37:   a1 04 00 00 00          mov    0x4,%eax
  3c:   c3                      ret    
  3d:   b8 00 00 00 00          mov    $0x0,%eax
  42:   c3                      ret    
NIL

>(defun test (x) 
    (when (or (and (consp x) (eq (car x) 'X))
              (and (consp x) (eq (car x) '|x|)))
      'OK))

TEST

>(compile 'test)

;; Compiling /tmp/gazonk_18523_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_18523_0.o.
;; Loading /tmp/gazonk_18523_0.o
 ;; start address -T 0xb4bd68 ;; Finished loading /tmp/gazonk_18523_0.o
#<compiled-function TEST>
NIL
NIL

>(test '(X))

OK

>(test '(|x|))

OK

\start
Date: 08 Jul 2007 21:02:05 -0400
From: Stephen Wilson
To: list
Subject: Re: 2.7.0 reports
Cc: Camm Maguire, Gabriel Dos Reis

Stephen Wilson writes:

> Hello Camm,
> 
> Another issue has come up, again w.r.t the handling of logical
> operations.

This is a false alarm.

Currently on make install gcl does not copy (at least)
$GCLROOT/bin/gcl and $GCLROOT/clcs/packages.lisp to $PREFIX/bin/gcl
and $PREFIX/lib/gcl-2.7.0/clcs/packages.lisp, respectively.

I have been copying these files by hand and must have missed a step.
My report was w.r.t a gcl approximately two days old.  Latest gclcvs
appears to be OK.


Appologies for the mistake.

\start
Date: Sun, 8 Jul 2007 21:40:40 -0400
From: Bill Page
To: Stephen Wilson
Subject: Re: Unions in Spad

On 08 Jul 2007 15:21:52 -0400, Stephen Wilson wrote:
>
> Spad, internally, has two notions of Unions.  The first variety might
> be termed `regular', the other is, not surprisingly, termed `new'.
>
> Regular Unions do not have tags associated with branches. For example:
>
>       Union(Integer, String)
>
> New Unions have tags, as in
>
>       Union(int: Integer, str: String)
>
> The shortcoming is how these two flavors interact.  Currently, Unions
> are of one kind or the other.  But this fact is nowhere asserted, and
> blending the two types leads to obscure errors.  For example:
>
>      Union(int: Integer, String)
>
> I would appreciate any input if the above `hybrid' Union is useful or
> desirable.
>

I think it is undesirable.

> If so, I have a strategy to make such Unions usable (but it may be a
> while before I find the time to implement it). If not, then there is
> an easy fix to assert the uniformity of Union branches.
>

I think mixed union constructions should be consider syntax errors.

Also it seems to me that the untagged union construction should be
flagged by the SPAD compiler as deprecated so that the library code
can eventually be updated to use the new tagged form that is
compatible with Aldor.

One might be tempted to argue that the untagged form is more readable
but I think the complications associated with the semantics of things
like:

   Union(Integer,Integer)

out weigh any linguistic advantage.

\start
Date: Sun, 8 Jul 2007 21:50:08 -0400
From: Bill Page
To: Stephen Wilson
Subject: Re: Unions in Spad

On 08 Jul 2007 17:51:54 -0400, Stephen Wilson wrote:
> ...
> But I think Aldor's treatment of selectors as elements of type
> Enumeration is worth looking at and possibly worth making explicit in
> Spad.  Spad seems to follow similar semantics conceptually but I cant
> see the direct connection to the type system at this time.
>

Gaby noted in another thread that Spad does in fact already implement
Enumeration as a basic data type even though it is completely
undocumented at the user level.

But really I think the concept of "selectors" in both Union and Record
is at best a legacy of earlier days in programming language design. It
makes much for sense to me to define Union and Record as co-limit and
limit in the sense of category theory. Then Union selectors are just
injections operations and Record selectors are projection operations
which are exported like any other function from these types. There is
no need for any lower level language construct.

\start
Date: Sun, 8 Jul 2007 21:04:46 -0500
From: Tim Daly
To: Richard Harke
Subject: Literate programming and Provisos

Up until we made an agreement with NAG, Scratchpad, the pre-Axiom
system, was being developed primarly on the IBM/RS6000. However, I
ported it to run on everything I could touch including several
different lisps (allegro, golden common, zetalisp, symbolics common
lisp, akcl, lispvm, spicelisp (cmucl), lucid common lisp, etc) on
several different platforms (SUN solaris, IBM/VM 370, IBM/RT,
Symbolics, and even a DJGPP port on DOS on a toshiba laptop).  The
code is very generic lisp at this point, uses almost no special
features of the native system, and was regularly cross-compiled on
multiple platforms in parallel. I even managed to get the algebra 
running on a linux system. Linux came on 3 diskettes.

I sent out copies of Scratchpad to people worldwide using different
kinds of platforms and lisps. The distribution included source code.
Scratchpad was viewed as a research platform, not as a "product".
There was competition but it was a very small world and everyone
knew everyone else. Stephen Watt was both a Maple developer and
a Scratchpad developer. Barry Trager had worked on pre-Macsyma
under Joel Moses at MIT.

That said, I had one of the first IBM/RS6000s. I had to have my office
specially modified with a motion detector and a high security lock to
have it installed. A funny war story is that to install the AIX opsys
I needed a terminal connected to a serial port (a TTY device) and the
only thing we could find in the building was a TI silent 700 portable
TTY-like device that used heat-sensitive paper. Fortunately the AIX
lead developers were in the same building.

I negotiated with Scott Fahlman on various CMUCL topics. He wanted
to get a set of RS6000s for his research project but I was unable to
close the deal. CMUCL was using the IBM/RT which was basically a hair
dryer that occasionally executed an instruction.

I'm unaware of any hardware specific version sold from IBM. In fact,
I'm unaware that IBM sold Scratchpad. I generally shipped copies free
for the asking. On a couple occasions I installed it on an IBM/RT and
shipped the whole RT.  But Scratchpad/Axiom would bury a 500khz PC.
It took many weeks and many tricks to get it running on DJGPP/DOS on
that Toshiba. So I can see an argument for top-of-the-line hardware.
Maybe a 6Mhz machine with 256k of memory. Ah, those were the days.

\start
Date: 08 Jul 2007 22:09:03 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: Unions in Spad

Bill Page writes:

> On 08 Jul 2007 15:21:52 -0400, Stephen Wilson wrote:
> >
> > Spad, internally, has two notions of Unions.  The first variety might
> > be termed `regular', the other is, not surprisingly, termed `new'.
> >
> > Regular Unions do not have tags associated with branches. For example:
> >
> >       Union(Integer, String)
> >
> > New Unions have tags, as in
> >
> >       Union(int: Integer, str: String)
> >
> > The shortcoming is how these two flavors interact.  Currently, Unions
> > are of one kind or the other.  But this fact is nowhere asserted, and
> > blending the two types leads to obscure errors.  For example:
> >
> >      Union(int: Integer, String)
> >
> > I would appreciate any input if the above `hybrid' Union is useful or
> > desirable.
> >
> 
> I think it is undesirable.

OK.  I personally agree.

> > If so, I have a strategy to make such Unions usable (but it may be a
> > while before I find the time to implement it). If not, then there is
> > an easy fix to assert the uniformity of Union branches.
> >
> 
> I think mixed union constructions should be consider syntax errors.

I personally agree as well.  Unfortunately, the current Spad parser
is, well, difficult to change.  I can check the uniformity of Union
branches at a post-parsing stage to at least get the assertion into
the system.  Perhaps in time my new parser could be used as a full
replacement for the current one.  

> Also it seems to me that the untagged union construction should be
> flagged by the SPAD compiler as deprecated so that the library code
> can eventually be updated to use the new tagged form that is
> compatible with Aldor.

There is a lot of code which uses the untagged union, so the
conversion would be a fair bit of work.  I could experiment with such
a change in the Axisp repo and solicit everyones help in changing the
Algebra.  In time, we might be able to get a changeset together which
could be applied to Silver.  Any thoughts on this?

> One might be tempted to argue that the untagged form is more readable
> but I think the complications associated with the semantics of things
> like:
> 
>    Union(Integer,Integer)
> 
> out weigh any linguistic advantage.

Absolutely, but this too could be flagged as an error by the compiler.

\start
Date: Sun, 8 Jul 2007 22:18:36 -0400
From: Bill Page
To: Stephen Wilson
Subject: Re: Unions in Spad

On 08 Jul 2007 22:09:03 -0400, Stephen Wilson wrote:
>...
> Bill Page wrote:
> > Also it seems to me that the untagged union construction should be
> > flagged by the SPAD compiler as deprecated so that the library code
> > can eventually be updated to use the new tagged form that is
> > compatible with Aldor.
>
> There is a lot of code which uses the untagged union, so the
> conversion would be a fair bit of work.  I could experiment with such
> a change in the Axisp repo and solicit everyones help in changing the
> Algebra.  In time, we might be able to get a changeset together which
> could be applied to Silver.  Any thoughts on this?
>

I think it is a good idea but that it need not be a high priority.
Perhaps related but much more important to me would be a general
cleanup of the output of the SPAD compiler. Right now it might be at
best said to be "spectacularly obscure". (I recall Gaby quoting one of
his students who shared this view of the SPAD output and error
messages.). It seems to me that the current diagnostic output was
intended to be intelligible only to someone who was familiar with the
internal design of the SPAD compiler. Surely it is possible to produce
compiler output that makes sense to someone who only programs at the
SPAD level.

\start
Date: 08 Jul 2007 22:27:00 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: Unions in Spad

Bill Page writes:

> On 08 Jul 2007 17:51:54 -0400, Stephen Wilson wrote:
> > ...
> > But I think Aldor's treatment of selectors as elements of type
> > Enumeration is worth looking at and possibly worth making explicit in
> > Spad.  Spad seems to follow similar semantics conceptually but I cant
> > see the direct connection to the type system at this time.
> >
> 
> Gaby noted in another thread that Spad does in fact already implement
> Enumeration as a basic data type even though it is completely
> undocumented at the user level.

Oh, I know there exists an Enumeration type.  But not only is it not
documented, its also unused.  Perhaps it is used to interact with
Aldor compiled libraries?  I'll review the mailing list archives.

> But really I think the concept of "selectors" in both Union and Record
> is at best a legacy of earlier days in programming language design. It
> makes much for sense to me to define Union and Record as co-limit and
> limit in the sense of category theory. Then Union selectors are just
> injections operations and Record selectors are projection operations
> which are exported like any other function from these types. There is
> no need for any lower level language construct.

Its been a while since I brushed up on Category Theory.  Yet another
todo item.  I thought that limit and co-limit were defined w.r.t an
index category.  How does this differ from the notion that an instance
of Enumeration type serves as the index into a record or union, and
how do the morphisms from the objects of the index category to the
objects of the category representing the elements of a union/record
differ from normal "selectors"?  Im probably missing some details, but
from my modest understanding of Category Theory, I feel the
categorical treatment is just a different vernacular to express the
same thing.  There are undoubtedly generalizations Im missing, but I
am curious how they might be expressed meaningfully in a programming
language.

Perhaps an example of how you envision this foundation working in
Spad?


\start
Date: 08 Jul 2007 22:34:16 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: Unions in Spad

Bill Page writes:
> I think it is a good idea but that it need not be a high priority.

I agree as well.  If I worked in that direction it would be a side
project which would get my attention only on occasion. 

> Perhaps related but much more important to me would be a general
> cleanup of the output of the SPAD compiler. Right now it might be at
> best said to be "spectacularly obscure". (I recall Gaby quoting one of
> his students who shared this view of the SPAD output and error
> messages.). It seems to me that the current diagnostic output was
> intended to be intelligible only to someone who was familiar with the
> internal design of the SPAD compiler. Surely it is possible to produce
> compiler output that makes sense to someone who only programs at the
> SPAD level.

I wish I had the motivation to do the work and refit the current
compiler with a proper error facility.  This is just another thing I
hope to solve `for free' as a consequence of the Lisp rewrite.

\start
Date: Sun, 8 Jul 2007 23:07:11 -0400
From: Bill Page
To: Stephen Wilson
Subject: Re: Unions in Spad

On 08 Jul 2007 22:34:16 -0400, Stephen Wilson wrote:
> ...
> Bill Page writes:
> > > Perhaps related but much more important to me would be a general
> > cleanup of the output of the SPAD compiler. Right now it might be at
> > best said to be "spectacularly obscure". (I recall Gaby quoting one of
> > his students who shared this view of the SPAD output and error
> > messages.). It seems to me that the current diagnostic output was
> > intended to be intelligible only to someone who was familiar with the
> > internal design of the SPAD compiler. Surely it is possible to produce
> > compiler output that makes sense to someone who only programs at the
> > SPAD level.
>
> I wish I had the motivation to do the work and refit the current
> compiler with a proper error facility.  This is just another thing I
> hope to solve `for free' as a consequence of the Lisp rewrite.
>

>From the point of view of the SPAD programmer that is just as good but
presumably much harder to achieve. :-) So I can only wish you success.

\start
Date: Sun, 8 Jul 2007 23:37:06 -0400
From: Bill Page
To: Stephen Wilson
Subject: Re: Unions in Spad

On 08 Jul 2007 22:27:00 -0400, Stephen Wilson wrote:
> ...
> Bill Page writes:
> > But really I think the concept of "selectors" in both Union and Record
> > is at best a legacy of earlier days in programming language design. It
> > makes much for sense to me to define Union and Record as co-limit and
> > limit in the sense of category theory. Then Union selectors are just
> > injections operations and Record selectors are projection operations
> > which are exported like any other function from these types. There is
> > no need for any lower level language construct.
>
> Its been a while since I brushed up on Category Theory.  Yet another
> todo item.  I thought that limit and co-limit were defined w.r.t an
> index category.

Category theory is a BIG subject so unless you are motived in a more
general manner I would recommend that you focus on the more recent use
of category theory in computer science. Although there are several
others to choose from, I think one very good place to start or to
review is the following book by Benjamin Pierce:

@BOOK{PIERCE91,
  author = {Benjamin C. Pierce},
  title = {Basic Category Theory for Computer Scientists},
  year = {1991},
  publisher = {MIT Press},
  fullisbn = {0-262-66071-7},
  orderinginfo = {MIT PRESS 55 Hayward ST. Cambridge Mass 02142 USA
                  800-356-0343},
  europeinfo = {14 Bloomsbury Square London WC1A 2LP U.K. Facsimile:
                  071-404-0601},
  plclub = {Yes},
  bcp = {Yes},
  keys = {books}
}

You might also be interested in some of his papers on "Intersection
and Union Types". See his website at:

http://www.cis.upenn.edu/~bcpierce/papers/index.shtml

Limits and co-limits are defined in a very general manner as type of
universal construction. For a very quick and mostly adequate
introduction see:

http://en.wikipedia.org/wiki/Limit_(category_theory)

> How does this differ from the notion that an instance
> of Enumeration type serves as the index into a record or union, and
> how do the morphisms from the objects of the index category to the
> objects of the category representing the elements of a union/record
> differ from normal "selectors"?

The notion of product and co-product that is most relevant is found in
the category SET. But I think it is easy to argue that a category with
much less structure is a better starting point for the goals of Axiom
and a language like SPAD.

> Im probably missing some details, but
> from my modest understanding of Category Theory, I feel the
> categorical treatment is just a different vernacular to express the
> same thing.  There are undoubtedly generalizations Im missing, but I
> am curious how they might be expressed meaningfully in a programming
> language.

I agree that very often category theory (as currently used in computer
science) is "just a different vernacular to express the same thing" as
can be expressed in other more conventional ways. But the advantage
that I see in the categorical language is the very high level of
abstraction.

>
> Perhaps an example of how you envision this foundation working in
> Spad?
>

The Record type should export operations that correspond to what would
otherwise be called selectors, e.g.

Record(A:Integer, B:String)

should export

  A: % -> Integer
  B: % -> String

inaddition to the uniquely defined higher-order operation

  product: (A:Type, A->X,A->Y) -> (A->%)

arising from categorical universality.

See the example at:

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

Similarly

Union(A:Integer, B:Integer)

should export

  A: Integer -> %
  B: String -> %
  sum: (A:Type, X->A,Y->A) -> (% -> A)

\start
Date: Sun, 8 Jul 2007 23:53:26 -0400
From: Bill Page
To: Alasdair McAndrew
Subject: Re: Axiom, FriCAS, forks and teeth

Alasdair,

On 7/8/07, you wrote:
> So I go away for an internet-free weekend, and what do I find when I come
> back?  A fork of Axiom with its own name, and people on the mailgroup baring
> their teeth at each other in a most unseemly manner.  So, so, fork away...
> but what I want to know is - where does this leave me, a common-or-garden
> user?

Personally I think you should view this as a positive development.
Clearly people care passionately enough about Axiom to argue about it
and to commit very significant efforts in the directions that they
most believe in, so one way or another it's future is now more assured
than it was before.

>  Learning a CAS - any CAS - really well, is a non-trivial task, and
> after spending much of the last month or so finding my way around Axiom,
> this forking business has me feeling very uncertain as to where - or whether
> - I should put any more time into these projects.  I have come to like Axiom
> very much indeed, but if it and its users are going to split into
> acrimonious groups, I shall feel very unsure of where my loyalties lie.

As an Axiom user I do not think you need to be very concerned about
where to place your loyalties. In spite of the differences in
approach, both the original Axiom project and the new FriCAS fork
still have largely compatible goals - a better and more reliable open
source computer algebra system.

> Maybe I should go back to Maxima...
>

I like Maxima too. But Axiom is different. By now you know all the reasons.

> I'm very nervy about all this.
>

Please don't be. From your vantage point you should be able to enjoy
all of this "FriCAS fracas" and ultimately benefit from one or the
other of these projects. There is no reason to think that the Axiom
project is going to disappear or that somehow that you will be asked
to take sides in some emotional debate.

\start
Date: 08 Jul 2007 23:57:16 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: Unions in Spad

Bill Page writes:

> On 08 Jul 2007 22:27:00 -0400, Stephen Wilson wrote:
> > ...
> > Bill Page writes:
> > > But really I think the concept of "selectors" in both Union and Record
> > > is at best a legacy of earlier days in programming language design. It
> > > makes much for sense to me to define Union and Record as co-limit and
> > > limit in the sense of category theory. Then Union selectors are just
> > > injections operations and Record selectors are projection operations
> > > which are exported like any other function from these types. There is
> > > no need for any lower level language construct.
> >
> > Its been a while since I brushed up on Category Theory.  Yet another
> > todo item.  I thought that limit and co-limit were defined w.r.t an
> > index category.
> 
> Category theory is a BIG subject so unless you are motived in a more
> general manner I would recommend that you focus on the more recent use
> of category theory in computer science. Although there are several
> others to choose from, I think one very good place to start or to
> review is the following book by Benjamin Pierce:
> 
> @BOOK{PIERCE91,
>   author = {Benjamin C. Pierce},
>   title = {Basic Category Theory for Computer Scientists},
>   year = {1991},
>   publisher = {MIT Press},
>   fullisbn = {0-262-66071-7},
>   orderinginfo = {MIT PRESS 55 Hayward ST. Cambridge Mass 02142 USA
>                   800-356-0343},
>   europeinfo = {14 Bloomsbury Square London WC1A 2LP U.K. Facsimile:
>                   071-404-0601},
>   plclub = {Yes},
>   bcp = {Yes},
>   keys = {books}
> }
> 
> You might also be interested in some of his papers on "Intersection
> and Union Types". See his website at:
> 
> http://www.cis.upenn.edu/~bcpierce/papers/index.shtml
> 
> Limits and co-limits are defined in a very general manner as type of
> universal construction. For a very quick and mostly adequate
> introduction see:
> 
> http://en.wikipedia.org/wiki/Limit_(category_theory)

OK.  Thanks for the suggestions!  Unsure when I will have time to
revisit this subject, but as I said, it is on my todo list.

[...]
> >
> > Perhaps an example of how you envision this foundation working in
> > Spad?
> >
> 
> The Record type should export operations that correspond to what would
> otherwise be called selectors, e.g.
> 
> Record(A:Integer, B:String)
> 
> should export
> 
>   A: % -> Integer
>   B: % -> String
> 
> inaddition to the uniquely defined higher-order operation
> 
>   product: (A:Type, A->X,A->Y) -> (A->%)
> 
> arising from categorical universality.
> 
> See the example at:
> 
> http://wiki.axiom-developer.org/SandBoxLimitsAndColimits
> 
> Similarly
> 
> Union(A:Integer, B:Integer)
> 
> should export
> 
>   A: Integer -> %
>   B: String -> %
>   sum: (A:Type, X->A,Y->A) -> (% -> A)

OK.  This is quite intelligible and perfectly reasonable.  I was
working with the assumption that you wanted a general mechanism to
express categorical concepts directly without recourse to builtin
primitives like Record or Union.  I would firmly support the
structuring of said primitives over a category based theory.

Concerning the compiler rewrite, I will most certainly seek your
advice when these issues become a practical concern.  I'm trying to
develop a `world view' of the features and facilities others would
like/expect.  Even if I cant implement all the features in one shot, I
can avoid coding the system into a corner so that future extensions
are feasible.

\start
Date: Mon, 9 Jul 2007 00:02:40 -0500
From: Tim Daly
To: Stephen Wilson
Subject: defintrf.spad compiler bug

Stephen,

Thanks for the posted diff-Naur patch.

I've applied this patch locally and am testing it.
The regress script should highlight all places where this changes
the behavior of the algebra code. If it is more than the defintrf
file I'll let you know.

Once it passes local testing I'll push it out to git and svn.

\start
Date: Mon, 9 Jul 2007 13:40:52 +0200 (CEST)
From: Waldek Hebisch
To: Stephen Wilson
Subject: Re: Unions in Spad

Stephen Wilson wrote:
> Bill Page writes:
> 
> > On 08 Jul 2007 15:21:52 -0400, Stephen Wilson wrote:
> > > If so, I have a strategy to make such Unions usable (but it may be a
> > > while before I find the time to implement it). If not, then there is
> > > an easy fix to assert the uniformity of Union branches.
> > >
> > 
> > I think mixed union constructions should be consider syntax errors.
> 
> I personally agree as well.  Unfortunately, the current Spad parser
> is, well, difficult to change.  I can check the uniformity of Union
> branches at a post-parsing stage to at least get the assertion into
> the system.  Perhaps in time my new parser could be used as a full
> replacement for the current one.  
> 

A little nitpick: if mixed union constructions are considered errors
for me it is clearly a semantic error.  I think it is better to catch
such errors on a post-parsing stage.  Why this may matter: syntax
errors frequently leave parser in a confused state, making hard to
detect other errors.   Also for users is seem easier to have simple
syntax + set of semantic constraints than to encode constraints
in syntax.

\start
Date: Mon, 9 Jul 2007 08:00:14 -0500
From: Tim Daly
To: Stephen Wilson
Subject: defintrf.spad compiler bug

Stephen,

Your patch also changes:
 DFINTTLS NIPROB   OPTPROB   PATTERN2 PMDOWN  PMINS    MHROWRED GENEEZ
 GHENSEL  INMODGCD INNMFACT  INTHERTR LAUPOL  MDDFACT  MONOTOOL PGCD
 PLEQN    PMPLCAT  PMQFCAT   RDETR    REAL    SUBRESP  INTPACK  E04AGNT 
 FFNBP    FPARFRAC IR        OPTPACK  PATTERN PMKERNEL AF       APPRULE 
 EF       ESTOOLS  FC FS2UPS GAUSSFAC INTAF   INTPAF   INTPM    PMFS 
 RDEEF    WUTSET   DFINTTLS  FS2EXPXP LAPLACE MODE1    COMBF    D01AGNT 
 SOLVETRA QCMPACK  SFQCMPK   FFCGP    D02AGNT PSETPK

I'm going to rebuild and look for the details of these changes.

\start
Date: 09 Jul 2007 11:08:20 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: emit-fn
Cc: list

Greetings!  Just a suggestion, when testing 2.7.0, omit calls to
(emit-fn t).  This was an older signature discovery mechanism which
I'm trying to replace by an automatic algorithm in 2.7.  Already found
and fixed a bug do to the conflicts between new and old.

\start
Date: 09 Jul 2007 11:47:03 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: defintrf.spad compiler bug
Cc: list

Tim Daly writes:

> Stephen,
> 
> Your patch also changes:
>  DFINTTLS NIPROB   OPTPROB   PATTERN2 PMDOWN  PMINS    MHROWRED GENEEZ
>  GHENSEL  INMODGCD INNMFACT  INTHERTR LAUPOL  MDDFACT  MONOTOOL PGCD
>  PLEQN    PMPLCAT  PMQFCAT   RDETR    REAL    SUBRESP  INTPACK  E04AGNT 
>  FFNBP    FPARFRAC IR        OPTPACK  PATTERN PMKERNEL AF       APPRULE 
>  EF       ESTOOLS  FC FS2UPS GAUSSFAC INTAF   INTPAF   INTPM    PMFS 
>  RDEEF    WUTSET   DFINTTLS  FS2EXPXP LAPLACE MODE1    COMBF    D01AGNT 
>  SOLVETRA QCMPACK  SFQCMPK   FFCGP    D02AGNT PSETPK
> 
> I'm going to rebuild and look for the details of these changes.

I started going through what appears to be the same list, will
continue this evening.

In all cases thus far (I have checked about 20% of the cases), the
changes are expected.   They all relate to the emission of
|check-union| forms where a |Record| form is macroexpanded into a
|Record0| call.

If all of these changes are of precicely of this kind, then I feel the
patch is OK.  There is no semantic change to the code, it is simply in
a form which the compiler can handle.

Thanks for your help in testing this!

\start
Date: Mon, 9 Jul 2007 12:00:22 -0400
From: Bill Page
To: Waldek Hebisch
Subject: Re: Unions in Spad

> > Bill Page writes:
> > ...
> > >
> > > I think mixed union constructions should be consider syntax errors.
> >
> Stephen Wilson wrote:
> > I personally agree as well.  Unfortunately, the current Spad parser
> > is, well, difficult to change.  I can check the uniformity of Union
> > branches at a post-parsing stage to at least get the assertion into
> > the system.  Perhaps in time my new parser could be used as a full
> > replacement for the current one.
'> >
>
On 7/9/07, Waldek Hebisch wrote:
> A little nitpick: if mixed union constructions are considered errors
> for me it is clearly a semantic error.  I think it is better to catch
> such errors on a post-parsing stage.  Why this may matter: syntax
> errors frequently leave parser in a confused state, making hard to
> detect other errors.   Also for users is seem easier to have simple
> syntax + set of semantic constraints than to encode constraints
> in syntax.
>

On reflection, I am inclined to agree that it should not be a syntax
error but perhaps for different reasons. Aldor defines a uniform
concept not in Spad called a "keyword argument". Among other things
keyword arguments can be used when calling a function. E.g. the
definition:

   f:(x:Integer)->Integer

allows f to be called like this:

  f(x==10)

Syntactically a construct like "x:Integer" can be used anywhere the
name "Integer" can be used. It associates a "keyword" or tag with a
type but otherwise remains the specification of a type.

So really in Aldor when writes

  Union(x:Integer, y:String)

one is using the same conventions. So as Waldek implied, the fact that
Aldor currently does not allow

  Union(Integer, String)

is not really a syntactic issue but rather a semantic one.

Thinking out load: Perhaps this use of ':' should be given explict
operator semantics so that it could be considered as just a pretty
form of type constructor, e.g.

  Keyword(x:Symbol,T:Type): ... with KeywordCategory ...
    == T add ...

(not withstanding that it's usage here is recursive). Then as a type
it would be easy to insist that a parameter to a constructor be of
this type by requiring KeywordCategory.

Does this make sense?

\start
Date: Mon, 09 Jul 2007 18:26:43 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Unions in Spad

> So really in Aldor when writes
> 
>  Union(x:Integer, y:String)
> 
> one is using the same conventions. So as Waldek implied, the fact that
> Aldor currently does not allow
> 
>  Union(Integer, String)
> 
> is not really a syntactic issue but rather a semantic one.

Unfortunately, the Aldor mailing list is dead. --- No replies to my 
recent question.

http://www.aldor.org/pipermail/aldor-l/2007-July/000643.html

Anyway, I would not say that Aldor does not allow 
"Union(Integer,String)". No hint in the AUG, but look at the error 
message given in
http://lists.nongnu.org/archive/html/axiom-developer/2007-07/msg00181.html

If you rewrite this program to

     U == Union(machInt: MachineInteger, sStr: String);

(just change this line) and then look at the error message.

woodpecker:~/scratch>aldor -laldor -fx aaa.as
"aaa.as", line 13:         if u case MachineInteger then {
                    ..................^
[L13 C19] #1 (Error) Argument 2 of `case' did not match any possible 
parameter type.
     The rejected type is Join(
                 PrimitiveType with
                     ....
     Expected one of:
       -- Enumeration(machInt: Type)
       -- Enumeration(sStr: Type)

It looks as if one also could do

   if u case MachineInteger then ...

with the current Aldor compiler, I just don't know how to type 
"MachineInteger" since the compiler immediately takes the *type* 
MachineInteger and not the *tag* MachineInteger.

Anyway, that usage of MachineInteger is not specified in the AUG so 
maybe one better does not use it that way.

\start
Date: Mon, 9 Jul 2007 12:38:25 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re: Unions in Spad

On 7/9/07, Ralf Hemmecke wrote:
> ...
> Anyway, I would not say that Aldor does not allow
> "Union(Integer,String)". No hint in the AUG, but look at the error
> message given in
> http://lists.nongnu.org/archive/html/axiom-developer/2007-07/msg00181.html
>
> If you rewrite this program to
>
>      U == Union(machInt: MachineInteger, sStr: String);
>
> (just change this line) and then look at the error message.
>
> woodpecker:~/scratch>aldor -laldor -fx aaa.as
> "aaa.as", line 13:         if u case MachineInteger then {
>                     ..................^
> [L13 C19] #1 (Error) Argument 2 of `case' did not match any possible
> parameter type.
>      The rejected type is Join(
>                  PrimitiveType with
>                      ....
>      Expected one of:
>        -- Enumeration(machInt: Type)
>        -- Enumeration(sStr: Type)
>
> It looks as if one also could do
>
>    if u case MachineInteger then ...
>
> with the current Aldor compiler, I just don't know how to type
> "MachineInteger" since the compiler immediately takes the *type*
> MachineInteger and not the *tag* MachineInteger.
>

Use quotes like this?

  'MachineInteger'

That makes in a member of an Enumeration. Maybe that is what Aldor expects?

> Anyway, that usage of MachineInteger is not specified in the AUG so
> maybe one better does not use it that way.
>

I have become quite confident that Aldor takes the most general road
whenever possible inspite of what might or might not be written in the
user's guide, so I am inclined to think that you are right.
'Union(Integer,String)' might very well be acceptible to the Aldor
compiler, we just need to intuit the proper usage.

\start
Date: Mon, 9 Jul 2007 13:29:56 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re: Unions in Spad

Ralf,

On 7/9/07, I wrote:
> ...
> Ralf Hemmecke wrote:
> >
> > It looks as if one also could do
> >
> >    if u case MachineInteger then ...
> >
> > with the current Aldor compiler, I just don't know how to type
> > "MachineInteger" since the compiler immediately takes the *type*
> > MachineInteger and not the *tag* MachineInteger.
> >
>
> Use quotes like this?
>
>   'MachineInteger'
>
> That makes in a member of an Enumeration. Maybe that is what Aldor expects?
> ..

Take a look at this example:

http://wiki.axiom-developer.org/SandBoxAldorTesting#msg20070709122631-0500@wiki.axiom-developer.org

#include "axiom"
macro I == Integer;
main():String == {
        import from I, Float;
        U == Union(Integer, Float);
        import from U;
        i: I := 2;
        s: Float := 1.5;
        ui: U := union i;
        us: U := union s;
        u: U := if odd? random(10) then ui else us;
        if u case Integer$'Integer' then {
                "Integer";
        } else {
                "Float";
        }
}

The result is the error message:

Compiler bug...Bug: gen0UnionCaseIndex: branch not in union
   The )library system command was not called after compilation.

So perhaps alll is not well...

\start
Date: Mon, 09 Jul 2007 20:08:48 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Unions in Spad

>> It looks as if one also could do
>>
>>    if u case MachineInteger then ...
>>
>> with the current Aldor compiler, I just don't know how to type
>> "MachineInteger" since the compiler immediately takes the *type*
>> MachineInteger and not the *tag* MachineInteger.

> Use quotes like this?
> 
>  'MachineInteger'
> 
> That makes in a member of an Enumeration. Maybe that is what Aldor expects?

I should have told that I, of course, had already considered that option.

woodpecker:~/scratch>aldor -laldor -fx aaa.as
"aaa.as", line 13:         if u case 'MachineInteger' then {
                    ..................^
[L13 C19] #1 (Error) Argument 2 of `case' did not match any possible 
parameter type.
     The rejected type is Join(
                  with
                     ==  add ()
   ....
     Expected one of:
       -- Enumeration(machInt: Type)
       -- Enumeration(sStr: Type)

But, of course it must fail.

   'MachineInteger'

is nothing else than

   Enumeration(MachineInteger: Type)

but what I need is an element of this enumeration type.

>> Anyway, that usage of MachineInteger is not specified in the AUG so
>> maybe one better does not use it that way.

> I have become quite confident that Aldor takes the most general road
> whenever possible inspite of what might or might not be written in the
> user's guide, so I am inclined to think that you are right.
> 'Union(Integer,String)' might very well be acceptible to the Aldor
> compiler, we just need to intuit the proper usage.

It seems that MachineInteger is rather special. Look at the following 
session.

Ralf

woodpecker:~/scratch>aldor -gloop
      AA  L      DDDD      OOO    RRRR
     A A  L      D   D    O   O   R   R
    A  A  L      D    D  O     O  R   R
   AAAAA  L      D    D  O     O  RRRR
  A    A  L      D   D    O   O   R  R
A     A  LLLLL  DDDD      OOO    R   R

(c) Numerical Algorithms Group Ltd 1995-2001
Release: Aldor(C) version 1.0.3 for LINUX(glibc2.3) (debug version)
Type "#int help" for more details.
%1 >> #include "aldor"
                                            Comp: 190 msec, Interp: 50 msec
%2 >> #include "aldorinterp"
                                            Comp: 80 msec, Interp: 0 msec
%3 >> MyDom: with == add;
Defined MyDom @
  with
     ==  add ()

                                            Comp: 10 msec, Interp: 0 msec
%4 >> MyDom
   () @
  with
     ==  add ()

                                            Comp: 0 msec, Interp: 0 msec
%5 >> import from 'MyDom'
                                            Comp: 0 msec, Interp: 0 msec
%6 >> MyDom
       ^
[L6 C1] #1 (Error) Have determined 2 possible types for the expression.
	Meaning 1:
                  with
                     ==  add ()
        ...
	Meaning 2: Enumeration(MyDom: Type)

%7 >> MachineInteger
   () @ Join(
PrimitiveType with
         0: %
         1: %
         -: (%, %) -> %
         bytes: %
         coerce: SInt -> %
         coerce: % -> SInt
         integer: Literal -> %
         min: %
         max: %
         odd?: % -> Boolean
         zero?: % -> Boolean
     ==  add ()
,
Join(CopyableType, IntegerType) with
         mod+: (%, %, %) -> %
         mod-: (%, %, %) -> %
         mod*: (%, %, %) -> %
         mod/: (%, %, %) -> %
         mod^: (%, %, %) -> %
         modInverse: (%, %) -> %
         export to IntegerSegment(%)
     ==  add ()
,
  with
     ==  add ()
)
                                            Comp: 0 msec, Interp: 0 msec
%8 >> import from 'MachineInteger'
                                            Comp: 10 msec, Interp: 0 msec
%9 >> MachineInteger
   () @ Join(
PrimitiveType with
         0: %
         1: %
         -: (%, %) -> %
         bytes: %
         coerce: SInt -> %
         coerce: % -> SInt
         integer: Literal -> %
         min: %
         max: %
         odd?: % -> Boolean
         zero?: % -> Boolean
     ==  add ()
,
Join(CopyableType, IntegerType) with
         mod+: (%, %, %) -> %
         mod-: (%, %, %) -> %
         mod*: (%, %, %) -> %
         mod/: (%, %, %) -> %
         mod^: (%, %, %) -> %
         modInverse: (%, %) -> %
         export to IntegerSegment(%)
     ==  add ()
,
  with
     ==  add ()
)
                                            Comp: 0 msec, Interp: 0 msec


But try to compile

---BEGIN aaa.as
#include "aldor"
#include "aldorio"
macro I == MachineInteger;
M1: with == add;
main(): () == {
	U == Union(M1, String);
	import from String;
	import from U;
	import from 'M1';
	s: String := "I am a string";
	u: U := union s;
	if u case M1 then {
		stdout << "Integer: " << newline;
	} else {
		stdout << "String: " << newline;
	}
}

main();
---END aaa.as

woodpecker:~/scratch>aldor -laldor -fx aaa.as
Compiler bug...Bug: gen0UnionCaseIndex: branch not in union

\start
Date: Mon, 09 Jul 2007 13:53:22 -0500
From: Jay Belanger
To: list
Subject: Re: Axiom, FriCAS, forks and teeth


Bill Page writes:
...
> On 7/8/07, you wrote:
>> So I go away for an internet-free weekend, and what do I find when I come
>> back?  A fork of Axiom with its own name, and people on the mailgroup baring
>> their teeth at each other in a most unseemly manner.  So, so, fork away...
>> but what I want to know is - where does this leave me, a common-or-garden
>> user?
>
> Personally I think you should view this as a positive development.
...
> so one way or another it's future is now more assured than it was
> before. 

I think that's stretching things, to put it mildly.  Resources are
being divided, developers are being split.  At least one person said
they're leaving the Axiom project if there aren't enough developers,
indicating that having developers leave (and anyone trying to work on
two projects, even closely related ones, won't contribute as much as
if they concentrated on one) can snowball.

I find the whole thing odd.  I thought Tim was pretty clear from the
beginning on what the goals of the Axiom project were, and it seems as
if many in the community hopped on board but really didn't like the
goals.  I thought that the literate CAS approach was very exciting,
and made it stand out quite a bit to me; a non-literate Axiom wouldn't
have nearly the appeal.

> There is no reason to think that the Axiom project is going to
> disappear

I don't think so, either, but the chances that it will are greater
than they were before.

\start
Date: Mon, 9 Jul 2007 14:57:19 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re: Unions in Spad

On 7/9/07, Ralf Hemmecke wrote:
> ...
> Bill Page wrote:
> > Use quotes like this?
> >
> >  'MachineInteger'
> >
> > That makes in a member of an Enumeration. Maybe that is what Aldor expects?
>
> ...
> But, of course it must fail.
>
>    'MachineInteger'
>
> is nothing else than
>
>    Enumeration(MachineInteger: Type)
>
> but what I need is an element of this enumeration type.
>

Sorry. I should have written MachineInteger$'MachineInteger' I think
that is the correct explicit notation of the element. Or you can
import from 'MachineInteger'.

>
> It seems that MachineInteger is rather special. Look at the following
> session.
>
> Ralf
>
> woodpecker:~/scratch>aldor -gloop
>       AA  L      DDDD      OOO    RRRR
>      A A  L      D   D    O   O   R   R
>     A  A  L      D    D  O     O  R   R
>    AAAAA  L      D    D  O     O  RRRR
>   A    A  L      D   D    O   O   R  R
> A     A  LLLLL  DDDD      OOO    R   R
>
> (c) Numerical Algorithms Group Ltd 1995-2001
> Release: Aldor(C) version 1.0.3 for LINUX(glibc2.3) (debug version)
> Type "#int help" for more details.
> %1 >> #include "aldor"
>                                             Comp: 190 msec, Interp: 50 msec
> %2 >> #include "aldorinterp"
>                                             Comp: 80 msec, Interp: 0 msec
> %3 >> MyDom: with == add;
> Defined MyDom @
>   with
>      ==  add ()
>
>                                             Comp: 10 msec, Interp: 0 msec
> %4 >> MyDom
>    () @
>   with
>      ==  add ()
>
>                                             Comp: 0 msec, Interp: 0 msec
> %5 >> import from 'MyDom'
>                                             Comp: 0 msec, Interp: 0 msec
> %6 >> MyDom
>        ^
> [L6 C1] #1 (Error) Have determined 2 possible types for the expression.
>         Meaning 1:
>                   with
>                      ==  add ()
>         ...
>         Meaning 2: Enumeration(MyDom: Type)
>

This makes sense because of the import, right? Aldor cannot tell from
the context which one you mean.

> %7 >> MachineInteger
>    () @ Join(
> PrimitiveType with
>          0: %
>          1: %
>          -: (%, %) -> %
>          bytes: %
>          coerce: SInt -> %
>          coerce: % -> SInt
>          integer: Literal -> %
>          min: %
>          max: %
>          odd?: % -> Boolean
>          zero?: % -> Boolean
>      ==  add ()
> ,
> Join(CopyableType, IntegerType) with
>          mod+: (%, %, %) -> %
>          mod-: (%, %, %) -> %
>          mod*: (%, %, %) -> %
>          mod/: (%, %, %) -> %
>          mod^: (%, %, %) -> %
>          modInverse: (%, %) -> %
>          export to IntegerSegment(%)
>      ==  add ()
> ,
>   with
>      ==  add ()
> )
>                                             Comp: 0 msec, Interp: 0 msec
> %8 >> import from 'MachineInteger'
>                                             Comp: 10 msec, Interp: 0 msec
> %9 >> MachineInteger
>    () @ Join(
> PrimitiveType with
>          0: %
>          1: %
>          -: (%, %) -> %
>          bytes: %
>          coerce: SInt -> %
>          coerce: % -> SInt
>          integer: Literal -> %
>          min: %
>          max: %
>          odd?: % -> Boolean
>          zero?: % -> Boolean
>      ==  add ()
> ,
> Join(CopyableType, IntegerType) with
>          mod+: (%, %, %) -> %
>          mod-: (%, %, %) -> %
>          mod*: (%, %, %) -> %
>          mod/: (%, %, %) -> %
>          mod^: (%, %, %) -> %
>          modInverse: (%, %) -> %
>          export to IntegerSegment(%)
>      ==  add ()
> ,
>   with
>      ==  add ()
> )
>                                             Comp: 0 msec, Interp: 0 msec
>

Interesting. I would have expected the same error as above.

>
> But try to compile
>
> ---BEGIN aaa.as
> #include "aldor"
> #include "aldorio"
> macro I == MachineInteger;
> M1: with == add;
> main(): () == {
>         U == Union(M1, String);
>         import from String;
>         import from U;
>         import from 'M1';
>         s: String := "I am a string";
>         u: U := union s;
>         if u case M1 then {
>                 stdout << "Integer: " << newline;
>         } else {
>                 stdout << "String: " << newline;
>         }
> }
>
> main();
> ---END aaa.as
>
> woodpecker:~/scratch>aldor -laldor -fx aaa.as
> Compiler bug...Bug: gen0UnionCaseIndex: branch not in union
>
> Cool!
>

Cool? That is the same error that I get if I write

 U == Union(Integer, String);
 u:U := ...
 if u case  Integer$'Integer' then ...

http://wiki.axiom-developer.org/SandBoxAldorTesting#msg20070709122631-0500@wiki.axiom-developer.org

Any, I think you were right the first. It was the intention of the
Aldor developers that an untagged Union should be possible. It just
seems that there is an error in the compiler that currently prevents
this.

\start
Date: Mon, 9 Jul 2007 13:58:11 -0500
From: Tim Daly
To: Stephen Wilson
Subject: defintrf bug

Stephen,

(|Record|...) macroexpands into (|Record0|....)
(|:|...) macroexpands into (CONS...)





in OPTPROB.nrlib/code.lsp

    (ELT (|Record| (|:| |lfn| 
                        (|List| (|Expression| (|DoubleFloat|))))
                   (|:| |init| (|List| (|DoubleFloat|)))))

was not expanded. Perhaps we need to do a macroexpand-all?






in DFINTTLS.nrlib/code.lsp, the source line in defintrf.spad, line 90
where 
  Z ==> Integer
  Q ==> Fraction Z
  B ==> Boolean
  REC ==> Record(left:Q, right:Q)
  keeprec? : (Q,REC) -> B
   
  keeprec?(a, rec)   == (a > rec.right) or (a < rec.left)

the code used to read:
(|DFINTTLS;keeprec?|
  (QCAR (PROG2 (LETT #0# (QREFELT $$ 3) NIL (QCDR #0#)

becomes

(|DFINTTLS;keeprec?|
  (QCAR (PROG2 (LETT #0# (QREFELT $$ 1) NIL (QCDR #0#)

I have no idea why the index changed. And in the same file

   (|Record| 
     (|:| (QREFELT $$ 2) (|Fraction| (|Integer|)))
     (|:| (QREFELT $$ 1) (|Integer)))
expands to
   (|Record0|
     (LIST (CONS '|endpoint|
                 (|Fraction| (|Integer|)))
           (CONS '|dir| (|Integer|))))

this seems like a bug in the algebra code to me.
The function keeprec? expects a REC record with left and right indices
but "endpoint" and "dir" are the indices of a REC2:
  REC2 ==> Record(endpoint:Q, dir:Z)
so it doesn't seem valid to call keeprec? on a REC2 construct.


Ultimately I think the algorithm is wrong. I think that even though
the signature for keeprec? is properly matched in the call, and the
shape of the record is the same yet the accessor names are wrong.

I'm still checking the other examples and they seem to be expanding
correctly. I'm not sure that your patch is needed.

\start
Date: Mon, 9 Jul 2007 15:28:27 -0400
From: Bill Page
To: Jay Belanger
Subject: Re: Axiom, FriCAS, forks and teeth

On 7/9/07, Jay Belanger wrote:
>
> Bill Page writes:
> ...
> > On 7/8/07, you wrote:
> >> So I go away for an internet-free weekend, and what do I find when I come
> >> back?  A fork of Axiom with its own name, and people on the mailgroup baring
> >> their teeth at each other in a most unseemly manner.  So, so, fork away...
> >> but what I want to know is - where does this leave me, a common-or-garden
> >> user?
> >
> > Personally I think you should view this as a positive development.
> ...
> > so one way or another it's future is now more assured than it was
> > before.
>
> I think that's stretching things, to put it mildly.  Resources are
> being divided, developers are being split.  At least one person said
> they're leaving the Axiom project if there aren't enough developers,
> indicating that having developers leave (and anyone trying to work on
> two projects, even closely related ones, won't contribute as much as
> if they concentrated on one) can snowball.

Only one Axiom developer (Martin Rubey) has said publicly that he
would probably quite the Axiom project but I am optimistic that in
fact he will continue his interest in Axiom one way or the other. I do
not see any more division now between the Axiom project and the FirCAS
project than there already was within the Axiom project before the
fork was officially declared.

>
> I find the whole thing odd.  I thought Tim was pretty clear from the
> beginning on what the goals of the Axiom project were, and it seems as
> if many in the community hopped on board but really didn't like the
> goals.  I thought that the literate CAS approach was very exciting,
> and made it stand out quite a bit to me; a non-literate Axiom wouldn't
> have nearly the appeal.
>

Well speaking for just myself, I am no less interested now in literate
programming and how this can be applied to CAS then I was when I
started with the Axiom project. I just think that 5 years is long
enough to spend on the current approach to conclude that it has been a
failure. It appears that there are valid reasons why Knuth-style
literate programming is not now a mainstream programming methodology
and these reasons apply just as much to Axiom as any other project.

But literate programming is not really the problem. Rather I think the
problem as usual, is just the way in which decisions are (and are not)
being made in the project.

> > There is no reason to think that the Axiom project is going to
> > disappear
>
> I don't think so, either, but the chances that it will are greater
> than they were before.
>

Nonsense. Forks have occurred in many very successful open source projects.

\start
Date: Mon, 09 Jul 2007 21:30:04 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Unions in Spad

Hi Bill,

> MachineInteger$'MachineInteger'

You are better than me. ;-) I tried

import from 'MachineInteger'
MachineInteger@'MachineInteger'

and failed. Using $ did not occur to me.

>> woodpecker:~/scratch>aldor -laldor -fx aaa.as
>> Compiler bug...Bug: gen0UnionCaseIndex: branch not in union
>>
>> Cool!

> Cool?

Well, you know how I meant it. But what can we do with a closed source 
compiler that has no developers? Finding bug after bug is just a waste 
of time. :-(

\start
Date: 09 Jul 2007 16:39:22 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: defintrf bug


Hello Tim,

Tim Daly writes:
> Stephen,
> 
> (|Record|...) macroexpands into (|Record0|....)
> (|:|...) macroexpands into (CONS...)
> 
> 
> 
> 
> 
> in OPTPROB.nrlib/code.lsp
> 
>     (ELT (|Record| (|:| |lfn| 
>                         (|List| (|Expression| (|DoubleFloat|))))
>                    (|:| |init| (|List| (|DoubleFloat|)))))
> 
> was not expanded. Perhaps we need to do a macroexpand-all?

I noticed similar issue with D01AGNT.  But this case is more
interesting, as it is showing we can get these unquoted union/record
tags via different paths then just through mkUnionFunList.

> in DFINTTLS.nrlib/code.lsp, the source line in defintrf.spad, line 90
> where 
>   Z ==> Integer
>   Q ==> Fraction Z
>   B ==> Boolean
>   REC ==> Record(left:Q, right:Q)
>   keeprec? : (Q,REC) -> B
>    
>   keeprec?(a, rec)   == (a > rec.right) or (a < rec.left)
> 
> the code used to read:
> (|DFINTTLS;keeprec?|
>   (QCAR (PROG2 (LETT #0# (QREFELT $$ 3) NIL (QCDR #0#)
> 
> becomes
> 
> (|DFINTTLS;keeprec?|
>   (QCAR (PROG2 (LETT #0# (QREFELT $$ 1) NIL (QCDR #0#)
> 
> I have no idea why the index changed. And in the same file

Im at a loss to explain this as well.

> 
>    (|Record| 
>      (|:| (QREFELT $$ 2) (|Fraction| (|Integer|)))
>      (|:| (QREFELT $$ 1) (|Integer)))
> expands to
>    (|Record0|
>      (LIST (CONS '|endpoint|
>                  (|Fraction| (|Integer|)))
>            (CONS '|dir| (|Integer|))))
> 
> this seems like a bug in the algebra code to me.
> The function keeprec? expects a REC record with left and right indices
> but "endpoint" and "dir" are the indices of a REC2:
>   REC2 ==> Record(endpoint:Q, dir:Z)
> so it doesn't seem valid to call keeprec? on a REC2 construct.

Nice catch.  But is this a bug in the algebra?

The call:

      select_!(keeprec?(i.halfinf.endpoint, #1), l) 

Seems well typed. We have:

     keeprec?    : (Q, REC) -> B

     i.halfinf.endpoint is of type Q (Fraction Integer)

     "l" should have inferred to be of type List REC, given its
     definition "l := realZeros p" (which is comming from
     RealZeroPackage, I belive), and so the second argument type of
     keeprec? is satisfied.

Am I missing a step?  This looks like another compiler bug to me, that
REC2 is being confused for REC.

> Ultimately I think the algorithm is wrong. I think that even though
> the signature for keeprec? is properly matched in the call, and the
> shape of the record is the same yet the accessor names are wrong.
> 
> I'm still checking the other examples and they seem to be expanding
> correctly. I'm not sure that your patch is needed.

Given these insights, I feel the patch is not fully correct.  It
appears to solve the original bug, but not the general problem. 

Main issue remains: Types which involve (|:| field Type) terms like
Record and Union have `field' appear unquoted, foiling
compWithMappingMode.  

Perhaps the use of macroexpand-all at all points where these
expressions are generated would work as a general solution, but I have
doubts that such an experiment would suceed.

I will try again with my original idea to make compWithMappingMode
smarter, to lift only those identifiers which it can prove are bound.

Im not sure if the posting of a `patch for testing' was a worthwhile
activity.  Im certain I would have locally rejected the patch in time,
but your observations have been a great help.  Comments?

Do the documentation bits of the patch look OK to you? I can post a
revised patch containing a (possibly improved) chunk of documentation.

\start
Date: 09 Jul 2007 17:02:15 -0400
From: Stephen Wilson
To: list
Subject: Re: defintrf bug

Hello again,

Stephen Wilson writes:
[...]
> >    (|Record| 
> >      (|:| (QREFELT $$ 2) (|Fraction| (|Integer|)))
> >      (|:| (QREFELT $$ 1) (|Integer)))
> > expands to
> >    (|Record0|
> >      (LIST (CONS '|endpoint|
> >                  (|Fraction| (|Integer|)))
> >            (CONS '|dir| (|Integer|))))
> > 
> > this seems like a bug in the algebra code to me.
> > The function keeprec? expects a REC record with left and right indices
> > but "endpoint" and "dir" are the indices of a REC2:
> >   REC2 ==> Record(endpoint:Q, dir:Z)
> > so it doesn't seem valid to call keeprec? on a REC2 construct.
> 
> Nice catch.  But is this a bug in the algebra?

Looking at the code again, this is actually fine.  The code in
question is being passed to check-union.  The type expression is not
related to the argument to keeprec?, but rather to the dereferencing
of the halfinf branch in the Union object bound to `i'.  The code is
checking that "i.halfinf" (of type REC2) is valid.

At least its not another bug.

\start
Date: Mon, 09 Jul 2007 23:03:34 +0200
From: Ralf Hemmecke
To: Jay Belanger
Subject: Re: Axiom, FriCAS, forks and teeth

> I find the whole thing odd.  I thought Tim was pretty clear from the 
> beginning on what the goals of the Axiom project were,

Could you give them right away without looking them up somewhere? Then
look them up. Where would you search?

> and it seems as if many in the community hopped on board but really
> didn't like the goals.

I think the goals have been repeated often on the mailing list, but they 
are not as present as they should/could have been.

> I thought that the literate CAS approach was
> very exciting, and made it stand out quite a bit to me; a
> non-literate Axiom wouldn't have nearly the appeal.

The literate approach is one goal that I am not going to sacrifice. The 
question rather is that we cannot easily achieve it and it is currently 
unwise to require perfect documentation always as we need more 
developers and must teach new developers how to program in an LP style. 
As long as the developer is still on the project, it should be allowed 
to move code to trunk that does not 100% meet perfection with respect to 
LP. We can be more and more restrictive if the number of contribution 
grows. (BTW, I don't say, it should be allowed to move code without a 
reasonable explanation to trunk, just that the degree of perfection need 
not be 100% always.)

\start
Date: 09 Jul 2007 17:21:18 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: Re: Axiom, FriCAS, forks and teeth

Ralf Hemmecke writes:
> Could you give them right away without looking them up somewhere? Then
> look them up. Where would you search?

Everything is a pamphlet.  Submit diff -Nuar patches to the list.

Anything else?

Perhaps these items are missing from the FAQ?  As always, patches
welcome.

> The literate approach is one goal that I am not going to
> sacrifice. The question rather is that we cannot easily achieve it and
> it is currently unwise to require perfect documentation always as we
> need more developers and must teach new developers how to program in
> an LP style. As long as the developer is still on the project, it
> should be allowed to move code to trunk that does not 100% meet
> perfection with respect to LP. We can be more and more restrictive if
> the number of contribution grows. (BTW, I don't say, it should be
> allowed to move code without a reasonable explanation to trunk, just
> that the degree of perfection need not be 100% always.)

I honestly dont think 100% perfection was a stated goal.  The patch I
recently posted was pretty much a failure.  It changed two or three
lines of code.  But I took the liberty to _start_ documenting the
function I was working with.  That piece of the contribution can be
salvaged.  Its far from perfect documentation, there is immense room
for improvement.

I wonder what will happen the next time someone touches that file.
Will they just change the code and be done with it?  Or will they add
a new insight, a new paragraph, or even `finish' my half-baked attempt?

\start
Date: Mon, 09 Jul 2007 21:16:34 -0400
From: Cliff Yapp
To: Bill Page
Subject: Re: Axiom, FriCAS, forks and teeth

Bill Page wrote:

> Only one Axiom developer (Martin Rubey) has said publicly that he
> would probably quite the Axiom project but I am optimistic that in
> fact he will continue his interest in Axiom one way or the other. I do
> not see any more division now between the Axiom project and the FirCAS
> project than there already was within the Axiom project before the
> fork was officially declared.

That is my sense as well.

>> I find the whole thing odd.  I thought Tim was pretty clear from the
>> beginning on what the goals of the Axiom project were, and it seems as
>> if many in the community hopped on board but really didn't like the
>> goals.

That thought has occurred to me as well.

>> I thought that the literate CAS approach was very exciting,
>> and made it stand out quite a bit to me; a non-literate Axiom wouldn't
>> have nearly the appeal.

Absolutely.  I see no reason to do another CAS unless some effort is
made to give it merits that are unique.  The Axiom project, to me, holds
that promise.

> Well speaking for just myself, I am no less interested now in literate
> programming and how this can be applied to CAS then I was when I
> started with the Axiom project. I just think that 5 years is long
> enough to spend on the current approach to conclude that it has been a
> failure. It appears that there are valid reasons why Knuth-style
> literate programming is not now a mainstream programming methodology
> and these reasons apply just as much to Axiom as any other project.

I don't agree, personally, which I think might be the core of the
difference in opinions.  Literate programming is not a mainstream
methodology (in my opinion) because few developers are willing to accept
the long lead times and hard work of researching the necessary
background to make a good literate document.  In fairness, most
situations don't need programs intended to last indefinitely, either -
or rather, the effort to develop such a program isn't justified or
supported by the circumstances.  Axiom, because it is intending to
represent something that is essentially timeless (mathematics) can and
should take a very long term view.  In my view the time needed to learn
the necessary mathematics (particularly for newcomers) is only slightly
increased by writing a pamphlet - indeed it is a good way to organize
one's thinking.

> But literate programming is not really the problem. Rather I think the
> problem as usual, is just the way in which decisions are (and are not)
> being made in the project.

I would term it a conflict between contradictory objectives - both
valid, but neither compatible with the other in these early stages.
Doing a literate system from the ground up, and making the attempt to do
the Right Thing at all stages, will not produce a quickly working
program.  This is acceptable to some, not to others.  I view neither
position as calling for hostility.

>> > There is no reason to think that the Axiom project is going to
>> > disappear
>>
>> I don't think so, either, but the chances that it will are greater
>> than they were before.
>>
> 
> Nonsense. Forks have occurred in many very successful open source projects.

I think Bill pegged it when he said that there isn't any more division
now than already existed "de-facto" in the project.

Remember, there is nothing that stops either project from using the
efforts of the other project, when the goals of each can benefit.  (So
long as the licensing remains compatible, of course.) People would have
gone in various directions regardless - this way we can do so without
spending time duking it out over the project goals.  Eventually, both
projects should get to the point where the MATH is what it's all about,
and when both reach that stage I expect things will be calmer.

Tim had the right idea.  Let's stop worrying, support both projects
according to our goals, wish both well, and get back to coding/writing.
 For me, that's back to asdf-literate.  (Yay, working computer...)

\start
Date: Mon, 09 Jul 2007 20:39:45 -0500
From: Jay Belanger
To: list
Subject: Re: Axiom, FriCAS, forks and teeth

Bill Page writes:
...
> But literate programming is not really the problem. Rather I think the
> problem as usual, is just the way in which decisions are (and are not)
> being made in the project.

One reason for the fork was to be able to put off documentation, and
many people seem to think that's a good idea.  It sounds like a
horrible idea to me.  Deciding to stick to the original goal hardly
seems like anything outrageous.

>> I don't think so, either, but the chances that it will are greater
>> than they were before.
>
> Nonsense. Forks have occurred in many very successful open source projects.

Which is a complete non-sequitor.

\start
Date: Mon, 9 Jul 2007 22:22:23 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Axiom, FriCAS, forks and teeth

On 7/9/07, C Y wrote:
> ... Literate programming is not a mainstream methodology (in my opinion)
> because few developers are willing to accept the long lead times and hard
> work of researching the necessary background to make a good literate
> document. ...

I think you are absolutely right about that. The trouble is: What are
we going to do about it? Bug fixes and new programming can only be
done by developers and the Axiom project still has far too few
developers to beat the odds. And to make matters worse, at the risk of
making a completely unsubstantiated but I think plausible
generalization, those developers who have the strongest programming
skills are least likely to have the skills required to write good
documentation (and vice versa).

I used to think that one possible solution would be for those people
who do have writing skills to work in a team with an experienced
develop who has the requisite programming skill. But with the Axiom
project at it's current size and the reluctance that many people seem
to have to really collaborate with others, even this seems to be
impractical.

So I am inclined to want to proceed with the Axiom project without
requiring literate programming (a situation no worse then at any other
time in Axiom's history) and take advantage now of the interest of
open source Internet community where and when it is possible to find
it. This way Axiom can progress instead of dying a slow death while we
all grow older. This does not mean abandoning the goal of a well
documented computer algebra system at the level of the program code.
If at some time in the future when/if the available literate
programming tools can be improved and/or if it is possible to attract
developers who have both the required skills or if it is somehow
possible to form working groups with people who are willing to combine
their skills, then perhaps the goal of improving Axiom in this way can
also be pursued. But as you implied, solving the problem of how to do
literate programming in a manner that will be accepted and used by
most developers today seems to be a very hard problem that has not
been solved yet.

\start
Date: Mon, 09 Jul 2007 22:55:42 -0400
From: Cliff Yapp
To: Bill Page
Subject: Re: Axiom, FriCAS, forks and teeth

Bill Page wrote:
> On 7/9/07, C Y wrote:
>> ... Literate programming is not a mainstream methodology (in my opinion)
>> because few developers are willing to accept the long lead times and hard
>> work of researching the necessary background to make a good literate
>> document. ...
> 
> I think you are absolutely right about that. The trouble is: What are
> we going to do about it?

Whatever we can.  I will make the best attempt I can to do what seems to
be the Right Thing, and hope to either a) prod someone with better
programming skills into doing it right and then document it (cl-web) or
b) eventually through stumbling around learning reach a point where the
tool can be built on.

In some ways, developers can "get away" without doing their homework
because they do not have to compete with programs that HAVE been written
with that attention to detail and design.  Someone has to start doing it
right, or no one will.  For decades, the focus has been on "getting
something working."  This is understandable - the market pays for it and
it is very useful practically.  But now I think we have enough of these
tools that we can take a deep breath, step back, and examine how to put
what has been learned into practice.

Axiom seems the perfect opportunity to me to start "doing it right."
Let's try to be trend setters.  We have an opportunity here to do
pioneering work - let's blaze some trails!

> Bug fixes and new programming can only be
> done by developers and the Axiom project still has far too few
> developers to beat the odds. And to make matters worse, at the risk of
> making a completely unsubstantiated but I think plausible
> generalization, those developers who have the strongest programming
> skills are least likely to have the skills required to write good
> documentation (and vice versa).

I don't know if that's true or not, but I can see how it might be - once
you DO know how to program, writing documentation feels like writing the
same thing twice in two languages (one being rather imprecise and verbose.)

> I used to think that one possible solution would be for those people
> who do have writing skills to work in a team with an experienced
> develop who has the requisite programming skill. But with the Axiom
> project at it's current size and the reluctance that many people seem
> to have to really collaborate with others, even this seems to be
> impractical.

Collaboration requires agreement on direction.  I don't think it has
been proven impractical yet.  Anyway I'll keep trying.  "Nothing worth
doing is easy."

> So I am inclined to want to proceed with the Axiom project without
> requiring literate programming (a situation no worse then at any other
> time in Axiom's history) and take advantage now of the interest of
> open source Internet community where and when it is possible to find
> it.

Isn't this one of the operating principles behind the FriCAS project?  I
support that goal - if the Axiom experiment ultimately doesn't succeed I
would want FriCAS to survive and preserve the effort already put forth -
it is still very useful.  I personally would stay with the Axiom
project, but I can see how FriCAS would be a better fit for many.

> This way Axiom can progress instead of dying a slow death while we
> all grow older.

FriCAS I think is the perfect place to pursue that (worthy) goal.

> This does not mean abandoning the goal of a well
> documented computer algebra system at the level of the program code.

If we are not to abandon it, work must continue on it.  I see no reason
that the Axiom project can't eventually study and incorporate
innovations made in FriCAS - it would be slower perhaps but FriCAS
addresses the immediate availability issue.

> If at some time in the future when/if the available literate
> programming tools can be improved and/or if it is possible to attract
> developers who have both the required skills or if it is somehow
> possible to form working groups with people who are willing to combine
> their skills, then perhaps the goal of improving Axiom in this way can
> also be pursued.

Which is why I think the current situation makes sense.  Axiom can
continue to drive in the same directions it has already driven, and
FriCAS can pursue more "practically oriented" directions.

> But as you implied, solving the problem of how to do
> literate programming in a manner that will be accepted and used by
> most developers today seems to be a very hard problem that has not
> been solved yet.

Then that becomes the first problem the Axiom project must solve.  There
is no way around the hard work of doing the background research, so the
only possible way over that hurdle is to have people motivated to climb
over it.  Beyond that, the tools should be smooth, helpful, and robust -
but they won't write themselves, so those who want them will have to get
to it ;-).


\start
Date: 10 Jul 2007 01:56:54 -0400
From: Stephen Wilson
To: list
Subject: Re: [Axiom-mail] Output/print without linefeed?

--=-=-=


Should have CC'ed axiom-developer, forwarding.

Stephen Wilson writes:
> *,
> 
> Alasdair McAndrew writes:
> > I was running a long program recently, and every now and again I wanted a
> > little output to indicate how far the program had got.  The "output" command
> > includes a line feed, which I don't want.  I've tried:
> > 
> >  )set expose add constructor IPRNTPK
> > 
> > but then, for example:
> > 
> > for i in 1..10 repeat iprint(i::String)
> > 
> > produces the output:
> > 
> > 1
> >    >> System error:
> >    FLUSH is invalid as a function.
> > 
> > Any ideas?
> 
> I entered this as bug #371 on Issue Tracker.
> 
> Attached is a patch containing a trivial fix.  The issue is in
> newdata.spad.pamphlet, where FORCE-OUTPUT is being referenced as a
> symbol, not as a function call.
> 
> The patch contains a new file: src/input/iprntpk.input.pamphlet which
> tests for this bug in the regression suite.
> 
> 
> Take care,
> Steve


--=-=-=

--- changelog	2007-07-09 22:09:36.000000000 -0400
+++ changelog.sxw	2007-07-09 22:10:17.000000000 -0400
@@ -1,3 +1,4 @@
+20070709 sxw fix issue #371, include regress test.
 20070705 wxh src/algebra/draw.spad clip myTrap1, myTrap2 range to SF (545)
 20070705 gdr remove execute bit from files (svn 651)
 20070704 tpd zips/tla-1.1.tar.gz svn propset mime-type binary/data

--=-=-=

--- newdata.spad.pamphlet	2007-07-08 14:52:49.000000000 -0400
+++ newdata.spad.pamphlet.sxw	2007-07-09 22:11:10.000000000 -0400
@@ -49,7 +49,7 @@
   Implementation == add
      iprint(s:String) == 
           PRINC(coerce(s)@Symbol)$Lisp
-          FORCE_-OUTPUT$Lisp
+          FORCE_-OUTPUT()$Lisp
 
 @
 \section{package TBCMPPK TabulatedComputationPackage}

--=-=-=

--- /dev/null	1994-07-17 19:46:18.000000000 -0400
+++ iprntpk.input.pamphlet	2007-07-09 21:45:13.000000000 -0400
@@ -0,0 +1,54 @@
+\documentclass{article}
+\usepackage{axiom}
+\begin{document}
+\title{\$SPAD/src/input iprntpk.input}
+\author{The Axiom Team}
+\maketitle
+\begin{abstract}
+\end{abstract}
+\eject
+\tableofcontents
+\eject
+\section{License}
+<<license>>=
+--Copyright The Numerical Algorithms Group Limited 1991.
+@
+<<*>>=
+)spool iprntpk.output
+)set message test on
+)set message auto off
+)clear all
+
+@
+This package exports but one function.  Nonetheless, we had a bug in
+this code, so a few tests are warranted. The function is iprint, which
+simply prints a string standard-output without a new line, and flushes
+the stream.
+
+<<*>>=
+--S 1 of 3
+)set expose add constructor IPRNTPK
+--R   InternalPrintPackage is now explicitly exposed in frame initial 
+--E 1
+
+--S 2 of 3
+iprint("Release the hounds!")
+--RRelease the hounds!                                                                   Type: Void
+--E 2
+
+--S 3 of 3
+for i in 1..10 repeat iprint(i::String)
+--R12345678910                                                                   Type: Void
+--E 3
+
+)spool 
+)lisp (bye)
+ 
+@
+\eject
+\begin{thebibliography}{99}
+\bibitem{1} nothing
+\end{thebibliography}
+\end{document}
+
+ 

--=-=-=--

\start
Date: Tue, 10 Jul 2007 08:34:34 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Axiom, FriCAS, forks and teeth

On 07/10/2007 04:22 AM, Bill Page wrote:
> On 7/9/07, C Y wrote:
>> ... Literate programming is not a mainstream methodology (in my opinion)
>> because few developers are willing to accept the long lead times and hard
>> work of researching the necessary background to make a good literate
>> document. ...

Literate programming is not mainstream since it costs a lot of time and 
the programmer puts all or at least most of his knowledge about the 
program, background, and design into a pamphlet. He basically teaches 
future programmers and lowers the hurdle for them to understand the 
program. *He makes himself more easily replacable by others.* Would you 
do LP if you work in industry?

The only reasonable way I see is: don't show the sources. But then you 
lose the ideal of LP that you want to teach...

\start
Date: Tue, 10 Jul 2007 07:56:44 -0400
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Axiom, FriCAS, forks and teeth

Ralf Hemmecke wrote:
> On 07/10/2007 04:22 AM, Bill Page wrote:
>> On 7/9/07, C Y wrote:
>>> ... Literate programming is not a mainstream methodology (in my opinion)
>>> because few developers are willing to accept the long lead times and
>>> hard
>>> work of researching the necessary background to make a good literate
>>> document. ...
> 
> Literate programming is not mainstream since it costs a lot of time and
> the programmer puts all or at least most of his knowledge about the
> program, background, and design into a pamphlet. He basically teaches
> future programmers and lowers the hurdle for them to understand the
> program. *He makes himself more easily replacable by others.* Would you
> do LP if you work in industry?

Probably would depend on the organization.  If they were smart enough to
want to retain people who do work of sufficiently high quality that it
is easily maintained down the road, yes.  If not, I'd be worried about
the company anyway... people are not (at least in the US) required to
stay at one job and often move to another one of their own accord.

> The only reasonable way I see is: don't show the sources. But then you
> lose the ideal of LP that you want to teach...

That's why I view open source as a potential venue for a new level of
software quality.  We can (and should) use techniques that would never
appeal to the commercial world because they do not (directly) translate
into salable product.

\start
Date: Tue, 10 Jul 2007 10:34:58 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Axiom, FriCAS, forks and teeth

While we are dragging this thread further into the merits/demerits of
literate programming, I thought I would mention one alternative to
literate programming that seems in comparison to be quite mainstream:
using visualization to improve the comprehensibility of software. See
for example:

http://www.jgrasp.org

I would *love* to have a tool like this for Axiom that also understood
and could navigate the Axiom library.

Part of the idea here is that programs themselves can be made more
directly comprehensible by human beings rather than making programming
equivalent to writing a research paper and then providing tools to
extract the embedded code in a form usable by a computer. One
advantage of this is that such tools can be layered on top of
traditional programming methodologies without change (much) the way
programmers work.

Ultimately of course the tools one uses tends to affect the way one
works, so if the goal is to move to more literate programming then one
approach would be to look for tools which "gently" encourage
programmers to work in this manner (but do not require it from the
get-go).

\start
Date: Tue, 10 Jul 2007 09:36:03 -0500
From: Tim Daly
To: Stephen Wilson, Alasdair McAndrew
Subject: FORCE-OUTPUT

Change applied. Test cycle started. --Tim

\start
Date: Tue, 10 Jul 2007 13:41:52 -0400
From: Didier Deshommes
To: list
Subject: Re: Axiom, FriCAS, forks and teeth

2007/7/10, Bill Page:
> While we are dragging this thread further into the merits/demerits of
> literate programming, I thought I would mention one alternative to

Speaking of liteerate programming, I stumbled accros this blog entry
about the (partial) failures of  the literate programming tool noweb:
http://www.cims.nyu.edu/~dbindel/eigenstuff/2007-04.html#x-2007-04-30-dsbweb

I don't know much about lp but maybe it isn't catching up because the
tools are too limited and/or too cumbersome for "normal users"?

\start
Date: Tue, 10 Jul 2007 13:49:51 -0500
From: Tim Daly
To: Didier Deshommes
Subject: Literate Programming

didier,

I looked at the link, read the code, and read the documentation.

Kudos to David. He's documenting his code. And he's using what
I'd characterize as a semi-literate style. I'd fit him into a
scale that looks something like:

Illiterate:
  0) raw code
  1) raw code with minor comments
  2) raw code with organized comments
Semi-literate:
  3) code with extractable comments (aka javadoc, doxygen)
  4) code with latex comments (dsbweb)
Literate:
  5) documentation with embedded code (web)

His comment style is exceptionally good. He writes for human readers.

My only nitpick comes from the fact that he's "still the programmer"
writing for the machine and decorating his code with nice comments.
It is better than no comments at all but I don't think he really
became fully literate.  For the kind of "little-file, C-mindset"
programming he is doing it probably isn't worth it. Literate
programming and the "file" idea tend to get in the way of each
other. {C, Java, etc} programmers tend to be unable to transcend
the file-based thinking.

The hardest thing I found about making the transition to literate
programming is that the "literate" part overrides the "programming"
part in importance. That is, besides writing for humans in comment
style you also end up having to "scramble" the program so it takes 
on a logical development style for the human reader. Writing for
the human is much harder and more time consuming than writing for
the machine. It only makes sense if the program is intended to
be maintained by other humans over a long time, raising the need
to write for humans.

dbsweb is clearly a "comment processor tool", like javadoc. The
structure of the program overrides the comment structure. Thus, "main"
ends up being the last thing in the file because the machine needs it
that way.  But if you read things like "Lisp in Small Pieces" he
starts out explaining things "top-down", so he starts explaining the
"main" program first. dbsweb doesn't have chunking and thus does not
allow you to "float" things into a logical sequence for the human. You
are primarily talking to the machine and dragging the human along.

That said, I'm happy to see that he has "gotten the idea" well enough
that he's willing to build a tool to help him along. But he still 
hasn't raised his eyes from the machine.

\start
Date: Tue, 10 Jul 2007 14:53:15 -0400
From: Bill Page
To: Didier Deshommes
Subject: Re: Axiom, FriCAS, forks and teeth

On 7/10/07, didier deshommes wrote:
> 2007/7/10, Bill Page:
> > While we are dragging this thread further into the merits/demerits of
> > literate programming, I thought I would mention one alternative to
>
> Speaking of liteerate programming, I stumbled accros this blog entry
> about the (partial) failures of  the literate programming tool noweb:
> http://www.cims.nyu.edu/~dbindel/eigenstuff/2007-04.html#x-2007-04-30-dsbweb
>
> I don't know much about lp but maybe it isn't catching up because the
> tools are too limited and/or too cumbersome for "normal users"?
>

Cool! Thanks for the ref. Maybe there is something to this approach
with "everything" in the comments? At least that way there is no
distinction between source as traditional developers usually see and
the documentation. To me this seems like a simpler form of the idea
promoted by Leo that markers should be inserted as comments in the
tangled code so that direct edits to the code can be automatically
reflected in the full literate source. In both cases this can be (more
or less) layered on top of traditional practices.

\start
Date: Tue, 10 Jul 2007 21:02:24 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Literate Programming

Tim,

Why don't you simply write text like that to a MathAction page? You can 
extend that with links and everything. And then each time somebody is 
asking what you think literate programming is and why this is important 
for Axiom, you could simply point to that URL. That would safe you hours 
for repeating yourself on this list. The list forgets easily. You know 
the MathAction link and that would lead also to more prominent 
documentation about Axiom. What do you think?

On 07/10/2007 08:49 PM, Tim Daly wrote:
> didier,
> 
> I looked at the link, read the code, and read the documentation.
> 
> Kudos to David. He's documenting his code. And he's using what
> I'd characterize as a semi-literate style. I'd fit him into a
> scale that looks something like:
> 
> Illiterate:
>   0) raw code
>   1) raw code with minor comments
>   2) raw code with organized comments
> Semi-literate:
>   3) code with extractable comments (aka javadoc, doxygen)
>   4) code with latex comments (dsbweb)
> Literate:
>   5) documentation with embedded code (web)
> 
> His comment style is exceptionally good. He writes for human readers.
> 
> My only nitpick comes from the fact that he's "still the programmer"
> writing for the machine and decorating his code with nice comments.
> It is better than no comments at all but I don't think he really
> became fully literate.  For the kind of "little-file, C-mindset"
> programming he is doing it probably isn't worth it. Literate
> programming and the "file" idea tend to get in the way of each
> other. {C, Java, etc} programmers tend to be unable to transcend
> the file-based thinking.
> 
> The hardest thing I found about making the transition to literate
> programming is that the "literate" part overrides the "programming"
> part in importance. That is, besides writing for humans in comment
> style you also end up having to "scramble" the program so it takes 
> on a logical development style for the human reader. Writing for
> the human is much harder and more time consuming than writing for
> the machine. It only makes sense if the program is intended to
> be maintained by other humans over a long time, raising the need
> to write for humans.
> 
> dbsweb is clearly a "comment processor tool", like javadoc. The
> structure of the program overrides the comment structure. Thus, "main"
> ends up being the last thing in the file because the machine needs it
> that way.  But if you read things like "Lisp in Small Pieces" he
> starts out explaining things "top-down", so he starts explaining the
> "main" program first. dbsweb doesn't have chunking and thus does not
> allow you to "float" things into a logical sequence for the human. You
> are primarily talking to the machine and dragging the human along.
> 
> That said, I'm happy to see that he has "gotten the idea" well enough
> that he's willing to build a tool to help him along. But he still 
> hasn't raised his eyes from the machine.
> 

\start
Date: Tue, 10 Jul 2007 14:11:01 -0500
From: Tim Daly
To: Didier Deshommes
Subject: Literate Programming

didier,

> I don't know much about lp but maybe it isn't catching up because the
> tools are too limited and/or too combersome for "normal users"?

I don't think it is a tools issue at the core of the problem.
I think the problem is that it is hard work. To write for the
machine I only have to convince the compiler to swallow the code.
To write for the human I have a much harder task.

The only thing I believe will make literate programming become the
norm will be "rising standards". Proofs in the 1800s are now considered
"handwaving" today, lacking in rigor. Standards have changed. Programs
from the 1960s look hopelessly primitive now. Standards have changed.
Eventually Axiom will set the standard for computational mathematics.

For large, theory based programs like Axiom where the algorithms and
answers are timeless it makes sense to invest time and effort into
documenting the code in great detail. Each person can contribute
something small and the whole will build up, reorganize, and
eventually represent a large (hopefully coherent) whole. We only need
to do a small amount with each change. If we document a single
function out of a domain because we modified that function then it
represents progress. People can take on the task of organizing and
documenting parts of code that are of interest to them. I've started
on the interpreter (bookvol5) and eventually hope to have that fully
literate.

It's not the tools. Latex is trivial to use. It's the work.

\start
Date: Tue, 10 Jul 2007 14:18:18 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Literate Programming

Ralf,

> Why don't you simply write text like that to a MathAction page?

I don't know, actually. Probably because the initial comment comes
in email. I'm 100% email driven, both for Axiom and work so I tend
to react to the linear stream. Besides, when I do have stuff on
MathAction (like the 2004 goals document) it tends to get lost even
when it is linked from the FAQ. And since my mail is text-only I
cannot embed or follow http links so I don't use them much. I'm
still living in the late 80s.

Hardly anything I write is worth keeping anyway :-)

\start
Date: Tue, 10 Jul 2007 21:37:09 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Literate Programming

> I don't know, actually. Probably because the initial comment comes
> in email. I'm 100% email driven, both for Axiom and work so I tend
> to react to the linear stream. Besides, when I do have stuff on
> MathAction (like the 2004 goals document) it tends to get lost even
> when it is linked from the FAQ. And since my mail is text-only I
> cannot embed or follow http links so I don't use them much. I'm
> still living in the late 80s.

Tim,

don't you think you should change a bit yourself? You cannot teach 
people how good LP is if you are still reading/writing your emails text 
based. If you have not advanced being able to just click on a link in an 
email and follow it to open a webbrowser with the linked page, then I 
tend to say that people will not believe what you say. Your visions will 
stay visions and will never come true. Please come to our time.

> Hardly anything I write is worth keeping anyway :-)

Not true. I like your visions and your preaching about LP. And in fact, 
I would have liked to see them on MathAction. And yes, things will be 
forgotten on a wiki if they are not prominently linked or easily found 
by google or if you don't repeat advertising that URL. I just wanted to 
suggest you to save some time. Typing one URL in a mail (or use your 
mouse and drag&drop it to your mailer) costs far less than typing the 
whole text again.

Ralf

PS: I hope you are not angry on me. ;-)

\start
Date: 10 Jul 2007 15:55:24 -0400
From: Stephen Wilson
To: list
Subject: Re: defintrf bug

--=-=-=

*,

Stephen Wilson writes:
> I will try again with my original idea to make compWithMappingMode
> smarter, to lift only those identifiers which it can prove are bound.

OK.  I believe we can bury this bug finally.

Attached is a patch against
compiler.boot.pamphlet:compWithMappingMode.  Im not including a
documentation change as I think a clean patch addressing this bug in
isolation is desirable. I will follow up with a patch which documents
the affected function within the next few days (as well as salvaging
the documentation from my previous patch).

Locally, this change appears to affect the generated lisp for DFINTTLS
only.  The change appears to pass all tests.  I am confident enough at
this point to `sign-off' this change.

The principle modification is basically one line.  Call getmode on an
identifier to see if it has a type in the current environment.  I was
reluctant to pursue this path initially because I could not convince
myself that this was a `correct' usage of the function.  This is due
to my lack of knowledge of the compiler as a whole.

Therefore, for those interested, find attached the file cwmm-test.spad
which basically stress tests the patch.  This gives me confidence that
the change is working as I expect it to for general use cases --
esp. when examining the generated Lisp.  I would like to see a
facility in place where spad code such as this could be tested as part
of the regression suit.  Something like AldorUnit for spad would
certainly be of great help.  Perhaps I can find the time to get
something like that in place.


Take care,
Steve



--=-=-=

--- changelog	2007-07-10 15:21:54.000000000 -0400
+++ changelog.sxw	2007-07-10 15:22:47.000000000 -0400
@@ -1,3 +1,4 @@
+20070710 sxw src/interp/compiler.boot.pamphlet fix issue #370
 20070709 sxw src/input/Makefile add iprntpk.regress
 20070709 sxw src/input/iprntpk.input new test case
 20070709 sxw src/algebra/newdata.spad fix force-output call (issue #371)

--=-=-=

--- compiler.boot.pamphlet	2007-07-10 14:35:20.000000000 -0400
+++ compiler.boot.pamphlet.sxw	2007-07-10 15:20:16.000000000 -0400
@@ -329,39 +329,40 @@
   $FUNNAME :local := nil
   $FUNNAME__TAIL :local := [nil]
   expandedFunction:=COMP_-TRAN CADR uu
-  frees:=FreeList(expandedFunction,vl,nil)
-    where FreeList(u,bound,free) ==
+  frees:=FreeList(expandedFunction,vl,nil,e)
+    where FreeList(u,bound,free,e) ==
       atom u =>
         not IDENTP u => free
         MEMQ(u,bound) => free
         v:=ASSQ(u,free) =>
           RPLACD(v,1+CDR v)
           free
+        not getmode(u, e) => free
         [[u,:1],:free]
       op:=CAR u
       MEMQ(op, '(QUOTE GO function)) => free
       EQ(op,'LAMBDA) =>
         bound:=UNIONQ(bound,CADR u)
         for v in CDDR u repeat
-          free:=FreeList(v,bound,free)
+          free:=FreeList(v,bound,free,e)
         free
       EQ(op,'PROG) =>
         bound:=UNIONQ(bound,CADR u)
         for v in CDDR u | NOT ATOM v repeat
-          free:=FreeList(v,bound,free)
+          free:=FreeList(v,bound,free,e)
         free
       EQ(op,'SEQ) =>
         for v in CDR u | NOT ATOM v repeat
-          free:=FreeList(v,bound,free)
+          free:=FreeList(v,bound,free,e)
         free
       EQ(op,'COND) =>
         for v in CDR u repeat
           for vv in v repeat
-            free:=FreeList(vv,bound,free)
+            free:=FreeList(vv,bound,free,e)
         free
       if ATOM op then u:=CDR u  --Atomic functions aren't descended
       for v in u repeat
-        free:=FreeList(v,bound,free)
+        free:=FreeList(v,bound,free,e)
       free
   expandedFunction :=
             --One free can go by itself, more than one needs a vector

--=-=-=



)abbrev domain CWMMT CompWithMappingModeTest

CompWithMappingModeTest() : Exports == Implementation where

  Exports == with
     runTests : () -> Boolean

  Implementation == add

     REC ==> Record(field1 : Integer, field2 : String)
     UN  ==> Union(rec : REC, str : String)

     -- The following function accepts a map as argument to test
     -- compWithMappingMode.
     mapper(fn : Integer -> Boolean, n: Integer) : Boolean == fn n

     -- We use the following as a target for currying and to pass to 
     -- mapper above.
     pred(x: Integer, y: Integer) : Boolean == 
       x < y => true
       true

     test1(x : Integer) : Boolean == 
        r : REC := [1, ""]
        mapper(pred(r.field1, #1), 1)

     test2(x : Integer) : Boolean == 
        r : REC := [1, ""]
        i : Integer := 1
        mapper(pred(r.field1 + x, #1), 1)

     test3(x : Integer) : Boolean == 
        r : REC := [1, ""]
        i : Integer := 1
        mapper(pred(r.field1 + i, #1), 1)

     test4(x : Integer) : Boolean ==
        r : REC := [1, ""]
        i : Integer := 1
        mapper(pred((r.field1 + min(#(r.field2), i)), #1), 1)

     test5(x : Integer) : Boolean ==
        r : REC := [1, ""]
        i : Integer := 1
        mapper(pred((r.field1 + min(#(r.field2), i + x)), #1), 1)

     test6(x : Integer) : Boolean ==
        u : UN := [[1, ""]$REC]
        mapper(pred(u.rec.field1, #1), 1)

     test7(x : Integer) : Boolean == 
        u : UN := [[1, ""]$REC]
        i : Integer := 1
        mapper(pred(u.rec.field1 + x, #1), 1)

     test8(x : Integer) : Boolean == 
        u : UN := [[1, ""]$REC]
        i : Integer := 1
        mapper(pred(u.rec.field1 + i, #1), 1)

     test9(x : Integer) : Boolean ==
        u : UN := [[1, ""]$REC]
        i : Integer := 1
        mapper(pred((u.rec.field1 + min(#(u.rec.field2), i)), #1), 1)

     test10(x : Integer) : Boolean ==
        u : UN := [[1, ""]$REC]
        i : Integer := 1
        mapper(pred((u.rec.field1 + min(#(u.rec.field2), i + x)), #1), 1)

     runTests() : Boolean ==
        test1(1) and test2(1) and test3(1) _
                 and test4(1) and test5(1) _
                 and test6(1) and test7(1) _
                 and test8(1) and test9(1) _
                 and test10(1)


--=-=-=--

\start
Date: Tue, 10 Jul 2007 15:43:56 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Literate Programming

Ralf,

> don't you think you should change a bit yourself?

It's worse than you believe, actually. All incoming email is in emacs
RMAIL on one machine and all outgoing email is sent from emacs on
another machine. So I actually retype emails when I reply. The reasons
are numerous, pointless, and historical. Web browsing is done on a
third machine. My mail master is deeply buried and tightly firewalled
so it has no browser installed. It doesn't even have a mouse since it
doesn't run X11, so it wouldn't be possible to "click on a link".  I
do everything everywhere in a completely vanilla, unmodified emacs and
have for the last century or so.

Due to long, heavily buried habits I found it painful to think about
literate programming. The hill was steeper for me than it would be
for someone new to the field. However, having crossed the hill I 
can't imagine that anyone could program any other way. Literate
programming requires you to stop thinking about the machine. Since
I do machine language understanding programs for work that's quite
a stretch :-). However I write those machine language understanding
programs in literate lisp programs.

I know it seems to most people that Literate Programming is both hard
and a waste of time. Having learned how to do it efficiently I find
that I write clearer code (since I have to explain every line) and
it is better structured (since I have to explain why it belongs there).
In some sense it is a waste for work because I'm doing research which
likely won't outlive me :-)

I had a hard time transitioning from using GOTOs to writing structured
programs. Since FORTRAN required GOTOs you had to simulate structured
programs. I felt it was a waste of time until I made the transition.

I had a hard time transitioning to "top down structured programming"
since it delayed writing code until you expanded the task enough to
be concretely implemented. I felt it was a waste of time until I made
the transition.

I had a hard time .... (repeat with each new technology) ...
I felt it was a waste of time until I made the transition.

The amazing thing is that programmers go thru this cycle every few
years making the same, "I don't want to change. It's too much work".
We now have very complex programming languages, like Aldor.
But we still comment like we were writing assembler. And we still
write for the machine.

If Axiom were already fully literate nobody would consider the idea of
writing a domain without documentation. There would be standards of
excellence that would be generally accepted and applied.  The only way
I know to raise the standards of excellence expected is to set the
example. Considering where we are in the history of computational
mathematics this is the time to start. It will feel like a waste of
time until we make the transition :-)

Lift your eyes. Look away from the machine and write for the future.


> PS: I hope you are not angry on me. ;-)

I'm not angry with anyone. 
Except myself for losing my patience at times.

\start
Date: Tue, 10 Jul 2007 23:15:42 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Literate Programming

Hi Tim,

On 07/10/2007 10:43 PM, Tim Daly wrote:
> Ralf,
> 
>> don't you think you should change a bit yourself?
> 
> It's worse than you believe, actually. All incoming email is in emacs
> RMAIL on one machine and all outgoing email is sent from emacs on
> another machine. So I actually retype emails when I reply. The reasons
> are numerous, pointless, and historical. Web browsing is done on a
> third machine. My mail master is deeply buried and tightly firewalled
> so it has no browser installed. It doesn't even have a mouse since it
> doesn't run X11, so it wouldn't be possible to "click on a link".  I
> do everything everywhere in a completely vanilla, unmodified emacs and
> have for the last century or so.

Do you think that I believe what you are claiming?

\start
Date: Tue, 10 Jul 2007 16:44:12 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Literate Programming

Ralf,

> Do you think that I believe what you are claiming?

Look at my email replies and look at the headers.
Normal replies have an "In-Reply-To: field which emacs RMAIL copies
when you click reply. See how many you find.

\start
Date: 10 Jul 2007 20:58:38 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: counting allocated bytes

--=-=-=

Hello,

I have been working on evaluating/integrating a Lisp based testing
framework into Axiom (based on Lift).  One of the features is the
ability to benchmark the running of tests.  

To accommodate the benchmark code, I needed a function which returns
the total number of bytes allocated since the image was started.  

I could not find such a function.  Perhaps I missed it? There is
SI:ALLOCATED, but it reports information for a specific type only.

I considered writing a function using SI:ALLOCATED and SI:SIZE-OF for
personal use.  However, when I considered if such a function would be
of use to GCL, I realized it may be better to attempt it in C.

Of course, if the facility already exists, then this is just a
learning experience for me.  Attached is a patch against alloc.c.

I have two issues with this code:

  * Is it correct to assume that all entries in tm_table with the
    tm_size field equal share the same allocation space?  I assumed
    this from the documentation for SI:ALLOCATED.

  * Im slightly concerned about overflow of the `bytes' variable.  Is
    this likely?  Should bignum arith be used?

Hopefully this might be of some use to GCL, however I completely
understand if it is deemed unnecessary, badly implemented, etc.

Sincerely,
Steve


--=-=-=

--- alloc.c	2007-07-04 14:54:42.000000000 -0400
+++ alloc.c.smw	2007-07-10 20:54:56.000000000 -0400
@@ -547,7 +547,24 @@
 	     RV(make_fixnum(tm->tm_nused))
 	     ));
 }
- 
+
+DEFUN_NEW("TOTAL-BYTES-ALLOCATED",object,fStotal_bytes_allocated,SI,0,0,NONE,OO,OO,OO,OO,(void),"")
+{int i,j;
+ bool counted;
+ long bytes = 0;
+ for(i=t_start; i < t_end; i++) {
+     counted = FALSE;
+     for(j=t_start; j < i; j++)
+         if (tm_table[i].tm_size == tm_table[j].tm_size) {
+             counted = TRUE;
+             break;
+         }
+     if (!counted)
+         bytes += tm_table[i].tm_size * tm_table[i].tm_nused;
+ }
+ RETURN1(make_fixnum(bytes));
+}
+
 DEFUN_NEW("RESET-NUMBER-USED",object,fSreset_number_used,SI,0,1,NONE,OO,OO,OO,OO,(object typ),"")
 {int i;
  if (VFUN_NARGS == 1)

--=-=-=--

\start
Date: Tue, 10 Jul 2007 21:38:34 -0500
From: Tim Daly
To: Stephen Wilson
Subject: defintrf bug

Stephen,

I've retracted your previous MACROEXPAND patch.
I've applied your compiler.boot patch. 
I'm starting a test cycle now 

\start
Date: 11 Jul 2007 07:23:08 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: Literate Programming

Tim Daly writes:

> Ralf,
> 
> > Do you think that I believe what you are claiming?
> 
> Look at my email replies and look at the headers.
> Normal replies have an "In-Reply-To: field which emacs RMAIL copies
> when you click reply. See how many you find.

Ah, that's why!  I often wondered why my gnus fails to thread your mails
correctly: I guess you also don't copy the "references:" field.

Tim, do you realize that your habits make it *very* difficult to work with you
at times?  Fortunately, with emails it's jhust a nuisance. But with svn, it's
really a way to block development.

Just to make sure you understand: I am completely convinced of the goal of
having "literate" files, and in fact, I also think that noweb is the right
tool.  Otherwise I would not have contributed documentation.

But I'm also convinced that I cannot continue axiom-development if our
development model remains as it is.  I will propose a model I could live with
on friday morning.

\start
Date: Wed, 11 Jul 2007 00:38:30 -0500
From: Tim Daly
To: Stephen Wilson
Subject: defintrf bug

Stephen,

> I've retracted your previous MACROEXPAND patch.
> I've applied your compiler.boot patch. 
> I'm starting a test cycle now 

Nice work. The patch you posted affects only the single failing file.

Now I'm going to integrate your spad-based test case which will take
some fooling minor fooling around. 

\start
Date: Wed, 11 Jul 2007 01:03:52 -0500
From: Tim Daly
To: Martin Rubey
Subject: Literate Programming

Martin,

> I will propose a model I could live with on friday morning.

And hopefully on the following monday :-)

I'm open to suggestion, especially if it smooths the working
environment. I've been trying to get the SVN running smoothly
by ensuring that every update is a changeset, that is, a single
logical change that adds a feature or fixes a bug. And I've been
marking either the bugzilla bug number or the SVN revision number
in the changelog entry.

Every patch has extensive testing here before anything actually
shows up in SVN. Posted patches, for instance the ones that Stephen
has been posting, usually get modified or expanded (e.g. to add 
the files to the Makefile chain, to rearrange documentation, etc).
Each patch requires at least two builds, a pre-patch build and a
post-patch build so any changes can be identified. Thus there is a
bit of lag from the time the patch hits the mailing list and the
time the patch hits SVN. In some cases, e.g. the first defintrf
patch, the posted patch never makes it thru testing at all.

This may seem like overkill, especially since people have already
tested their patch before posting it. However, the silver branch
should never be broken (modulo mistakes). Its a quality issue.

I realize I've been a bit of a pompous ass and I do apologize
for exposing my fundamental character so clearly in public :-)

Seriously though, I hope you can accept my apology.

\start
Date: 11 Jul 2007 07:19:27 -0500
From: Gabriel Dos Reis
To: Camm Maguire
Subject: re: directory/truename transition

Camm Maguire writes:

[...]

| 4) ignore 2.7.0 for mingw until someone shows real interest in it, at
|    which time I'd be most happy to help.  2.6.8 will always be there
|    to suffice, and decoupling 2.7.0 from mingw will liberate
|    development.   Who knows, with any luck, Windows itself will go the
|    way of histories dustbin by the time this is ever an issue.


To my mind, this suggests that Axiom would be better off:

  (1) dropping Lisp as its base runtime system as soon as possible. or
  (2) moving to other open source Lisp system as soon as possible, in
      particular those that support Windows.

\start
Date: 11 Jul 2007 07:33:48 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: friCAS

Tim Daly writes:

| Waldek,
| 
| You've decided that you'd rather not contribute to Axiom.

Tim --

   Stop that nonsense.

To my mind, you owe Waldek an apology.

And please stop being divisive and exclusive; you're on the road of
sabotaging the project and its community.

\start
Date: 11 Jul 2007 07:44:43 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: FriCAS
Cc: Bill Page

Ralf Hemmecke writes:

[...]

| Anyway, I believe (and I am probably right) that the branching (which
| started with build-improvements and then wh-sandbox) without sending
| patches (against gold) to the list was because these patches would
| disappear into a (formerly hidden gold-to-be).

Yes.

And I still believe branching was and is the Right Thing to do in
those specific cases.

I'd urge Tim to stop being divisive, exclusive, dragging the
project down into deeper black holes.

[...]

| Now gold-to-be=silver=trunk is in the open and developer knows about
| the hottest and latest development. That is good. In my eyes sending
| patches is about to begin. Gaby is preparing. But note, we had no open
| silver (but rather two or three unofficial ones). This chaos has
| stopped me from actually opening a doc-improvements branch.

Ralf --
  
  I would suggest that you branch off SF trunk (e.g. silver) and do
your work there and prepare patches.  Ignore Tim's politics for
doc-improvements branch.

\start
Date: 11 Jul 2007 07:57:30 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Axiom, FriCAS, forks and teeth

The notion that Axiom would need just to be written once and never
rewritten again is -- I'm afraid -- completely deconnected from
reality, and reflects an amateurish approach to software that
saddens me.

(1)  As a law, useful software evolve; otherwise they die.

(2)  Axiom is to support computational mathematics.  While 1+1=2
     will ternally be true, computation technologies *evolve*, *change*
     and many parts of Axiom will have to be changed, evolved,
     rewritten.

When you think you have 30 years to write Axiom, think about what
the environment in which it will be deployed will look like.  If you
don't need to make it useful, you can disregard my comments.  If you
don't need to sustain its development till 30 years from now, please
disregard my comments.
      
\start
Date: 11 Jul 2007 08:01:38 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Axiom, FriCAS, forks and teeth

Ralf Hemmecke writes:

| On 07/10/2007 04:22 AM, Bill Page wrote:
| > On 7/9/07, C Y wrote:
| >> ... Literate programming is not a mainstream methodology (in my opinion)
| >> because few developers are willing to accept the long lead times and hard
| >> work of researching the necessary background to make a good literate
| >> document. ...
| 
| Literate programming is not mainstream since it costs a lot of time
| and the programmer puts all or at least most of his knowledge about
| the program, background, and design into a pamphlet.

It costs lot of resouorces and it is not obvious that empirical data we have 
support the claim that it is an effective and efficient methodology.

[ well, as far as Axiom is concerned, it is more efficient at
  generating emails than making the project better. ]

I'm not saying that Axiom should not be properly documented.  Quite
the contrary. 

\start
Date: 11 Jul 2007 08:03:18 -0500
From: Gabriel Dos Reis
To: Jay Belanger
Subject: Re: Axiom, FriCAS, forks and teeth

Jay Belanger writes:

| Bill Page writes:
| ...
| > But literate programming is not really the problem. Rather I think the
| > problem as usual, is just the way in which decisions are (and are not)
| > being made in the project.
| 
| One reason for the fork was to be able to put off documentation,

Did you get that for a fact from Waldek?

\start
Date: 11 Jul 2007 08:05:32 -0500
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Unions in Spad

Stephen Wilson writes:

| *,
| 
| During my work figuring out the defintrf.spad bug, I noticed a
| shortcoming in the handling of unions.
| 
| Spad, internally, has two notions of Unions.  The first variety might
| be termed `regular', the other is, not surprisingly, termed `new'.
| 
| Regular Unions do not have tags associated with branches. For example:
| 
|       Union(Integer, String)
| 
| New Unions have tags, as in
| 
|       Union(int: Integer, str: String)

Both are documented in the Axiom book by Jensk and Sutor.

I believe, they are almost right.  Except one thing that I consider
a bug, not a feature:  the labels in unions and records should be
properly scoped/predicated instead of being dumped into the global space.

\start
Date: 11 Jul 2007 08:08:27 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Unions in Spad

Bill Page writes:

| But really I think the concept of "selectors" in both Union and Record
| is at best a legacy of earlier days in programming language design. 

Curiously, I believe they almost right.  fields in
unions and records need to be properly scoped.

| It
| makes much for sense to me to define Union and Record as co-limit and
| limit in the sense of category theory. Then Union selectors are just
| injections operations and Record selectors are projection operations
| which are exported like any other function from these types. There is
| no need for any lower level language construct.

Well, if we are to be following that reasoning, there is no need for Spad
-- we just need lambda calculus. 
We should be discussing what is useful, convenient; not the bare
minimum that is necessary.

\start
Date: 11 Jul 2007 12:01:29 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: Unions in Spad

Bill, Waldek,

Thank you both for your replies!

I think the consensus is that `hybrid' Union types are not desirable.
Consequently, I will look into making Spad strictly enforce this.  In
addition, the constraint that an untagged Union not have identically
typed branches, and that in the tagged case all branch names are
distinct.

Bill Page writes:
[...]
> Thinking out load: Perhaps this use of ':' should be given explict
> operator semantics so that it could be considered as just a pretty
> form of type constructor, e.g.
> 
>   Keyword(x:Symbol,T:Type): ... with KeywordCategory ...
>     == T add ...
> 
> (not withstanding that it's usage here is recursive). Then as a type
> it would be easy to insist that a parameter to a constructor be of
> this type by requiring KeywordCategory.
> 
> Does this make sense?

If we were to support keyword arguments, the binding of arguments
would need to be part of the type.  I believe that what you are
suggesting is essentially how one one would need to view `x : T' when
implementing the facility.

\start
Date: 11 Jul 2007 12:22:15 -0400
From: Stephen Wilson
To: Waldek Hebisch
Subject: Re: Unions in Spad

Hello Waldek,

Waldek Hebisch writes:

> I think it is better to catch such errors on a post-parsing stage.
> Why this may matter: syntax errors frequently leave parser in a
> confused state, making hard to detect other errors.  Also for users
> is seem easier to have simple syntax + set of semantic constraints
> than to encode constraints in syntax.

My personal preference is for strict syntax constraints, with a syntax
error being a hard error.  Main reasons being that to continue and
process syntactically invalid input is for the sole purpose of generating
additional error messages.  I feel users would not mind having a
single accurate error message vs. wading through a pile of possibly
nonsensical reports.  I find this approach more useful especially when
the language has an interpreter (which would be very nice to have for
Spad). 

Semantic errors are just as likely to leave a type-checker or other
analysis phase in a confused state.

Im not sure how simple syntax vs. strict semantic constraints makes
the users life any easier.  They still need to play by the rules,
grammatical or not.

Just my 2 cents.

\start
Date: 11 Jul 2007 11:26:47 -0500
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Unions in Spad

Stephen Wilson writes:

| Bill, Waldek,
| 
| Thank you both for your replies!
| 
| I think the consensus is that `hybrid' Union types are not desirable.

I'm not sure I understand the arguments why they are not desirable.

\start
Date: 11 Jul 2007 12:40:19 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: Unions in Spad

Gabriel Dos Reis writes:

> Stephen Wilson writes:
> | I think the consensus is that `hybrid' Union types are not desirable.
> 
> I'm not sure I understand the arguments why they are not desirable.

Main question is _why_ they might be desirable.  Spad does not
support them.  Aldor might in theory, but only in theory.

As such a construct appears to give no real benefit for anyone,  Im
thinking that properly encoding the constraint is the proper move.

Do you have an argument for `hybrid' Unions?

\start
Date: 11 Jul 2007 13:45:43 -0400
From: Camm Maguire
To: Tim Daly
Subject: TAGS file for pamphlets

Greetings!  Anyone know how to make an emacs TAGS file from pamphlet
source? 

\start
Date: 11 Jul 2007 13:51:13 -0400
From: Camm Maguire
To: Tim Daly
Subject: lisp compilation warnings

Greetings!  The axiom build is full of compilation warnings, most of
which are un-defvared global variables, plus a few argument number
mismatches.  This makes it hard for me to catch genuine 2.7 errors
early on in the build.  Is there any simple way to instuct the lisp
code generator to defvar the globals?

\start
Date: 11 Jul 2007 13:58:27 -0400
From: Camm Maguire
To: Tim Daly
Subject: 2.7 build

Greetings!  Right after interpsys is created, and ACPLOT.spad is
compiled, something writes the source file ACPLOT.lsp, which contains:


(/VERSIONCHECK 2) 

(DEFUN |ACPLOT;NFtoSF| (|x| $)
  (PROG ()
    (RETURN
      (+ '#1=#((|DoubleFloat|)
               (#<compiled-function |lookupComplete|> #1#
                #(~= 231 |zero?| 237 |wholePart| 242 |unitNormal| 247
                  |unitCanonical| 252 |unit?| 257 |truncate| 262 |tanh|
...

The function is unreadable.  Where is the function that writes this
source? 

\start
Date: Wed, 11 Jul 2007 11:03:37 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Axiom, FriCAS, forks and teeth

--- Gabriel Dos Reis wrote:

> The notion that Axiom would need just to be written once and never
> rewritten again is -- I'm afraid -- completely deconnected from
> reality, and reflects an amateurish approach to software that
> saddens me.

This may indeed be amateurish, but after all I AM an amateur.  I am
aware that Axiom will need to be extended and built upon indefinitely,
if for no other reason than because mathematical research is
continuing.  What I want is for solved problems to remain solved, just
as TeX's solution to typesetting has kept it a solved problem for
decades.  What is the limit?  How robust and future proof can the
system be made?  I want to find out.
 
> (1)  As a law, useful software evolve; otherwise they die.

Certainly.  If actual new ideas appear, they should be incorporated.  I
would hope that these would be in areas like new mathematics, new
output formats, new graphics backends, etc - i.e. changes not involving
the core of the system.

Maybe this is a practical impossibility, but I am not yet convinced of
that and would like to try.

> (2)  Axiom is to support computational mathematics.  While 1+1=2
>      will ternally be true, computation technologies *evolve*,
>      *change* and many parts of Axiom will have to be changed,
>      evolved, rewritten.

My hope is that changes and new abilities can be added strictly to
address new ideas and new operating environments, and that the internal
design and logic will scale independently of any external technology
changes.  Maybe it can't work this way, but I am hopeful that new
effort could someday be focused almost exclusively on mathematical
features and not superstructure.

> When you think you have 30 years to write Axiom, think about what
> the environment in which it will be deployed will look like.  If you
> don't need to make it useful, you can disregard my comments.  If you
> don't need to sustain its development till 30 years from now, please
> disregard my comments.

Speaking ONLY for myself, short term usefulness is not my primary goal.
 Please note I am NOT saying that it is an unimportant goal, just that
it is not what drives my personal interest in this project.

I am tremendously impressed by what Knuth has achieved with TeX, which
is still used and has gone unsurpassed for decades.  New features have
been added as new technologies are created (pdf export, for example)
but the core of TeX has stood the test of time.  I want a CAS which
will do the same thing for computational mathematics - stand the test
of time.  It took something like 10 years to create TeX, IIRC.  The
results have paid off, at the expense of a long lead time.  The system
is still extended today, of course, but the foundation has remained
steady.

THAT is the kind of project I want to work on.  The TeX of computer
algebra systems.  Am I disconnected from reality?  Possibly.  But we
have a wide variety of commercial systems and even free alternatives
like Maxima that are addressing real problems today.  Axiom's codebase
itself can be forked to a project with different objectives.  MY
PERSONAL INTEREST is in the long term, TeX-like system that can last -
can it be done?  What would it take?

I don't ask anyone to accept my interests as the "correct" ones - they
are simply my interests and the reason I spend my time on this project.
 Other people have other interests, and that is great.  I intend to
pursue mine - the experiment of Axiom as a long term project.

\start
Date: 11 Jul 2007 14:12:21 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: Re: lisp compilation warnings

--=-=-=

Hi Camm,

Camm Maguire writes:

> Greetings!  The axiom build is full of compilation warnings, most of
> which are un-defvared global variables, plus a few argument number
> mismatches.  This makes it hard for me to catch genuine 2.7 errors
> early on in the build.  Is there any simple way to instuct the lisp
> code generator to defvar the globals?


Could you try this patch?  Only minimally tested.

Take care,
Steve



--=-=-=

diff --git a/src/interp/comp.lisp.pamphlet b/src/interp/comp.lisp.pamphlet
index f822aad..08a1438 100644
--- a/src/interp/comp.lisp.pamphlet
+++ b/src/interp/comp.lisp.pamphlet
@@ -309,16 +309,20 @@
       (let ((fluids (S+ fluidvars SpecialVars)))
         (setq x
               (if fluids
-                  `(,(first x) ,(second x)
-                    (prog ,lvars (declare (special . ,fluids))
-                      (return ,(third x))))
-                  (list (first x) (second x)
-		     (if (or lvars (contained 'RETURN (third x)))
-			 `(prog ,lvars (return ,(third x)))
-		         (third x)) )))))
+                 (progn
+                   (format out-stream "~%~{(defvar ~S)~%~}" fluids)
+                   `(,(first x) ,(second x)
+                     (prog ,lvars (declare (special . ,fluids))
+                           (return ,(third x)))))
+                 (list (first x) (second x)
+                       (if (or lvars (contained 'RETURN (third x)))
+                           `(prog ,lvars (return ,(third x)))
+                           (third x)))))))
     (let ((fluids (S+ (comp-fluidize (second x)) SpecialVars)))
       (if fluids
-          `(,(first x) ,(second x) (declare (special . ,fluids)) . ,(cddr x))
+          (progn
+            (format out-stream "~%~{(defvar ~S)~%~}" fluids)
+            `(,(first x) ,(second x) (declare (special . ,fluids)) . ,(cddr x)))
           `(,(first x) ,(second x) . ,(cddr x))))))
 
 ; Fluidize: Returns a list of fluid variables in X

--=-=-=--

\start
Date: 11 Jul 2007 14:32:10 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: Re: 2.7 build

Camm Maguire writes:

> Greetings!  Right after interpsys is created, and ACPLOT.spad is
> compiled, something writes the source file ACPLOT.lsp, which contains:
> 
> 
> (/VERSIONCHECK 2) 
> 
> (DEFUN |ACPLOT;NFtoSF| (|x| $)
>   (PROG ()
>     (RETURN
>       (+ '#1=#((|DoubleFloat|)
>                (#<compiled-function |lookupComplete|> #1#
>                 #(~= 231 |zero?| 237 |wholePart| 242 |unitNormal| 247
>                   |unitCanonical| 252 |unit?| 257 |truncate| 262 |tanh|
> ...
> 
> The function is unreadable.  Where is the function that writes this
> source? 

Unfortunately I cannot reproduce.  I get:

   (DEFUN |ACPLOT;NFtoSF| (|x| $) 
        (PROG NIL (RETURN (+ 0.0 (SPADCALL |x| (QREFELT $ 22))))))

Perhaps this is a wh-sandbox issue?  CC'ing Waldek.


\start
Date: Wed, 11 Jul 2007 13:36:01 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Unions in Spad

On Wed, 11 Jul 2007, Stephen Wilson wrote:

| Gabriel Dos Reis writes:
| 
| > Stephen Wilson writes:
| > | I think the consensus is that `hybrid' Union types are not desirable.
| > 
| > I'm not sure I understand the arguments why they are not desirable.
| 
| Main question is _why_ they might be desirable.  Spad does not
| support them.  Aldor might in theory, but only in theory.
| 
| As such a construct appears to give no real benefit for anyone,  Im
| thinking that properly encoding the constraint is the proper move.
| 
| Do you have an argument for `hybrid' Unions?

In general, I'm of the opinion that the language should be
constrained only when we cannot come with proper semantics.
I'm not sure this case is one such case; that is why I would
like to understand the arguments.  I don't want a language
designed to express only what I can think of today.

\start
Date: 11 Jul 2007 14:40:09 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: Unions in Spad

Gabriel Dos Reis writes:

[...]
> In general, I'm of the opinion that the language should be
> constrained only when we cannot come with proper semantics.
> I'm not sure this case is one such case; that is why I would
> like to understand the arguments.  I don't want a language
> designed to express only what I can think of today.

In general I agree.  Thats why I posted the questino to begin with  --
I did not want to rashly abandon the possibility that the construct
might have some use.

I belive a useful semantics for a `hybrid' Union is possible.  I
belive I can make it work but am unsure when I will have the time to
implement it.  Perhaps it would be best to get a prototype running and
conduct some experiments to get an empirical `feel' for the construct?

\start
Date: Wed, 11 Jul 2007 13:41:41 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Axiom, FriCAS, forks and teeth

On Wed, 11 Jul 2007, C Y wrote:

| > (1)  As a law, useful software evolve; otherwise they die.
| 
| Certainly.  If actual new ideas appear, they should be incorporated.  I
| would hope that these would be in areas like new mathematics, new
| output formats, new graphics backends, etc - i.e. changes not involving
| the core of the system.

I believe that the core of the system would have to change, evolved,
rewritten, rethinked. 
The future -- at least the near future -- is in parallel/distributed
computations with multicores expected to grow exponentially.  We
will have to rethink most of the algorithms at the of the system.
Not just envelops like graphics backends.

Computational mathematic is not a static thing -- because it is
about computation and the technology evolves, quite rapidly.

\start
Date: Wed, 11 Jul 2007 13:44:52 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Unions in Spad

On Wed, 11 Jul 2007, Stephen Wilson wrote:

| I belive a useful semantics for a `hybrid' Union is possible.  I
| belive I can make it work but am unsure when I will have the time to
| implement it.  Perhaps it would be best to get a prototype running and
| conduct some experiments to get an empirical `feel' for the construct?

That would be definitely useful.

I hope to have time to put the slides of the talk I gave about Axiom
(personal views) on the web by tonight.

In general I would like to see `real' algebra datatypes and
pattern matching in pad, instead of the current cruiosu case statements.

\start
Date: Wed, 11 Jul 2007 21:04:23 +0200 (CEST)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: Axiom, FriCAS, forks and teeth
Cc: Gabriel Dos Reis

C Y wrote:
> --- Gabriel Dos Reis wrote:
> > (1)  As a law, useful software evolve; otherwise they die.
> 
> Certainly.  If actual new ideas appear, they should be incorporated.  I
> would hope that these would be in areas like new mathematics, new
> output formats, new graphics backends, etc - i.e. changes not involving
> the core of the system.
> 

A little example:

integrate(simplify(D((((((2-(a+log(1)))+sqrt(x)/exp(1))/((exp(x)-sqrt(log(x)-x)-(1-log(exp(sqrt(a)))))+2*(log(x)+1)))+(x))+2)+sqrt(x+2), x)), x)

if you wait long enough (IIRC about 1 hour on my machine), it will
run out of memory.  Checking why shows that Axiom is unable to
compute GCD of two polynomials.  The polynomials when printed are
few kilobytes in size and of relativly low degree (11 in main
variable, 40 in an auxilary one) but involve algbraic quantities
(square roots).  Axiom uses Lazard version on polynomial
remainder sequence algorithm, which IIUC was considered
state of the art around 95.  But today we know about modular
algorithm for problem -- my understanding is that modular
algorithm is supposed to compute this GCD in few seconds
(possible even in fraction of second).  So while old algorithm
remains correct, a superior one may be invented and replace
the old.

There is an extra twist to this:  I suspect that polynomials
in question are relatively prime.  With high probability
a simple modular method will discover this.  But there is
a question how to hook modular method so that it gets
used.  I belive that the polynomials have type 'UP(Expression Integer)'
and you need some extra work to determine if modular method
is applicable.

In short: new algorithms are discovered and to use new algorithm
you may be forced to change parts of the system which at first
glance have nothing to do with new code.

\start
Date: Wed, 11 Jul 2007 15:21:35 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Axiom, FriCAS, forks and teeth
Cc: Gabriel Dos Reis

On 7/11/07, C Y wrote:
> ...
> THAT is the kind of project I want to work on.  The TeX of computer
> algebra systems.  Am I disconnected from reality?  Possibly.  But we
> have a wide variety of commercial systems and even free alternatives
> like Maxima that are addressing real problems today.  Axiom's codebase
> itself can be forked to a project with different objectives.  MY
> PERSONAL INTEREST is in the long term, TeX-like system that can last -
> can it be done?  What would it take?
> ...

I would say that this goal is certainly very disconnected from
reality. I think comparing computer typesetting (TeX) to computer
algebra (in general) is rather like comparing arithmetic to
mathematics (in general). We know pretty well how to do typesetting
and basic arithmetic by computer. And arguably the technology to do
these things hasn't changed very much in the last 30 years (not
withstanding a few significant innovations in numerical algorithms and
vectorized font systems etc.). But the goals of Principia Mathematica
(a universal treatment of mathematics) has been shown by
mathematicians themselves (e.g. Geodel's theorem) not to be attainable
even in principle. Similarly it seems to me that we just barely have a
few clues about how to use a computer to do algebra and more general
mathematics. We don't really know what programming languages and
systems might or might not be appropriate.

As interesting as Axiom is as a research project, realistically Axiom
(nor any other computer algebra system today) is nowhere near reaching
these goals. If by some miracle we actual had a bunch of energetic
mathematicians and developers working full time on Axiom right now, we
would likely still be scrambling just to catch up with other systems
that have become much more capable while Axiom has slept. But like
Principia Mathematica, I think there is a very real possibility that
Axiom's strongly-typed object-oriented approach is not capable even in
principle of serving as the foundation for a "universal" solution to
doing mathematics by computer. Maybe mathematics is necessarily an
activity that must be carried out in a less structured way and so
computer systems would necessarily have to be designed in a manner to
support this. I just don't know.

Anyway, research and experimentation is necessary at several different
levels and if in the end you decide to spend your time working towards
a goal that seems so far away to me that we can only just barely
imagine it, who am I to try to suggest you do otherwise. ... :-)

\start
Date: 11 Jul 2007 15:23:08 -0400
From: Stephen Wilson
To: list
Subject: Bug in GeneralizedMultivariateFactorize?

*,

I was hoping for some help with GeneralizedMultivariateFactorize
(GENMFACT) in allfact.spad.pamphlet.

The issue is with the following code, in particular with the call to
squareFree at the end:

   T == add
    factor(p:P) : Factored P ==
      R has FiniteFieldCategory => factor(p)$MultFiniteFactorize(OV,E,R,P)
      R is Polynomial(S) and S has EuclideanDomain =>
         factor(p)$MPolyCatPolyFactorizer(E,OV,S,P)
      R is Fraction(S) and S has CharacteristicZero and 
        S has EuclideanDomain =>
            factor(p)$MRationalFactorize(E,OV,S,P)
      R is Fraction Polynomial S =>
         factor(p)$MPolyCatRationalFunctionFactorizer(E,OV,S,P)
      R has CharacteristicZero and R has EuclideanDomain =>
               factor(p)$MultivariateFactorize(OV,E,R,P)
      squareFree p


Here, P satisfies a PolynomialCategory over an IntegralDomain.  But
such a P does not export squareFree unless the coefficient ring is a
GcdDomain.  This is a bug in GENMFACT, I believe.

I do not have the experience necessary with the algebra code yet to be
terribly efficient in determining what the proper fix here is.
Perhaps it is as simple as requiring GcdDomain.

Could anyone provide some insight here?

\start
Date: Wed, 11 Jul 2007 12:45:36 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Axiom, FriCAS, forks and teeth

--- Gabriel Dos Reis wrote:

> I believe that the core of the system would have to change, evolved,
> rewritten, rethinked.
> The future -- at least the near future -- is in parallel/distributed
> computations with multicores expected to grow exponentially.  We
> will have to rethink most of the algorithms at the of the system.
> Not just envelops like graphics backends.

For performance concerns, certainly - and I would support and be highly
interested in such work.  For myself, I am more interested in the
limits of correctness verification than high performance parallel
computing.
 
> Computational mathematic is not a static thing -- because it is
> about computation and the technology evolves, quite rapidly.

It depends on what one wants to achieve.  Many interesting and
practical problems are likely within the domain of today's systems, but
physical scientists must do a great deal of computation work either by
hand or with a wary eye on the results of their CAS.  I would like the
CAS to be more reliable with its correctness (either by itself or with
the aid of proof-based results checking) than human beings - it opens
up a new category of usefulness for the tools, IMHO.

\start
Date: Wed, 11 Jul 2007 12:55:30 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Axiom, FriCAS, forks and teeth
Cc: Gabriel Dos Reis

--- Bill Page wrote:

> I would say that this goal is certainly very disconnected from
> reality. I think comparing computer typesetting (TeX) to computer
> algebra (in general) is rather like comparing arithmetic to
> mathematics (in general). We know pretty well how to do typesetting
> and basic arithmetic by computer. And arguably the technology to do
> these things hasn't changed very much in the last 30 years (not
> withstanding a few significant innovations in numerical algorithms
> and vectorized font systems etc.).

Right.  So those abilities and algorithms should be defined once,
reliably, and then used with confidence in the results.  As innovations
are found we can implement the new algorithms and call them if we find
they are better.

> But the goals of Principia Mathematica
> (a universal treatment of mathematics) has been shown by
> mathematicians themselves (e.g. Geodel's theorem) not to be
> attainable even in principle.

OK.  So then, how DO we work with mathematics? (I don't expect an
answer - but it's still a reasonable question, unless one wants to
throw up one's hands.  A universal treatment (whatever that means)
might not be possible, but what is the best solution (or solutions)
that ARE possible?)

> Similarly it seems to me that we just barely have
> a few clues about how to use a computer to do algebra and more 
> general mathematics. We don't really know what programming
> languages and systems might or might not be appropriate.

If we design a system that supports (as nearly as possible without
introducing ambiguity) the way mathematicians are expressing themselves
it seems to me we are doing as well as anyone CAN do.  Anyway it seems
a reasonable direction to proceed, unless someone has better ideas.

> As interesting as Axiom is as a research project, realistically Axiom
> (nor any other computer algebra system today) is nowhere near
> reaching these goals.

Agreed.  We need to get busy ;-).

> If by some miracle we actual had a bunch of energetic
> mathematicians and developers working full time on Axiom right now,
> we would likely still be scrambling just to catch up with other
> systems that have become much more capable while Axiom has slept.

Sure, if you count features.  But can any of those systems take an
answer and use their internal routines to guide the creation of an
axiomatic proof of a answer?  Something that could be verified by ANY
mechanical proof checker that understand the chosen language, or even a
sufficiently patient human?  Without that, how can we trust the results
of any system?  Why should scientists depend on a tool they can't know
is without error and have no hope of verifying?

> But like Principia Mathematica, I think there is a very real
> possibility that Axiom's strongly-typed object-oriented approach is
> not capable even in principle of serving as the foundation for
> a "universal" solution to doing mathematics by computer.

I would be curious what branch(es) of mathematics you think Axiom will
be incapable of dealing with, via one form or another of extension?  Is
there any possible system you feel would be MORE useful?

> Maybe mathematics is necessarily an
> activity that must be carried out in a less structured way and so
> computer systems would necessarily have to be designed in a manner to
> support this. I just don't know.

Neither do I.  But the structured approach to mathematics seems to
yield many useful practical results, even if it cannot be all-inclusive
and remain self consistent.  Perhaps we need the ability to select the
structure in which we wish to approach a given problem.

I would like to understand more thoroughly Godel's work - while I am
sure it is true in general I am not sure how much of a problem it
presents for systems like Axiom.  Surely it's worth finding out.

> Anyway, research and experimentation is necessary at several
> different levels and if in the end you decide to spend your time
> working towards a goal that seems so far away to me that we can
> only just barely imagine it, who am I to try to suggest you do 
> otherwise. ... :-)

If no one works toward those goals, where does the truly new work come
from?  I don't suggest I am capable of such work, but I WOULD like to
make it as easy as possible for work to be done towards those distant
goals.  Also, I would like to "future proof" work that has already been
done, so that as long as it is useful to the system it can be depended
on to work.  Recovering ground previously covered is always a waste. 
Dealing with OS related implementation details is a nusiance that
should be minimized as much as possible.

Am I nuts?  Probably ;-).  I don't know if even Tim shares my views in
this respect.  I know I'm not a good fit for FriCAS, perhaps I am not a
good fit for Axiom.  But what else can we do in a volunteer project but
pursue our interests?  If those are not compatible with the project, I
can work on my own - I have no wish to disrupt anything any further
than it has already been disrupted.

\start
Date: Wed, 11 Jul 2007 15:09:20 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Axiom, FriCAS, forks and teeth

On Wed, 11 Jul 2007, C Y wrote:

| 
| --- Gabriel Dos Reis wrote:
| 
| > I believe that the core of the system would have to change, evolved,
| > rewritten, rethinked.
| > The future -- at least the near future -- is in parallel/distributed
| > computations with multicores expected to grow exponentially.  We
| > will have to rethink most of the algorithms at the of the system.
| > Not just envelops like graphics backends.
| 
| For performance concerns, certainly - and I would support and be highly
| interested in such work.  For myself, I am more interested in the
| limits of correctness verification than high performance parallel
| computing.

Multicore are no longer supercomputers myths you would find in
highly financed National Labs.  They are the reality today.  
If you order a machine from Dell, the probability that you
get a multicore is very high.  How do you we wisely and efficiently
use that computational power?  Clearly Waldek has an example where
Axiom is making a dumb use of resource.  No matter how correct the answer
is.  How would you react to computation of determinant of
an nxn matrix with complexity O(n!)?


Many things that were considered absolute truths or theorems a decade
ago are no longer valid.  We have to retthink the algorithms we
implement; we have to rethink the core system.

\start
Date: 11 Jul 2007 16:14:25 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: Re: counting allocated bytes

Greetings, and thank you so much!

This is now in.  Your assumptions are correct, but alas the n_used
counter is not reliably maintained.  Here is the version now checked
in commensurate with (room):

DEFUN_NEW("TOTAL-BYTES-ALLOCATED",object,fStotal_bytes_allocated,SI,0,0,NONE,OO,OO,OO,OO,(void),"") {
  int i;
  unsigned long bytes;
  for(bytes=0,i=t_start; i < t_end; i++) {
    struct typemanager *tm=tm_of(i);
    if (tm->tm_type!=i)
      continue;
    bytes += TM_NUSED(*tm) * tm->tm_size;
  }
  bytes+=ncbpage*PAGESIZE;
  bytes+=rb_pointer-rb_start;
  RETURN1(make_fixnum(bytes));

}

Quite a big difference.  I need to fix tm_nused someday.  Notes:

1) This is a slight overestimate -- we really should subtract the free
   block space from the contiguous allocation usage
2) The algorithm needs correcting when sgc is on -- is one interested
   in the active read-write set, of the static read-only set here?
3) This might motivate me to provide a function to print the
   contiguous block structure for Matt Kaufmann ...

Also think I fixed the install of clcs/packages.lisp and bin/gcl.
Please let me know if problems persist.

Thanks again so much!


Stephen Wilson writes:

> Hello,
> 
> I have been working on evaluating/integrating a Lisp based testing
> framework into Axiom (based on Lift).  One of the features is the
> ability to benchmark the running of tests.  
> 
> To accommodate the benchmark code, I needed a function which returns
> the total number of bytes allocated since the image was started.  
> 
> I could not find such a function.  Perhaps I missed it? There is
> SI:ALLOCATED, but it reports information for a specific type only.
> 
> I considered writing a function using SI:ALLOCATED and SI:SIZE-OF for
> personal use.  However, when I considered if such a function would be
> of use to GCL, I realized it may be better to attempt it in C.
> 
> Of course, if the facility already exists, then this is just a
> learning experience for me.  Attached is a patch against alloc.c.
> 
> I have two issues with this code:
> 
>   * Is it correct to assume that all entries in tm_table with the
>     tm_size field equal share the same allocation space?  I assumed
>     this from the documentation for SI:ALLOCATED.
> 
>   * Im slightly concerned about overflow of the `bytes' variable.  Is
>     this likely?  Should bignum arith be used?
> 
> Hopefully this might be of some use to GCL, however I completely
> understand if it is deemed unnecessary, badly implemented, etc.

\start
Date: Wed, 11 Jul 2007 13:16:15 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Axiom, FriCAS, forks and teeth

--- Gabriel Dos Reis wrote:

> Multicore are no longer supercomputers myths you would find in
> highly financed National Labs.  They are the reality today.  

Sure.

> If you order a machine from Dell, the probability that you
> get a multicore is very high.  How do you we wisely and efficiently
> use that computational power?

As I said, that is an interesting and important question - just not my
primary area of interest.

> Clearly Waldek has an example where Axiom is making a dumb use of
> resource.  No matter how correct the answer
> is.  How would you react to computation of determinant of
> an nxn matrix with complexity O(n!)?

Better than I would to a complexity O(1) computation whose
implementation I couldn't trust.  Correctness first, then performance. 
Both are important, but in my personal opinion correctness is more so. 
Of course, you want to use the best algorithms available, but not at
the expense of adding risk of incorrect answers.  And right now, the
view seems to be that all existing CASs have risk of incorrect answers.
 
> Many things that were considered absolute truths or theorems a decade
> ago are no longer valid.  We have to retthink the algorithms we
> implement; we have to rethink the core system.

That's an interesting direction to go, and I hope it bears fruit, but
it is not my first concern.  I would rather have the computer spend a
few extra minutes using verified, trustable routines to check that my
answer to a problem being published in a paper is correct, although
obviously the BEST case is to be both fast and trustworthy.

\start
Date: 11 Jul 2007 16:17:11 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: Re: 2.7 build

Great!  What in your opinion is the best (simplest) tree to work with
purely for the purpose of finalizing the 2.7 build?  I'd like it to be
very close to what might eventually go into Debian, so I guess this
means Silver?  How do I get Silver?  What are you using?

Take care,

Stephen Wilson writes:

> Camm Maguire writes:
> 
> > Greetings!  Right after interpsys is created, and ACPLOT.spad is
> > compiled, something writes the source file ACPLOT.lsp, which contains:
> > 
> > 
> > (/VERSIONCHECK 2) 
> > 
> > (DEFUN |ACPLOT;NFtoSF| (|x| $)
> >   (PROG ()
> >     (RETURN
> >       (+ '#1=#((|DoubleFloat|)
> >                (#<compiled-function |lookupComplete|> #1#
> >                 #(~= 231 |zero?| 237 |wholePart| 242 |unitNormal| 247
> >                   |unitCanonical| 252 |unit?| 257 |truncate| 262 |tanh|
> > ...
> > 
> > The function is unreadable.  Where is the function that writes this
> > source? 
> 
> Unfortunately I cannot reproduce.  I get:
> 
>    (DEFUN |ACPLOT;NFtoSF| (|x| $) 
>         (PROG NIL (RETURN (+ 0.0 (SPADCALL |x| (QREFELT $ 22))))))
> 
> Perhaps this is a wh-sandbox issue?  CC'ing Waldek.

\start
Date: Wed, 11 Jul 2007 15:19:42 -0500 (CDT)
From: Gabriel Dos Reis
To: Jay Belanger
Subject: Re: Axiom, FriCAS, forks and teeth

On Wed, 11 Jul 2007, Jay Belanger wrote:

| 
| Gabriel Dos Reis writes:
| 
| > Jay Belanger writes:
| >
| > | Bill Page writes:
| > | ...
| > | > But literate programming is not really the problem. Rather I think the
| > | > problem as usual, is just the way in which decisions are (and are not)
| > | > being made in the project.
| > |
| > | One reason for the fork was to be able to put off documentation,
| >
| > Did you get that for a fact from Waldek?
| 
| Yes; didn't you?

No.  Otherwise, I would not have asked.

| In the announcement of the fork, Waldek quotes Tim as saying
| that literate programming was a primary goal of the Axiom project, and
| if somebody wanted to get somewhere faster that they should fork.

I believe it takes an extraordinary amount of both stretch and imagination 
(which, obviously, I do not have) to conclude from that quote that Waldek
wanted "be able to put off documentation" -- when in fact he did, in his 
wh-sandbox contribution, document his findings and work and he continues 
to do so.  That is why I wanted facts or statements from himself 
instead of putting words in his month or assigning him ill motives.

\start
Date: Wed, 11 Jul 2007 15:27:37 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Axiom, FriCAS, forks and teeth

On Wed, 11 Jul 2007, C Y wrote:

| --- Gabriel Dos Reis wrote:
| 
| > Multicore are no longer supercomputers myths you would find in
| > highly financed National Labs.  They are the reality today.  
| 
| Sure.
| 
| > If you order a machine from Dell, the probability that you
| > get a multicore is very high.  How do you we wisely and efficiently
| > use that computational power?
| 
| As I said, that is an interesting and important question - just not my
| primary area of interest.
| 
| > Clearly Waldek has an example where Axiom is making a dumb use of
| > resource.  No matter how correct the answer
| > is.  How would you react to computation of determinant of
| > an nxn matrix with complexity O(n!)?
| 
| Better than I would to a complexity O(1) computation whose
| implementation I couldn't trust.  Correctness first, then performance. 

In  the context of situation where O(n^3) algorithms are known?

| Both are important, but in my personal opinion correctness is more so. 

Yes, but when I say algorithm, there is the implied assumption that the
algorithm was answering the question, i.e. giving the answer.  So, 
correctness is not at issue.  We are talking about choising efficient answers
between correct answers.

| Of course, you want to use the best algorithms available, but not at
| the expense of adding risk of incorrect answers. 

Nobody is suggesting that the system should not give correct answer.
The issue is *efficiently* computing the answer.  Not just giving
the answer.  

\start
Date: Wed, 11 Jul 2007 16:37:13 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Unions in Spad

On 11 Jul 2007 08:08:27 -0500, Gabriel Dos Reis wrote:
> ...
> Bill Page writes:
> | It
> | makes much for sense to me to define Union and Record as co-limit and
> | limit in the sense of category theory. Then Union selectors are just
> | injections operations and Record selectors are projection operations
> | which are exported like any other function from these types. There is
> | no need for any lower level language construct.
>
> Well, if we are to be following that reasoning, there is no need for Spad
> -- we just need lambda calculus.
> We should be discussing what is useful, convenient; not the bare
> minimum that is necessary.
>

That is not what I am arguing. I want Record and Union domains just as
they exist now in Spad but with a simple and rigorous object-oriented
semantics consistent with other Axiom domains. We do not need to talk
about selectors and enumerations in order to define these concepts. It
is enough that these domains export projection and product
(respectively, injection and sum) operations that satisfy certain
(categorical) axioms, in the same way that other domains in Axiom do.

Here are some some toy notions...

We can recover the usual notation for records by defining '.' as left
associative application. Given the value of some 'a' of type 'A' we
can define an instance 'r' of some Record having a "field" named 'x'
that takes values from 'A'. But 'x' is actually the name of one of the
projection functions exported by the record.

  a:A
  r:Record(x:A, ...) := [a, ... ]
  x$Record(x:A, ... )  : % -> A
  x(r) = r.x =  a

Eg.

p1:Record(Age:Integer,Name:String) := [25, "Peter"]
p1.Age = 25
Name(p1) = "Peter"

And we can do something similar (bug categorically dual) for unions:

Given the value of some 'b' of type 'B' we can define an instance 'u'
of some Union having a "field" named 'y' with values from 'B'. But 'y'
is actually the name of one of the injection functions exported by the
Union. Evaluating y of b yields a member of the Union.

  b:B
  u:Union(y:B, ...) := y(b) = b.y
  y$Union(y:B, ... ) : B -> %
  case y : % -> Boolean

'case' classifies the sub-object (injective map) 'y' over the Union.
'/y' denotes the inverse of 'y' defined over this sub-object of u. For
convenience '.' is omitted in the expression 'u./y'.

  if u.case(y) then u/y = b

Eg.

d1:Union(inches:Float,feet:Float) := (2.5).feet
d2:Union(inches:Float,feet:Float) := inches(30.0)
if d1 case feet then d1/feet = 2.5
try d1 := feet(d2/inches / 12.0)

It seems to me these primitive domains would be quite easy to provide in Spad.

Another issue. It seems strange to me that Spad does not have any
primitives for exception handling, e.g. 'try'.

\start
Date: Wed, 11 Jul 2007 15:47:02 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Unions in Spad

On Wed, 11 Jul 2007, Bill Page wrote:

| On 11 Jul 2007 08:08:27 -0500, Gabriel Dos Reis wrote:
| > ...
| > Bill Page writes:
| > | It
| > | makes much for sense to me to define Union and Record as co-limit and
| > | limit in the sense of category theory. Then Union selectors are just
| > | injections operations and Record selectors are projection operations
| > | which are exported like any other function from these types. There is
| > | no need for any lower level language construct.
| >
| > Well, if we are to be following that reasoning, there is no need for Spad
| > -- we just need lambda calculus.
| > We should be discussing what is useful, convenient; not the bare
| > minimum that is necessary.
| >
| 
| That is not what I am arguing. I want Record and Union domains just as
| they exist now in Spad but with a simple and rigorous object-oriented
| semantics consistent with other Axiom domains. We do not need to talk
| about selectors and enumerations in order to define these concepts. It
| is enough that these domains export projection and product
| (respectively, injection and sum) operations that satisfy certain
| (categorical) axioms, in the same way that other domains in Axiom do.

My point is that the selectors are precisely the projectors -- and
the injectors are already there.  

| Here are some some toy notions...
| 
| We can recover the usual notation for records by defining '.' as left
| associative application. Given the value of some 'a' of type 'A' we
| can define an instance 'r' of some Record having a "field" named 'x'
| that takes values from 'A'. But 'x' is actually the name of one of the
| projection functions exported by the record.

I agree.  And I think that is what the current semantics does.

|  a:A
|  r:Record(x:A, ...) := [a, ... ]
|  x$Record(x:A, ... )  : % -> A
|  x(r) = r.x =  a
| 
| Eg.
| 
| p1:Record(Age:Integer,Name:String) := [25, "Peter"]
| p1.Age = 25
| Name(p1) = "Peter"
| 
| And we can do something similar (bug categorically dual) for unions:
| 
| Given the value of some 'b' of type 'B' we can define an instance 'u'
| of some Union having a "field" named 'y' with values from 'B'. But 'y'
| is actually the name of one of the injection functions exported by the
| Union. Evaluating y of b yields a member of the Union.
| 
|  b:B
|  u:Union(y:B, ...) := y(b) = b.y
|  y$Union(y:B, ... ) : B -> %
|  case y : % -> Boolean
| 
| 'case' classifies the sub-object (injective map) 'y' over the Union.
| '/y' denotes the inverse of 'y' defined over this sub-object of u. For
| convenience '.' is omitted in the expression 'u./y'.
| 
|  if u.case(y) then u/y = b
| 
| Eg.
| 
| d1:Union(inches:Float,feet:Float) := (2.5).feet
| d2:Union(inches:Float,feet:Float) := inches(30.0)
| if d1 case feet then d1/feet = 2.5
| try d1 := feet(d2/inches / 12.0)
| 
| It seems to me these primitive domains would be quite easy to provide in Spad.
| 
| Another issue. It seems strange to me that Spad does not have any
| primitives for exception handling, e.g. 'try'.

Agreed.  More strangely to me, it seems odd that Spad does not
have algebraic data types ans pattern matching (Boot does).

They support different styles of programming.

\start
Date: Wed, 11 Jul 2007 15:48:56 -0500 (CDT)
From: Gabriel Dos Reis
To: Jay Belanger
Subject: Re: Axiom, FriCAS, forks and teeth

On Wed, 11 Jul 2007, Jay Belanger wrote:

| 
| Gabriel Dos Reis writes:
| ...
| > I believe it takes an extraordinary amount of both stretch and imagination
| 
| It requires neither; it only requires reading and paying attention.

`reading more' into what is actually written and intended.

\start
Date: Wed, 11 Jul 2007 16:55:31 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Unions in Spad

On 7/11/07, Gabriel Dos Reis wrote:
> On Wed, 11 Jul 2007, Bill Page wrote:
>...
> | Another issue. It seems strange to me that Spad does not have any
> | primitives for exception handling, e.g. 'try'.
>
> Agreed.  More strangely to me, it seems odd that Spad does not
> have algebraic data types ans pattern matching (Boot does).
>
> They support different styles of programming.
>

Maybe, just maybe, it is reasonable to associate Spad more with the
earlier "ScratchPad I" project. As I understand it from the scant
literature about these early days, ScratchPad I was a more
"symbolically oriented" computer algebra system. I don't know if there
is any code left at all anywhere for this first attempt. But it is my
understanding that most of the same people were involved again in the
"ScratchPad II" project that eventually became Axiom. I think that
ScratchPad II deliberately tried to introduce a different style of
programming.

In my opinion this is yet one more reason why Spad should *not* be
removed from the core Axiom system.

\start
Date: 11 Jul 2007 16:57:03 -0400
From: Camm Maguire
To: Matt Kaufmann
Subject: gcl inlining policy
Cc: Robert Sumner, Jared Davis

Thanks so much Matt and Jared for the very helpful feedback.  My
comments on GCL at the moment below:

Matt Kaufmann writes:

> Hi, Camm --
> 
> I forwarded some of your inlining thread to a couple of people who I
> thought would have useful comments, and I got an interesting reply
> saying "Feel free to forward this email to anyone".  (Thanks, Jared.)
> So I'm forwarding it to you below, and letting you decide if you want
> to forward it to some or all in the thread.
> 
> -- Matt
> From: "Jared C. Davis" Jared Davis
> Subject: Re: [Richard Fateman: RE: [Maxima] gcl inlining policy]
> To: "Matt Kaufmann" Matt Kaufmann
> Cc: Robert Sumner
> Date: Fri, 6 Jul 2007 21:37:19 -0500
> 
> Hi,
> 
> Feel free to forward this email to anyone, but it's probably not
> particularly useful.
> 
> As an ACL2 user, I feel it's particularly important to set up "proper"
> abstractions.  Since there is no "shell principle" and I have no way
> to define new objects or structures, I end up using something like a
> tuple/alist/custom-cons-structure for this purpose.  To develop good
> rewrite rules, it's crucial to define proper recognizers, accessors,
> and constructors.  This leads me to have several aliases for "first",
> "second", "third", etc.  These aliases are particularly useful when
> combined with forcing, and they're excellent candidates to be inlined.
>  This would probably be a useful technique for any ACL2 user.  (Also,
> the ACL2 system code often uses macros instead of inline functions,
> and this is probably unfortunate.)

All of these includeing car et. al. are now inlined from source, which
is adjusted for the ambient safety level thus:

safety 3: all checks, all variables of generic type, no src inlining,
          no branch elimination
safety 2: src inlining with checks, branch elimination, full variable type propagation
safety 1: only check on function entry, src inlines without checks,
          reverse type propagation
safety 0: check-type at body head turned into declare, no checking
          unless user makes same explicit.

> 
> One other really crucial use of inlining, for me, is that all the base
> functions in Milawa are total with :guard t.  For example, MILAWA::CAR
> is defined as (if (consp x) (COMMON-LISP::car x) nil), and my
> arithmetic operations will nfix their arguments and results if needed.
>  Inlining these primitives allows smart Lisp compilers to see and
> optimize-away a lot of common subexpressions; for example, I often
> write code like the following:
> 
>    (let ((foo (first x))
>          (bar (second x))
>          (baz (third x)))
>      (do-stuff foo bar baz))
> 

This is on now at safety 0,1 in GCL:

>(disassemble '(lambda (x) (let ((foo (first x)) (bar (second x)) (baz (third x))) (do-stuff foo bar baz))) nil)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.

#include "gazonk_14987_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function CMP-ANON	*/

static object LI1__CMP_ANON___gazonk_14987_0(V3,V4)

fixnum V3;object V4;
{	 VMB1 VMS1 VMV1
	goto TTL;
TTL:;
	{object V5;
	object V6;
	object V7;
	/*(FIRST X)*/
	{object V8;
	V8= (V4);
	/*(CAR X)*/
	{object V9;
	V9= (V8);
	V5= ((V9))->c.c_car;}
	/* END (CAR X)*/}
	/* END (FIRST X)*/
	/*(SECOND X)*/
	{object V10;
	V10= (V4);
	/*(CADR X)*/
	{object V11;
	V11= (V10);
	/*(CAR (CDR X))*/
	{object V12;
	{object V13;
	/*(CDR X)*/
	{object V14;
	V14= (V11);
	V13= ((V14))->c.c_cdr;}
	/* END (CDR X)*/
	V12=V13;}
	V6= ((V12))->c.c_car;}
	/* END (CAR (CDR X))*/}
	/* END (CADR X)*/}
	/* END (SECOND X)*/
	/*(THIRD X)*/
	{object V15;
	V15= (V4);
	/*(CADDR X)*/
	{object V16;
	V16= (V15);
	/*(CAR (CDDR X))*/
	{object V12;
	{object V17;
	/*(CDDR X)*/
	{object V18;
	V18= (V16);
	/*(CDR (CDR X))*/
	{object V19;
	{object V20;
	/*(CDR X)*/
	{object V14;
	V14= (V18);
	V20= ((V14))->c.c_cdr;}
	/* END (CDR X)*/
	V19=V20;}
	V17= ((V19))->c.c_cdr;}
	/* END (CDR (CDR X))*/}
	/* END (CDDR X)*/
	V12=V17;}
	V7= ((V12))->c.c_car;}
	/* END (CAR (CDDR X))*/}
	/* END (CADDR X)*/}
	/* END (THIRD X)*/
	{object V21;
	if (V3) {
	V21= (VFUN_NARGS=3,(/* DO-STUFF */(*LnkLI0)(V3,(V5),(V6),(V7))));
	} else {
	V21= (VFUN_NARGS=3,(/* DO-STUFF */(*LnkLI0)((fixnum)0,(V5),(V6),(V7))));
	vs_top=base;
	}
	return(V21);}}
	base[0]=base[0];
	return Cnil;
}

>(disassemble '(lambda (x) (declare (optimize (safety 2)))(let ((foo (first x)) (bar (second x)) (baz (third x))) (do-stuff foo bar baz))) nil)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.

#include "gazonk_14987_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function CMP-ANON	*/

static object LI1__CMP_ANON___gazonk_14987_0(V3,V4)

fixnum V3;object V4;
{	 VMB1 VMS1 VMV1
	goto TTL;
TTL:;
	{object V5;
	object V6;
	object V7;
	/*(FIRST X)*/
	{register object V8;
	V8= (V4);
	if(!(listp((V8)))){
	goto T6;}
	goto T4;
	goto T6;
T6:;
	V8= (VFUN_NARGS=4,(/* CHECK-TYPE-SYMBOL */(*LnkLI2)(((object)VV[0]),(V8),((object)VV[1]),Cnil)));
	goto T4;
T4:;
	{object V9;
	V9= (V8);
	/*(CAR X)*/
	{register object V10;
	V10= (V9);
	{object V11;
	V11= (V10);
	V5= ((V11))->c.c_car;}}
	/* END (CAR X)*/}}
	/* END (FIRST X)*/
	/*(SECOND X)*/
	{register object V12;
	V12= (V4);
	if(!(listp((V12)))){
	goto T17;}
	goto T15;
	goto T17;
T17:;
	V12= (VFUN_NARGS=4,(/* CHECK-TYPE-SYMBOL */(*LnkLI2)(((object)VV[0]),(V12),((object)VV[1]),Cnil)));
	goto T15;
T15:;
	{object V13;
	V13= (V12);
	/*(CADR X)*/
	{register object V14;
	V14= (V13);
	{object V15;
	V15= (V14);
	/*(CAR (CDR X))*/
	{register object V16;
	{object V17;
	/*(CDR X)*/
	{register object V18;
	V18= (V15);
	{object V19;
	V19= (V18);
	V17= ((V19))->c.c_cdr;}}
	/* END (CDR X)*/
	V16=V17;}
	if(!(listp((V16)))){
	goto T32;}
	goto T30;
	goto T32;
T32:;
	V16= (VFUN_NARGS=4,(/* CHECK-TYPE-SYMBOL */(*LnkLI2)(((object)VV[0]),(V16),((object)VV[1]),Cnil)));
	goto T30;
T30:;
	{object V20;
	V20= (V16);
	V6= ((V20))->c.c_car;}}
	/* END (CAR (CDR X))*/}}
	/* END (CADR X)*/}}
	/* END (SECOND X)*/
	/*(THIRD X)*/
	{register object V21;
	V21= (V4);
	if(!(listp((V21)))){
	goto T39;}
	goto T37;
	goto T39;
T39:;
	V21= (VFUN_NARGS=4,(/* CHECK-TYPE-SYMBOL */(*LnkLI2)(((object)VV[0]),(V21),((object)VV[1]),Cnil)));
	goto T37;
T37:;
	{object V22;
	V22= (V21);
	/*(CADDR X)*/
	{register object V23;
	V23= (V22);
	{object V24;
	V24= (V23);
	/*(CAR (CDDR X))*/
	{register object V25;
	{object V26;
	/*(CDDR X)*/
	{register object V27;
	V27= (V24);
	{object V28;
	V28= (V27);
	/*(CDR (CDR X))*/
	{register object V29;
	{object V30;
	/*(CDR X)*/
	{register object V18;
	V18= (V28);
	{object V19;
	V19= (V18);
	V30= ((V19))->c.c_cdr;}}
	/* END (CDR X)*/
	V29=V30;}
	if(!(listp((V29)))){
	goto T59;}
	goto T57;
	goto T59;
T59:;
	V29= (VFUN_NARGS=4,(/* CHECK-TYPE-SYMBOL */(*LnkLI2)(((object)VV[0]),(V29),((object)VV[1]),Cnil)));
	goto T57;
T57:;
	{object V31;
	V31= (V29);
	V26= ((V31))->c.c_cdr;}}
	/* END (CDR (CDR X))*/}}
	/* END (CDDR X)*/
	V25=V26;}
	if(!(listp((V25)))){
	goto T65;}
	goto T63;
	goto T65;
T65:;
	V25= (VFUN_NARGS=4,(/* CHECK-TYPE-SYMBOL */(*LnkLI2)(((object)VV[0]),(V25),((object)VV[1]),Cnil)));
	goto T63;
T63:;
	{object V32;
	V32= (V25);
	V7= ((V32))->c.c_car;}}
	/* END (CAR (CDDR X))*/}}
	/* END (CADDR X)*/}}
	/* END (THIRD X)*/
	{object V33;
	if (V3) {
	V33= (VFUN_NARGS=3,(/* DO-STUFF */(*LnkLI3)(V3,(V5),(V6),(V7))));
	} else {
	V33= (VFUN_NARGS=3,(/* DO-STUFF */(*LnkLI3)((fixnum)0,(V5),(V6),(V7))));
	vs_top=base;
	}
	return(V33);}}
	base[0]=base[0];
	return Cnil;
}

>

Given the tentative redefinition of the safety settings, checks on
each function call are only enabled at safety >=2.  GCL binds the
lambda list source via a 'let, so the check-type works on the original
source variable, not the surrounding variable.  (The check-type does an
implicit setq for the type, which does automatically propagate to
references further down in the source body.)  GCL has support for
reverse type propagation, in which the binding mentioned above
triggers an implicit setq for the surrounding variable, but it appears
hard to justify turning this on at safety 2.  Currently it is turned
on at safety 0,1.  The idea being that at safety 2 one gets the full
checking effect as if the inlining was not performed -- the code above
would trigger three errors if passed a non-list which the user then
reset in the interactive check-type code and each call was a genuine
function call.

I'm writing this too quickly, so the above might sound opaque.  I can
clarify if there is interest.  I just bring it up to poll users'
opinions of what behavior would be useful at various safety settings.

Here is the reverse type propagation in action:

(disassemble '(lambda (x) (first x) (listp x)) nil)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.

#include "gazonk_14987_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function CMP-ANON	*/

static object LI1__CMP_ANON___gazonk_14987_0(V2)

object V2;
{	 VMB1 VMS1 VMV1
	goto TTL;
TTL:;
	/*(FIRST X)*/
	{object V3;
	V3= (V2);
	/*(CAR X)*/
	{object V4;
	V4= (V3);
	(void)(((V4))->c.c_car);}
	/* END (CAR X)*/}
	/* END (FIRST X)*/
	{object V5 = Ct;VMR1
	(V5);}
	return Cnil;
}

>(disassemble '(lambda (x) (declare (optimize (safety 1)))(first x) (listp x)) nil)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.

#include "gazonk_14987_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function CMP-ANON	*/

static object LI1__CMP_ANON___gazonk_14987_0(V2)

object V2;
{	 VMB1 VMS1 VMV1
	goto TTL;
TTL:;
	/*(FIRST X)*/
	{object V3;
	V3= (V2);
	/*(CAR X)*/
	{object V4;
	V4= (V3);
	(void)(((V4))->c.c_car);}
	/* END (CAR X)*/}
	/* END (FIRST X)*/
	{object V5 = Ct;VMR1
	(V5);}
	return Cnil;
}

>(disassemble '(lambda (x) (declare (optimize (safety 2)))(first x) (listp x)) nil)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.

#include "gazonk_14987_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function CMP-ANON	*/

static object LI1__CMP_ANON___gazonk_14987_0(V2)

object V2;
{	 VMB1 VMS1 VMV1
	goto TTL;
TTL:;
	/*(FIRST X)*/
	{register object V3;
	V3= (V2);
	if(!(listp((V3)))){
	goto T6;}
	goto T4;
	goto T6;
T6:;
	V3= (VFUN_NARGS=4,(/* CHECK-TYPE-SYMBOL */(*LnkLI2)(((object)VV[0]),(V3),((object)VV[1]),Cnil)));
	goto T4;
T4:;
	{object V4;
	V4= (V3);
	/*(CAR X)*/
	{register object V5;
	V5= (V4);
	{object V6;
	V6= (V5);
	(void)(((V6))->c.c_car);}}
	/* END (CAR X)*/}}
	/* END (FIRST X)*/
	{object V7 = (listp((V2))?Ct:Cnil);VMR1
	(V7);}
	return Cnil;
}

>


> Where first, second, and third are macros expanding to the appropriate
> nest of MILAWA::car and MILAWA::cdr's.  Inlining my car and cdr here
> will expose the (consp x) test in each binding, and the compiler can
> then get rid of these redundnat checks.
> 

I hope the above indicates we are competitive here.

> I believe that on CMUCL (and I think also SBCL), these two kinds of
> inlining give me almost a 50% speedup when running in raw lisp to
> check proofs.  And, the last time I compared these Lisps against GCL
> for my program (which was a long time ago), CMUCL was only taking 4
> seconds, SBCL was taking about 6 seconds, and GCL 2.6.7 was taking 11
> seconds to check some proofs with my system.
> 

I'd love to see some simple code I could benchmark.

> I think OpenMCL also has some support for inlinining, but I found it
> buggy in the last pre-release and as a result it was unusable.  I
> reported this to Gary Byers, and I think he's fixed it in CVS, and
> perhaps it's available in some release I'm not using yet.
> 
> I don't have a lot of intuition about what ought to be inlined by
> default.  Certainly anything relatively "small" and nonrecursive would
> make a fine candidate.  I also had an idle thought awhile back that

What really interests me is that the inlining could provide for some
loop unrolling of tail recursive functions.  GCL carries list length
information around causing same to terminate in some cases.  So far we
punt if the recursion is > 2 deep.  This is to support the likes of
mapl:

>(si::function-src 'mapl)

(LAMBDA (SYSTEM::F SYSTEM::L1 &REST SYSTEM::L)
  (DECLARE (OPTIMIZE (SAFETY 2)) (:DYNAMIC-EXTENT SYSTEM::L))
  (CHECK-TYPE SYSTEM::L1 SYSTEM:PROPER-LIST)
  (BLOCK MAPL
    (BLOCK ()
      (LET ((SYSTEM::R SYSTEM::L1) (SYSTEM::L1 SYSTEM::L1)
            (SYSTEM::L SYSTEM::L))
        (TAGBODY
          #:G4392
          (IF (NOT (OR (ENDP SYSTEM::L1) (MEMBER-IF 'ENDP SYSTEM::L)))
              (PROGN
                (TAGBODY (APPLY SYSTEM::F SYSTEM::L1 SYSTEM::L))
                (LET* ((#:G4393 (CDR SYSTEM::L1))
                       (#:G4394 (MAPL (LAMBDA (SYSTEM::X)
                                        (LET*
                                         ((#:G4395 SYSTEM::X)
                                          (#:G4396 (CDAR SYSTEM::X)))
                                          (PROGN
                                            (RPLACA #:G4395 #:G4396)
                                            #:G4396)))
                                      SYSTEM::L)))
                  (SETQ SYSTEM::L1 #:G4393)
                  (SETQ SYSTEM::L #:G4394)
                  NIL)
                (GO #:G4392))
              (RETURN-FROM () (PROGN SYSTEM::R))))))))

>(disassemble '(lambda (x) (mapl 'cdr x)) nil)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.

#include "gazonk_14987_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function CMP-ANON	*/

static object LI1__CMP_ANON___gazonk_14987_0(V2)

object V2;
{	 VMB1 VMS1 VMV1
	goto TTL;
TTL:;
	/*(MAPL 'CDR X)*/
	{object V3;
	object V4;
	V3= (V2);
	V4= Cnil;
	{register object V5;
	register object V6;
	register object V7;
	V5= (V3);
	V6= (V3);
	V7= Cnil;
	goto T3;
T3:;
	/*(ENDP L1)*/
	{register object V8;
	V8= (V6);
	if(((V8))==Cnil){
	goto T6;}}
	/* END (ENDP L1)*/
	/*(MEMBER-IF 'ENDP L)*/
	/*(MEMBER ITEM LIST TEST 'FUNCALL KEY KEY)*/
	/*(ENDP LIST)*/
	/* END (ENDP LIST)*/
	goto T9;
	/* END (MEMBER ITEM LIST TEST 'FUNCALL KEY KEY)*/
	/* END (MEMBER-IF 'ENDP L)*/
	goto T9;
T9:;
	{register object V9;
	V9= (V6);
	/*(CDR G2507)*/
	{register object V10;
	V10= (V9);
	(void)(((V10))->c.c_cdr);}
	/* END (CDR G2507)*/}
	{register object V11;
	register object V12;
	{object V13;
	/*(CDR L1)*/
	{register object V10;
	V10= (V6);
	V13= ((V10))->c.c_cdr;}
	/* END (CDR L1)*/
	V11=V13;}
	{object V14;
	/*(MAPL (LAMBDA (X)
        (LET* ((G4395 X) (G4396 (CDAR X)))
          (PROGN (RPLACA G4395 G4396) G4396)))
      L)*/
	{register object V15;
	V15= Cnil;
	goto T26;
	goto T24;
	goto T26;
T26:;
	/*(ENDP L1)*/
	/* END (ENDP L1)*/
	goto T24;
T24:;
	V14= Cnil;
	goto T20;
	V14= Cnil;}
	/* END (MAPL (LAMBDA (X)
        (LET* ((G4395 X) (G4396 (CDAR X)))
          (PROGN (RPLACA G4395 G4396) G4396)))
      L)*/
	goto T20;
T20:;
	V12=V14;}
	V6= (V11);
	V7= Cnil;}
	goto T3;
	goto T6;
T6:;
	{object V16 = (V5);VMR1
	(V16);}
	{object V17 = Cnil;VMR1
	(V17);}}}
	/* END (MAPL 'CDR X)*/
	return Cnil;
}

>

> mutually recursive functions might be unwound to expose tail
> recursion, e.g., think of datatype such as
>   TERM ::= ATOM | (FN TERM1 ... TERMN)

Here is something I really like -- hope this could be useful:

>(defun foo (x &optional (y 0)) (if x (bar (cdr x) (1+ y)) y))

FOO

>(defun bar (x &optional (y 0)) (if x (foo (cdr x) (1+ y)) y))

BAR

>(foo '(1 2 3))

3

>(compile 'foo)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.
;; Loading /tmp/gazonk_14987_0.o
 ;; start address -T 0x107e7f8 ;; Finished loading /tmp/gazonk_14987_0.o
#<compiled-function FOO>
NIL
NIL

>(compile 'bar)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.
;; Loading /tmp/gazonk_14987_0.o
Pass1 signature discovery on 1 functions ...
Mutual recursion detected: (FOO BAR), recompiling BAR2512
Pass1 signature discovery on 1 functions ...
Pass1 signature discovery on 2 functions ...
Compiling and loading new source in #<output stream "/tmp/gazonk_14987_X0QEXb.lsp">
;; Compiling /tmp/gazonk_14987_X0QEXb.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_X0QEXb.o.
;; Loading /tmp/gazonk_14987_X0QEXb.o
 ;; start address -T 0x10ab828 ;; Finished loading /tmp/gazonk_14987_X0QEXb.o
 ;; start address -T 0x10db668 ;; Finished loading /tmp/gazonk_14987_0.o
#<compiled-function BAR>
NIL
NIL

>(disassemble 'BAR2512 nil)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.

#include "gazonk_14987_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function BAR2512	*/

static object LI1__BAR2512___gazonk_14987_0(object V2,object V1,object first,...)
{	
	va_list ap;
	int narg = VFUN_NARGS; VMB1 VMS1 VMV1
	{fixnum V3;
	register object V4;
	register object V5;
	va_start(ap,first);
	V3= fix(V2);
	V4= V1;
	narg -= 2;
	if (narg <= 0) goto T1;
	else {
	V5= first;}
	--narg; goto T2;
	goto T1;
T1:;
	V5= Cnil;
	goto T2;
T2:;
	goto TTL;
TTL:;switch(V3){
	case 0:
	goto T5;
T5:;
	{register object V6;
	register object V7;
	V6= (V4);
	V7= (V5);
	if(((V6))==Cnil){
	goto T8;}
	V3= (fixnum)1;
	/*(CDR X)*/
	{register object V8;
	V8= (V6);
	V4= ((V8))->c.c_cdr;}
	/* END (CDR X)*/
	V5= immnum_plus((V7),make_fixnum(1));
	goto TTL;
	goto T8;
T8:;
	{object V9 = (V7);VMR1
	(V9);}}
	default:
	goto T6;
T6:;
	{register object V10;
	register object V11;
	V10= (V4);
	V11= (V5);
	if(((V10))==Cnil){
	goto T16;}
	V3= (fixnum)0;
	/*(CDR X)*/
	{register object V8;
	V8= (V10);
	V4= ((V8))->c.c_cdr;}
	/* END (CDR X)*/
	V5= immnum_plus((V11),make_fixnum(1));
	goto TTL;
	goto T16;
T16:;
	{object V12 = (V11);VMR1
	(V12);}}
	{object V13 = Cnil;VMR1
	(V13);}}
	{object V14 = Cnil;VMR1
	(V14);}
	va_end(ap);
	return Cnil;}
	}
>(disassemble 'foo nil)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.

#include "gazonk_14987_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function FOO	*/

static object LI1__FOO___gazonk_14987_0(object V1,object first,...)
{	
	va_list ap;
	int narg = VFUN_NARGS; VMB1 VMS1 VMV1
	{object V2;
	object V3;
	va_start(ap,first);
	V2= V1;
	narg -= 1;
	if (narg <= 0) goto T1;
	else {
	V3= first;}
	--narg; goto T2;
	goto T1;
T1:;
	V3= make_fixnum(0);
	goto T2;
T2:;
	goto TTL;
TTL:;
	{object V4 = (VFUN_NARGS=3,(/* BAR2512 */(*LnkLI0)(make_fixnum(0),(V2),(V3))));VMR1
	(V4);}
	va_end(ap);
	return Cnil;}
	}
>(disassemble 'bar nil)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.

#include "gazonk_14987_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function BAR	*/

static object LI1__BAR___gazonk_14987_0(object V1,object first,...)
{	
	va_list ap;
	int narg = VFUN_NARGS; VMB1 VMS1 VMV1
	{object V2;
	object V3;
	va_start(ap,first);
	V2= V1;
	narg -= 1;
	if (narg <= 0) goto T1;
	else {
	V3= first;}
	--narg; goto T2;
	goto T1;
T1:;
	V3= make_fixnum(0);
	goto T2;
T2:;
	goto TTL;
TTL:;
	{object V4 = (VFUN_NARGS=3,(/* BAR2512 */(*LnkLI0)(make_fixnum(1),(V2),(V3))));VMR1
	(V4);}
	va_end(ap);
	return Cnil;}
	}


> If you were to define a recognizer for such a function, it would
> probably take the form of a mutual-recursion with a TERM recognizer
> and a TERM LIST recognizer.  If you just inline the term recognizer,
> you'll find the resulting term-list recognizer to be entirely tail
> recursive, which is potentially a big win.  But I'm using flag
> functions instead now, so I don't know if this actually works in these
> other Lisps.

Don't know if you are familiar with the takr benchmark, but this
obviously really helps here.  How useful it is in real code is still
unclear to me.  It is a little bit of scheme that GCL has brought into
CL. 

> 
> One other idea is, I think, called "fusion" in the literature.  It's
> not quite the same as inlining, but it's sort of similar in spirit.
> Imagine expresions such as:
>    power4 x = map square (map square x)
> one way to compile power4 would be to have it create an intermediate
> list of squares, then a result list of power4's.  A smarter way would
> be to basically simplify the definition to "map (square square) x", so
> that consing together the intermediate list can be avoided.  I really
> like to write ACL2 code that operates by filtering, mapping, and
> folding operations over lists, but sometimes I have to "manually"
> perform the folding and prove that my folded function is the same as
> some combination of these higher order functions for efficiency's
> sake.  Introducing accumulators as appropriate would seem to fall into
> this category.  If GCL could automatically handle this kind of thing,
> it would be great, but this is probably all much further down the road
> and much harder to do in an impure language like Common Lisp.  That
> is, how do we know "square" is side-effect free?
> 

I am taking a stab at propagating a side-effect-free property
automatically.  But I don't yet see how to implement something like
the above ....

> Anyway, I'm just excited for GCL to support function inlining via
> declaims.  I don't really care what it does automatically, because I
> don't use much Lisp beyond whatever is provided by ACL2.  Maybe
> functions like "length" could be implemented as inlined wrappers of
> the form:
>   (if (stringp x) (nasty_c_code::string-length x) (nasty_c_code::list-length x))
> but probably all of you understand these kinds of details much better than me.
> 

Yep:

>(disassemble 'length nil)

;; Compiling /tmp/gazonk_14987_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_14987_0.o.

#include "gazonk_14987_0.h"
void init_code(){do_init((void *)VV);}
/*	local entry for function LENGTH	*/

static fixnum LI1__LENGTH___gazonk_14987_0(V2)

register object V2;
{	 VMB1 VMS1 VMV1
	goto TTL;
TTL:;
	if(((/* PROPER-SEQUENCEP */(*LnkLI3)((V2))))==Cnil){
	goto T5;}
	goto T3;
	goto T5;
T5:;
	V2= (VFUN_NARGS=4,(/* CHECK-TYPE-SYMBOL */(*LnkLI4)(((object)VV[0]),(V2),((object)VV[1]),Cnil)));
	goto T3;
T3:;
	{register object V3;
	V3= (V2);
	if(!(listp((V3)))){
	goto T8;}
	/*(ENDP X)*/
	{register object V4;
	V4= (V3);
	{register object V5;
	V5= (V4);
	if(!(((V5))==Cnil)){
	goto T11;}}}
	/* END (ENDP X)*/
	{fixnum V6 = (fixnum)0;VMR1
	(V6);}
	goto T11;
T11:;
	/*(ENDP (SETQ X (CDR X)))*/
	{register object V7;
	/*(CDR X)*/
	{register object V8;
	V8= (V3);
	{register object V9;
	V9= (V8);
	V3= ((V9))->c.c_cdr;}}
	/* END (CDR X)*/
	V7= (V3);
	{object V10;
	V10= (V7);
	if(!(((V10))==Cnil)){
	goto T18;}}}
	/* END (ENDP (SETQ X (CDR X)))*/
	{fixnum V11 = (fixnum)1;VMR1
	(V11);}
	goto T18;
T18:;
	/*(ENDP (SETQ X (CDR X)))*/
	{register object V7;
	/*(CDR X)*/
	{register object V8;
	V8= (V3);
	{register object V9;
	V9= (V8);
	V3= ((V9))->c.c_cdr;}}
	/* END (CDR X)*/
	V7= (V3);
	{object V10;
	V10= (V7);
	if(!(((V10))==Cnil)){
	goto T31;}}}
	/* END (ENDP (SETQ X (CDR X)))*/
	{fixnum V12 = (fixnum)2;VMR1
	(V12);}
	goto T31;
T31:;
	/*(ENDP (SETQ X (CDR X)))*/
	{register object V7;
	/*(CDR X)*/
	{register object V8;
	V8= (V3);
	{register object V9;
	V9= (V8);
	V3= ((V9))->c.c_cdr;}}
	/* END (CDR X)*/
	V7= (V3);
	{object V10;
	V10= (V7);
	if(!(((V10))==Cnil)){
	goto T44;}}}
	/* END (ENDP (SETQ X (CDR X)))*/
	{fixnum V13 = (fixnum)3;VMR1
	(V13);}
	goto T44;
T44:;
	/*(ENDP (SETQ X (CDR X)))*/
	{register object V7;
	/*(CDR X)*/
	{register object V8;
	V8= (V3);
	{register object V9;
	V9= (V8);
	V3= ((V9))->c.c_cdr;}}
	/* END (CDR X)*/
	V7= (V3);
	{object V10;
	V10= (V7);
	if(!(((V10))==Cnil)){
	goto T57;}}}
	/* END (ENDP (SETQ X (CDR X)))*/
	{fixnum V14 = (fixnum)4;VMR1
	(V14);}
	goto T57;
T57:;
	{register fixnum V15;
	register object V16;
	V15= (fixnum)5;
	/*(CDR X)*/
	{register object V8;
	V8= (V3);
	{register object V9;
	V9= (V8);
	V16= ((V9))->c.c_cdr;}}
	/* END (CDR X)*/
	goto T76;
T76:;
	/*(ENDP X)*/
	{register object V4;
	V4= (V16);
	{register object V5;
	V5= (V4);
	if(((V5))==Cnil){
	goto T79;}}}
	/* END (ENDP X)*/
	{register fixnum V17;
	register object V18;
	V19 = V15;
	V17= (fixnum)(V19)+((fixnum)1);
	{object V20;
	/*(CDR X)*/
	{register object V8;
	V8= (V16);
	{register object V9;
	V9= (V8);
	V20= ((V9))->c.c_cdr;}}
	/* END (CDR X)*/
	V18=V20;}
	V15= V17;
	V16= (V18);}
	goto T76;
	goto T79;
T79:;
	{fixnum V21 = V15;VMR1
	(V21);}
	{fixnum V22 = fixint(Cnil);VMR1
	(V22);}}
	goto T8;
T8:;
	{fixnum V23 = (fixnum)((V3))->v.v_fillp;VMR1
	(V23);}}
	base[0]=base[0];
}


GCL unrolls the first few iterations to count short list lengths, here
<= 5. 

> I guess as a parting thought, it's not really the size of the code
> that you care about.  I mean, you really want to inline if:
>    (1) it allows you to avoid the overhead of many function calls, or

Absolutely critical in lisp it seems.

>    (2) it allows you to see the sort of "repeated subterm"
> optimizations I mentioned in the MILAWA::CAR example.
> 

So far we have no automatic repeated subexpression simplifier, but I
have discussed this with Boyer in the past.

> The only downside of inlining is the disk space needed for the
> executable, and really who cares?  I mean, gosh, I bought a 250
> GIGABYTE hard drive awhile ago for something like $70.  If disk space
> is like 30 cents per GB (and dropping), then I'm happy for GCL to use
> several GB of disk space if it wants to.
> 

Thanks for the data point ...

Quite surprising to me -- code is often smaller when inlined.

> Maybe as a first cut, you could try to heuristically guess at these
> things.  We could imagine labelling a function as BIG if it is
> recursive or calls any BIG function on a non-constant value.  Non-big
> functions could be called SMALL.  A simple heuristic would be to
> always inline SMALL functions.  Maybe this isn't good enough, maybe
> you want to also have REALLYBIG functions that recursively call a BIG
> function.  Then you could unwind BIG functions up to, say, 5 times,
> depending on the sheer code size, and never unwind REALLYBIG
> functions.

Here is the current heuristic based on *space*

(defun acceptable-inline (h form tpis)
  (let* ((c1 (car h))
	 (sz (cadr h))
	 (d (and c1
		 (inline-possible (car form))
		 (or (< sz (* 1000 (- 3 (max 0 *space*))))
		     (and (< *space* 3) (member-if (lambda (x) (and (atomic-tp (car x)) (functionp (cadar x)))) tpis))))))

(sz is rougly the number of conses in the pass1 output)
(if an explicit function is passed as an arg, inline regardless of *space*)


> 
> But by now I'm talking nonsense.  Maybe the only good advice is to
> keep the autoamatic-inlining policy somehow flexible, so it can be
> changed after testing shows how we failed to handle some case well.
> We could also ask the SBCL or CMUCL lists, or Gary Byers, about their
> strategy for inlining and what experience led them to that strategy.

I imagine one wants to turn it off without going to safety 3.  Right
now, *speed* 0 will do it too, but this is really awful....

Take care,

> 
> Cheers,
>     Jared
> 
> On 7/6/07, Matt Kaufmann wrote:
> > Hi, Rob and Jared --
> >
> > Rob, didn't you once tell me that Allegro ignores function inlining
> > proclamations?  Jared, didn't you once tell me that CMUCL does really
> > well with function inlining?  Below are relevant emails (starting with
> > the one that started this thread) in case either of you is interested.
> >
> > -- Matt
> > ============================================================
> >
> > To: gcl-devel@gnu.org
> > cc: Robert Boyer, Matt Kaufmann,
> >         Tim Daly, list,
> >         Robert Dodier,
> >         Maxima mailing list <Maxima@math.utexas.edu>
> > Subject: gcl inlining policy
> > From: Camm Maguire
> > Date: Fri, 06 Jul 2007 12:58:02 -0400
> > X-SpamAssassin-Status: No, hits=-2.5 required=5.0
> > X-UTCS-Spam-Status: No, hits=-280 required0
> >
> > Greetings!  If you would be so kind, I'd appreciate some direction on
> > the desired inlining policy fro gcl 2.7.0.
> >
> > GCL has always inlined certain functions, e.g. mapcar, member, etc.
> > Without this, performance would be noticeably worse.
> >
> > Traditionally, this has been accomplished though ad-hoc 'c1 functions
> > in the compiler, or C-snippet inline attributes in cmpopt.lsp.  Thus
> > one had not only to write the function, but its inline support in the
> > compiler as well.  Support for these remain, but thanks to Boyer's
> > suggestion to carry the original source around in the image, automatic
> > inlining is now possible.  Support for this is in place in 2.7 with
> > notable improvements in performance.
> >
> > The question is, what functions should be inlined by default?
> > Currently, symbols external to the lisp package are automatically
> > considered. Explicitly declared or declaimed functions are also.
> > inlining may decline if the inline is too large, using a heuristic
> > function using the *space* setting as input, though in many cases,
> > inlined code is smaller.  The real cost of inlining is compiler speed,
> > and tracing support.
> >
> > Boyer recently posted a benchmark which would benefit greatly from
> > automatic inlining of user functions.
> >
> > Separately, should inlining be allowed at safety 3?
> >
> > Take care,
> > --
> > Camm Maguire                                            Camm Maguire
> > ==========================================================================
> > "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> >
> > ------- Start of forwarded message -------
> > X-YMail-OSG: dfiyZd8VM1nP5PL6C0Yh5UuU_.FW78sSgGm09IOVpI8fTvWYGSsFiTgB9EbYmCi0WHN3WTCiw6gYbouFtYpFf8mA4RHd7wQsTusEKt1fU6GgHDK96gV4wXdJLWta
> > Reply-To: Richard Fateman
> > From: "Richard Fateman" Richard Fateman
> > To: "'Raymond Toy'" Raymond Toy, Tim Daly
> > Cc: Robert Boyer, "'Camm Maguire'" Camm Maguire,
> >         "'Robert Dodier'" Robert Dodier,
> >         "'Matt Kaufmann'" Matt Kaufmann, <Maxima@math.utexas.edu>,
> >         <list>
> > Subject: RE: [Maxima] gcl inlining policy
> > Date: Fri, 6 Jul 2007 14:21:44 -0700
> > Organization: UC Berkeley
> > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
> > Thread-index: AcfAEG3zIg6uXqNEThWEWqdh2j5r/gAAi7gg
> > In-reply-to: <468EAC40.2070903@ericsson.com>
> > X-SpamAssassin-Status: No, hits=-2.0 required=5.0
> > X-UTCS-Spam-Status: No, hits=-198 required0
> >
> > It seems to me that in-lining a function of any significant length is very
> > likely to be a mistake, though I suppose it depends on the memory cache
> > management.  If the in-lining is done to remove consing, then perhaps the
> > solution is to address the consing itself.  I don't know the exact
> > circumstances of the needed optimization, but if it is arithmetic-related,
> > perhaps this can be done by stack allocation of temporary numbers.  I
> > haven't tried timing of ACL2 in Allegro Common Lisp, but it might be
> > revealing to do so.  It is my understanding that Allegro mostly, if not
> > entirely, ignores inline declarations of user-defined functions.
> > I have been told that this was a deliberate decision after a careful
> > consideration of the semantic consequences of inlining to the CL standard
> > versus the expected gain in performance.
> >
> > RJF
> >
> >
> > > -----Original Message-----
> > > From: maxima-bounces@math.utexas.edu
> > > [mailto:maxima-bounces@math.utexas.edu] On Behalf Of Raymond Toy
> > > Sent: Friday, July 06, 2007 1:55 PM
> > > To: Tim Daly
> > > Cc: Robert Boyer; Camm Maguire; Robert Dodier; Matt
> > > Kaufmann; Maxima@math.utexas.edu; list
> > > Subject: Re: [Maxima] gcl inlining policy
> > >
> > > Tim Daly wrote:
> > > >> As for space optimization I'm not sure it matters. I can't
> > > think of a
> > > > case where inlining will happen so many times that space is
> > > an issue.
> > > > Who writes a function with 50 mapcars? For space
> > > optimization it might
> > > > be better to throw away the cached sources.
> > >
> > > Here is an example where there is LOTS of inlining.  CMUCL supports
> > > double-double floats and has support for unboxed
> > > double-double floats.
> > > However, to make things fast, the code that implements the basic
> > > arithmetic operations is inlined.  So the routine that
> > > calculates log(x)
> > > via rational approximation has inlined lots of routines,
> > > perhaps 50 or
> > > more arithmetic operations.  A double-double add takes about
> > > 200 bytes.
> > >   The space used is a lot.
> > >
> > > I also have a quad-double implementation.  That is even
> > > larger because a
> > > quad-double operation is some 1K bytes long.  But if you don't inline
> > > the basic arithmetic function and all the internal functions that are
> > > needed to implement it, the consing slows down the operation by a
> > > significant fraction (half or more?).  To make these inline, I had to
> > > increase CMUCL's inlining threshold to 1600 (the  upper limit on the
> > > number of inline function calls that will be expanded in any
> > > given code
> > > object).
> > >
> > > Anyway, this is really way off topic for maxima, so I will
> > > refrain from
> > > saying more on this list.

\start
Date: 11 Jul 2007 17:08:51 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: Re: counting allocated bytes

--=-=-=

Hello Camm,

Thank you for including this change!

[...]
> 2) The algorithm needs correcting when sgc is on -- is one interested
>    in the active read-write set, of the static read-only set here?

My understanding of stratified gc is that the read-only set is what
counts here, but I would need to delve into the details of GCL's
implementation before I could make a conclusive statement in this
regard.


To save you some typing, attached is a very terse patch against
si-defs.texi.  Not to sure what else one needs to say about this
function.


Thanks again,
Steve


--=-=-=

--- si-defs.texi	2007-07-11 17:06:05.000000000 -0400
+++ si-defs.texi.smw	2007-07-11 17:05:16.000000000 -0400
@@ -375,7 +375,14 @@
 
 
 @end deffn
+@defun TOTAL-BYTES-ALLOCATED ()
+Package:SI
+
+GCL specific: Returns the total number of bytes allocated by GCL since
+the image was started.
 
+
+@end defun
 @defun *MAKE-SPECIAL (symbol)
 Package:SI
 

--=-=-=--

\start
Date: Wed, 11 Jul 2007 17:20:52 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Axiom, FriCAS, forks and teeth
Cc: Gabriel Dos Reis

On 7/11/07, C Y wrote:
>
> > But the goals of Principia Mathematica
> > (a universal treatment of mathematics) has been shown by
> > mathematicians themselves (e.g. Geodel's theorem) not to be
> > attainable even in principle.
>
> OK.  So then, how DO we work with mathematics? (I don't expect an
> answer - but it's still a reasonable question, unless one wants to
> throw up one's hands.  A universal treatment (whatever that means)
> might not be possible, but what is the best solution (or solutions)
> that ARE possible?)

Perhaps the answer lies in category theory as a foundation for
mathematics and as a model for appropriate formalisms in computer
science.

> ...
>  But can any of those systems take an
> answer and use their internal routines to guide the creation of an
> axiomatic proof of a answer?  Something that could be verified by ANY
> mechanical proof checker that understand the chosen language, or even a
> sufficiently patient human?  Without that, how can we trust the results
> of any system?  Why should scientists depend on a tool they can't know
> is without error and have no hope of verifying?
>

Well, they do tend to depend on each other, right? ;-)

Seriously, I do not think we are at the stage where we can trust the
output of any system -- certainly not one that is complicated enough
to include arithmetic (ref: Geodel's theorem). I agree that the
marriage of computer algebra and computer aided proof systems is an
interesting concept but it is still at the very early research stage.

> ...
> I would be curious what branch(es) of mathematics you think Axiom will
> be incapable of dealing with, via one form or another of extension?  Is
> there any possible system you feel would be MORE useful?
>

Category theory, category theory. Any computer algebra system that
makes at least a half way attempt to structure things according to
category theory.

> ...
> Am I nuts?  Probably ;-).  I don't know if even Tim shares my views in
> this respect.  I know I'm not a good fit for FriCAS, perhaps I am not a
> good fit for Axiom.  But what else can we do in a volunteer project but
> pursue our interests?  If those are not compatible with the project, I
> can work on my own - I have no wish to disrupt anything any further
> than it has already been disrupted.
>

Gee, there must be something (bad vibes?) in the air recently ... ;-)

Certainly you have as much right to be here (or there) as anyone else.
I do not find any of the work you do or your comments at all
disruptive.

\start
Date: 11 Jul 2007 17:26:22 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: Re: 2.7 build

Camm Maguire writes:

> Great!  What in your opinion is the best (simplest) tree to work with
> purely for the purpose of finalizing the 2.7 build?  I'd like it to be
> very close to what might eventually go into Debian, so I guess this
> means Silver?  How do I get Silver?  What are you using?

I am basically using Silver.  Its a local tree but I can pull out the
relevant changes and make them available on axiom-developer.org.  It
might take a day or two to do the merge and test.  This is work I need
to do regardless and will advise when ready.


Current build is progressing past layer 14 of the algebra and going
steady.


As Silver is the staging ground for future Axiom releases, I think
Silver is of most importance for Debian.

You can get silver via SVN at sourceforge:

   svn co https://axiom.svn.sourceforge.net/svnroot/axiom/trunk/axiom 

Or via GIT on axiom-developer (the password is `linus'):

   git-clone ssh://git@axiom-developer.org/home/git/silver silver

Both trees are kept in sync by Tim.

\start
Date: Wed, 11 Jul 2007 16:26:59 -0500
From: Doug Stewart
To: list
Subject: Re: Axiom, FriCAS, forks and teeth

Gabriel Dos Reis wrote:
> On Wed, 11 Jul 2007, C Y wrote:
>
> | 
> | --- Gabriel Dos Reis wrote:
> | 
> | > I believe that the core of the system would have to change, evolved,
> | > rewritten, rethinked.
> | > The future -- at least the near future -- is in parallel/distributed
> | > computations with multicores expected to grow exponentially.  We
> | > will have to rethink most of the algorithms at the of the system.
> | > Not just envelops like graphics backends.
> | 
> | For performance concerns, certainly - and I would support and be highly
> | interested in such work.  For myself, I am more interested in the
> | limits of correctness verification than high performance parallel
> | computing.
>
> Multicore are no longer supercomputers myths you would find in
> highly financed National Labs.  They are the reality today.  
> If you order a machine from Dell, the probability that you
> get a multicore is very high.  How do you we wisely and efficiently
> use that computational power?  Clearly Waldek has an example where
> Axiom is making a dumb use of resource.  No matter how correct the answer
> is.  How would you react to computation of determinant of
> an nxn matrix with complexity O(n!)?
>
>
> Many things that were considered absolute truths or theorems a decade
> ago are no longer valid.  We have to retthink the algorithms we
> implement; we have to rethink the core system.
>
> -- Gaby
>
>   


Tim said:
"

The hardest thing I found about making the transition to literate
programming is that the "literate" part overrides the "programming"
part in importance. That is, besides writing for humans in comment
style you also end up having to "scramble" the program so it takes 
on a logical development style for the human reader. Writing for
the human is much harder and more time consuming than writing for
the machine. It only makes sense if the program is intended to
be maintained by other humans over a long time, raising the need
to write for humans.
"

Gaby said:
"
I believe that the core of the system would have to change, evolved,

 rewritten, rethinked.
"

I think that this will be true, If you think back 20 years and see
what computing was like then, compared to now, and then try and look
forward 20-30 years, yes things will change.  Now look at the
undocumented or poorly documented code and try changing it!  I think
Tim's comments of writing for the humans that will have to change-
improve it, is fundamental. I gust have to look at some of my code
written 20 years ago to see how vitally important Tim's statement is.

Doug

PS I am just a user but I have been reading all the emails for the
last 2 years, and hope to some day be able to help.

\start
Date: Wed, 11 Jul 2007 23:28:42 +0200
From: Gregory Vanuxem
To: Camm Maguire
Subject: re: counting allocated bytes

Hello Stephen and Camm,

I'm particularly interested by this addition. Can it be considered as
comparable to get-byte-consed in SBCL or CMUCL ?

For information I resurrected code of Axiom relative to Lisp memory
management (g-timer.boot) and I use get- byte-consed on CMUCL and SBCL.
I wonder if this new function can be used. As far as I know (correct me
if I'm wrong) get-byte-consed (SBCL, CMUCL) returns the number of bytes
allocated, freed and "purified" so total-bytes-allocated and
get-bytes-consed seem to have different purposes. Stephen, can you tell
me what is the counterpart of TOTAL-BYTES-ALLOCATED on SBCL (or CMUCL or
Clisp) ?

Greg


Le mercredi 11 juillet 2007 =E0 16:14 -0400, Camm Maguire a =E9crit :
> Greetings, and thank you so much!
>
> This is now in.  Your assumptions are correct, but alas the n_used
> counter is not reliably maintained.  Here is the version now checked
> in commensurate with (room):
>
> DEFUN_NEW("TOTAL-BYTES-ALLOCATED",object,fStotal_bytes_allocated,SI,0,0=
,NONE,OO,OO,OO,OO,(void),"") {
>   int i;
>   unsigned long bytes;
>   for(bytes=0,i=t_start; i < t_end; i++) {
>     struct typemanager *tm=tm_of(i);
>     if (tm->tm_type!=i)
>       continue;
>     bytes += TM_NUSED(*tm) * tm->tm_size;
>   }
>   bytes+=ncbpage*PAGESIZE;
>   bytes+=rb_pointer-rb_start;
>   RETURN1(make_fixnum(bytes));
>
> }
>
> Quite a big difference.  I need to fix tm_nused someday.  Notes:
>
> 1) This is a slight overestimate -- we really should subtract the free
>    block space from the contiguous allocation usage
> 2) The algorithm needs correcting when sgc is on -- is one interested
>    in the active read-write set, of the static read-only set here?
> 3) This might motivate me to provide a function to print the
>    contiguous block structure for Matt Kaufmann ...
>
> Also think I fixed the install of clcs/packages.lisp and bin/gcl.
> Please let me know if problems persist.
>
> Thanks again so much!
>
>
> Stephen Wilson writes:
>
> > Hello,
> >
> > I have been working on evaluating/integrating a Lisp based testing
> > framework into Axiom (based on Lift).  One of the features is the
> > ability to benchmark the running of tests. 
> >
> > To accommodate the benchmark code, I needed a function which returns
> > the total number of bytes allocated since the image was started. 
> >
> > I could not find such a function.  Perhaps I missed it? There is
> > SI:ALLOCATED, but it reports information for a specific type only.
> >
> > I considered writing a function using SI:ALLOCATED and SI:SIZE-OF for
> > personal use.  However, when I considered if such a function would be
> > of use to GCL, I realized it may be better to attempt it in C.
> >
> > Of course, if the facility already exists, then this is just a
> > learning experience for me.  Attached is a patch against alloc.c.
> >
> > I have two issues with this code:
> >
> >   * Is it correct to assume that all entries in tm_table with the
> >     tm_size field equal share the same allocation space?  I assumed
> >     this from the documentation for SI:ALLOCATED.
> >
> >   * Im slightly concerned about overflow of the `bytes' variable.  Is
> >     this likely?  Should bignum arith be used?
> >
> > Hopefully this might be of some use to GCL, however I completely
> > understand if it is deemed unnecessary, badly implemented, etc.

\start
Date: Wed, 11 Jul 2007 23:56:08 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: FriCAS mailing list

There is now a Google group (mailing list):

 

It is intended that all FriCAS specific discussion should take
place on the fricas-devel list.

You can also find my first writeup about FriCAS at:

http://www.math.uni.wroc.pl/~hebisch/fricas.html

(this is a copy of registration text at SourceForge).

\start
Date: Wed, 11 Jul 2007 14:56:46 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Axiom, FriCAS, forks and teeth
Cc: Gabriel Dos Reis


--- Bill Page wrote:

> On 7/11/07, C Y wrote:

> > OK.  So then, how DO we work with mathematics? (I don't expect an
> > answer - but it's still a reasonable question, unless one wants to
> > throw up one's hands.  A universal treatment (whatever that means)
> > might not be possible, but what is the best solution (or solutions)
> > that ARE possible?)
> 
> Perhaps the answer lies in category theory as a foundation for
> mathematics and as a model for appropriate formalisms in computer
> science.

Then, in that case, we are ENTIRELY in agreement! :-).  That is
PRECISELY the direction I am interested in exploring.
 
> Seriously, I do not think we are at the stage where we can trust the
> output of any system -- certainly not one that is complicated enough
> to include arithmetic (ref: Geodel's theorem). I agree that the
> marriage of computer algebra and computer aided proof systems is an
> interesting concept but it is still at the very early research stage.

Certainly.  But that to me is a call to drive the research forward - it
won't happen by itself.  Since at the moment funding and programs to do
this seem rather hard to come by, it must be done outside traditional
academic research institutions.  (Although I hope with a quality that
will appeal to them none the less...)
 
> > I would be curious what branch(es) of mathematics you think Axiom
> > will be incapable of dealing with, via one form or another of 
> > extension?  Is
> > there any possible system you feel would be MORE useful?
> >
> 
> Category theory, category theory. Any computer algebra system that
> makes at least a half way attempt to structure things according to
> category theory.

EXACTLY.  I understood Axiom was already relatively close to category
theory, but not quite.  Once a proper non-algebra framework is in place
(i.e. one I can ignore), my next thought is to use Stephen's SPAD to
attempt to implement a CAS foundation which will feel "natural" to
research mathematicians, and begin to include the current Algebra work
in that framework.

> > ...
> > Am I nuts?  Probably ;-).  I don't know if even Tim shares my views
> > in this respect.  I know I'm not a good fit for FriCAS, perhaps I
am
> > not a good fit for Axiom.  But what else can we do in a volunteer
> > project but pursue our interests?  If those are not compatible with
> > the project, I can work on my own - I have no wish to disrupt
> > anything any further than it has already been disrupted.
> 
> Gee, there must be something (bad vibes?) in the air recently ... ;-)
> 
> Certainly you have as much right to be here (or there) as anyone
> else. I do not find any of the work you do or your comments at all
> disruptive.

Thank you for that, Bill.  I very much enjoy the Axiom community, and
admire its members for their skill and willingness to contribute.  My
hope is that we can all settle into where we feel comfortable (Axiom or
FriCAS as interest dictates) and advance the state of the art.

Now, I need to write some actual pamphlets... ;-)

\start
Date: Wed, 11 Jul 2007 17:13:21 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Unions in Spad

On Wed, 11 Jul 2007, Bill Page wrote:

| In my opinion this is yet one more reason why Spad should *not* be
| removed from the core Axiom system.

Yes; Spad should be *improved*, instead of being removed and replaced
with a lower-level language.

\start
Date: Wed, 11 Jul 2007 18:19:44 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Unions in Spad

Sorry, what I said (obviously) applies to Spad. Perhaps it is not even
controversial.  But I really intended to write was a reply to your
comment in defense of BOOT and reasons for distinguishing it from
Spad:

> Maybe, just maybe, it is reasonable to associate BOOT more with the
> earlier "ScratchPad I" project. As I understand it from the scant
> literature about these early days, ScratchPad I was a more
> "symbolically oriented" computer algebra system
> ...
> In my opinion this is yet one more reason why Boot should *not* be
> removed from the core Axiom system.

Regards,
Bill Page.

On 7/11/07, Gabriel Dos Reis wrote:
> On Wed, 11 Jul 2007, Bill Page wrote:
>
> | In my opinion this is yet one more reason why Spad should *not* be
> | removed from the core Axiom system.
>
> Yes; Spad should be *improved*, instead of being removed and replaced
> with a lower-level language.

\start
Date: 11 Jul 2007 19:01:28 -0400
From: Stephen Wilson
To: Gregory Vanuxem
Subject: re: counting allocated bytes
Cc: Camm Maguire

Gregory Vanuxem writes:

> Hello Stephen and Camm,
> 
> I'm particularly interested by this addition. Can it be considered as
> comparable to get-byte-consed in SBCL or CMUCL ?

I do not belive so.  IIRC get-bytes-consed returns an increasing
sequence of integers, effectively counting the number of allocations
performed.

I was actually aiming for somthing similar, but due to my
inexperience with GCL's internals I clearly got something wrong.  I
was using si::allocated as a guide.  The sixth value is the number of
uses of the given type.  Compare the following:

>(si:allocated 'cons)

204399
819
819
512
0
4503032

>(si:total-bytes-allocated)

3296240

>(defvar *c* (make-list 10000))

*C*

>(si:allocated 'cons)

194336
819
819
512
0
4513095

>(si:total-bytes-allocated)

3377336

>(setq *c* nil)

NIL

>(gbc t)

T

>(si:allocated 'cons)

204527
819
819
512
0
4513143

>(si:total-bytes-allocated)

3293360


Notice how si::allocated is returning an increasing integer sequence
in its sixth value,  whereas total-bytes-allocated is, as Camm
mentioned, a report commensurate with (room).


Camm, is it possible that tm_nused is providing the type of
information  necessary to get an accurate picture of how much a
function is consing, predictably increasing even amidst gc's?

\start
Date: Wed, 11 Jul 2007 19:39:25 -0400
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: Axiom, FriCAS, forks and teeth
Cc: Gabriel Dos Reis

Waldek Hebisch wrote:

> So while old algorithm
> remains correct, a superior one may be invented and replace
> the old.

Sure.  And I would agree with that.  I was thinking more along the lines
of the build system, the interpreter, client-server communication, etc.
 I would expect the mathematics to grow and change, although I DO hope
that category theory as a framework will endure and scale.

> There is an extra twist to this:  I suspect that polynomials
> in question are relatively prime.  With high probability
> a simple modular method will discover this.  But there is
> a question how to hook modular method so that it gets
> used.  I belive that the polynomials have type 'UP(Expression Integer)'
> and you need some extra work to determine if modular method
> is applicable.
> 
> In short: new algorithms are discovered and to use new algorithm
> you may be forced to change parts of the system which at first
> glance have nothing to do with new code.

That sounds reasonable to me - I would regard that as an investigation
into new mathematics and as such a legitimate reason to update Axiom's
mathematical logic.  What I'm hoping to avoid is needing to do anything
major with the non-mathematical components of the system - they should
do what is needed and not break.  How to achieve this is probably where
the debate comes in, but I'll not start that up again.

P.S. - how does one sign up for the new email list?

\start
Date: Wed, 11 Jul 2007 18:59:21 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Axiom, FriCAS, forks and teeth

On Wed, 11 Jul 2007, C Y wrote:

| Waldek Hebisch wrote:
| 
| > So while old algorithm
| > remains correct, a superior one may be invented and replace
| > the old.
| 
| Sure.  And I would agree with that.  I was thinking more along the lines
| of the build system, the interpreter, client-server communication, etc.
|  I would expect the mathematics to grow and change, although I DO hope
| that category theory as a framework will endure and scale.

Category theory is just a language.  The most interesting part is how
one exploits that language to tell a story.

\start
Date: Wed, 11 Jul 2007 19:43:49 -0500
From: Jay Belanger
To: list
Subject: Re: Axiom, FriCAS, forks and teeth

Gabriel Dos Reis writes:
...
> | In the announcement of the fork, Waldek quotes Tim as saying
> | that literate programming was a primary goal of the Axiom project, and
> | if somebody wanted to get somewhere faster that they should fork.
>
> I believe it takes an extraordinary amount of both stretch and imagination
> (which, obviously, I do not have) to conclude from that quote that Waldek
> wanted "be able to put off documentation"

I just noticed that you only quoted part of what I wrote, and you only 
quoted a part which I explicity stated did not address the "put off 
documentation" comment.  This is, of course, dishonest of you.

\start
Date: Thu, 12 Jul 2007 03:20:08 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: Re: 2.7 installation
Cc: axiom-devel <list>, gcl-devel@gnu.org

Camm Maguire wrote:
> 
> Also think I fixed the install of clcs/packages.lisp and bin/gcl.
> Please let me know if problems persist.
> 

I just updated from cvs and the problem persists.  Configured with

./configure --enable-ansi --disable-xgcl --prefix=/var/tmp/hebisch/usrn

We get now '${PREFIX}/lib/gcl-2.7.0/bin/gcl' while we need
'${PREFIX}/bin/gcl'.  AFAICS clcs/packages.lisp is just a typo (we need
clcs/package.lisp):

--- makefile.bb	2007-07-12 03:05:53.000000000 +0200
+++ makefile	2007-07-12 03:06:07.000000000 +0200
@@ -178,7 +178,7 @@
 merge:
 	$(CC) -o merge merge.c
 
-LISP_LIB=bin/gcl clcs/packages.lisp clcs/myload1.lisp clcs/gcl_clcs_macros.lisp cmpnew/gcl_collectfn.o cmpnew/gcl_collectfn.lsp xgcl-2/sysdef.lisp xgcl-2/gcl_dwtest.lsp xgcl-2/gcl_dwtestcases.lsp lsp/gcl_gprof.lsp lsp/gcl_info.o lsp/gcl_profile.lsp lsp/gcl_export.lsp lsp/gcl_autoload.lsp cmpnew/gcl_cmpmain.lsp cmpnew/gcl_cmpopt.lsp cmpnew/gcl_lfun_list.lsp lsp/gcl_auto_new.lsp h/cmpinclude.h unixport/init_$(SYSTEM).lsp unixport/lib$(SYSTEM).a unixport/libgclp.a gcl-tk/tk-package.lsp $(TK_LISP_LIB) $(RL_LIB) $(FIRST_FILE) $(LAST_FILE) $(addsuffix /sys-proclaim.lisp,lsp cmpnew pcl clcs) unixport/gcl.script
+LISP_LIB=bin/gcl clcs/package.lisp clcs/myload1.lisp clcs/gcl_clcs_macros.lisp cmpnew/gcl_collectfn.o cmpnew/gcl_collectfn.lsp xgcl-2/sysdef.lisp xgcl-2/gcl_dwtest.lsp xgcl-2/gcl_dwtestcases.lsp lsp/gcl_gprof.lsp lsp/gcl_info.o lsp/gcl_profile.lsp lsp/gcl_export.lsp lsp/gcl_autoload.lsp cmpnew/gcl_cmpmain.lsp cmpnew/gcl_cmpopt.lsp cmpnew/gcl_lfun_list.lsp lsp/gcl_auto_new.lsp h/cmpinclude.h unixport/init_$(SYSTEM).lsp unixport/lib$(SYSTEM).a unixport/libgclp.a gcl-tk/tk-package.lsp $(TK_LISP_LIB) $(RL_LIB) $(FIRST_FILE) $(LAST_FILE) $(addsuffix /sys-proclaim.lisp,lsp cmpnew pcl clcs) unixport/gcl.script
 
 install_command:
 	rm -f bin/$(BINSCPT)

\start
Date: 11 Jul 2007 21:58:40 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: re: counting allocated bytes

Greetings!

Stephen Wilson writes:

> Hi Gregory,
> 
> Gregory Vanuxem writes:
> 
> > Hello Stephen and Camm,
> > 
> > I'm particularly interested by this addition. Can it be considered as
> > comparable to get-byte-consed in SBCL or CMUCL ?
> 
> I do not belive so.  IIRC get-bytes-consed returns an increasing
> sequence of integers, effectively counting the number of allocations
> performed.
> 
> I was actually aiming for somthing similar, but due to my
> inexperience with GCL's internals I clearly got something wrong.  I
> was using si::allocated as a guide.  The sixth value is the number of
> uses of the given type.  Compare the following:
> 
> >(si:allocated 'cons)
> 
> 204399
> 819
> 819
> 512
> 0
> 4503032
> 
> >(si:total-bytes-allocated)
> 
> 3296240
> 
> >(defvar *c* (make-list 10000))
> 
> *C*
> 
> >(si:allocated 'cons)
> 
> 194336
> 819
> 819
> 512
> 0
> 4513095
> 
> >(si:total-bytes-allocated)
> 
> 3377336
> 
> >(setq *c* nil)
> 
> NIL
> 
> >(gbc t)
> 
> T
> 
> >(si:allocated 'cons)
> 
> 204527
> 819
> 819
> 512
> 0
> 4513143
> 
> >(si:total-bytes-allocated)
> 
> 3293360
> 
> 
> Notice how si::allocated is returning an increasing integer sequence
> in its sixth value,  whereas total-bytes-allocated is, as Camm
> mentioned, a report commensurate with (room).
> 
> 
> Camm, is it possible that tm_nused is providing the type of
> information  necessary to get an accurate picture of how much a
> function is consing, predictably increasing even amidst gc's?
> 

Yes it appears so.  See also si::reset-number-used.  I was confused as
it would appear the proper variable name is tm_totalloc or somesuch.

\start
Date: 11 Jul 2007 22:01:37 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: re: counting allocated bytes

Greetings!  As per my last message please also note that this does not
include allocation on the C stack as in :dynamic-extent or in GCL
forked child processes, which allocate everything on the C stack to
avoid copy-on-write penalties.

Stephen Wilson writes:

> Hi Gregory,
> 
> Gregory Vanuxem writes:
> 
> > Hello Stephen and Camm,
> > 
> > I'm particularly interested by this addition. Can it be considered as
> > comparable to get-byte-consed in SBCL or CMUCL ?
> 
> I do not belive so.  IIRC get-bytes-consed returns an increasing
> sequence of integers, effectively counting the number of allocations
> performed.
> 
> I was actually aiming for somthing similar, but due to my
> inexperience with GCL's internals I clearly got something wrong.  I
> was using si::allocated as a guide.  The sixth value is the number of
> uses of the given type.  Compare the following:
> 
> >(si:allocated 'cons)
> 
> 204399
> 819
> 819
> 512
> 0
> 4503032
> 
> >(si:total-bytes-allocated)
> 
> 3296240
> 
> >(defvar *c* (make-list 10000))
> 
> *C*
> 
> >(si:allocated 'cons)
> 
> 194336
> 819
> 819
> 512
> 0
> 4513095
> 
> >(si:total-bytes-allocated)
> 
> 3377336
> 
> >(setq *c* nil)
> 
> NIL
> 
> >(gbc t)
> 
> T
> 
> >(si:allocated 'cons)
> 
> 204527
> 819
> 819
> 512
> 0
> 4513143
> 
> >(si:total-bytes-allocated)
> 
> 3293360
> 
> 
> Notice how si::allocated is returning an increasing integer sequence
> in its sixth value,  whereas total-bytes-allocated is, as Camm
> mentioned, a report commensurate with (room).
> 
> 
> Camm, is it possible that tm_nused is providing the type of
> information  necessary to get an accurate picture of how much a
> function is consing, predictably increasing even amidst gc's?

\start
Date: 11 Jul 2007 22:08:55 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: Re: 2.7 installation

Greetings!  My apologies -- obviously I'm testing with the source tree
in place.  It should be fixed now.  Please let me know if problems
persist.

Take care,

Waldek Hebisch writes:

> Camm Maguire wrote:
> > 
> > Also think I fixed the install of clcs/packages.lisp and bin/gcl.
> > Please let me know if problems persist.
> > 
> 
> I just updated from cvs and the problem persists.  Configured with
> 
> ./configure --enable-ansi --disable-xgcl --prefix=/var/tmp/hebisch/usrn
> 
> We get now '${PREFIX}/lib/gcl-2.7.0/bin/gcl' while we need
> '${PREFIX}/bin/gcl'.  AFAICS clcs/packages.lisp is just a typo (we need
> clcs/package.lisp):
> 
> --- makefile.bb	2007-07-12 03:05:53.000000000 +0200
> +++ makefile	2007-07-12 03:06:07.000000000 +0200
> @@ -178,7 +178,7 @@
>  merge:
>  	$(CC) -o merge merge.c
>  
> -LISP_LIB=bin/gcl clcs/packages.lisp clcs/myload1.lisp clcs/gcl_clcs_macros.lisp cmpnew/gcl_collectfn.o cmpnew/gcl_collectfn.lsp xgcl-2/sysdef.lisp xgcl-2/gcl_dwtest.lsp xgcl-2/gcl_dwtestcases.lsp lsp/gcl_gprof.lsp lsp/gcl_info.o lsp/gcl_profile.lsp lsp/gcl_export.lsp lsp/gcl_autoload.lsp cmpnew/gcl_cmpmain.lsp cmpnew/gcl_cmpopt.lsp cmpnew/gcl_lfun_list.lsp lsp/gcl_auto_new.lsp h/cmpinclude.h unixport/init_$(SYSTEM).lsp unixport/lib$(SYSTEM).a unixport/libgclp.a gcl-tk/tk-package.lsp $(TK_LISP_LIB) $(RL_LIB) $(FIRST_FILE) $(LAST_FILE) $(addsuffix /sys-proclaim.lisp,lsp cmpnew pcl clcs) unixport/gcl.script
> +LISP_LIB=bin/gcl clcs/package.lisp clcs/myload1.lisp clcs/gcl_clcs_macros.lisp cmpnew/gcl_collectfn.o cmpnew/gcl_collectfn.lsp xgcl-2/sysdef.lisp xgcl-2/gcl_dwtest.lsp xgcl-2/gcl_dwtestcases.lsp lsp/gcl_gprof.lsp lsp/gcl_info.o lsp/gcl_profile.lsp lsp/gcl_export.lsp lsp/gcl_autoload.lsp cmpnew/gcl_cmpmain.lsp cmpnew/gcl_cmpopt.lsp cmpnew/gcl_lfun_list.lsp lsp/gcl_auto_new.lsp h/cmpinclude.h unixport/init_$(SYSTEM).lsp unixport/lib$(SYSTEM).a unixport/libgclp.a gcl-tk/tk-package.lsp $(TK_LISP_LIB) $(RL_LIB) $(FIRST_FILE) $(LAST_FILE) $(addsuffix /sys-proclaim.lisp,lsp cmpnew pcl clcs) unixport/gcl.script
>  
>  install_command:
>  	rm -f bin/$(BINSCPT)

\start
Date: 11 Jul 2007 22:22:30 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: Re: 2.7 build

Greetings!

Stephen Wilson writes:

> Camm Maguire writes:
> 
> > Great!  What in your opinion is the best (simplest) tree to work with
> > purely for the purpose of finalizing the 2.7 build?  I'd like it to be
> > very close to what might eventually go into Debian, so I guess this
> > means Silver?  How do I get Silver?  What are you using?
> 
> I am basically using Silver.  Its a local tree but I can pull out the
> relevant changes and make them available on axiom-developer.org.  It
> might take a day or two to do the merge and test.  This is work I need
> to do regardless and will advise when ready.
> 
> 
> Current build is progressing past layer 14 of the algebra and going
> steady.
> 

Great!  Can't wait to see your mods.  So I take it any 2.7/axiom
problems are limited?

Take care,

> 
> As Silver is the staging ground for future Axiom releases, I think
> Silver is of most importance for Debian.
> 
> You can get silver via SVN at sourceforge:
> 
>    svn co https://axiom.svn.sourceforge.net/svnroot/axiom/trunk/axiom 
> 
> Or via GIT on axiom-developer (the password is `linus'):
> 
>    git-clone ssh://git@axiom-developer.org/home/git/silver silver
> 
> Both trees are kept in sync by Tim.
> 
\start
Date: 11 Jul 2007 22:38:33 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: re: counting allocated bytes

Greetings!

Shouldn't this function be total-bytes-used on second thought?

Stephen Wilson writes:

> Hello Camm,
> 
> Thank you for including this change!
> 
> [...]
> > 2) The algorithm needs correcting when sgc is on -- is one interested
> >    in the active read-write set, of the static read-only set here?
> 
> My understanding of stratified gc is that the read-only set is what
> counts here, but I would need to delve into the details of GCL's
> implementation before I could make a conclusive statement in this
> regard.
> 

Actually a hybrid:

current algorithm counts
all used cells
all allocated contiguous pages
read-write only used relocatable blocks.

Take care,

> 


> To save you some typing, attached is a very terse patch against
> si-defs.texi.  Not to sure what else one needs to say about this
> function.
> 
> 
> Thanks again,
> Steve
> 
> 
> --- si-defs.texi	2007-07-11 17:06:05.000000000 -0400
> +++ si-defs.texi.smw	2007-07-11 17:05:16.000000000 -0400
> @@ -375,7 +375,14 @@
>  
>  
>  @end deffn
> +@defun TOTAL-BYTES-ALLOCATED ()
> +Package:SI
> +
> +GCL specific: Returns the total number of bytes allocated by GCL since
> +the image was started.
>  
> +
> +@end defun
>  @defun *MAKE-SPECIAL (symbol)
>  Package:SI

\start
Date: 11 Jul 2007 23:34:21 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: re: counting allocated bytes

Camm Maguire writes:

> Greetings!
> 
> Shouldn't this function be total-bytes-used on second thought?

Yes, absolutely.  Unfortunately the intended result and the effective
result do not match,  but I belive this is a usefull function to have
in many situations.

I am looking into the possibility of getting a proper implementation
of a get-bytes-consed varient, using a new slot tm_totalloc in the
typemanager to carry a bignum (and thus not relying on tm_nused for
this purpose).  Unfortunately this would mean an mp addition in the
middle of make_cons.  Furthermore there does not seem to be a general
interface to direct, destructive mp arithmetic exported via the
generic mp.h.  Is pari still supported?  

> 
> Stephen Wilson writes:
> 
> > Hello Camm,
> > 
> > Thank you for including this change!
> > 
> > [...]
> > > 2) The algorithm needs correcting when sgc is on -- is one interested
> > >    in the active read-write set, of the static read-only set here?
> > 
> > My understanding of stratified gc is that the read-only set is what
> > counts here, but I would need to delve into the details of GCL's
> > implementation before I could make a conclusive statement in this
> > regard.
> > 
> 
> Actually a hybrid:
> 
> current algorithm counts
> all used cells
> all allocated contiguous pages
> read-write only used relocatable blocks.
> 
> Take care,
> 
> > 
> 
> 
> > To save you some typing, attached is a very terse patch against
> > si-defs.texi.  Not to sure what else one needs to say about this
> > function.
> > 
> > 
> > Thanks again,
> > Steve
> > 
> > 
> > --- si-defs.texi	2007-07-11 17:06:05.000000000 -0400
> > +++ si-defs.texi.smw	2007-07-11 17:05:16.000000000 -0400
> > @@ -375,7 +375,14 @@
> >  
> >  
> >  @end deffn
> > +@defun TOTAL-BYTES-ALLOCATED ()
> > +Package:SI
> > +
> > +GCL specific: Returns the total number of bytes allocated by GCL since
> > +the image was started.
> >  
> > +
> > +@end defun
> >  @defun *MAKE-SPECIAL (symbol)
> >  Package:SI

\start
Date: 11 Jul 2007 23:44:07 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: Re: 2.7 build

Camm Maguire writes:

> Greetings!
> 
> Stephen Wilson writes:
> 
> > Camm Maguire writes:
> > 
> > > Great!  What in your opinion is the best (simplest) tree to work with
> > > purely for the purpose of finalizing the 2.7 build?  I'd like it to be
> > > very close to what might eventually go into Debian, so I guess this
> > > means Silver?  How do I get Silver?  What are you using?
> > 
> > I am basically using Silver.  Its a local tree but I can pull out the
> > relevant changes and make them available on axiom-developer.org.  It
> > might take a day or two to do the merge and test.  This is work I need
> > to do regardless and will advise when ready.
> > 
> > 
> > Current build is progressing past layer 14 of the algebra and going
> > steady.
> > 
> 
> Great!  Can't wait to see your mods.  So I take it any 2.7/axiom
> problems are limited?

Well, the algebra build chocked again at layer 19, but we are close.

There is undoubtedly a few quality bugs to iron out, if my experiences
with full builds using 2.6.8pre in ANSI mode carry over to a run on
our test-suite.  But in general, yes, I would think the issues are
limited.

I have high hopes that Axiom can be ready for a full ANSI release near
about the time GCL goes 2.7.0.


Sincerely,
Steve



> 
> Take care,
> 
> > 
> > As Silver is the staging ground for future Axiom releases, I think
> > Silver is of most importance for Debian.
> > 
> > You can get silver via SVN at sourceforge:
> > 
> >    svn co https://axiom.svn.sourceforge.net/svnroot/axiom/trunk/axiom 
> > 
> > Or via GIT on axiom-developer (the password is `linus'):
> > 
> >    git-clone ssh://git@axiom-developer.org/home/git/silver silver
> > 
> > Both trees are kept in sync by Tim.

\start
Date: 12 Jul 2007 01:59:04 -0500
From: Gabriel Dos Reis
To: Jay Belanger
Subject: Re: Axiom, FriCAS, forks and teeth

Jay Belanger writes:

| Gabriel Dos Reis writes:
| ...
| > | In the announcement of the fork, Waldek quotes Tim as saying
| > | that literate programming was a primary goal of the Axiom project, and
| > | if somebody wanted to get somewhere faster that they should fork.
| >
| > I believe it takes an extraordinary amount of both stretch and imagination
| > (which, obviously, I do not have) to conclude from that quote that Waldek
| > wanted "be able to put off documentation"
| 
| I just noticed that you only quoted part of what I wrote, and you only 
| quoted a part which I explicity stated did not address the "put off 
| documentation" comment.  This is, of course, dishonest of you.

I quoted, as usual, the most important part of the message that I needed to
address.  There was no transmutation. 

\start
Date: 11 Jul 2007 17:29:50 -0500
From: Gabriel Dos Reis
To: Doug Stewart
Subject: Re: Axiom, FriCAS, forks and teeth

Doug Stewart writes:

[...]

| Now look at the undocumented or poorly documented code and try changing it!
| I think Tim's comments of writing for the humans that will have to
| change- improve it, is fundamental. I gust have to look at some of
| my code written 20 years ago to see how vitally important Tim's
| statement is. 

It appears to me that people seem to think that disagreeing with
Tim's dogmatic pamphlet style is disagreeing with better and well 
documented Axiom system.  Nothing could be farther from truth.

As a matter of fact, almost all of the existing pamphlets pass Tim's
pamphlet test only at the syntax level.  And the ones that look
advanced documentation look to me poorer than non-pamphletized
documentation -- e.g. I have far less trouble reading 
and trying to undestand SBCL source code than reading and
understanding bookvol5 and friends and the rest of the system.

\start
Date: Thu, 12 Jul 2007 13:00:47 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: Re: 2.7 build

I am now testing yesterday gcl-cvs.  I have set up safety to 3.  I hit
two problems.  One is segfault -- it went away when I tried to debug
it:


)compile "RADCAT.spad"

Segmentation violation: c stack ok:signalling error
   >> System error:
   Condition in MAKE-INPUT-FILENAME [or a callee]: INTERNAL-SIMPLE-ERROR: Caught fatal error [memory may be damaged]: Segmentation violation.


I am somewhat worried: this is a first time I see a segfault in safety 3
build. 

The second problem is that the function |ICformat| apparently is
miscompiled, Lisp code differs only trivially from code in 2.6.8
build.  In particular at the beggining we have:

(DEFUN |ICformat| (|u|)
  (PROG (|v| |l'| |l1| |l|)
    (RETURN
      (SEQ (COND
             ((ATOM |u|) |u|)
             ((AND (PAIRP |u|) (EQ (QCAR |u|) '|has|))
              (|compHasFormat| |u|))
             ((OR (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
                       (PROGN (SPADLET |l| (QCDR |u|)) 'T))
                  (AND (PAIRP |u|) (EQ (QCAR |u|) '|and|)
                       (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
              (SPADLET |l|
                       (REMDUP (PROG (#1=#:G7955)


however, the call:

(|ICformat| '(|and| |foo| |bar| |foo|))

in 2.7.0 falls to the end and signals error, while in 2.6.8 compiled
Axiom it works OK.  It looks that Steve had similar problem (but later
wrote that it works OK).

One extra remark: the extra PROG which I saw previously seem to be
gone -- I am not sure if it is safety 3 or something in gcl changed.
But now I see:

(DEFUN |ALIST;dictionary;$;1| ($) (SPADCALL NIL (QREFELT $ 11)))

(the same as in other dialects), while earlier 2.7 gave me:

(DEFUN |ALIST;dictionary;$;1| ($)
  (PROG () (RETURN (SPADCALL NIL (QREFELT $ 11)))))

\start
Date: Thu, 12 Jul 2007 08:55:11 -0400
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Axiom, FriCAS, forks and teeth

Gabriel Dos Reis wrote:
> Doug Stewart writes:
> 
> [...]
> 
> | Now look at the undocumented or poorly documented code and try changing it!
> | I think Tim's comments of writing for the humans that will have to
> | change- improve it, is fundamental. I gust have to look at some of
> | my code written 20 years ago to see how vitally important Tim's
> | statement is. 
> 
> It appears to me that people seem to think that disagreeing with
> Tim's dogmatic pamphlet style is disagreeing with better and well 
> documented Axiom system.  Nothing could be farther from truth.

No, or at least I don't see it that way.  I view it more as a
disagreement about method than a disagreement about the end goal.

> As a matter of fact, almost all of the existing pamphlets pass Tim's
> pamphlet test only at the syntax level.

On that point, I agree - in fact, I don't see how anyone could disagree.
  And for myself, much as I would prefer to be working on units and
dimensions, I am having to take a "from square one" approach to
understanding how the system works.  I figure as long as that must be
done anyway, I may as well try to do something useful to contribute at
that level.

>  And the ones that look
> advanced documentation look to me poorer than non-pamphletized
> documentation -- e.g. I have far less trouble reading 
> and trying to undestand SBCL source code than reading and
> understanding bookvol5 and friends and the rest of the system.

As I understand it, bookvol5 is nowhere near completion.  What is your
take on dhmatrix?  As I understand it that file is closer to a "proper"
literate document.  Or, for that matter, what about cl-web?

\start
Date: Thu, 12 Jul 2007 15:32:24 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: Re: 2.7 installation

Camm Maguire wrote:
> Greetings!  My apologies -- obviously I'm testing with the source tree
> in place.  It should be fixed now.  Please let me know if problems
> persist.
> 

The latest cvs version installs fine.  Thanks.

\start
Date: Thu, 12 Jul 2007 10:05:22 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Axiom, FriCAS, forks and teeth
Cc: Gabriel Dos Reis

On 7/12/07, C Y wrote:
>...
> Gaby wrote:
> >  And the ones that look
> > advanced documentation look to me poorer than non-pamphletized
> > documentation -- e.g. I have far less trouble reading
> > and trying to undestand SBCL source code than reading and
> > understanding bookvol5 and friends and the rest of the system.
>

I agree!

> As I understand it, bookvol5 is nowhere near completion.  What is your
> take on dhmatrix?  As I understand it that file is closer to a "proper"
> literate document.  Or, for that matter, what about cl-web?
>

I think dhmatrix as a literate document is rather "marginal". Yes it
presents the main ideas of the code but does not seem like much
advance over embedded comments to me.

cl-web: A very well written example for a relatively small program. I
think this is very hard to reproduce for most Axiom components.
(cl-web is not Axiom).

\start
Date: Thu, 12 Jul 2007 07:14:18 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Axiom, FriCAS, forks and teeth
Cc: Gabriel Dos Reis

--- Bill Page wrote:

> > As I understand it, bookvol5 is nowhere near completion.  What is
> > your take on dhmatrix?  As I understand it that file is closer to a
> > "proper" literate document.  Or, for that matter, what about 
> > cl-web?
> 
> I think dhmatrix as a literate document is rather "marginal". Yes it
> presents the main ideas of the code but does not seem like much
> advance over embedded comments to me.

Hmm.  OK.  I'll have to look over it again - my (admittedly hazy)
recollection was that there was a fair bit of introductory material
before the code appeared.

> cl-web: A very well written example for a relatively small program. I
> think this is very hard to reproduce for most Axiom components.
> (cl-web is not Axiom).

That's a concern, and a valid point.  As I have not yet gotten to any
major Axiom component, I must concede that for myself the viability
remains un-tested.  

\start
Date: Thu, 12 Jul 2007 09:55:57 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Literate Programs

Cliff,

Since you and others, like Ralf, have actually TRIED to write literate
programs your criticisms carry weight. You have experience.  I note
that those reviews seem to be at least semi-favorable.

I posted a list of half-a-dozen literate books. I find them immensely
readable and very insightful. I can understand the code because I
understand the ideas behind the code which are included in the
surrounding paragraphs. We need the same for the algebra.

It is trivially easy to complain about anything when you haven't
seriously tried to use the technology. I can think of a dozen
reasons not to use Ruby on Rails but I've never tried it. Most
of these criticisms fall into the categories of
  "It is time consuming" -- we have time
  "It slows us down"     -- not doing it slows everyone else
  "It is too hard"       -- no, it isn't. 
  "I'm used to raw code" -- that's fine for toy programs
  "The tools suck"       -- it's open source, make them better

What are the specific failings? Where did the tool not provide
sufficient support? What improvements need to be made? How can we
make the tools better (e.g. asdf understanding pamphlets).

It is easy to say "no". It is hard to propose "better".

\start
Date: Thu, 12 Jul 2007 11:05:29 -0400
From: William Sit
To: Gabriel Dos Reis, Bill Page, Stephen Wilson, Waldek Hebisch
Subject: Re: Unions in Spad

Stephen Wilson wrote:

> Main question is _why_ they [hybrid union] might be desirable.
> Spad does not support them. Aldor might in theory, but only in
> theory.
> [...]
>
> Do you have an argument for `hybrid' Unions?

Gabriel Dos Reis wrote:

> In general, I'm of the opinion that the language should be
>
> constrained only when we cannot come with proper
> semantics.
> I'm not sure this case is one such case; that is why I
> would
> like to understand the arguments. I don't want a language
> designed to express only what I can think of today.

I agree with Gaby.

The construction of Union (in Axiom) as implementing the
notion of coproduct or external direct sum in Category
Theory, specifically as disjoint union in Set Theory and
taking place in the category of sets, should have nothing to
do with tags, but with an index set and the sets associated
with each index. (By the way, the notions of union,
coproduct, and colimit are distinct concepts in category
theory, so let's not get too involved with these.) Since in
Axiom, sets are domains of SetCategory, accordingly,  Union
(renamed) should be specified as:

IndexedUnion(I: SetCategory, g:I ->SetCategory):SetCategory

Example 1:
I:= Integer
g(i:I):SetCategory == if even? i then Integer else String
J:= IndexedUnion(I,g)

A more mathematical example would be to construct the prime
field if i is prime, and a product of prime fields over
factors of i if i is composite. In the next example, we
construct the set of all square matrices with integer
entries.

Example 2:
I:=Integer
g(i:I):SetCategory == SquareMatrix(i, Integer)
J:=IndexedUnion(i,g)

Technically, g here is a domain constructor. Whether the
implementation should be done as primitive or not depends on
language limitation of Spad. As we shall see, at the Spad
level, we would need domains and categories to be first
class objects and maps would need to allow input-dependent
types as its output. So Axiom may not allow that.

As it currently exists, Union (in Axiom) can only form the
disjoint union of a *finite* number of sets (each of which
is a domain of SetCategory, NOT as elements of Set S for
some domain S, which are finite subsets of S). The index set
in the tagged version is the set of tags, but this is
clearly not enough (there being no useful operations in the
set of tags). The index set in the untagged version probably
defaults to {1, ..., n} where n is the number of sets
(domains) in the union or some n distinct strings generated
randomly. (I did not check the code since Union is a
primitive and its code lives below the algebra level -- not
an excuse, just incompetence on the lower levels on my
part).

The convenience of tags (in the case of a small, finite
index set) is that the user does not have to make the set of
tags into a domain and the tags are supposedly more
meaningful to the user. Now, is a hybrid Union type
desirable? Example 6 below will illustrate a possible use.
In my opinion, the "mixed" Union where tags are allowed for
a small finite subset of the index set would allow the best
of both worlds. Unfortunately, tags are strings (by
definition) whereas there is no such restriction on an index
set (or the rest of it). In most cases, for the index set to
remain a domain, the indices must be homogeneous in type and
so if there are tags, then the index set should be a subset
of the set of all strings. In the finite case, it would be
an *element* of Set String (and thus, not a *domain*).  But
Union should allow infinite index sets as well and an
infinite set of strings is difficult to manipulate in code.

One plausible reason why Union is implemented as a primitive
rather than at the algebra level is to avoid having to
require a user at the algebra level to make the index set
into a *domain*.  To allow hybrid index set, it would be
again simpler to implement as a primitive than at the
algebra level as Bill Page proposed, because requiring the
user to make the hybrid index set into a domain would be a
bit harder and less intuitive. We need a domain constructor
(which is easy to implement):

TagAsDomain( T: Set String): SetCategory

Note that Set String is used, not List String. This type of
construction is already used in Axiom, as in the domain
"failed" when we use Union("failed", ...). So it is probably
handled specifically by the compiler, or there is a similar
function at lower level. The above specification would
enforce automatically the constraints Stephen thinks Spad is
currently lacking (but documented, see hyperdoc on Union):

> I think the consensus is that `hybrid' Union types are not
> desirable.
> Consequently, I will look into making Spad strictly
> enforce this. In
> addition, the constraint that an untagged Union not have
> identically
> typed branches, and that in the tagged case all branch
> names are
> distinct.

Example 3:
I:= TagsAsDomain({"a", "b", "c"})
-- this would be {"a","b","c"} as a domain
g(i:I):SetCategory ==
  i = "a" => A
  i = "b" => B
  i = "c" => C
J:=IndexedUnion(I,g)

Clearly this is a bit awkward at the algebra level, compared
to

Union(a:A, b:B, c:C)

But a compiler can easily translate the above into the
detailed algebra code in Example 3. On the other hand, in
this algebraic level version, there is no "untagged" Union
(all domains in IndexedUnion are indexed) and the "untagged"
version should not require any constraints such as the
associated domains be distinct. It is only required that the
elements of the index set be distinct, which is
automatically enforced because it is a set. Indeed, hybrid
union indexed by a heterogeneous set can be handled easily
too, using IndexedUnion itself!

Example 4:
I:=IntegerMod(2)
L:=TagsAsDomain({"a","b","c"})
g(i:I):SetCategory ==
  zero? i => L
  IntegerMod(5)
J:= IndexedUnion(I,g)
f(j:J):SetCategory == ...
K:= IndexedUnion(J, f)

Again, it would be much easier to have this implemented
enumeratively and perhaps as a primitive and allow the user
to simply write, in case the index set is finite and small:

Union(a:A,b:B,c:C,D,E,F,G,H)

However, the more abstract specification of IndexedUnion is
far more powerful.

Example 5:

I:=IntegerMod(2)
L:=TagsAsDomain({"a","b","c"})
g(i:I):SetCategory ==
  zero? i => L
  String
J:= IndexedUnion(I,g)
f(j:J):SetCategory == ...
K:= IndexedUnion(J, f)

In the definition of f, we can actually distinguish the "a"
in L from the "a" in String because each element of
IndexedUnion is "tagged" and we will use the "=" from L or
from String (this is related to the scoping issue of current
implementation raised by Gaby). Since J in Example 5 is
itself an IndexedUnion object, this brings us to the "case"
question, or more generally:

What should be exported from IndexedUnion?

Clearly, there needs to be a way to coerce elements from the
domains into the union. If we were to adopt Bill Page's idea
that the injections (and projections for Product or Record)
should be named by tags, then it would be very clumsy to
implement them when the Union is over a large finite set and
impossible over an infinite set.  This may be one reason why
Axiom separates Union into two versions, tagged (when the
indexed set is finite and small) and untagged (the general
case).  I can only think of two purposes of tags: (1) to
distinguish cases when a domain occurs multiple times in the
arguments of Union, and (2) for convenience of use.  The
first of these can be handled by the index set and the
second, too, but convenience depends on the size of the
index set, as illustrated in the previous examples.

Based on the notion of constructing IndexedUnion using an
index set, I propose the following exports (there should be
more if one compares this with IndexedAggregate or other
Indexed* constructors, but for the purpose of this
discussion, they are irrelevant):

IndexedUnion(I: SetCategory, g:I ->SetCategory):SetCategory
== with
      "=": (%, %) -> Boolean
      index: % -> I
         ++ index(x) returns the index i such that x belongs
to g(i)
      value(x:%): g(index(x))
         ++ index(x) returns x as an element in g(index(x))
      coerce(i:I, x:g(i)): %
         ++ coerce(i,x) creates x as an element of % in the
component g(i)


These are just generalization of what currently exist but I
get rid of the "case" and replace it with "index" and
"value".  Instead of multiple overloading of "case" and
"coerce", we now need only one (this afterall, is exactly
the advantage of indexing over explicit enumeration). Of
course, we need to be able to use input-dependent
signatures. This is a requirement when we deal with
heterogeneous objects. In Example 5, where J itself is
defined using IndexedUnion, the function f may be defined in
the following way. The example illustrates how IndexedUnion
may be used.

Example 6 (Example 5 continued):

I:=IntegerMod(2)
L:=tagsAsDomain({"a","b","c"})
g(i:I):SetCategory ==
  zero? i => L
  String
J:= IndexedUnion(I,g)
f(j, J) :SetCategory ==
  jU := value(j)
  index(j) =$I 0 =>
     jU =$L "a" => A
     jU =$L "b" => B
     jU =$L "c" => C
  IntegerMod(#jU)
K:=IndexedUnion(J,f)

Of course this example is contrived. However, I can imagine
constructions in mathematics over a set J where for a finite
number of (exception) elements of J, there are two cases
whereas for all the other there is only one. This would
necessitate exceptional handling as in Example 6 above.

What about the data representation of Union? Can we do this
at the algebra level? We seem to need non-homogeneous data
representation! In lower level, this is not difficult, say
using pointers (perhaps another reason why Union is
implemented as primitive, to hide pointers at the algebra
level), but at the algebra level, Axiom is not designed for
heterogeneous objects (that's why people use C++):

    Rep:= Record( index: I, value:g(i) )

if allowed would be perfect (note that Record is also a
primitive, so let the lower level handle pointers). Record,
categorically the product construction, should also be done
using an index set. A plausible and trivial implementation
of the exported functions is:

      x = y == (x.index = y.index) and (x.value = y.value)
      index(x) == x.index
      value(x)== x.value
      coerce(i:I, v:g(i)) == [i, v]$Rep

By generalizing TagsAsDomain, replacing String by any
domain, we can create arbitrarily complicated index sets an
IndexedUnion objects.


\start
Date: 12 Jul 2007 10:22:45 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Literate Programs

Tim Daly writes:

[...]

| It is trivially easy to complain about anything when you haven't
| seriously tried to use the technology.

True.  It is equally easy to dismiss review under the name of "you
haven't seriously tried", when in fact the reviewer has tried the
technology and many others.  Does that ring a bell to you?

\start
Date: 12 Jul 2007 11:22:10 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: Re: 2.7 build

Greetings!

Waldek Hebisch writes:

> I am now testing yesterday gcl-cvs.  I have set up safety to 3.  I hit
> two problems.  One is segfault -- it went away when I tried to debug
> it:
> 
> 
> )compile "RADCAT.spad"
> 
> Segmentation violation: c stack ok:signalling error
>    >> System error:
>    Condition in MAKE-INPUT-FILENAME [or a callee]: INTERNAL-SIMPLE-ERROR: Caught fatal error [memory may be damaged]: Segmentation violation.
> 
> 
> I am somewhat worried: this is a first time I see a segfault in safety 3
> build. 
> 

As I mentioned a while ago, I'm trying to implement a more reasonable
(e.g. faster) safety 3, partially in response to your ealier request.
The older mode is still available at (the non-standard) safety 4.  It
would not surprise me if there are not a few issues to work out, but
the ansi-test suite, which is compiled at safety 3, is working fine.

For quick debugging of segfaults, run with )set break break and )lisp
(si::use-fast-links nil), then :bt at the break.  For robust
debugging, build gcl with --enable-debug and run under gdb.

I think the work-around you posted in your patch earlier regarding
universal-error-handler effectively disables error reporting, but am
not completely sure.  In your tree, I've tried simply removing the GCL
from #-(or gcl ccl) above and commenting out the
universal-error-handler embedding with (apparently) successful
results.  

This said, I have seen a segfault in your tree at the interpsys stage
which I would love to chase down.  Stephen's success has led me to
believe this is something specific to your tree, but GCL should
ideally never segfault.  Would it be possible for you and Stephen to
isolate what differences in your trees allow him to proceed well into
the algebra stage, but stops your tree shortly after interpsys? 

To be most efficient, it would be absolutely fantastic if you could
boil the error down to a simple example in lisp akin to Stephen's very
helpful reports of late.  My problem is that I do not know the axiom
sources nearly as well as the GCL sources -- it will therefore take
quite a while simply to find the relevant function leading to the
error.  

For example, in the report below ...

> The second problem is that the function |ICformat| apparently is
> miscompiled, Lisp code differs only trivially from code in 2.6.8
> build.  In particular at the beggining we have:
> 
> (DEFUN |ICformat| (|u|)
>   (PROG (|v| |l'| |l1| |l|)
>     (RETURN
>       (SEQ (COND
>              ((ATOM |u|) |u|)
>              ((AND (PAIRP |u|) (EQ (QCAR |u|) '|has|))
>               (|compHasFormat| |u|))
>              ((OR (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
>                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
>                   (AND (PAIRP |u|) (EQ (QCAR |u|) '|and|)
>                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
>               (SPADLET |l|
>                        (REMDUP (PROG (#1=#:G7955)

I take it this source is generated by some other function in axiom
which is malfunctioning, (akin to the writing of #<compiled function
...> in the generated lisp sources I reported earlier).  What is this
function?  How do I run it to produce the above output?  I take it the
difference lies in the gensym above -- this appears clearly wrong, and
indicates an error either in GCL's compilation of the function that
generates this source, or a mistake in one of the patches applied in
your tree.  Stephen, can you reproduce this?

> 
> 
> however, the call:
> 
> (|ICformat| '(|and| |foo| |bar| |foo|))
> 
> in 2.7.0 falls to the end and signals error, while in 2.6.8 compiled
> Axiom it works OK.  It looks that Steve had similar problem (but later
> wrote that it works OK).
> 

I don't see how this is related to Stephen's earlier report regarding
logical expression evaluation -- am I missing something?  It appears
we have a printing problem in your tree somewhere.

> One extra remark: the extra PROG which I saw previously seem to be
> gone -- I am not sure if it is safety 3 or something in gcl changed.
> But now I see:
> 
> (DEFUN |ALIST;dictionary;$;1| ($) (SPADCALL NIL (QREFELT $ 11)))
> 
> (the same as in other dialects), while earlier 2.7 gave me:
> 
> (DEFUN |ALIST;dictionary;$;1| ($)
>   (PROG () (RETURN (SPADCALL NIL (QREFELT $ 11)))))
> 

These are equivalent in lisp, but it still indicates some instability
in the axiom code generator.  There is nothing in GCL  that I can see
at the moment that would automatically make this conversion.

Please let me know if my suggestions above are unworkable.

BTW, am assuming we are still working with the source produced by svn
update in wh-sandbox as modified by the patches your posted.  If the
source tree is different, a complete set of instructions describing
how to reproduce this would be most helpful.

\start
Date: 12 Jul 2007 13:21:54 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: Re: 2.7 build

Camm Maguire writes:
[...]
> > The second problem is that the function |ICformat| apparently is
> > miscompiled, Lisp code differs only trivially from code in 2.6.8
> > build.  In particular at the beggining we have:
> > 
> > (DEFUN |ICformat| (|u|)
> >   (PROG (|v| |l'| |l1| |l|)
> >     (RETURN
> >       (SEQ (COND
> >              ((ATOM |u|) |u|)
> >              ((AND (PAIRP |u|) (EQ (QCAR |u|) '|has|))
> >               (|compHasFormat| |u|))
> >              ((OR (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
> >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
> >                   (AND (PAIRP |u|) (EQ (QCAR |u|) '|and|)
> >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
> >               (SPADLET |l|
> >                        (REMDUP (PROG (#1=#:G7955)
> 
> I take it this source is generated by some other function in axiom
> which is malfunctioning, (akin to the writing of #<compiled function
> ...> in the generated lisp sources I reported earlier).  What is this
> function?  How do I run it to produce the above output?  I take it the
> difference lies in the gensym above -- this appears clearly wrong, and
> indicates an error either in GCL's compilation of the function that
> generates this source, or a mistake in one of the patches applied in
> your tree.  Stephen, can you reproduce this?

My reading of the code does not suggest an error w.r.t the gensym.

Unfortunately this may have already been resolved were it not for
another mistake on my part.  I gave a bug report which related to this
issue but latter claimed it was a false alarm.  While collecting my
changes last night I noticed that I had inadvertently merged a local
work-around, thus masking the bug.

Many apologies for the confusion here.  Bellow follows the original
report.  Have rerun the examples with latest gclcvs, with identical
results.


Sincerely,
Steve

==-----------------------

Hello Camm,

Another issue has come up, again w.r.t the handling of logical
operations.

I hope these reports are not just pointing out known issues!  I only
wish I had the knowledge to fix them myself.


==--- test.lisp ---

(defun test (x) 
  (when (or (and (consp x) (eq (car x) 'X) t)
            (and (consp x) (eq (car x) '|x|) t))
    'OK))

==-----------------

Note that if the T's are dropped from the AND expressions, the
function behaves as expected.


steve:tmp> gcl
GCL (GNU Common Lisp)  2.7.0 ANSI    Jul  7 2007 19:13:09
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

Temporary directory for compiler files set to /tmp/

>(compile-file "test.lisp")

;; Compiling test.lisp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling test.o.
#P"/home/steve/tmp/test.o"
NIL
NIL

>(load "test.o")

;; Loading test.o
 ;; start address -T 0xb4acd8 ;; Finished loading test.o
80

>(test '(X))

OK

>(test '(|x|))

NIL

>(disassemble 'test)

;; Compiling /tmp/gazonk_18523_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_18523_0.o.

#include "gazonk_18523_0.h"
void init_code(){do_init((void *)VV);}
/*      local entry for function TEST   */

static object LI1(V2)

object V2;
{        VMB1 VMS1 VMV1
        goto TTL;
TTL:;
        if(!(consp((V2)))){
        goto T2;}
        /*(CAR X)*/
        {object V4;
        V4= (V2);
        V3= ((V4))->c.c_car;}
        /* END (CAR X)*/
        if(!((V3)==(((object)VV[0])))){
        goto T2;}
        {object V5 = ((object)VV[1]);VMR1
        (V5);}
        goto T2;
T2:;
        {object V6 = Cnil;VMR1
        (V6);}
        return Cnil;
}
#(#(X OK
    (%INIT
     . #((LET ((*DISABLE-RECOMPILE* T))
           (MFSFUN 'TEST 0 1 0)
           (ADD-HASH 'TEST '((T) SYMBOL)
               '((CAR (LIST) T) (EQ (T T) BOOLEAN) (CONSP (T) T))
COMMON-LISP-USER
LISPLAMBDA!
           ,DECLA,OPTIMIZ,SAFETY        ,BLOCK
                                              TEST      ,IF     ,OR
!,AN!,CONSP-    !,E!,CAR!,QUOTE-!,T
/-      12
          x,PROG2
                 OK '/tmp/gazonk_18523_0.lsp))
         (DO-RECOMPILE)))))
static object LI1();
#define VMB1 object  V3;
#define VMS1
#define VMV1
#define VMR1(VMT1) return(VMT1);
#define VM1 0
static void * VVi[3]={
#define Cdata VV[2]
(void *)(LI1)
};
#define VV (VVi)

/tmp/gazonk_18523_0.o:     file format elf32-i386

Disassembly of section .text:

00000000 <init_code>:
   0:   68 00 00 00 00          push   $0x0
   5:   e8 fc ff ff ff          call   6 <init_code+0x6>
   a:   58                      pop    %eax
   b:   c3                      ret    

0000000c <LI1>:
   c:   8b 54 24 04             mov    0x4(%esp),%edx
  10:   81 fa 00 00 00 00       cmp    $0x0,%edx
  16:   74 25                   je     3d <LI1+0x31>
  18:   81 fa ff ff ff bf       cmp    $0xbfffffff,%edx
  1e:   77 1d                   ja     3d <LI1+0x31>
  20:   f6 02 01                testb  $0x1,(%edx)
  23:   74 08                   je     2d <LI1+0x21>
  25:   81 3a ff ff ff bf       cmpl   $0xbfffffff,(%edx)
  2b:   76 10                   jbe    3d <LI1+0x31>
  2d:   a1 00 00 00 00          mov    0x0,%eax
  32:   39 42 04                cmp    %eax,0x4(%edx)
  35:   75 06                   jne    3d <LI1+0x31>
  37:   a1 04 00 00 00          mov    0x4,%eax
  3c:   c3                      ret    
  3d:   b8 00 00 00 00          mov    $0x0,%eax
  42:   c3                      ret    
NIL

>(defun test (x) 
    (when (or (and (consp x) (eq (car x) 'X))
              (and (consp x) (eq (car x) '|x|)))
      'OK))

TEST

>(compile 'test)

;; Compiling /tmp/gazonk_18523_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_18523_0.o.
;; Loading /tmp/gazonk_18523_0.o
 ;; start address -T 0xb4bd68 ;; Finished loading /tmp/gazonk_18523_0.o
#<compiled-function TEST>
NIL
NIL

>(test '(X))

OK

>(test '(|x|))

OK

\start
Date: Thu, 12 Jul 2007 19:54:10 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: Re: 2.7 build

> Greetings!
> 
> Waldek Hebisch writes:
> 
> > I am now testing yesterday gcl-cvs.  I have set up safety to 3.  I hit
> > two problems.  One is segfault -- it went away when I tried to debug
> > it:
> > 
> > 
> > )compile "RADCAT.spad"
> > 
> > Segmentation violation: c stack ok:signalling error
> >    >> System error:
> >    Condition in MAKE-INPUT-FILENAME [or a callee]: INTERNAL-SIMPLE-ERROR: Caught fatal error [memory may be damaged]: Segmentation violation.
> > 
> > 
> > I am somewhat worried: this is a first time I see a segfault in safety 3
> > build. 
> > 
> 
> As I mentioned a while ago, I'm trying to implement a more reasonable
> (e.g. faster) safety 3, partially in response to your ealier request.
> The older mode is still available at (the non-standard) safety 4.  It
> would not surprise me if there are not a few issues to work out, but
> the ansi-test suite, which is compiled at safety 3, is working fine.
> 
> For quick debugging of segfaults, run with )set break break and )lisp
> (si::use-fast-links nil), then :bt at the break.  For robust
> debugging, build gcl with --enable-debug and run under gdb.
>

Yes, I did

)set break break
)lisp (si::use-fast-links nil)
)read "boo1.input"

and the segfault went away -- this stage finished without problems.
 
> I think the work-around you posted in your patch earlier regarding
> universal-error-handler effectively disables error reporting, but am
> not completely sure.  In your tree, I've tried simply removing the GCL
> from #-(or gcl ccl) above and commenting out the
> universal-error-handler embedding with (apparently) successful
> results.  
>

Axiom tries to catch all errors and provide its own error reporting
-- Axiom messages may lack some information compared to native Lisp 
error reporting.  To do this Axiom either uses Ansi condition handler
or GCL specific universal-error-handler embedding.   It is OK to
disable Axiom error catcher during build.  "Production" Axiom have
to catch numerical errors, but otherwise Axiom error hander just
pretends that things are under control...

 
> This said, I have seen a segfault in your tree at the interpsys stage
> which I would love to chase down.  Stephen's success has led me to
> believe this is something specific to your tree, but GCL should
> ideally never segfault.  Would it be possible for you and Stephen to
> isolate what differences in your trees allow him to proceed well into
> the algebra stage, but stops your tree shortly after interpsys? 
> 

There are two possible reasons:

1) differences in Spad compiler.  wh-sandox fixed several bugs and
   removed a lot of code.  It is possible that removal introduced
   a new bug.  It is possible that Stephen fixed a bug that remains
   unfixed in wh-sandox.

2) wh-sandox compiles algebra in quite different way.  In particular,
   in first stage wh-sandox compiles about 200 files in a single
   Lisp image.  This puts much more stress on garbage collector than
   the old way.  Anather thing is that some files which silver
   compiles at the very end are compiled just at the beggining.
   Yet another thing: wh-sandox uses extra flags, so code takes
   different path.

> To be most efficient, it would be absolutely fantastic if you could
> boil the error down to a simple example in lisp akin to Stephen's very
> helpful reports of late.  My problem is that I do not know the axiom
> sources nearly as well as the GCL sources -- it will therefore take
> quite a while simply to find the relevant function leading to the
> error.  

In case of segfault I doubt that a small example is possible. 

> 
> For example, in the report below ...
> 
> > The second problem is that the function |ICformat| apparently is
> > miscompiled, Lisp code differs only trivially from code in 2.6.8
> > build.  In particular at the beggining we have:
> > 
> > (DEFUN |ICformat| (|u|)
> >   (PROG (|v| |l'| |l1| |l|)
> >     (RETURN
> >       (SEQ (COND
> >              ((ATOM |u|) |u|)
> >              ((AND (PAIRP |u|) (EQ (QCAR |u|) '|has|))
> >               (|compHasFormat| |u|))
> >              ((OR (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
> >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
> >                   (AND (PAIRP |u|) (EQ (QCAR |u|) '|and|)
> >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
> >               (SPADLET |l|
> >                        (REMDUP (PROG (#1=#:G7955)
> 
> I take it this source is generated by some other function in axiom
> which is malfunctioning, (akin to the writing of #<compiled function
> ...> in the generated lisp sources I reported earlier).  What is this
> function?  How do I run it to produce the above output?  I take it the
> difference lies in the gensym above -- this appears clearly wrong, and
> indicates an error either in GCL's compilation of the function that
> generates this source, or a mistake in one of the patches applied in
> your tree.  Stephen, can you reproduce this?
> 

Let me repeat:  I belive that the Lisp code above is correct.  This
code is an output of depsys, which translates Boot to Common Lisp.
The translator extenivly uses gensym-ed symbols, and AFAICS gensym-ed
work fine.  In fact, what I am saying is: modulo names of gensym-ed
symbols (which are irrelevant to the meaning) the Lisp code for this
function produced during 2.7.0 build is identical to Lisp code from
build using 2.6.8.

This function is contained in the file 'functor.boot.pamphlet' and
is a part of the Spad compiler.  'functor.boot.pamphlet' is translated
to Lisp giving 'functor.clip'.  'functor.clip' is compiled to
'functor.o'.  'functor.o' is used during Spad compilation.
'functor.o' produced by gcl-2.7.0 works incorrectly.

> > 
> > 
> > however, the call:
> > 
> > (|ICformat| '(|and| |foo| |bar| |foo|))
> > 
> > in 2.7.0 falls to the end and signals error, while in 2.6.8 compiled
> > Axiom it works OK.  It looks that Steve had similar problem (but later
> > wrote that it works OK).
> > 
> 
> I don't see how this is related to Stephen's earlier report regarding
> logical expression evaluation -- am I missing something?  It appears
> we have a printing problem in your tree somewhere.
>

Well, I belive that the logical expression in the code above is
evaluated incorrectly.  Basically, the |ICformat| performs a
series of pattern matches and depending on the outcame chooses
code to execute.  If no of the patterns matches |ICformat| signals
error.  The input above should be matched by the expression:

> >              ((OR (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
> >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
> >                   (AND (PAIRP |u|) (EQ (QCAR |u|) '|and|)
> >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))

but apparently, the expression above compiled by 2.7.0 does not
match (the code takes error branch).  I have modified by hand the
Lisp file changing the expression above to:

             ((OR (AND (PAIRP |u|) (OR (EQ (QCAR |u|) 'AND) (EQ (QCAR |u|) '|and|) )
                       (PROGN (SPADLET |l| (QCDR |u|)) 'T))
                  (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
                       (PROGN (SPADLET |l| (QCDR |u|)) 'T)))


Ater such change I was able to succesfully continue the build
(currently I am running the test suite).
 
So, I belive that the expression above is miscompiled by gcl.  I will
try to reduce problem to smaller example.

> > One extra remark: the extra PROG which I saw previously seem to be
> > gone -- I am not sure if it is safety 3 or something in gcl changed.
> > But now I see:
> > 
> > (DEFUN |ALIST;dictionary;$;1| ($) (SPADCALL NIL (QREFELT $ 11)))
> > 
> > (the same as in other dialects), while earlier 2.7 gave me:
> > 
> > (DEFUN |ALIST;dictionary;$;1| ($)
> >   (PROG () (RETURN (SPADCALL NIL (QREFELT $ 11)))))
> > 
> 
> These are equivalent in lisp, but it still indicates some instability
> in the axiom code generator.  There is nothing in GCL  that I can see
> at the moment that would automatically make this conversion.
>

Axiom tries to "optimize" generated Lisp code -- removal of PROG is
almost surely one of such optimizations.  However, Axiom makes various
unportable assumptions, and probably one of this assumptions is
(was) broken by the new gcl.

> Please let me know if my suggestions above are unworkable.
> 
> BTW, am assuming we are still working with the source produced by svn
> update in wh-sandbox as modified by the patches your posted.  If the
> source tree is different, a complete set of instructions describing
> how to reproduce this would be most helpful.
> 

I am working with the same tree as my first trial at gcl-2.7 build, namely
revision 636 of wh-sandbox + the patch that I posted.  If you did update
you probably got revision 646 which is slightly different.


\start
Date: Thu, 12 Jul 2007 15:48:20 -0500
From: Tim Daly
To: list
Subject: Literate Programming

An extended quote from:

Mills, Bruce "Theoretical Introduction to Programming"
Springer-Verlag 2006 ISBN 1-84628-021-4 pp 10-11

Notion 5: Literate Programming

Donald Knuth once said,
... when you write a program
      think of it primarily as a work of literature.

To program in computing is to prove in mathematics: both in syntax and
in semantics. The formal structure of a program is identical to that
of a formal constructive proof. To write a routine is to assert the
theorem that {\sl the code performs to specification}.

Although there are errors in mathematics works, the density is much
lower than in contemporary programs. In the mythos, this is due to a
greater complexity or urgency of software. The truth is, mathematics
was designed to be understood. A mathematics book does not just prove,
it also motivates, justifies, and discusses. This human nature makes
it easier to follow, detect errors, use elsewhere, or extend.

The larger part of the life of a piece of software is maintenance. The
code is modified to suit new specifications, conceptual errors are
identified and corrected, and typographical faults removed. This is
also the life of a mathematical proof.

A mathematical proof can be lengthy, technical, complex, obscure and
urgent: and yet it will not be left without justification. The
mathematical community would not accept it if it was. The fact that
much code is written without proper contemplation today is related to
market forces.  But, whatever excuse we give for why there is this
lack, this means (very) low-quality code.

There are good proofs and there are bad proofs. A good proof conforms
to both logic and intuition. A bad proof might give no clear concept
of why the result is true or might be difficult to follow. A flawed
proof with good discussion may be of more use in the development of
related correct material, than a technically correct proof with no
explanation.

Code should be written to be clear by itself, but also with good
comments.  More than just a cursive phrase stating {\sl this variable
stores the number of hobos found in Arkansas}. It should contain
discussion, explanation, and justification.

The natural language in a mathematics book is like the comments in a
program and is typically more extensive than the formal language. We
can compute $f(n) = \sum_{i=1)^n{i}$, by a loop. The loop is
``self-commenting'' because it reflects the original specification.
But it is better to compute this as $f(n)=n(n+1)/2$ relying on the
identity $f(n) = \sum_{i=1)^n{i} = n(n+1)/2$, which is by no means
obvious. In the code, we need a non-trivial comment to explain why
what we are doing works.

A program should be developed with a coherent theory of its operation.
Clearly defined data structures, with explicit axioms, greatly ease
the use and re-use of the code. If each item has a clearly explained
purpose and a distinct, justified, and discussed property, if each
item is a whole as well as a part, then it is much less likely that a
later programmer will accidently misuse it.

Consider a program to be written primarily to explain to another human
what it is that we want the computer to do, how it is to happen, and
why we can believe that we have achieved our aim. Do this even if you
write code for yourself. The ``other'' human being might be you in a
few month's time when the details have escaped your mind.

I have found it advisable that, in selecting what to write in comments,
if you have just spent a lot of time writing a routine, you should
write down what is obvious. Because it is likely that it is only
obvious to you now because you are steeped in the problem, next day,
next week, or next month, when you come back to modify it, the
operating principle might not be obvious at all.

Literate Haskell style is supported by typical Haskell environments. 
In this approach, the code-comment relation is reversed. Normally the 
code has primacy, and the comments are introduced by a special syntax, 
as if in afterthought. In the literate approach, the comments are 
primary.  By default, text is comment; the code must be introduced by 
a special notation stating that it is code.




and another comment from the same book: p346

There are several concepts wrapped up in the idea of literate
programming.  However, the central matter that I am interested in here
is that programming by humans should be a human enterprise. Knuth has
suggested that a program should, first and foremost, be a literary
work, to be read by humans. This is analogous to the approach in a
mathematics book.  The text of the book is like the comments in a
program, and it is typically bigger than the formal development.

\start
Date: 12 Jul 2007 17:14:38 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: Re: 2.7 build

Greetings, and thanks once again for a great report!  Should be fixed
now -- please let me know if problems persist.

Take care,

Stephen Wilson writes:

> Camm Maguire writes:
> [...]
> > > The second problem is that the function |ICformat| apparently is
> > > miscompiled, Lisp code differs only trivially from code in 2.6.8
> > > build.  In particular at the beggining we have:
> > > 
> > > (DEFUN |ICformat| (|u|)
> > >   (PROG (|v| |l'| |l1| |l|)
> > >     (RETURN
> > >       (SEQ (COND
> > >              ((ATOM |u|) |u|)
> > >              ((AND (PAIRP |u|) (EQ (QCAR |u|) '|has|))
> > >               (|compHasFormat| |u|))
> > >              ((OR (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
> > >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
> > >                   (AND (PAIRP |u|) (EQ (QCAR |u|) '|and|)
> > >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
> > >               (SPADLET |l|
> > >                        (REMDUP (PROG (#1=#:G7955)
> > 
> > I take it this source is generated by some other function in axiom
> > which is malfunctioning, (akin to the writing of #<compiled function
> > ...> in the generated lisp sources I reported earlier).  What is this
> > function?  How do I run it to produce the above output?  I take it the
> > difference lies in the gensym above -- this appears clearly wrong, and
> > indicates an error either in GCL's compilation of the function that
> > generates this source, or a mistake in one of the patches applied in
> > your tree.  Stephen, can you reproduce this?
> 
> My reading of the code does not suggest an error w.r.t the gensym.
> 
> Unfortunately this may have already been resolved were it not for
> another mistake on my part.  I gave a bug report which related to this
> issue but latter claimed it was a false alarm.  While collecting my
> changes last night I noticed that I had inadvertently merged a local
> work-around, thus masking the bug.
> 
> Many apologies for the confusion here.  Bellow follows the original
> report.  Have rerun the examples with latest gclcvs, with identical
> results.
> 
> 
> Sincerely,
> Steve
> 
> ==-----------------------
> 
> Hello Camm,
> 
> Another issue has come up, again w.r.t the handling of logical
> operations.
> 
> I hope these reports are not just pointing out known issues!  I only
> wish I had the knowledge to fix them myself.
> 
> 
> ==--- test.lisp ---
> 
> (defun test (x) 
>   (when (or (and (consp x) (eq (car x) 'X) t)
>             (and (consp x) (eq (car x) '|x|) t))
>     'OK))
> 
> ==-----------------
> 
> Note that if the T's are dropped from the AND expressions, the
> function behaves as expected.
> 
> 
> steve:tmp> gcl
> GCL (GNU Common Lisp)  2.7.0 ANSI    Jul  7 2007 19:13:09
> Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> 
> Temporary directory for compiler files set to /tmp/
> 
> >(compile-file "test.lisp")
> 
> ;; Compiling test.lisp.
> ;; End of Pass 1.  
> ;; End of Pass 2.  
> ;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
> ;; Finished compiling test.o.
> #P"/home/steve/tmp/test.o"
> NIL
> NIL
> 
> >(load "test.o")
> 
> ;; Loading test.o
>  ;; start address -T 0xb4acd8 ;; Finished loading test.o
> 80
> 
> >(test '(X))
> 
> OK
> 
> >(test '(|x|))
> 
> NIL
> 
> >(disassemble 'test)
> 
> ;; Compiling /tmp/gazonk_18523_0.lsp.
> ;; End of Pass 1.  
> ;; End of Pass 2.  
> ;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
> ;; Finished compiling /tmp/gazonk_18523_0.o.
> 
> #include "gazonk_18523_0.h"
> void init_code(){do_init((void *)VV);}
> /*      local entry for function TEST   */
> 
> static object LI1(V2)
> 
> object V2;
> {        VMB1 VMS1 VMV1
>         goto TTL;
> TTL:;
>         if(!(consp((V2)))){
>         goto T2;}
>         /*(CAR X)*/
>         {object V4;
>         V4= (V2);
>         V3= ((V4))->c.c_car;}
>         /* END (CAR X)*/
>         if(!((V3)==(((object)VV[0])))){
>         goto T2;}
>         {object V5 = ((object)VV[1]);VMR1
>         (V5);}
>         goto T2;
> T2:;
>         {object V6 = Cnil;VMR1
>         (V6);}
>         return Cnil;
> }
> #(#(X OK
>     (%INIT
>      . #((LET ((*DISABLE-RECOMPILE* T))
>            (MFSFUN 'TEST 0 1 0)
>            (ADD-HASH 'TEST '((T) SYMBOL)
>                '((CAR (LIST) T) (EQ (T T) BOOLEAN) (CONSP (T) T))
> COMMON-LISP-USER
> LISPLAMBDA!
>            ,DECLA,OPTIMIZ,SAFETY        ,BLOCK
>                                               TEST      ,IF     ,OR
> !,AN!,CONSP-    !,E!,CAR!,QUOTE-!,T
> /-      12
>           x,PROG2
>                  OK '/tmp/gazonk_18523_0.lsp))
>          (DO-RECOMPILE)))))
> static object LI1();
> #define VMB1 object  V3;
> #define VMS1
> #define VMV1
> #define VMR1(VMT1) return(VMT1);
> #define VM1 0
> static void * VVi[3]={
> #define Cdata VV[2]
> (void *)(LI1)
> };
> #define VV (VVi)
> 
> /tmp/gazonk_18523_0.o:     file format elf32-i386
> 
> Disassembly of section .text:
> 
> 00000000 <init_code>:
>    0:   68 00 00 00 00          push   $0x0
>    5:   e8 fc ff ff ff          call   6 <init_code+0x6>
>    a:   58                      pop    %eax
>    b:   c3                      ret    
> 
> 0000000c <LI1>:
>    c:   8b 54 24 04             mov    0x4(%esp),%edx
>   10:   81 fa 00 00 00 00       cmp    $0x0,%edx
>   16:   74 25                   je     3d <LI1+0x31>
>   18:   81 fa ff ff ff bf       cmp    $0xbfffffff,%edx
>   1e:   77 1d                   ja     3d <LI1+0x31>
>   20:   f6 02 01                testb  $0x1,(%edx)
>   23:   74 08                   je     2d <LI1+0x21>
>   25:   81 3a ff ff ff bf       cmpl   $0xbfffffff,(%edx)
>   2b:   76 10                   jbe    3d <LI1+0x31>
>   2d:   a1 00 00 00 00          mov    0x0,%eax
>   32:   39 42 04                cmp    %eax,0x4(%edx)
>   35:   75 06                   jne    3d <LI1+0x31>
>   37:   a1 04 00 00 00          mov    0x4,%eax
>   3c:   c3                      ret    
>   3d:   b8 00 00 00 00          mov    $0x0,%eax
>   42:   c3                      ret    
> NIL
> 
> >(defun test (x) 
>     (when (or (and (consp x) (eq (car x) 'X))
>               (and (consp x) (eq (car x) '|x|)))
>       'OK))
> 
> TEST
> 
> >(compile 'test)
> 
> ;; Compiling /tmp/gazonk_18523_0.lsp.
> ;; End of Pass 1.  
> ;; End of Pass 2.  
> ;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
> ;; Finished compiling /tmp/gazonk_18523_0.o.
> ;; Loading /tmp/gazonk_18523_0.o
>  ;; start address -T 0xb4bd68 ;; Finished loading /tmp/gazonk_18523_0.o
> #<compiled-function TEST>
> NIL
> NIL
> 
> >(test '(X))
> 
> OK
> 
> >(test '(|x|))
> 
> OK
> 
\start
Date: 12 Jul 2007 17:19:10 -0400
From: Stephen Wilson
To: William Sit
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

Dear William,

You never cease to amaze me with your keen insights!

I read your post over a few times, and I believe I have a grasp on the
issues.  I am sightly pressed for time, so Id like to just comment on a
few points for now.


William Sit writes:
[...]
> The above specification would enforce automatically the constraints
> Stephen thinks Spad is currently lacking (but documented, see
> hyperdoc on Union):

Just for clarity, it is not that I dont think Spad lacks a
specification in this regard.  Its the implementation I have concern
with.  For example, in Spad code Union(Integer,Integer) can be used as
a valid type (though the interpreter will recognize it as malformed if
the type is used in a declaration).  The tagged case has problems
too. Consider:

==--- union-test.spad ----

)abbrev domain BAR Bar

Bar() : Exp == Impl where
   Exp == with
     inj : Integer -> %
     inj : String -> %
     prj : % -> Integer
   Impl == add
     Rep := Union(tag1: Integer, tag1: String)
     inj (n : Integer) : % == [n]
     inj (s : String) : % == [s]
     prj p == (p::Rep).tag1

==----------------

                        AXIOM Computer Algebra System 
                          Version: Axiom (May 2007)
               Timestamp: Wednesday July 11, 2007 at 14:11:07 
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------

(1) -> )co union-test.spad
[...]
   Bar is now explicitly exposed in frame initial 
   Bar will be automatically loaded when needed from 
      /home/steve/development/axiom/spad-playpen/BAR.nrlib/code
(1) -> bi := inj 1
   Loading /home/steve/development/axiom/spad-playpen/BAR.nrlib/code 
      for domain Bar 

 LISP output:
(0 . 1)
                                                                    Type: Bar
(2) -> bs := inj ""

 LISP output:
(1 . )
                                                                    Type: Bar
(3) -> prj bi

   (3)  1
                                                        Type: PositiveInteger
(4) -> prj bs
 
   >> Error detected within library code:
   (1 . ) cannot be coerced to mode (Integer)

> Based on the notion of constructing IndexedUnion using an
> index set, I propose the following exports (there should be
> more if one compares this with IndexedAggregate or other
> Indexed* constructors, but for the purpose of this
> discussion, they are irrelevant):
> 
> IndexedUnion(I: SetCategory, g:I ->SetCategory):SetCategory
> == with
>       "=": (%, %) -> Boolean
>       index: % -> I
>          ++ index(x) returns the index i such that x belongs
> to g(i)
>       value(x:%): g(index(x))
>          ++ index(x) returns x as an element in g(index(x))
>       coerce(i:I, x:g(i)): %
>          ++ coerce(i,x) creates x as an element of % in the
> component g(i)

In fact, I believe that IndexedAggregate is very important here.  The
concept of IndexedUnion and the familiar notion of Dictionary are
exceedingly similar.  If were it not for the context, reading the
signature above would immediately make me think `hash table'.

> What about the data representation of Union? Can we do this
> at the algebra level? We seem to need non-homogeneous data
> representation! In lower level, this is not difficult, say
> using pointers (perhaps another reason why Union is
> implemented as primitive, to hide pointers at the algebra
> level), but at the algebra level, Axiom is not designed for
> heterogeneous objects (that's why people use C++):

Absolutely, the critical issue here is non-homogeneous data.  For Spad
to evolve into a truly flexible language capable of supporting the
constructs you have so very kindly detailed,  I believe that it would
be worth while to consider the `static typing where possible, dynamic
typing where necessary' approach to language design.


Again, many thanks for your detailed article!

\start
Date: Thu, 12 Jul 2007 16:23:44 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Unions in Spad

On Thu, 12 Jul 2007, Stephen Wilson wrote:

|                                               I believe that it would
| be worth while to consider the `static typing where possible, dynamic
| typing where necessary' approach to language design.

I think we all agree on that.  The issue -- a very tough isue -- is
to define "where necessary" in the context of dependent types.

\start
Date: 12 Jul 2007 18:14:28 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: Re: 2.7 build

Greetings!

Waldek Hebisch writes:

> )set break break
> )lisp (si::use-fast-links nil)
> )read "boo1.input"
> 
> and the segfault went away -- this stage finished without problems.
>  

OK, am trying to reproduce...

> In case of segfault I doubt that a small example is possible. 
> 

OK

> > 
> > For example, in the report below ...
> > 
> > > The second problem is that the function |ICformat| apparently is
> > > miscompiled, Lisp code differs only trivially from code in 2.6.8
> > > build.  In particular at the beggining we have:
> > > 
> > > (DEFUN |ICformat| (|u|)
> > >   (PROG (|v| |l'| |l1| |l|)
> > >     (RETURN
> > >       (SEQ (COND
> > >              ((ATOM |u|) |u|)
> > >              ((AND (PAIRP |u|) (EQ (QCAR |u|) '|has|))
> > >               (|compHasFormat| |u|))
> > >              ((OR (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
> > >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
> > >                   (AND (PAIRP |u|) (EQ (QCAR |u|) '|and|)
> > >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
> > >               (SPADLET |l|
> > >                        (REMDUP (PROG (#1=#:G7955)
> > 
> > I take it this source is generated by some other function in axiom
> > which is malfunctioning, (akin to the writing of #<compiled function
> > ...> in the generated lisp sources I reported earlier).  What is this
> > function?  How do I run it to produce the above output?  I take it the
> > difference lies in the gensym above -- this appears clearly wrong, and
> > indicates an error either in GCL's compilation of the function that
> > generates this source, or a mistake in one of the patches applied in
> > your tree.  Stephen, can you reproduce this?
> > 
> 
> Let me repeat:  I belive that the Lisp code above is correct.  This
> code is an output of depsys, which translates Boot to Common Lisp.
> The translator extenivly uses gensym-ed symbols, and AFAICS gensym-ed
> work fine.  In fact, what I am saying is: modulo names of gensym-ed
> symbols (which are irrelevant to the meaning) the Lisp code for this
> function produced during 2.7.0 build is identical to Lisp code from
> build using 2.6.8.

My apologies -- I misunderstood you to be saying that the trivial
difference was the cause of the failure.  And the gensym is OK given
the prog.

> 
> This function is contained in the file 'functor.boot.pamphlet' and
> is a part of the Spad compiler.  'functor.boot.pamphlet' is translated
> to Lisp giving 'functor.clip'.  'functor.clip' is compiled to
> 'functor.o'.  'functor.o' is used during Spad compilation.
> 'functor.o' produced by gcl-2.7.0 works incorrectly.
> 

Thank you -- am trying to see if the latest fix for Stephen fixes this
too. 

> > > 
> > > 
> > > however, the call:
> > > 
> > > (|ICformat| '(|and| |foo| |bar| |foo|))
> > > 
> > > in 2.7.0 falls to the end and signals error, while in 2.6.8 compiled
> > > Axiom it works OK.  It looks that Steve had similar problem (but later
> > > wrote that it works OK).
> > > 
> > 
> > I don't see how this is related to Stephen's earlier report regarding
> > logical expression evaluation -- am I missing something?  It appears
> > we have a printing problem in your tree somewhere.
> >
> 
> Well, I belive that the logical expression in the code above is
> evaluated incorrectly.  Basically, the |ICformat| performs a
> series of pattern matches and depending on the outcame chooses
> code to execute.  If no of the patterns matches |ICformat| signals
> error.  The input above should be matched by the expression:
> 
> > >              ((OR (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
> > >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
> > >                   (AND (PAIRP |u|) (EQ (QCAR |u|) '|and|)
> > >                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
> 

Looks very similar to his report now -- again my apologies.

> but apparently, the expression above compiled by 2.7.0 does not
> match (the code takes error branch).  I have modified by hand the
> Lisp file changing the expression above to:
> 
>              ((OR (AND (PAIRP |u|) (OR (EQ (QCAR |u|) 'AND) (EQ (QCAR |u|) '|and|) )
>                        (PROGN (SPADLET |l| (QCDR |u|)) 'T))
>                   (AND (PAIRP |u|) (EQ (QCAR |u|) 'AND)
>                        (PROGN (SPADLET |l| (QCDR |u|)) 'T)))
> 
> 
> Ater such change I was able to succesfully continue the build
> (currently I am running the test suite).
>  

Bet its gone now ...

> So, I belive that the expression above is miscompiled by gcl.  I will
> try to reduce problem to smaller example.
> 

No need.

> > > One extra remark: the extra PROG which I saw previously seem to be
> > > gone -- I am not sure if it is safety 3 or something in gcl changed.
> > > But now I see:
> > > 
> > > (DEFUN |ALIST;dictionary;$;1| ($) (SPADCALL NIL (QREFELT $ 11)))
> > > 
> > > (the same as in other dialects), while earlier 2.7 gave me:
> > > 
> > > (DEFUN |ALIST;dictionary;$;1| ($)
> > >   (PROG () (RETURN (SPADCALL NIL (QREFELT $ 11)))))
> > > 
> > 
> > These are equivalent in lisp, but it still indicates some instability
> > in the axiom code generator.  There is nothing in GCL  that I can see
> > at the moment that would automatically make this conversion.
> >
> 
> Axiom tries to "optimize" generated Lisp code -- removal of PROG is
> almost surely one of such optimizations.  However, Axiom makes various
> unportable assumptions, and probably one of this assumptions is
> (was) broken by the new gcl.
> 
> > Please let me know if my suggestions above are unworkable.
> > 
> > BTW, am assuming we are still working with the source produced by svn
> > update in wh-sandbox as modified by the patches your posted.  If the
> > source tree is different, a complete set of instructions describing
> > how to reproduce this would be most helpful.
> > 
> 
> I am working with the same tree as my first trial at gcl-2.7 build, namely
> revision 636 of wh-sandbox + the patch that I posted.  If you did update
> you probably got revision 646 which is slightly different.
> 

OK, I've reverted exactly to this source for testing.  How are you
testing at safety 3 -- with an initial declaim in saved_ansi_gcl?

\start
Date: 12 Jul 2007 18:20:49 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: re: debugging

Greetings!  Again, I get

--->-->PlaneAlgebraicCurvePlot(constructor): Unexpected HT command: \indented
"\\indented{1}{Plot a NON-SINGULAR plane algebraic curve \\spad{p}(\\spad{x},{}\\spad{y}) = 0.} Author: Clifton \\spad{J}. Williamson Date Created: Fall 1988 Date Last Updated: 27 April 1990 Keywords: algebraic curve,{} non-singular,{} plot Examples: References:"

Error: 
Signalled by COMPILER::COMPILE-FILE1.
INTERNAL-SIMPLE-READER-ERROR: Stream error on stream #<input stream "ACPLOT.NRLIB/ACPLOT.lsp">: The default dispatch macro signalled an error.

Broken at COMPILER::COMPILE-FILE1.  Type :H for Help.
 1 (Continue) Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
 2 Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
 3 Return to top level.
BOOT>>
cat ACPLOT.NRLIB/ACPLOT.lsp

(/VERSIONCHECK 2) 

(DEFUN |ACPLOT;NFtoSF| (|x| $)
  (PROG ()
    (RETURN
      (+ '#1=#((|DoubleFloat|)
               (#<compiled-function |lookupComplete|> #1#
                #(~= 231 |zero?| 237 |wholePart| 242 |unitNormal| 247
...

Is this the same issue as you are reporting (or related)?

\start
Date: Thu, 12 Jul 2007 19:47:58 -0400
From: William Sit
To: Stephen Wilson
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

Stephen Wilson wrote:

> You never cease to amaze me with your keen insights!

Thanks. Unfortunately, in Axiom, I have found that the simpler things
look, the more difficult it is to analyse. (This is one reason I find
literate programming impossible to achieve. If we are still having
problems understanding the simplest domain constructions, how can we
ever document the cutting edge algebra domains?)

> I read your post over a few times ...

Sorry, I'll try to write clearer next time around. (Clearly, it is
difficult to write ...).

> William Sit writes:
> [...]
> > The above specification would enforce automatically the constraints
> > Stephen thinks Spad is currently lacking (but documented, see
> > hyperdoc on Union):
>
> Just for clarity, it is not that I dont think Spad lacks a
> specification in this regard.  Its the implementation I have concern
> with.  For example, in Spad code Union(Integer,Integer) can be used as
> a valid type (though the interpreter will recognize it as malformed if
> the type is used in a declaration).  The tagged case has problems
> too.

Yes, I understand that. In my lines above, "lacking" refers to lacking
"enforce ... constraints" (not "documented"). Poor sentence construct,
sorry.

> Consider:
>
> ==--- union-test.spad ----
>
> )abbrev domain BAR Bar
>
> Bar() : Exp == Impl where
>    Exp == with
>      inj : Integer -> %
>      inj : String -> %
>      prj : % -> Integer
>    Impl == add
>      Rep := Union(tag1: Integer, tag1: String)
>      inj (n : Integer) : % == [n]
>      inj (s : String) : % == [s]
>      prj p == (p::Rep).tag1
>
> ==----------------

Yes, the compiler did not enforce what was specified in the hyperdoc
specification ("In this tagged Union, tags a, ..., b must be
distinct.") But there are lots of other things the compiler would not
enforce for various reasons (such as "Commutative" and other
attributes). In this case, probably no Axiom programmer would use the
same tag for two distinct fields (I won't even use the same identifier
outside of Union Rep even though I should be able to).  In mathematics
articles, I would be equally careful not to use the same symbol for
different quantities, even if it were just a dummy index. (I modified
the notations in my previous email several times for this reason.)

>                         AXIOM Computer Algebra System
>                           Version: Axiom (May 2007)
>                Timestamp: Wednesday July 11, 2007 at 14:11:07
> -----------------------------------------------------------------------------
>    Issue )copyright to view copyright notices.
>    Issue )summary for a summary of useful system commands.
>    Issue )quit to leave AXIOM and return to shell.
> -----------------------------------------------------------------------------
>
> (1) -> )co union-test.spad
> [...]
>    Bar is now explicitly exposed in frame initial
>    Bar will be automatically loaded when needed from
>       /home/steve/development/axiom/spad-playpen/BAR.nrlib/code
> (1) -> bi := inj 1
>    Loading /home/steve/development/axiom/spad-playpen/BAR.nrlib/code
>       for domain Bar
>
>  LISP output:
> (0 . 1)
>                                                                     Type: Bar
> (2) -> bs := inj ""
>
>  LISP output:
> (1 . )
>                                                                     Type: Bar
> (3) -> prj bi
>
>    (3)  1
>                                                         Type: PositiveInteger
> (4) -> prj bs
>
>    >> Error detected within library code:
>    (1 . ) cannot be coerced to mode (Integer)

 The problem is the interpreter looks up the signature of prj and finds (only)
one whose target is Integer. This is all as it should be. However, this run time
error may not show up if both fields are Integer.

Try this:  testu2.spad
-------
)abbrev domain BAR Bar

Bar() : Exp == Impl where
   Exp == with
     inj1 : Integer -> %
     inj2 : Integer -> %
     prj : % -> Integer
   Impl == add
     Rep := Union(tag1: Integer, tag2: Integer)
     inj1 (n : Integer) : % == [n]
     inj2 (s : Integer) : % == [2*s]
     prj p == (p::Rep).tag1
-------
After compiling,

(4) -> i1:= inj1 1

 LISP output:
(0 . 1)
                                                                    Type: Bar
(5) -> i2:= inj2 1

 LISP output:
(0 . 2)
                                                                    Type: Bar
(6) -> prj i1

   (6)  1
                                                        Type: PositiveInteger
(7) -> prj i2

   (7)  2
                                                        Type: PositiveInteger

Note the answer is even *correct*! Axiom should have signaled a
failure or error.  This is most likely due to internal
*implementation* of Rep and i2::Rep should not be allowed to apply to
tag1. But EVEN IF it is using tag1, how on earth did it get the value
2? The problem is that in inj2, there is no indication that the value
should be placed into the tag2 field! (but neither is there an
indication to place it into tag1 field. Axiom simply gives it to the
first one! If correct indexing is done and kept, this would not have
happened or allowed. Instead of the two inj1 and inj2, I would use
coerce(0, 1) and coerce(1, 1), (assuming index set is IntegerMod(2)),
and to retrieve the values , I would simply use value(p) as in my
proposal, and there would be no problem. Note that my proposed Rep is
also more efficient than the current Rep (which seems to reserve space
for ALL possible domain values and tags, but did not keep the indexing
information) when all you need is just space for ONE domain value and
its index, per Record.

Unfortunately, for the current Union implementation, there seems to be
no way to tell even which domain the underlying value of p belongs, so
that one cannot distinguish the two cases to implement prj correctly
(even if the tags and domains are all distinct). The current "case"
requires one to know beforehand the value (without any indication of
the index of the domain) to test against, as in (p case 1) or (p case
""). It is designed to be more like a "switch" than to give you
information on the element. So I think it is a design flaw in
Union. That is why my proposed exports in IndexedUnion does not use
"case" at all. Rather, it is simpler to tell the index and value of a
member in a disjoint union.  (By the way, the idea of "disjoint union"
is precisely to allow the same value to wear two or more hats.)

> > Based on the notion of constructing IndexedUnion using an
> > index set, I propose the following exports (there should be
> > more if one compares this with IndexedAggregate or other
> > Indexed* constructors, but for the purpose of this
> > discussion, they are irrelevant):
> >
> > IndexedUnion(I: SetCategory, g:I ->SetCategory):SetCategory
> > == with
> >       "=": (%, %) -> Boolean
> >       index: % -> I
> >          ++ index(x) returns the index i such that x belongs
> > to g(i)
> >       value(x:%): g(index(x))
> >          ++ index(x) returns x as an element in g(index(x))
> >       coerce(i:I, x:g(i)): %
> >          ++ coerce(i,x) creates x as an element of % in the
> > component g(i)
>
> In fact, I believe that IndexedAggregate is very important here.  The
> concept of IndexedUnion and the familiar notion of Dictionary are
> exceedingly similar.  If were it not for the context, reading the
> signature above would immediately make me think `hash table'.

That would be another discussion altogether. For now, I believe there
is no need for hashing in the implementation of IndexedUnion. If I
understanding this correctly, hashing involves placing items in a
fixed prealloted space by computing the address of storage from the
content (or key) of the stored item.  Here we don't have such a
situation, unless lists of IndexedUnion objects are involved (which is
where Aggregate comes in).

> > What about the data representation of Union? Can we do this
> > at the algebra level? We seem to need non-homogeneous data
> > representation! In lower level, this is not difficult, say
> > using pointers (perhaps another reason why Union is
> > implemented as primitive, to hide pointers at the algebra
> > level), but at the algebra level, Axiom is not designed for
> > heterogeneous objects (that's why people use C++):
>
> Absolutely, the critical issue here is non-homogeneous data.  For Spad
> to evolve into a truly flexible language capable of supporting the
> constructs you have so very kindly detailed,  I believe that it would
> be worth while to consider the `static typing where possible, dynamic
> typing where necessary' approach to language design.

Do you recall we had a fairly long discussion on dependent types?

http://wiki.axiom-developer.org/18AxiomDomainsAndAldorReturnTypes

I believe I figured out a way to code it in current Axiom, but not
that naturally. The idea is to use package or domain constructors,
because these clearly allow dependent types. I need to review that to
see if it can be applied to IndexedUnion. I have a feeling it is not
possible because Record cannot be coerced at the algebra level to take
heterogeneous objects. So if you can hack Record into doing that, we
can probably implement the exported functions somehow.  Certainly, if
Record remains primitive, then all the exported functions I proposed
can be easily implemented. (Functions implemented in primitive domain
such as "case" do not show up in ")di op case" or ")show Union" (but
they show up in hyperdoc)).

\start
Date: 12 Jul 2007 19:28:36 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Literate Programming

Tim Daly writes:

[...]

| Literate Haskell style is supported by typical Haskell environments. 
| In this approach, the code-comment relation is reversed. Normally the 
| code has primacy, and the comments are introduced by a special syntax, 
| as if in afterthought. In the literate approach, the comments are 
| primary.  By default, text is comment; the code must be introduced by 
| a special notation stating that it is code.

Anyone talking about Literate Haskell should *actually* try to 
see how it is practiced on large scale Haskell programs.  I had had
direct conversations with Simon Peyton Jones (and Simon Marlow) about
GHC -- probably the largest Haskell program -- its literate
documentation (almost two years ago) and its documentation no later
than a month ago at HOPL-III).

\start
Date: 12 Jul 2007 21:21:17 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: Literate Programming

Just soliciting opinions -- would well documented GCL
1) carry function documentation strings around in the image accessible via describe
2) have info pages searchable by describe
3) have lisp comments in the source
4) be written in pamphlets

How to integrate with the lisp functions apropos, documentation, etc.?

\start
Date: 12 Jul 2007 21:42:32 -0400
From: Stephen Wilson
To: William Sit
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

William Sit writes:

> Stephen Wilson wrote:
> 
> > You never cease to amaze me with your keen insights!
 
> Thanks. Unfortunately, in Axiom, I have found that the simpler
> things look, the more difficult it is to analyse. (This is one
> reason I find literate programming impossible to achieve. If we are
> still having problems understanding the simplest domain
> constructions, how can we ever document the cutting edge algebra
> domains?)

I agree that the challenge is great.  Perhaps if we can get an
IndexedUnion implemented we can work together to get some good
documentation together?  You are far more capable of writing for the
mathematically inclined reader, and I would hope to be able to
contribute some pieces perhaps more natural from a programmers
perspective.  Undoubtedly others can contribute to the process.

Many hands make light work, after all! :)

> > I read your post over a few times ...
 
> Sorry, I'll try to write clearer next time around. (Clearly, it is
> difficult to write ...).

Oh no, your writing was quite clear.  I am a slow learner, and it can
take me quite some time to digest things.

> > William Sit writes:
> > [...]
> > > The above specification would enforce automatically the constraints
> > > Stephen thinks Spad is currently lacking (but documented, see
> > > hyperdoc on Union):
> >
> > Just for clarity, it is not that I dont think Spad lacks a
> > specification in this regard.  Its the implementation I have concern
> > with.  For example, in Spad code Union(Integer,Integer) can be used as
> > a valid type (though the interpreter will recognize it as malformed if
> > the type is used in a declaration).  The tagged case has problems
> > too.
 
> Yes, I understand that. In my lines above, "lacking" refers to
> lacking "enforce ... constraints" (not "documented"). Poor sentence
> construct, sorry.
 
> > Consider:
> >
> > ==--- union-test.spad ----
> >
> > )abbrev domain BAR Bar
> >
> > Bar() : Exp == Impl where
> >    Exp == with
> >      inj : Integer -> %
> >      inj : String -> %
> >      prj : % -> Integer
> >    Impl == add
> >      Rep := Union(tag1: Integer, tag1: String)
> >      inj (n : Integer) : % == [n]
> >      inj (s : String) : % == [s]
> >      prj p == (p::Rep).tag1
> >
> > ==----------------
 
> Yes, the compiler did not enforce what was specified in the hyperdoc
> specification ("In this tagged Union, tags a, ..., b must be
> distinct.") But there are lots of other things the compiler would
> not enforce for various reasons (such as "Commutative" and other
> attributes). In this case, probably no Axiom programmer would use
> the same tag for two distinct fields (I won't even use the same
> identifier outside of Union Rep even though I should be able to).
> In mathematics articles, I would be equally careful not to use the
> same symbol for different quantities, even if it were just a dummy
> index. (I modified the notations in my previous email several times
> for this reason.)

Absolutely, and I understand your careful methods.  On the other hand,
I would like one day for the Spad compiler to be feed utter garbage
and still cope with the input gracefully.

[...]
> Try this:  testu2.spad
> -------
> )abbrev domain BAR Bar
> 
> Bar() : Exp == Impl where
>    Exp == with
>      inj1 : Integer -> %
>      inj2 : Integer -> %
>      prj : % -> Integer
>    Impl == add
>      Rep := Union(tag1: Integer, tag2: Integer)
>      inj1 (n : Integer) : % == [n]
>      inj2 (s : Integer) : % == [2*s]
>      prj p == (p::Rep).tag1
> -------
> After compiling,
> 
> (4) -> i1:= inj1 1
> 
>  LISP output:
> (0 . 1)
>                                                                     Type: Bar
> (5) -> i2:= inj2 1
> 
>  LISP output:
> (0 . 2)
>                                                                     Type: Bar
> (6) -> prj i1
> 
>    (6)  1
>                                                         Type: PositiveInteger
> (7) -> prj i2
> 
>    (7)  2
>                                                         Type: PositiveInteger
> 

> Note the answer is even *correct*! Axiom should have signaled a
> failure or error.  This is most likely due to internal
> *implementation* of Rep and i2::Rep should not be allowed to apply
> to tag1. But EVEN IF it is using tag1, how on earth did it get the
> value 2?  The problem is that in inj2, there is no indication that
> the value should be placed into the tag2 field! (but neither is
> there an indication to place it into tag1 field. Axiom simply gives
> it to the first one! If correct indexing is done and kept, this
> would not have happened or allowed. Instead of the two inj1 and
> inj2, I would use coerce(0, 1) and coerce(1, 1), (assuming index set
> is IntegerMod(2)), and to retrieve the values , I would simply use
> value(p) as in my proposal, and there would be no problem. Note that
> my proposed Rep is also more efficient than the current Rep (which
> seems to reserve space for ALL possible domain values and tags, but
> did not keep the indexing information) when all you need is just
> space for ONE domain value and its index, per Record.

The Lisp output you are seeing is actually the underlying
representation which, if I understand correctly, is equivalent to the
representation based on Record.

The representation is a dotted pair, a cons cell, where the first
element is an integer index denoting the valid branch, and the second
yielding the raw data representing the value therein.

So you can see from your example that i1 and i2 give, respectively, 
(0 . 1) and (0 . 2), thus inj1 and inj2 are placing their values in
the tag1 field.

> Unfortunately, for the current Union implementation, there seems to
> be no way to tell even which domain the underlying value of p
> belongs, so that one cannot distinguish the two cases to implement
> prj correctly (even if the tags and domains are all distinct). The
> current "case" requires one to know beforehand the value (without
> any indication of the index of the domain) to test against, as in (p
> case 1) or (p case ""). It is designed to be more like a "switch"
> than to give you information on the element. So I think it is a
> design flaw in Union. That is why my proposed exports in
> IndexedUnion does not use "case" at all. Rather, it is simpler to
> tell the index and value of a member in a disjoint union.  (By the
> way, the idea of "disjoint union" is precisely to allow the same
> value to wear two or more hats.)

Yes, the issues involved here have come up in various other `thought
experiments' of my own in an attempt to figure how Spad could be made
more reflexive/introspective.  One problem is that the raw
representation of the values do not carry type information.  So
instead of (0 . 1) as representation for a Union element we really
need something like (0 (|Integer|) 1).  But this is a simplification.
Ideally (I think), domain elements should carry a header which gives
this information.  However, it may not be necessary to always carry
this extra baggage.  Homogeneous lists/vectors, polynomials, for
example, could store the information once rather than repeat it in all
its terms.

There may even be ways to classify a domain as `rich' enough to
warrant if such a representation of its elements is necessary at all.
 
> > > Based on the notion of constructing IndexedUnion using an
> > > index set, I propose the following exports (there should be
> > > more if one compares this with IndexedAggregate or other
> > > Indexed* constructors, but for the purpose of this
> > > discussion, they are irrelevant):
> > >
> > > IndexedUnion(I: SetCategory, g:I ->SetCategory):SetCategory
> > > == with
> > >       "=": (%, %) -> Boolean
> > >       index: % -> I
> > >          ++ index(x) returns the index i such that x belongs
> > > to g(i)
> > >       value(x:%): g(index(x))
> > >          ++ index(x) returns x as an element in g(index(x))
> > >       coerce(i:I, x:g(i)): %
> > >          ++ coerce(i,x) creates x as an element of % in the
> > > component g(i)
> >
> > In fact, I believe that IndexedAggregate is very important here.  The
> > concept of IndexedUnion and the familiar notion of Dictionary are
> > exceedingly similar.  If were it not for the context, reading the
> > signature above would immediately make me think `hash table'.
 
> That would be another discussion altogether. For now, I believe
> there is no need for hashing in the implementation of
> IndexedUnion. If I understanding this correctly, hashing involves
> placing items in a fixed prealloted space by computing the address
> of storage from the content (or key) of the stored item.  Here we
> don't have such a situation, unless lists of IndexedUnion objects
> are involved (which is where Aggregate comes in).

Its not so much the representation that I was driving at (sorry for
the ambiguity!).  If one thought of `index' as a function which
returns the last element added to a table, `I' your set of keys, and
`g' a hash function, then you basically get an interface compatible with
the semantics of IndexedUnion.  So I can think of IndexedUnion as a
`dictionary of types', plus the ability to associate a single value
with a given {key, type} pair.  However, this analogy may not turn out
to be terribly useful in practice -- I just couldnt help seeing the
connection.

[...]
> > > What about the data representation of Union? Can we do this
> > > at the algebra level? We seem to need non-homogeneous data
> > > representation! In lower level, this is not difficult, say
> > > using pointers (perhaps another reason why Union is
> > > implemented as primitive, to hide pointers at the algebra
> > > level), but at the algebra level, Axiom is not designed for
> > > heterogeneous objects (that's why people use C++):
> >
> > Absolutely, the critical issue here is non-homogeneous data.  For Spad
> > to evolve into a truly flexible language capable of supporting the
> > constructs you have so very kindly detailed,  I believe that it would
> > be worth while to consider the `static typing where possible, dynamic
> > typing where necessary' approach to language design.
> 
> Do you recall we had a fairly long discussion on dependent types?
> 
> http://wiki.axiom-developer.org/18AxiomDomainsAndAldorReturnTypes

Absolutely I do.  In fact, I have reread that exchange several times
over the past few years, as I have been thinking about the issues
involved regularly since that time (as I said, I am a slow learner :).

> I believe I figured out a way to code it in current Axiom, but not
> that naturally. The idea is to use package or domain constructors,
> because these clearly allow dependent types. I need to review that
> to see if it can be applied to IndexedUnion. I have a feeling it is
> not possible because Record cannot be coerced at the algebra level
> to take heterogeneous objects. So if you can hack Record into doing
> that, we can probably implement the exported functions somehow.
> Certainly, if Record remains primitive, then all the exported
> functions I proposed can be easily implemented. (Functions
> implemented in primitive domain such as "case" do not show up in
> ")di op case" or ")show Union" (but they show up in hyperdoc)).

It would be possible today to do this by calling out to Lisp and
carefully choosing a representation there.  I believe that would be
entirely equivalent to getting a `hacked' record available which suits
your purpose.  Just view Lisp as a supply if infinitely many
`primitive types' to get past the aversion of punting Spads type
system.  This would have practical benefits as we could then
understand better what it would take to implement a more graceful
solution.  I and Im sure others would be more than willing to help
choose a Lisp representation and implement any necessary machinery, as
I understand you are not fluent in the language (many apologies in
advance if that is not accurate!).

\start
Date: Thu, 12 Jul 2007 21:29:00 -0500
From: Tim Daly
To: list
Subject: Literate Programming

In investigating the use of LP in Haskell I came across this example:
<http://www.ninebynine.org/Software/HaskellDL/DLExploration.lhs>

This is interesting from a few perspectives. First, it shows a working
example of a literate haskell (LHS) file. I notice that the LHS style
is very similar to what you'd find in a math textbook (if you skip
printing the > signs and used a different print font). Thus the code
appears to be surrounded by context explanations, just as equations
are surrounded in a math textbook.

Second, it appears that LHS files do not have chunks. At least I could
not find an example of chunking. I'm not a haskell programmer but I
suspect that there is a requirement for code placement order in
haskell.  Do the "module" and "import" statments have to come first?
If so, chunking would be useful because you could move these away to
the very end and explain them in the implementation details.

Third, this is interesting as a knowledge representation program,
something that will be important to the crystal work later. He
mentions the ideas of Satisfiability, Subsumption, Equivalence, and
Disjointness.  All of these can be expressed as subsumption, which is
the basis of the work I knew at IBM (KREP, KROPS). Although I authored
a language (KROPS) that depended on knowledge representation I doubt I
could have decoded his haskell implementation without the documentation.

Fourth, he has included test cases along with their explanations.

Fifth, from the couple dozen other examples of LHS I've seen there
are people who have built "native latex" tools (ala Cliff's ASDF work
for lisp). See 
<http://www.jantar.org/lambdaTeX>. 
(He apparently wrote the whole tool in TeX. Amazing.) 
You can see the result at
<http://www.jantar.org/lambdaTeX/Example.pdf>

There is also a lhs2TeX (i.e. "noweave") program at
<http://www.informatik.uni-bonn.de/~loeh/lhs2tex> 
and an emacs mode at
<http://www.fh-wedel.de/~di/html/unix/.emacs.herbert>



As someone who is "skilled in the art" (like a mathematician can be
skilled in the art of reading and understanding math books) I can read
and follow the knowledge representation code even though I don't
read or write haskell. In fact, I find that I can "read" the haskell
code once I've read the explanations, although I'm not able to parse
it for things like syntax errors.

I've heard the comment that haskell code is somewhat similar to spad
code which leads me to put this pamphlet "on the shelf" so I can refer
to it when the crystal work begins. A spad version of this work would
be very interesting. We could begin to talk about what Axiom "knows"
and it can infer things, as you'd expect from a knowledged-based system.
>From this I can conclude that the literate form of the haskell work is
much more valuable than raw code.



This recent paper by Martin Grabm\"uller ``Monad Transformers Step by Step''
<http://uebb.cs.tu-berlin.de/~magr/pub/Transformers.lhs> (source)
<http://uebb.cs.tu-berlin.de/~magr/pub/Transformers.pdf> (pdf)
is a beautifully done example of a paper using literate latex with 
executable haskell code embedded. It seems clear that this paper could
easily be "drag-and-dropped" onto a running sytem. This is the kind of
thing we can do in Axiom, especially using Cliff's asdf/cl-web work.



Given all of this existing work in the haskell community (google shows
literate haskell 456k hits, 529k for literate lisp, 2.24M for literate C)
I don't see that Axiom is breaking any new ground.

\start
Date: Thu, 12 Jul 2007 22:03:55 -0500
From: Tim Daly
To: Camm Maguire
Subject: Literate Programming

> Just soliciting opinions -- would well documented GCL
> 1) carry function documentation strings around in the image 
>    accessible via describe
> 2) have info pages searchable by describe
> 3) have lisp comments in the source
> 4) be written in pamphlet

Yes, to all of the above, although you might have guessed that :-)

> How to integrate with the lisp functions apropos, documentation, etc.?

It might be worthwhile to put URL references in the lisp documentation
strings rather than have the documentation directly in the in-core
string. That way you could describe a function and then follow a
link. For most functions you could probably just link to the
hyperspec URL.  Or, alternatively you could put info link information
there so people using emacs can just go to the info link. You already
have the .info files.

It appears to me that there is a subtle "mindset" that leads you to write
> 3) have lisp comments in the source
> 4) be written in pamphlet
as though these were somehow unrelated. The "literate" view is a shift
from "be written in pamphlets" to "pamphlets written for humans with
embedded lisp". Perhaps that's what you meant by (4) and I missed it.

If you look at "Lisp in Small Pieces" you'll see an example of what
I'd consider the ideal version of GCL documentation. One way to 
approach such an effort would be to do individual pamphlets that
explain the sgc garbage collection algorithm, for example, and then
another explaining tail recursion, C library relocation, etc. If these
get written while you're working on sections of code rather than as a
huge "lump" of documentation the task can be done in manageable chunks
(pun intended). 

Individual user-level functions can be documented by many different
people (in theory) because all that would be required is to paraphrase
the standard and explain any GCL-specific details.

\start
Date: 12 Jul 2007 23:56:13 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Literate Programming

Hello,

I would like to add a few comments:

First, pamphlet files as we use them in the Axiom project, from my
understanding, are subject to possibly radical change.  So even though
I have enthusiasm for the pamphlet concept, I have reservations about
promoting the format for use by other projects -- under the assumption
that a pamphlet file is somehow tied to Axiom and its literate goals.
Of course, that does not preclude the use of a literate document type
for GCL.

Second, the general audience for GCL of course needs to be considered.
I like the idea of embedding a URL into a docstring, as it might be
integrable with Slime or some other development environment in a very
useful way.  IIRC, the ANSI spec gives the implementation a lot of
freedom regarding how docstrings are handled.

I have given only brief thought to what my `ideal' literate
environment might be for the specific task of writing Lisp code.  A
language specific tool offers the possibility of tailoring not only
the typesetting of the source code, but also the possibility of
`weaving' selected components of the literature into a doc string.
Within Lisp and an IDE, one might be able to envision many
interactions between the document on the one hand, and cross
referencing via embedded URLS in doc strings, appropos, who-calls,
etc.

So I guess there might be two notions involved here.  Documenting GCL
the Program, and allowing GCL to function as a member of a powerful
Lisp based literate programming tool chain.


\start
Date: Fri, 13 Jul 2007 00:13:52 -0400
From: William Sit
To: Stephen Wilson
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

Stephen Wilson wrote:

> I agree that the challenge is great.  Perhaps if we can get an
> IndexedUnion implemented we can work together to get some good
> documentation together?  You are far more capable of writing for the
> mathematically inclined reader, and I would hope to be able to
> contribute some pieces perhaps more natural from a programmers
> perspective.  Undoubtedly others can contribute to the process.
>
> Many hands make light work, after all! :)

Okay. Let's make that a near-term goal. How about starting a sandbox
page for this "pamphlet" (I'll even to agree to try this format by
inserting the documentation if you start the skeleton). Then anyone
can add to it as they see fit. If you agree (at least for now) with
what I propose as a possible implementation model, I can adapt that
email into the pamplet.

> Absolutely, and I understand your careful methods.  On the other hand,
> I would like one day for the Spad compiler to be feed utter garbage
> and still cope with the input gracefully.

I think that would be great (but a very difficult goal to achieve)!
Perhaps one can set different optimization levels using )set commands
on the fly, especially with compiling Axiom source. I guess that is
already available, but I just don't know how.

> The Lisp output you are seeing is actually the underlying
> representation which, if I understand correctly, is equivalent to the
> representation based on Record.
>
> The representation is a dotted pair, a cons cell, where the first
> element is an integer index denoting the valid branch, and the second
> yielding the raw data representing the value therein.
>
> So you can see from your example that i1 and i2 give, respectively,
> (0 . 1) and (0 . 2), thus inj1 and inj2 are placing their values in
> the tag1 field.

This simple representation limits the generality and naturalness of
implementation. But where are the tags? Are they in some symbol table
where (0.1) and (1.2) would be their values? I think the tags (at
least according to the examples I gave) should be used as the index or
part of the index set, and the index set should not be limited to the
natural integers (of course, if the index set is ordered, one can put
it into a bijection with 0.. n or 0.. , but that requires something
else to store the bijection; if the index set is not ordered, then
some hashing function would be needed). In mathematics, we let the
index set to be quite arbitrary, and often a set of other mathematical
objects. So for example, the disjoint union of all prime fields would
require an index set that is the set of primes.

Subject to a hashing of the index set into an initial segment or the
entire set of the natural numbers, I think the data representation
using a pair (a . b) is fine and efficient. But this cannot be the
same as Record, because in a Record, you need to store all the data
fields for each record. In Union, you only need only to store one.
The design flaw in Union is the exported functions currently do not
allow branch specification, even though the lisp representation is
"indexed" (but without type info, according to you, below). So there
is no way to even coerce (the provided function in Union) an element
correctly if the domains AND the tags are not distinct. And there is
no way to discover the index of an element in the union in that case.

> > Unfortunately, for the current Union implementation, there seems
> > to be no way to tell even which domain the underlying value of p
> > belongs, so that one cannot distinguish the two cases to implement
> > prj correctly (even if the tags and domains are all distinct). The
> > current "case" requires one to know beforehand the value (without
> > any indication of the index of the domain) to test against, as in
> > (p case 1) or (p case ""). It is designed to be more like a
> > "switch" than to give you information on the element. So I think
> > it is a design flaw in Union. That is why my proposed exports in
> > IndexedUnion does not use "case" at all. Rather, it is simpler to
> > tell the index and value of a member in a disjoint union.  (By the
> > way, the idea of "disjoint union" is precisely to allow the same
> > value to wear two or more hats.)

> Yes, the issues involved here have come up in various other `thought
> experiments' of my own in an attempt to figure how Spad could be made
> more reflexive/introspective.  One problem is that the raw
> representation of the values do not carry type information.  So
> instead of (0 . 1) as representation for a Union element we really
> need something like (0 (|Integer|) 1).  But this is a simplification.
> Ideally (I think), domain elements should carry a header which gives
> this information.  However, it may not be necessary to always carry
> this extra baggage.  Homogeneous lists/vectors, polynomials, for
> example, could store the information once rather than repeat it in all
> its terms.
>
> There may even be ways to classify a domain as `rich' enough to
> warrant if such a representation of its elements is necessary at all.

Surely, there should be ways to avoid redundant or unnecessary
baggage. But somewhere, the type information is kept, perhaps by the
interpreter, with each identifier. For compiled code, there should be
less baggage. According to your explanation, I think the pair
representation is sufficient to implement IndexedUnion as a
primitive. Note that at the algebra level, it is not feasible to use
Union as Rep because of the design flaw.

> > Do you recall we had a fairly long discussion on dependent types?

> > http://wiki.axiom-developer.org/18AxiomDomainsAndAldorReturnTypes

> Absolutely I do.  In fact, I have reread that exchange several times
> over the past few years, as I have been thinking about the issues
> involved regularly since that time (as I said, I am a slow learner :).

> > I believe I figured out a way to code it in current Axiom, but not
> > that naturally. The idea is to use package or domain constructors,
> > because these clearly allow dependent types. I need to review that
> > to see if it can be applied to IndexedUnion. I have a feeling it
> > is not possible because Record cannot be coerced at the algebra
> > level to take heterogeneous objects. So if you can hack Record
> > into doing that, we can probably implement the exported functions
> > somehow.  Certainly, if Record remains primitive, then all the
> > exported functions I proposed can be easily
> > implemented. (Functions implemented in primitive domain such as
> > "case" do not show up in ")di op case" or ")show Union" (but they
> > show up in hyperdoc)).

> It would be possible today to do this by calling out to Lisp and
> carefully choosing a representation there.  I believe that would be
> entirely equivalent to getting a `hacked' record available which suits
> your purpose.  Just view Lisp as a supply if infinitely many
> `primitive types' to get past the aversion of punting Spads type
> system.  This would have practical benefits as we could then
> understand better what it would take to implement a more graceful
> solution.  I and Im sure others would be more than willing to help
> choose a Lisp representation and implement any necessary machinery, as
> I understand you are not fluent in the language (many apologies in
> advance if that is not accurate!).

"Not fluent" is giving me more credit than I deserve! I am certainly
all thumbs when it comes to lisp and I marvel at you, Tim, Gaby,
Waldek and Camm making exchanges (mostly "gibberish" to me) but
understanding one another so easily. (I think if I were to spend time
learning this, I certainly would need literate programming on the
level Tim is advocating! But my objection is that I should NOT be
involved in this "mess" because I am not qualified.)

In the proposed IndexedUnion, what is missing is the Rep:=
Record[index:I, value: g(i)]. The key is to implement "coerce" since
that creates elements of the domain IndexedUnion, and most likely
requires the use of a hash function, especially when the index set is
infinite.  It should be possible to implement in lisp all the four
functions ("=", index, value, coerce) and others like outputForm. This
way, we do not have to worry about the "signatures" of "value" having
dependent types. It would be more involved to do so at the algebra
level and the implementation would not be natural.  As an experiment,
rather than modifying Record, perhaps we can create IndexedUnion as a
primitive type directly (from scratch).

Whatever the primitive types are, the important thing is that there be
a well-designed user interface (exported functions) on par with all
other algebra code. Right now, Tuple and Union are "inaccessible" from
the algebra layer without going to lisp (Record seems okay ). That is,
in my view, a design flaw. They should be designed as if they were
genuine domains (where one can construct elements and extract
information from elements and compute with them). How they are
implemented and optimized at the lower levels should not be of concern
to the algebra layer.

\start
Date: 13 Jul 2007 01:18:14 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Literate Programming

Tim Daly writes:

| Second, it appears that LHS files do not have chunks.

There is no chunks in LHS.


|        .  Do the "module" and "import" statments have to come first?

Yes -- see the Haskell Report.

  http://haskell.org/onlinereport/intro.html

[...]

| There is also a lhs2TeX (i.e. "noweave") program at
| <http://www.informatik.uni-bonn.de/~loeh/lhs2tex> 

This is the only "serious" modern lhs2TeX I've ever used.

[...]


Try to compile the documentation of GHC to see how the actual practice
is done.  Try GHC.

-- Gaby



\start
Date: Fri, 13 Jul 2007 02:16:23 -0400
From: Bill Page
To: William Sit
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

On 7/13/07, William Sit wrote:

> Whatever the primitive types are, the important thing is that there
> be a well-designed user interface (exported functions) on par with
> all other algebra code. Right now, Tuple and Union are
> "inaccessible" from the algebra layer without going to lisp (Record
> seems okay ). That is, in my view, a design flaw. They should be
> designed as if they were genuine domains (where one can construct
> elements and extract information from elements and compute with
> them). How they are implemented and optimized at the lower levels
> should not be of concern to the algebra layer.

+1 Yes, exactly! There should be no need ever to "escape" to lower
levels. Already Axiom and Aldor use different internal representations
for many things including Record. But that should be no concern to the
Axiom library programmer and in fact for the most part that is
accomplished by the magic of the Axiom Aldor interface. But the
existing Axiom library code written in Spad has many places where
assumptions (often unstated hidden assumptions) about internal
representations are made. This ultimately will make modular conversion
of the Axiom library to Aldor much more difficult than it should be.

But choosing the correct "primitive types" is a rather hard problem.
That is in my opinion one place where category theory comes in. We
know from very general considerations (topos theory) that if we expect
to be able to implement a large part of mathematics (e.g.that part
that presumes set theory) in our language we will need a language that
is complete enough to at least represent all limits and co-limits plus
exponentiation and sub-object classifiers. Category theory contains a
theorem that this is possible if we implement just two limits
(equalizers and products) and two co-limits (co-equalizers and
co-products). It also says that there is a certain kind of redundancy
between the combination of limits, co-limits and exponentiation so
that it is possible (but quite complicated) to implement co-limits in
terms of limits and exponentiation. And vice versa, limits in terms of
co-limits and exponentiation.

See for example the very quick introductory article by John Baez:

http://www.math.ucr.edu/home/baez/topos.html

Topos Theory in a Nutshell
John Baez
April 12, 2006

It turns out that most modern languages already have products
(Records) and some form of exponentiation (representation of
higher-order functions) but there is considerable variation in the
representation of co-products (if they exist explicitly at all). In
fact most programming languages have a strong bias away from all
notions related to co-limits. However category theory says *exactly*
what co-products should be like by the fundamental properties of
categorical duality: If we represent the axiomatic algebraic
properties of limits in terms of a commutative diagram, then we can
obtain the algebraic properties of co-limits simply by reversing the
direction of all of the arrows in the diagram. This simple duality has
enormous implications for the actual implementation of the primitive
types and sometimes quite unexpected consequences. This starts at a
very basic level of only looking at a function as a mapping in one
direction:

  f: X -> Y

But in any sufficiently complicated category (e.g. Set) arrows come
with a "built-in" dual concept

  f: Y <- X

that can be represented in terms of "fibers", i.e. as the family of
subsets of  X indexed by Y

  f' : Y -> 2^X

http://en.wikipedia.org/wiki/Image_(mathematics)

This bias against these dual notions runs very deep and effects the
expressiveness of our mathematical programming language in important
concepts such as equivalence classes and equality as well as many
fundamental ideas that arise in algebraic topology. Which again
emphasizes the role of category theory and the need to "get it right"
in the choice of primitive types.

Further ref: http://en.wikipedia.org/wiki/Topos_theory

\start
Date: Fri, 13 Jul 2007 02:24:36 -0400
From: William Sit
To: Stephen Wilson
Subject: Re: Unions in Spad

William Sit wrote:

> In the proposed IndexedUnion, what is missing is the Rep:=
> Record[index:I, value: g(i)].

     Actually, this can probably be similated by Record(i:I, x:Any) to avoid dependent
types.

However, there is another problem: the signature of the index map

     g: I->List SetCategory

has syntax problem. (So, alas, all my examples inherit this problem.)
A list (more correctly, a set) of domains in the SetCategory is NOT a
domain and hence cannot be used as the target of a map. So we have to
turn a list or set into a domain, much like turning a list of tags
into a domain (TagsAsDomain).  Here however, we are one level higher
because we are trying to make a set of *domains* such as {Integer,
String} into a domain.

While there is probably a way to do this in Lisp, the question is how
should a user of Axiom input this map g? It looks like we need to
capture this at the algebra level and make all these maps into a
domain, too. So domains and perhaps even categories must be first
class objects. Unfortunately, even the domain Any does not capture
sets of domains as objects.  This despite the Rep for Any is
Record(dm:SExpression, ob:None). The Interpreter refuses to convert
domains into objects of Any.

-> (1) k:List Any:= [Integer, String]

    Cannot convert an element of the construct to type Any.


In summary, we need:


(1) make a list or set of domains from SetCategory (or any category) a
legal construction

(2) SetAsDomain to convert a list or set of domains (or elements, or
maps, perhaps or categories) as a domain of SetCategory

(3) Record to accept dependent types, such as [i: I, x:g(i)]

(4) maps such as g: I -> SetAsDomain([Integer, String]) should be
first class objects and used as parameters, and definable in the
Interpreter.

The construction is related to the bug in Union when the domains are
not distinct (but the tags are): In Union(a:A, b:B) where A = B, the
two coerce functions (one from A to % and one from B to %) coincides,
with no way to distinguish the two.

\start
Date: Fri, 13 Jul 2007 08:26:01 +0200
From: Ralf Hemmecke
To: Stephen Wilson
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

=--- union-test.spad ----
> 
> )abbrev domain BAR Bar
> 
> Bar() : Exp == Impl where
>    Exp == with
>      inj : Integer -> %
>      inj : String -> %
>      prj : % -> Integer
>    Impl == add
>      Rep := Union(tag1: Integer, tag1: String)
>      inj (n : Integer) : % == [n]
>      inj (s : String) : % == [s]
>      prj p == (p::Rep).tag1

Stephen, have you ever thought about the difference between Rep and %?
The type of [n] would be Rep, since there is no function

   bracket: Integer -> %

so if you write

   inj (n : Integer) : % == [n]

as above, that should be a type error.

\start
Date: 13 Jul 2007 01:39:43 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Literate Programming

Tim Daly writes:

[...]

| I don't see that Axiom is breaking any new ground.

GHC -- probably the largest Haskell application on the planet, that
inspires almost all Haskellers -- is not dogmatic about LHS and its
syntactic format.  In fact, the working Haskellers of GHC are not
dogmatic about LHS at all -- they always warmly welcome newcomers and
try to retain the existing ones.

\start
Date: 13 Jul 2007 03:12:01 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

Hi Ralf,

This is late in the night for me, so please forgive the terse
response.


Ralf Hemmecke writes:

> =--- union-test.spad ----
> > )abbrev domain BAR Bar
> > Bar() : Exp == Impl where
> >    Exp == with
> >      inj : Integer -> %
> >      inj : String -> %
> >      prj : % -> Integer
> >    Impl == add
> >      Rep := Union(tag1: Integer, tag1: String)
> >      inj (n : Integer) : % == [n]
> >      inj (s : String) : % == [s]
> >      prj p == (p::Rep).tag1
> 
> Stephen, have you ever thought about the difference between Rep and %?

Yes. 

> The type of [n] would be Rep, since there is no function
> 
>    bracket: Integer -> %

Perhaps you are thinking in terms of Aldor?  In Spad, we have:

   1) -> )sh Union(tag1: Integer, tag1: String)
    Union(tag1: Integer,tag1: String) is a domain constructor.
   ------------------------------- Operations --------------------------------

    ?=? : (%,%) -> Boolean                ?case? : (%,tag1) -> Boolean
    ?case? : (%,tag1) -> Boolean          coerce : % -> OutputForm
    construct : Integer -> %              construct : String -> %
    ?.? : (%,tag1) -> Integer             ?.? : (%,tag1) -> String

Here, `bracket' is known as `construct', and as you can see, there are
two such operations. 

> 
> so if you write
> 
>    inj (n : Integer) : % == [n]
> 
> as above, that should be a type error.

On the contrary, it is a call to:
   
    construct : Integer -> %

which is well typed.

\start
Date: 13 Jul 2007 03:24:42 -0400
From: Stephen Wilson
To: Stephen Wilson
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis


Stephen Wilson writes:

> > so if you write
> > 
> >    inj (n : Integer) : % == [n]
> > 
> > as above, that should be a type error.
> 
> On the contrary, it is a call to:
>    
>     construct : Integer -> %
> 
> which is well typed.

Sorry.  Again it is late.  Spad will perform automatic coercions for
you from type Rep to type %, which is clearly the key point here.
Often there is no need for `rep' and `per' as in Aldor.

\start
Date: Fri, 13 Jul 2007 04:24:29 -0400
From: William Sit
To: Stephen Wilson, Gabriel Dos Reis, Bill Page,  Waldek Hebisch
Subject: Re: Unions in Spad (Correction)

I made some erratic comments (attached below) on design flaw in Union
that was based on hyperdoc documentation. Since hyperdoc does not
allow insertion of parameters for Union (for unknown reasons), I was
"misled". Thanks to Stephen's reply to Ralf's comments, I now learn
that the )show command does allow that and the set of exported
functions are slightly different.

Here is the exports for :
(1) -> )show Union(tag1:Integer, tag2:Integer)
 Union(tag1: Integer,tag2: Integer) is a domain constructor.
------------------------------- Operations --------------------------------

 ?=? : (%,%) -> Boolean                ?case? : (%,tag1) -> Boolean
 ?case? : (%,tag2) -> Boolean          coerce : % -> OutputForm
 construct : Integer -> %              construct : Integer -> %
 ?.? : (%,tag1) -> Integer             ?.? : (%,tag2) -> Integer

(There were only "=", "case" and "coerce" in hyperdoc and their usages
for "case" in

Union(a:A, b:B):
   x case y (x: %, y: A) returns an element of Boolean
   x case y (x:%, y:B) returns an element of Boolean
were wrong).

It is not possible to construct elements in the above domain and
specify which copy of Integer in the Union one wants the input to
below. There are two "construct" but they have the same signature and
so the Interpreter will simply select the first. So while there is
still some design flaw, it is possible to distinguish the cases.
However, there is still some bug:

(1) -> dom:=Union(tag1:Integer, tag2:Integer)

   (1)  Union(tag1: Integer,tag2: Integer)
                                                                 Type: Domain
(2) -> j1:dom:=[1]

   (2)  1
                                 Type: Union(tag1: Integer,tag2: Integer,

(3) -> j1 case tag1

   (3)  true
                                                                Type: Boolean
(4) -> j1 case 1

   >> Error detected within library code:
   upcase: bad Union form

protected-symbol-warn called with (NIL)

Perhaps a better error message should be given, like:
(5) -> j1.tag2

   >> Error detected within library code:
   (0 . 1) cannot be coerced to mode (Integer)

protected-symbol-warn called with (NIL)

It is not clear what function is called to evaluate the next one, but
the "coerce" works as given in hyperdoc.


(6) -> coerce(j1)@Integer

 Function Selection for coerce
      Arguments: Union(tag1: INT,tag2: INT)
      Target type: INT
   -> no appropriate coerce found in Integer
   -> no appropriate coerce found in Integer

 [1]  signature:   INT -> INT
      implemented: slot $(Integer) from INT
 [2]  signature:   INT -> INT
      implemented: slot $(Integer) from INT
 [3]  signature:   INT -> INT
      implemented: slot $(Integer) from INT
 [4]  signature:   INT -> INT
      implemented: slot $(Integer) from INT
 [5]  signature:   INT -> INT
      implemented: slot $$ from INT
 [6]  signature:   INT -> INT
      implemented: slot $$ from INT


   (6)  1
                                                                Type: Integer


\start
Date: Fri, 13 Jul 2007 04:33:39 -0400
From: William Sit
To: Bill Page
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

Dear Bill:

Before we get into more category theory, the prerequisite
for even talking about colimits (or limits) is the very
simple idea of a family of morphisms (as well as objects) as
required in these constructions (for example, the notion of
a diagram). This is no more than an indexed set and a map
from the indexed set to a set of maps  (morphisms) or
domains (objects). The implementation problems are already
glaring. Let's solve some practical problems first.

Category theory is beautiful, but when we start
implementing, the great generality of category theory
becomes more of a hindrance than a help. No doubt it
clarifies many algebraic constructions by carefully
describing the conditions, and duality makes it easy to
accept results with half the effort.  In this respect, CT is
quite similar to Model Theory in logic. Powerful
mathematics, no doubt, and essential to the understanding of
mathematical structures, notions such as various dimensions,
and algorithms. But when it comes to application, one still
has to unwind all the definitions in the specific category
and interpret the results there. Without getting notions
back to the less abstract, and reducing the details to
computer science, it's just idealism. I'm sure the earlier
Axiom developers all know category theory (and the results
you mentioned which have been known long long time ago) and
were much influenced by it. But from what we know about
Axiom implementation, the details and technical difficulties
pretty much forced certain unpleasant choices. The case of
Union (untagged and tagged) is one such compromise.  The
proliferation of different data representations to make
computation efficient for specific problems is another. None
of this can be helped by CT.

However, I would be interested to hear how you plan to
create a basic computer algebra system from scratch based on
category theory. Specifically, how does duality help with
say implementation of products and coproducts when their
data representation cannot be dualized? ( I know duality
would help with how one should specify exports, which is
important; but how does duality help with implementation?)
What do we have now that the earlier developers don't have
that makes you think this time around, we can do better
(other than because computers are faster)?

\start
Date: 13 Jul 2007 03:45:02 -0500
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Unions in Spad

Stephen Wilson writes:

| Stephen Wilson writes:
| 
| > > so if you write
| > > 
| > >    inj (n : Integer) : % == [n]
| > > 
| > > as above, that should be a type error.
| > 
| > On the contrary, it is a call to:
| >    
| >     construct : Integer -> %
| > 
| > which is well typed.
| 
| Sorry.  Again it is late.  Spad will perform automatic coercions for
| you from type Rep to type %, which is clearly the key point here.
| Often there is no need for `rep' and `per' as in Aldor.

However, many times I've come across to bugs in the Spad compiler
either unable to perform that automatic conversion, or that automatic
conversion seriously confuses it.  Note also that if an operation
is defined on both $ and Rep, then on takes precedence.  That choice
should be left to the user, who knows what he/she intended.
Therefore, I see a need for per and rep.  In fact, in my local
tree I have both per and rep -- but unlike Aldor, they are not
macros: they are built-in operators.  Ideally, I would like to
see pretend uses close to zero.

\start
Date: Fri, 13 Jul 2007 11:10:57 +0200
From: Ralf Hemmecke
To: Stephen Wilson
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

>> Stephen, have you ever thought about the difference between Rep and %?

> Yes. 

Good.

>> The type of [n] would be Rep, since there is no function
>>
>>    bracket: Integer -> %
> 
> Perhaps you are thinking in terms of Aldor?

Yes, but that has nothing to do with Aldor.

>  In Spad, we have:
> 
>    1) -> )sh Union(tag1: Integer, tag1: String)
>     Union(tag1: Integer,tag1: String) is a domain constructor.
>    ------------------------------- Operations --------------------------------
> 
>     ?=? : (%,%) -> Boolean                ?case? : (%,tag1) -> Boolean
>     ?case? : (%,tag1) -> Boolean          coerce : % -> OutputForm
>     construct : Integer -> %              construct : String -> %
>     ?.? : (%,tag1) -> Integer             ?.? : (%,tag1) -> String

> Here, `bracket' is known as `construct', and as you can see, there are
> two such operations. 

OK. Let's assume that 'construct' exists (BTW my previous mail has 
already considered that case, but let's try to make it explicit.

>> so if you write
>>
>>    inj (n : Integer) : % == [n]
>>
>> as above, that should be a type error.
> 
> On the contrary, it is a call to:
>    
>     construct : Integer -> %
> 
> which is well typed.

Sorry, but I believe you are wrong. Rep and % are perhaps identical in 
their represenstation, but they export different functions. You know 
that, since you know Aldor. And if you want to have that treated 
differently in SPAD, then I am not on your side. I don't care what the 
current SPAD compiler or interpreter does. I'd rather like to look at 
the example from a specification point of view.

Since

   construct: Integer -> %

is exported by

   Union(tag1: Integer, tag1: String)

In the context of

 > )abbrev domain BAR Bar
 > > > Bar() : Exp == Impl where
 > > >    Exp == with
 > > >      inj : Integer -> %
 > > >      inj : String -> %
 > > >      prj : % -> Integer
 > > >    Impl == add
 > > >      Rep := Union(tag1: Integer, tag1: String)
 > > >      inj (n : Integer) : % == [n]
 > > >      inj (s : String) : % == [s]
 > > >      prj p == (p::Rep).tag1

if there where a statement like

   import from Rep

there would then be

   construct: Integer -> Union(tag1: Integer, tag1: String)

in scope. Clearly,

   [n]

would be of type Union(tag1: Integer, tag1: String) and not of type %.
Type mismatch. That is why Aldor would require to write

   inj (n : Integer) : % == per [n]

Although that costs some typing. It's much clearer. Not only for the 
compiler but also for me. (Don't tell me that per is actually only a 
macro. I know that.)

And I hope some time SPAD also requires to write

   Rep == ...

because

   Rep := ...

introduces a variable Rep (not a constant). Would you think that

)abbrev domain BAR Bar
Bar() : Exp == Impl where
   Exp == with
     inj : Integer -> %
     inj : String -> %
     prj : % -> Integer
   Impl == add
     Rep := Union(tag1: Integer, tag1: String)
     inj (n : Integer) : % == [n]
     Rep := Union(tag1: String, tag1: Integer)
     inj (s : String) : % == [s]
     prj p == (p::Rep).tag1

should actually compile? On my machine (GOLD) it does. With some 
warnings, but that's all.

By the way let me give another example.

In Aldor I can write the following:

woodpecker:~>aldor -fx -laldor aaa.as
woodpecker:~>aaa
     inc f = 2
get inc f = 101

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

Foo: with {
   inj: Integer -> %;
   inc: % -> Integer;
   inc: % -> %;
   get: % -> Integer;
} == add {
   Rep == Integer;
   import from Rep;
   inj(z: Integer): % == per z;
   inc(x: %): Integer == rep x + 1;
   inc(x: %): % == per(rep x + 100);
   get(x: %): Integer == rep x;
}
main(): () == {
   z: Integer := 1;
   f: Foo := inj z;
   stdout << "    inc f = " << inc f << newline;
   stdout << "get inc f = " << get inc f << newline;
}
main();
---END aaa.as

Write the same program in SPAD and compile it.

\start
Date: Fri, 13 Jul 2007 11:40:45 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: rep, per, Rep in SPAD/Aldor, was: Re: Unions in Spad

> However, many times I've come across to bugs in the Spad compiler
> either unable to perform that automatic conversion, or that automatic
> conversion seriously confuses it.  Note also that if an operation
> is defined on both $ and Rep, then on takes precedence.  That choice
> should be left to the user, who knows what he/she intended.

Exactly.

> Therefore, I see a need for per and rep.  In fact, in my local
> tree I have both per and rep -- but unlike Aldor, they are not
> macros: they are built-in operators.  Ideally, I would like to
> see pretend uses close to zero.

I agree that pretend should almost never be seen in higher level code. 
That rep and per are just macros in Aldor is not really problematic.

rep, per, Rep are *not* part of the Aldor language. (Gaby, I know that 
you know.)  Although, all this macro business is a bit hard to 
understand, I would not really agree to add rep, per, and Rep to the 
language specification. The "pretend" is enough. I would only say that 
they should become part of the language if "pretend" disappears. but 
then we trade one construct for three. And maybe "pretend" cannot be 
made superfluous.

Why am I saying this? Maybe Martin now starts to listen more 
carefully... ;-)

In Aldor-Combinat, our species export two functions (simplified)

   structures: Set L -> Generator %;
   isoTypes:   Set L -> Generator %;

where L is the domain of labels of the structure.

I have not really a full picture yet (so don't take that overly 
serious), but sometimes it comes to Martin's and my mind that isotypes 
should actually return something else. For example, take Partition. 
structures, would return set partitions while isoTypes (currently) 
return representatives of an equivalence classes (a.k.a. isomorphism 
type). Clearly these equivalence classes are in one-to-one 
correspondence with integer partitions. Integer partitions could be 
handled much more efficiently. So it would be useful to have 2 different 
representations for one domain.

Let me for a moment even use an additional symbol %2. I'd like to say

   isoTypes: Set L -> Generator %2;

Of course that doesn't work in Aldor, but to my current knowledge it 
seems that having several of these % symbols would better fit to the 
multisort-algebra view on domains. It is not always the case that just 
one carrier set is the most important and called %.

This is another hint why I would rather not like Rep, rep, per as new 
keywords. That is too restrictive.

I am not a language guy so please point me to the nonsense that I have 
written.

\start
Date: Fri, 13 Jul 2007 05:15:20 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: rep, per, Rep in SPAD/Aldor, was: Re: Unions in Spad

On Fri, 13 Jul 2007, Ralf Hemmecke wrote:

| rep, per, Rep are *not* part of the Aldor language. (Gaby, I know
| that you know.)  Although, all this macro business is a bit hard to
| understand, I would not really agree to add rep, per, and Rep to the
| language specification. The "pretend" is enough. I would only say
| that they should become part of the language if "pretend"
| disappears. but then we trade one construct for three.  And maybe
| "pretend" cannot be made superfluous.

I don't suggest that "pretend" be removed.  Just like general casts in C, or
similar constructs in other languages, I don't think it should be
removed and yet make Spad (or Aldor) expressive enough.  

However, I do believe that `rep' and `per' are fundamentally part
of the language semantics of domain.  I don't think Rep should be there.
Rep is quite of redundant with the pair rep/per.
`rep' and `per' are there to fold/unfold views -- they are at the core
of Spad or Aldor.

| Why am I saying this? Maybe Martin now starts to listen more carefully... ;-)
| 
| In Aldor-Combinat, our species export two functions (simplified)
| 
|   structures: Set L -> Generator %;
|   isoTypes:   Set L -> Generator %;
| 
| where L is the domain of labels of the structure.
| 
| I have not really a full picture yet (so don't take that overly serious), but
| sometimes it comes to Martin's and my mind that isotypes should actually
| return something else. For example, take Partition. structures, would return
| set partitions while isoTypes (currently) return representatives of an
| equivalence classes (a.k.a. isomorphism type). Clearly these equivalence
| classes are in one-to-one correspondence with integer partitions. Integer
| partitions could be handled much more efficiently. So it would be useful to
| have 2 different representations for one domain.

Yes.  How would that conflict with making rep and per part of the language?

Many (most?) domains have only on representation, so it makes sense
to `optimize' the notation for the common cases.  For those that do
need more refinement, users can provide their own views and the language
will recognize that.  There is a precedence for that.  In C++ for example,
user-defined types come equipped with a compiler generated copy constructor
if user the user does not declare one.  For many value types, that is
exactly what is needed and the semantics is optimal.

So, think about this:

  (1) if a domain defines Rep, then automatically rep/per are
     generated.

  (2) if a domain defines one of per or rep, then the automatic
      definition of the other is suppressed.

| Let me for a moment even use an additional symbol %2. I'd like to say
| 
|   isoTypes: Set L -> Generator %2;
| 
| Of course that doesn't work in Aldor, but to my current knowledge it seems
| that having several of these % symbols would better fit to the
| multisort-algebra view on domains. It is not always the case that just one
| carrier set is the most important and called %.

I sort of agree.  When you have seveval representations (algebra in universal
algebra sense) that abstract to the a given domain, then you actually
have a category (in CT sense).  Would it not be convenient to express
that in the code and actually use Spad categories?

| This is another hint why I would rather not like Rep, rep, per as new
| keywords. That is too restrictive.
| 
| I am not a language guy so please point me to the nonsense that I have
| written.

Well, I'm not a language designer by education.  Only by experience
and as a user.  So don't dimunish yourself :-)

\start
Date: Fri, 13 Jul 2007 13:15:24 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: Re: 2.7 build

Camm Maguire wrote: 
> > I am working with the same tree as my first trial at gcl-2.7 build, namely
> > revision 636 of wh-sandbox + the patch that I posted.  If you did update
> > you probably got revision 646 which is slightly different.
> > 
> 
> OK, I've reverted exactly to this source for testing.  How are you
> testing at safety 3 -- with an initial declaim in saved_ansi_gcl?
> 

I changed declaration in 'src/inter/interp-proclaims.lisp' (by default
there is a safety 1 declaration here).  I also put the same declaration
in 'src/lisp/axiom-lisp.lisp.pamphlet' (so that bootsys is also build
using safety 3).  

There is one more change: in 'src/lisp/Makefile.pamphlet' I have
now '(compiler::emit-fn nil)' (previously it was t).

I can report a succesful build at safety 3.  Unfortunatly, results
of testsuite are rather bad -- there are many wrong answers.
However it is likely that wrong results are just due to few bugs...

I also re-tried build at safety 1: it fails early (more details
in another mail).

\start
Date: Fri, 13 Jul 2007 13:57:16 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: rep, per, Rep in SPAD/Aldor

On 07/13/2007 12:15 PM, Gabriel Dos Reis wrote:
> On Fri, 13 Jul 2007, Ralf Hemmecke wrote:
> 
> | rep, per, Rep are *not* part of the Aldor language. (Gaby, I know that you
> | know.)  Although, all this macro business is a bit hard to understand, I would
> | not really agree to add rep, per, and Rep to the language specification. The
> | "pretend" is enough. I would only say that they should become part of the
> | language if "pretend" disappears. but then we trade one construct for three.
> | And maybe "pretend" cannot be made superfluous.
> 
> I don't suggest that "pretend" be removed.  Just like general casts in C, or
> similar constructs in other languages, I don't think it should be
> removed and yet make Spad (or Aldor) expressive enough.  

OK.

> However, I do believe that `rep' and `per' are fundamentally part
> of the language semantics of domain.

Oh. You explicitly say "domain" (you don't include "package"). So I 
somehow have to agree. But not really. You know that by using "pretend", 
I could remove any uses of Rep, per, rep. Of course, nobody should write 
that code but rather follow the convention with Rep. What you want is to 
turn a convention into a rule. All I want to say is that this conflicts 
a bit with the design goals of Aldor: rather remove restrictions than 
introducing new features. I actually thought that you adhere to this 
principle. ;-)

> I don't think Rep should be there.
> Rep is quite of redundant with the pair rep/per.

I don't think, that I understand. There must be some way to actually 
write down the representation domain. If you have only rep and per, how 
would you do this?

> `rep' and `per' are there to fold/unfold views -- they are at the core
> of Spad or Aldor.

As I said, in some way you are right. It always confused me with this 
"Rep :=" or "Rep ==>" or "Rep ==" and no proper description of why Rep 
is so important (the concept, not the literal "Rep"). But now I know 
that if in my include file I define

macro {
	ying x == ((x)@%) pretend Ying;
	yang r == ((r)@Ying) pretend %;
}

I could completely do without Rep and rather say

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

Foo: with {
   inj: Integer -> %;
   get: % -> Integer;
} == add {
   Ying == Integer;
   import from Ying;
   inj(z: Integer): % == yang z;
   get(x: %): Integer == ying x;
}
---END aaa.as

Gaby, I think that code is rather for others than for you. I am sure you 
understand that business quite well.

> | Why am I saying this? Maybe Martin now starts to listen more carefully... ;-)
> | 
> | In Aldor-Combinat, our species export two functions (simplified)
> | 
> |   structures: Set L -> Generator %;
> |   isoTypes:   Set L -> Generator %;
> | 
> | where L is the domain of labels of the structure.
> | 
> | I have not really a full picture yet (so don't take that overly serious), but
> | sometimes it comes to Martin's and my mind that isotypes should actually
> | return something else. For example, take Partition. structures, would return
> | set partitions while isoTypes (currently) return representatives of an
> | equivalence classes (a.k.a. isomorphism type). Clearly these equivalence
> | classes are in one-to-one correspondence with integer partitions. Integer
> | partitions could be handled much more efficiently. So it would be useful to
> | have 2 different representations for one domain.

> Yes.  How would that conflict with making rep and per part of the language?

No conflict. It just introduces new and unnecessary keywords. The 
conflict is with the principle I stated above.

> Many (most?) domains have only on representation, so it makes sense
> to `optimize' the notation for the common cases.

I completely agree. I just say it is not necessary to add new keywords. 
What do you think is the problem with rep and per as macros?

 > For those that do
> need more refinement, users can provide their own views and the language
> will recognize that.  There is a precedence for that.  In C++ for example,
> user-defined types come equipped with a compiler generated copy constructor
> if user the user does not declare one.  For many value types, that is
> exactly what is needed and the semantics is optimal.

I somehow begin to understand your view.

> So, think about this:
> 
>   (1) if a domain defines Rep, then automatically rep/per are
>      generated.

But that is also the way it is now in Aldor. If you don't define Rep and 
use rep/per, that gives a compile time error.

>   (2) if a domain defines one of per or rep, then the automatic
>       definition of the other is suppressed.

This is something I don't understand. Without defining Rep, I cannot 
define per. Why should I define rep/per anyway. They should just allow a 
different view on a object.

> | Let me for a moment even use an additional symbol %2. I'd like to say
> | 
> |   isoTypes: Set L -> Generator %2;
> | 
> | Of course that doesn't work in Aldor, but to my current knowledge it seems
> | that having several of these % symbols would better fit to the
> | multisort-algebra view on domains. It is not always the case that just one
> | carrier set is the most important and called %.

> I sort of agree.  When you have seveval representations (algebra in universal
> algebra sense) that abstract to the a given domain, then you actually
> have a category (in CT sense).  Would it not be convenient to express
> that in the code and actually use Spad categories?

OK, let me give my view on domains.

You have probably read
http://portal.axiom-developer.org/refs/articles/doye-aldor-phd.pdf
where Doye says that domains are somehow like order sorted algebras.

This is something like A = ((C1,...,Cn), (f1,...,fm)) with cardinal 
numbers n and m. (Of course, in Aldor we cannote express the infinite 
case since that would mean to write an infinite program.)

The order-sorted view is somehow correct, but if we look at an Aldor 
domain, there is always some distinguished thing (I don't know how to 
actually call this thing) which is denoted by %. It actually corresponds 
to the A from above. However, Aldor let's you think that it corresponds 
to C1 (the distinguished domain) which is usually denoted by Rep.

In Aldor we write

Foo: with {
   coerce: Integer -> %;
   test?: % -> Boolean;
} == add {
   Rep == String;
   ...
}

and mean something like

   Foo = ((%, Integer, Boolean), (coerce, test?))

in the multisorted algebra sense. We don't actually make Integer and 
Boolean (not String) an argument to Foo or "with", they are implicit.

Now, I have written % in the Foo = ... above and not

   Foo = ((Rep, Integer, Boolean), (coerce, test?))

since then the signatures of coerce and test? would not be OK.

That is the confusing point. Actually, there should be Rep and Foo 
should correspond to %. This is what we do in mathematics all the time. 
We speak of the (additive) monoid of integers and denote it by Z 
although that is at most the carrier set and some people would find that 
confusing if Z is used without reference to the additive structure.


I think there is a difference if we consider the "with" or the "add" 
part of a domain.

For the "with" part (and that is what a user of the domain actually 
sees), the above definition clearly corresponds to

   Foo = ((%, Integer, Boolean), (coerce, test?))

And for the user of this algebra, Foo and % are identified. That is what 
Aldor does here. (Although, it is mathematically not strictly correct.)
But most mathematicians do so in (almost) all cases.

Now let us look to the "add" part. There we have yet another domain, 
namely Rep. Inside "add" we actually consider an algebra like

   Foo' = ((%, Rep, Integer, Boolean), (coerce, test?, per, rep))

Hmmm, I have just cooked that all up right now, but it seems a pretty
coherent view on domains.

Since "add {...}" is an anonymous domain, it should actually export what 
is in the signature part of Foo', so let's see.

aldor -gloop
%1 >> #include "aldor"
%2 >> #include "aldorinterp"
%3 >> add {Rep==String;coerce(z:Integer):%==per 
"int";test?(x:%):Boolean==true}
   () @  with
         Rep: ? == String
         coerce: (z: AldorInteger) -> %
         test?: (x: %) -> Boolean

That is pretty close, but lacks per and rep. Gaby, I think that is one 
point for you. Here I would like to see rep,per, Rep. Don't you agree?
But note if we export Rep, we somehow are in conflict with "hiding the 
representation".

Any other opinions.

Actually, I started that mail with something else in mind, but now I am 
not so sure anymore whether I would really like to have %, %2, %3, etc. 
anymore. This correspondence of Foo with % is in some way rather 
ingenious. I have to think more about my original reference to wanting 
two representations for species in Aldor-Combinat.

Sorry, Gaby, I have not really responded to that categorial view in your 
statement above. I think I don't understand it properly. Could you 
elaborate and add a bit of your wisdom.

\start
Date: Fri, 13 Jul 2007 14:22:47 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: re: debugging

> Greetings!  Again, I get
> 
> --->-->PlaneAlgebraicCurvePlot(constructor): Unexpected HT command: \indented
> "\\indented{1}{Plot a NON-SINGULAR plane algebraic curve \\spad{p}(\\spad{x},{}\\spad{y}) = 0.} Author: Clifton \\spad{J}. Williamson Date Created: Fall 1988 Date Last Updated: 27 April 1990 Keywords: algebraic curve,{} non-singular,{} plot Examples: References:"
> 
> Error: 
> Signalled by COMPILER::COMPILE-FILE1.
> INTERNAL-SIMPLE-READER-ERROR: Stream error on stream #<input stream "ACPLOT.NRLIB/ACPLOT.lsp">: The default dispatch macro signalled an error.
> 
> Broken at COMPILER::COMPILE-FILE1.  Type :H for Help.
>  1 (Continue) Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
>  2 Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
>  3 Return to top level.
> BOOT>>
> cat ACPLOT.NRLIB/ACPLOT.lsp
> 
> (/VERSIONCHECK 2) 
> 
> (DEFUN |ACPLOT;NFtoSF| (|x| $)
>   (PROG ()
>     (RETURN
>       (+ '#1=#((|DoubleFloat|)
>                (#<compiled-function |lookupComplete|> #1#
>                 #(~= 231 |zero?| 237 |wholePart| 242 |unitNormal| 247
> ...
> 
> Is this the same issue as you are reporting (or related)?
> 

At safety 3 this function compiles just fine.  At safty 1 I get an
error earlier, in DFLOAT.lsp I see:

(DEFUN |DFLOAT;base;Pi;7| ($)
  (PROG () (RETURN (FLOAT-RADIX '#<OBJNULL>))))


Now, #<OBJNULL> is IMHO very strong indication of memory corruption
(I see no legal way to produce it).  OTOH the vector (value of '#1')
you see is clearly wrong in this place, but it looks like normal
Axiom domain vector.  So ATM it not clear if both failures are related.

\start
Date: 13 Jul 2007 14:20:49 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: re: debugging

Greetings!

I discovered that make clean was leaving NRLIB directories and source
present in src/algebra.  So I started afresh:

svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/wh-sandbox
...
svn update -r 636
D    src/input/bugs2007.input.pamphlet
U    src/input/Makefile.pamphlet
U    src/input/Makefile.in
U    src/interp/daase.lisp.pamphlet
U    src/interp/Makefile.pamphlet
U    src/interp/Makefile.in
U    src/interp/i-output.boot.pamphlet
U    src/interp/unlisp.lisp.pamphlet
U    src/lisp/axiom-lisp.lisp.pamphlet
U    src/lisp/Makefile.in
U    src/lisp/Makefile.pamphlet
U    ChangeLog.wh
Updated to revision 636.
cat ../../whd|patch -p0 
patching file src/interp/spaderror.lisp.pamphlet
patching file src/interp/interp-proclaims.lisp
patching file src/interp/Makefile.pamphlet
patching file src/interp/Makefile.in
patching file src/interp/bookvol5.pamphlet
patching file src/interp/nruncomp.boot.pamphlet
patching file src/lisp/axiom-lisp.lisp.pamphlet
patching file src/lisp/Makefile.in
patching file src/lisp/Makefile.pamphlet
./configure --with-lisp=$(pwd)/../../foo2/unixport/saved_ansi_gcl
make
...
   finalizing NRLIB UPOLYC- 
   Processing UnivariatePolynomialCategory& for Browser database:
--------(vectorise ((Vector R) % (NonNegativeInteger)))---------
--------(makeSUP ((SparseUnivariatePolynomial R) %))---------
--------(unmakeSUP (% (SparseUnivariatePolynomial R)))---------
--------(multiplyExponents (% % (NonNegativeInteger)))---------
--------(divideExponents ((Union % failed) % (NonNegativeInteger)))---------
--------(monicDivide ((Record (: quotient %) (: remainder %)) % %))---------
--------(karatsubaDivide ((Record (: quotient %) (: remainder %)) % (NonNegativeInteger)))---------
--------(shiftRight (% % (NonNegativeInteger)))---------
--------(shiftLeft (% % (NonNegativeInteger)))---------
--------(pseudoRemainder (% % %))---------
--------(differentiate (% % (Mapping R R) %))---------
--------(discriminant (R %))---------
--------(resultant (R % %))---------
--------(elt ((Fraction %) (Fraction %) (Fraction %)))---------
--------(order ((NonNegativeInteger) % %))---------
--------(subResultantGcd (% % %))---------
--------(composite ((Union % failed) % %))---------
--------(composite ((Union (Fraction %) failed) (Fraction %) %))---------
--------(pseudoQuotient (% % %))---------
--------(pseudoDivide ((Record (: coef R) (: quotient %) (: remainder %)) % %))---------
--------(separate ((Record (: primePart %) (: commonPart %)) % %))---------
--------(additiveValuation (attribute))---------
--------(elt (R (Fraction %) R))---------
--------(integrate (% %))---------
--------constructor---------

(still going)

In foo2, I have gcl ansi cvs head built with --enable-debug to try to
catch any segfault.

Is it possible we're not getting a clean start on your previously
reported safety 1 bug re: OBJNULL?

Take care,



Waldek Hebisch writes:

> > Greetings!  Again, I get
> > 
> > --->-->PlaneAlgebraicCurvePlot(constructor): Unexpected HT command: \indented
> > "\\indented{1}{Plot a NON-SINGULAR plane algebraic curve \\spad{p}(\\spad{x},{}\\spad{y}) = 0.} Author: Clifton \\spad{J}. Williamson Date Created: Fall 1988 Date Last Updated: 27 April 1990 Keywords: algebraic curve,{} non-singular,{} plot Examples: References:"
> > 
> > Error: 
> > Signalled by COMPILER::COMPILE-FILE1.
> > INTERNAL-SIMPLE-READER-ERROR: Stream error on stream #<input stream "ACPLOT.NRLIB/ACPLOT.lsp">: The default dispatch macro signalled an error.
> > 
> > Broken at COMPILER::COMPILE-FILE1.  Type :H for Help.
> >  1 (Continue) Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
> >  2 Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
> >  3 Return to top level.
> > BOOT>>
> > cat ACPLOT.NRLIB/ACPLOT.lsp
> > 
> > (/VERSIONCHECK 2) 
> > 
> > (DEFUN |ACPLOT;NFtoSF| (|x| $)
> >   (PROG ()
> >     (RETURN
> >       (+ '#1=#((|DoubleFloat|)
> >                (#<compiled-function |lookupComplete|> #1#
> >                 #(~= 231 |zero?| 237 |wholePart| 242 |unitNormal| 247
> > ...
> > 
> > Is this the same issue as you are reporting (or related)?
> > 
> 
> At safety 3 this function compiles just fine.  At safty 1 I get an
> error earlier, in DFLOAT.lsp I see:
> 
> (DEFUN |DFLOAT;base;Pi;7| ($)
>   (PROG () (RETURN (FLOAT-RADIX '#<OBJNULL>))))
> 
> 
> Now, #<OBJNULL> is IMHO very strong indication of memory corruption
> (I see no legal way to produce it).  OTOH the vector (value of '#1')
> you see is clearly wrong in this place, but it looks like normal
> Axiom domain vector.  So ATM it not clear if both failures are related.

\start
Date: Fri, 13 Jul 2007 20:44:04 +0200
From: Ralf Hemmecke
To: Stephen Wilson
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

See below...

>> Try this:  testu2.spad
>> -------
>> )abbrev domain BAR Bar
>>
>> Bar() : Exp == Impl where
>>    Exp == with
>>      inj1 : Integer -> %
>>      inj2 : Integer -> %
>>      prj : % -> Integer
>>    Impl == add
>>      Rep := Union(tag1: Integer, tag2: Integer)
>>      inj1 (n : Integer) : % == [n]
>>      inj2 (s : Integer) : % == [2*s]
>>      prj p == (p::Rep).tag1
>> -------
>> After compiling,
>>
>> (4) -> i1:= inj1 1
>>
>>  LISP output:
>> (0 . 1)
>>                                                                     Type: Bar
>> (5) -> i2:= inj2 1
>>
>>  LISP output:
>> (0 . 2)
>>                                                                     Type: Bar
>> (6) -> prj i1
>>
>>    (6)  1
>>                                                         Type: PositiveInteger
>> (7) -> prj i2
>>
>>    (7)  2
>>                                                         Type: PositiveInteger
>>
> 
>> Note the answer is even *correct*! Axiom should have signaled a failure or error.

In Aldor you would have written that as

---BEGIN aaa.as
#pile
#include "aldor"
#include "aldorio"

Bar : Exp == Impl where
   Exp ==> with
     inj1 : Integer -> %
     inj2 : Integer -> %
     prj1 : % -> Integer
     prj2 : % -> Integer
   Impl ==> add
     Rep == Union(tag1: Integer, tag2: Integer)
     import from Rep
     inj1(n : Integer) : % == per [tag1==n]
     inj2(s : Integer) : % == per [tag2==2*s]
     prj1(p: %): Integer == (rep p).tag1
     prj2(p: %): Integer == (rep p).tag2

main(): () == {
   z: Integer := 1;
   b1: Bar := inj1 z;
   b2: Bar := inj2 z;
   stdout << "prj1 b1 = " << prj1 b1 << newline;
   stdout << "prj2 b2 = " << prj2 b2 << newline;
   stdout << "prj1 b2 = " << prj1 b2 << newline;
}
main();
---END aaa.as

woodpecker:~>aldor -fx -laldor aaa.as
woodpecker:~>aaa
prj1 b1 = 1
prj2 b2 = 2
Unhandled Exception: RuntimeError()
(Aldor error) Bad union branch.
prj1 b2 = woodpecker:~>

Does that make someone more happy?

\start
Date: Fri, 13 Jul 2007 21:10:33 +0200
From: Ralf Hemmecke
To: William Sit
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

>> So you can see from your example that i1 and i2 give, respectively,
>>  (0 . 1) and (0 . 2), thus inj1 and inj2 are placing their values
>> in the tag1 field.
> 
> This simple representation limits the generality and naturalness of
> implementation. But where are the tags?


Compile the following program with
aldor -flsp -fc -laldor aaa.as
and grep generated the lisp and c sources for "tag1".
You will not find it.

Why do you think that limits the generality of the implementation. Why
do you think "tag1" is important in generated code?

If you create something of the form Union(foo:Integer,bar:Integer) you
get exactly the same representation in the generated file, but still as
aldor code you cannot turn an element of

Union(foo:Integer,bar:Integer)

into

Union(tag1:Integer,tag2:Integer)

since these are two different types.

Ralf

-----------------
#pile
#include "aldor"
#include "aldorio"

Bar : Exp == Impl where
  Exp ==> with
    inj1 : Integer -> %
    prj1 : % -> Integer
  Impl ==> add
    Rep == Union(tag1: Integer, tag2: Integer)
    import from Rep
    inj1(n : Integer) : % == per [tag1==n]
    prj1(p: %): Integer == (rep p).tag1

main(): () == {
  z: Integer := 1;
  b1: Bar := inj1 z;
  stdout << "prj1 b1 = " << prj1 b1 << newline;
}
main();
-------------------

\start
Date: Fri, 13 Jul 2007 21:56:32 +0200
From: Ralf Hemmecke
To: William Sit
Subject: Re: Unions in Spad

> However, there is another problem: the signature of the index map
>      g: I->List SetCategory
> has syntax problem. (So, alas, all my examples inherit this problem.) A list (more
> correctly, a set) of domains in the SetCategory is NOT a domain and hence cannot be used as
> the target of a map. So we have to turn a list or set into a domain, much like turning a
> list of tags into a domain (TagsAsDomain).  Here however, we are one level higher because
> we are trying to make a set of *domains* such as {Integer, String} into a domain.
> 
> While there is probably a way to do this in Lisp, the question is how should a user of
> Axiom input this map g? It looks like we need to capture this at the algebra level and make
> all these maps into a domain, too. So domains and perhaps even categories must be first
> class objects. Unfortunately, even the domain Any does not capture sets of domains as
> objects.  This despite the Rep for Any is Record(dm:SExpression, ob:None). The Interpreter
> refuses to convert domains into objects of Any.
> 
> -> (1) k:List Any:= [Integer, String]
> 
>     Cannot convert an element of the construct to type Any.

Interesting. Now you also stumble over the same problem.

http://www.aldor.org/pipermail/aldor-l/2007-June/000640.html

\start
Date: Fri, 13 Jul 2007 23:18:40 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Gcl-2.6.8 on Intel Solaris 10
Cc: Camm Maguire

I have now found reason for wrong results on Intel Solaris 10.
Namely, gcl compiled some floating point functions assuming
that the machine is big endian.

So, one got:

>(floor 8.5)

0
8.5

The code to do conversion looks brittle -- it uses unions to
do "type convesion", which probably violates C aliasing rules.
Also setting parametrs in system specific configuration files
does not look like best method (2.7.0 apparently uses different
method to determine if the machine is big endian).

So good fix would probably clean the gcl code a little.  However,
below is almost minimal patch in the style used in 2.6.8.  It
solves the 'floor' problems -- in fact it seems that when this
patch is applied there is no regression in Axiom compared to
Linux.

--- gcl/h/solaris-i386.h	Thu Jul 12 22:30:08 2007
+++ gcl_m/h/solaris-i386.h	Fri Jul 13 22:19:10 2007
@@ -1,3 +1,6 @@
+#define I386
+#define LITTLE_END
+
 #define ElfW(a) Elf32_ ## a
 #if !defined(HAVE_LIBBFD) && !defined(USE_DLOPEN)
 #define __ELF_NATIVE_CLASS 32

\start
Date: 13 Jul 2007 17:26:19 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: re: debugging

Greetings!  

Previous message a false alarm, as my fresh build just failed, though
not with any segfault.  Again, but in a different place:

(DEFUN |DFLOAT;base;Pi;7| ($)
  (PROG ()
    (RETURN
      (FLOAT-RADIX
          '#1=#((|DoubleFloat|)
                (#<compiled-function |lookupComplete|> #1#


Same function that you found with the objnull.  Question -- what
function(s) write this source?

\start
Date: 13 Jul 2007 17:41:02 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: Re: Gcl-2.6.8 on Intel Solaris 10

Greetings, and thanks!  This is in now in Version_2_6_8pre.

(more extensive cleanups hopfully forthcoming in 2.7)

Take care,

Waldek Hebisch writes:

> I have now found reason for wrong results on Intel Solaris 10.
> Namely, gcl compiled some floating point functions assuming
> that the machine is big endian.
> 
> So, one got:
> 
> >(floor 8.5)
> 
> 0
> 8.5
> 
> The code to do conversion looks brittle -- it uses unions to
> do "type convesion", which probably violates C aliasing rules.
> Also setting parametrs in system specific configuration files
> does not look like best method (2.7.0 apparently uses different
> method to determine if the machine is big endian).
> 
> So good fix would probably clean the gcl code a little.  However,
> below is almost minimal patch in the style used in 2.6.8.  It
> solves the 'floor' problems -- in fact it seems that when this
> patch is applied there is no regression in Axiom compared to
> Linux.
> 
> --- gcl/h/solaris-i386.h	Thu Jul 12 22:30:08 2007
> +++ gcl_m/h/solaris-i386.h	Fri Jul 13 22:19:10 2007
> @@ -1,3 +1,6 @@
> +#define I386
> +#define LITTLE_END
> +
>  #define ElfW(a) Elf32_ ## a
>  #if !defined(HAVE_LIBBFD) && !defined(USE_DLOPEN)
>  #define __ELF_NATIVE_CLASS 32
> 
\start
Date: Fri, 13 Jul 2007 17:29:46 -0500
From: Tim Daly
To: list
Subject: Literate Programming
Cc: David Bindel

Having reread what I wrote about David Bindel's literate tool dsbweb
I want to clarify that I classified the tool as semi-literate. I was
not, and never intended to imply, that David was semi-literate. That
is reasonably clear but I just want to make it exactly clear.

\start
Date: Sat, 14 Jul 2007 01:02:07 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: re: debugging

> Greetings!  
> 
> Previous message a false alarm, as my fresh build just failed, though
> not with any segfault.  Again, but in a different place:
> 
> (DEFUN |DFLOAT;base;Pi;7| ($)
>   (PROG ()
>     (RETURN
>       (FLOAT-RADIX
>           '#1=#((|DoubleFloat|)
>                 (#<compiled-function |lookupComplete|> #1#
> 
> 
> Same function that you found with the objnull.  Question -- what
> function(s) write this source?
> 

There are several functions involved.  In case of #<OBJNULL> using
traces I see that |compDefineCapsuleFunction| function (defined
in 'define.boot.pamphlet') gets:

 1> (|compDefineCapsuleFunction|
         (DEF (|base|) (NIL) (NIL)
              ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|))))
...
...


It seems that (|elt| $ (|Zero|)) give us '#<OBJNULL>.  |elt| is
handled in 'compiler.boot.pamphlet':


    2> (|compForm1| ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|)))

      3> (|compElt| (|elt| $ (|Zero|)) |$EmptyMode|
....
....
      <3 (|compElt|
             ((|call| (XLAM |ignore| '#<OBJNULL>)) $

\start
Date: 13 Jul 2007 19:39:01 -0400
From: Stephen Wilson
To: Stephen Wilson
Subject: Re: 2.7 build
Cc: Camm Maguire

Sorry for the delay on this!

I have collected a set of patches which I belive approximate what we
need to get Silver building atop gclcvs-2.7.0 in ANSI mode.  I am
still having issues during the final rebuild of the databases, but the
algebra as a whole compiles.

This patchset does not represent the absolute minimum of changes
necessary for the build.  But it strives to be fairly lightweight.

A large number of the changes are temporary workarounds and need
better solutions.

Waldek, I belive wh-sandbox might address some of these issues
properly.  Perhaps we can use this patchset as a baseline to recover
some of the wh-sandbox efforts and present a changeset for Silver in
time?



To make use of the patch get a fresh checkout of Silver and then:

     cd silver && patch -p1 < silver-gclcvs.patch



Notes about the patchset:


!!!!
One needs to have the latest gclcvs-2.7.0 built and installed in your
$PATH.  The makefiles assume the existance of the command `gcl'.  The
image used to build the system (obj/${SYS}/bin/lisp) is generated via
COMPILER::LINK, with the necessary axiom objects included, and
SI::*DISABLE-RECOMPILE* set to T.

Moreover, if gcl is updated, it suffices to do a `rm lsp/gcldir' to
eliminate a tag file used to indicate the build image has been
generated.  Upon remake, the new gcl in $PATH will be used to link a
fresh image, with minimal recompilation of the tree.
!!!!


The build does not use interp-proclaims.lisp, nor generate *.fn's,
nor invokes COMPILER::MAKE-PROCLAIMS.

sys-pkg.lisp is reworked, and is not in a final form.  Some conflicts
exist in the original silver code, so this file needs a subset of
these changes.  More generally, the bulk of the work is to use
DEFPACKAGE, and to name the symbols therin by strings.  This is a
personal preference as a great many symbols are mixed case in the
axiom code base.  I find the strings "FOOBAR" and "FooBar" easier to
distinguish than 'foobar and '|FooBar|, and I belive this usage might
reduce the chance for programmer error. In addition, the BOOT package
is devoid of exports, as it has no clients.  I am not commited to the
overall form of this change, as it is a result of lifting the diff
from a personal branch.

I eliminated calls to SI::ALLOCATE as I found the current calls
resulted in some issues during debugging.  These calls need to be
retooled. 

A few changes were needed due to incompatabilities with the new
pathname semantics.  In particular, *DEFAULT-PATHNAME-DEFAULTS* is
left untouched.  Other temporary changes were needed until we can
normalize Axioms handling of pathnames.

An unnecessary change but one included regardless is the factoring out
of a few functions previously defined in FLET's in daase.lisp.pamphlet.
This is simply an aid for debugging purposes.

Certain changes were needed in the algebra.  For some reason Spad
functions of the form:
    foo(n: Integer): Integer ==
       if zero? n then
         x := 1
       else
         x := 2
       x
do not compile, and need an explicit type declaration at the points of
assignment to x.  This needs to be fixed.

I needed to tweek the algebra layers in one case as I found an
autoload dependency conflict.  I have yet to analyze this case.

The file allfact.spad apparently has an algebra bug which needs to be
fixed, but was not picked up < 2.7.0 builds.  I simply hacked in a
change which allows the build to progress.  I recently posted an email
to axiom-developer regarding this issue. See:
 http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00270.html

Aside from a few mismatched parens, special declarations, and the
removal of some minor bitrot, thats pretty much it.



And of course, I can try to answer any further questions, and help
address any outstanding/overlooked issues.




Sincerley,
Steve



--=-=-=

diff --git a/Makefile b/Makefile
index 86c7905..8503293 100644
--- a/Makefile
+++ b/Makefile
@@ -14,8 +14,9 @@ LSP=${SPD}/lsp
 #GCLVERSION=gcl-2.6.6
 #GCLVERSION=gcl-2.6.7pre
 #GCLVERSION=gcl-2.6.7
-GCLVERSION=gcl-2.6.8pre
+#GCLVERSION=gcl-2.6.8pre
 #GCLVERSION=gcl-2.6.8pre2
+GCLVERSION=gclcvs
 AWK=gawk
 GCLDIR=${LSP}/${GCLVERSION}
 SRC=${SPD}/src
@@ -147,3 +148,4 @@ clean:
 	@ for i in `find src -name "Makefile"` ; do rm -f $$i ; done
 	@ for i in `find src -name "Makefile.dvi"` ; do rm -f $$i ; done
 	@ rm -f lastBuildDate
+
diff --git a/Makefile.pamphlet b/Makefile.pamphlet
index 2109665..7b4a675 100644
--- a/Makefile.pamphlet
+++ b/Makefile.pamphlet
@@ -748,8 +748,9 @@ forget to erase the lsp/Makefile the wrong patches will be applied.
 #GCLVERSION=gcl-2.6.6
 #GCLVERSION=gcl-2.6.7pre
 #GCLVERSION=gcl-2.6.7
-GCLVERSION=gcl-2.6.8pre
+#GCLVERSION=gcl-2.6.8pre
 #GCLVERSION=gcl-2.6.8pre2
+GCLVERSION=gclcvs
 @
 
 \subsubsection{The [[GCLOPTS]] configure variable}
diff --git a/lsp/Makefile.pamphlet b/lsp/Makefile.pamphlet
index 4a2d3fb..17b8b06 100644
--- a/lsp/Makefile.pamphlet
+++ b/lsp/Makefile.pamphlet
@@ -1176,6 +1176,31 @@ clean:
 	@( cd ccl ; ${ENV} ${MAKE} clean )
 
 @
+\subsection{The gclcvs stanza}
+This stanza will be written when the GCLVERSION variable is
+``gclcvs''. It will overwrite the default version. See the 
+top level Makefile.pamphlet.
+
+<<gclcvs>>=
+# gcl version gclcvs
+OUT=${OBJ}/${SYS}/bin
+OBLIB=${OBJ}/${SYS}/lib
+LINKOBJECTS= ${OBLIB}/bsdsignal.o \
+	     ${OBLIB}/cfuns-c.o   \
+	     ${OBLIB}/sockio-c.o
+
+all:
+	@echo 1 building ${LSP} ${GCLVERSION}
+
+gcldir: 
+	@echo 2 building ${GCLVERSION}
+	@echo '(let ((si::*disable-recompile* t))' \
+	         '(compiler::link nil "${OUT}/lisp" nil "${LINKOBJECTS}"))' | gcl
+	@echo 13 finished system build on `date` | tee >gcldir
+
+clean:
+
+@
 \section{Gnu Common Lisp 2.5}
 GCL 2.5 requires a different Makefile. In particular, GCL 2.5
 has a different method of building the lisp image. And, just to
diff --git a/src/algebra/Makefile.pamphlet b/src/algebra/Makefile.pamphlet
index 987ea71..e0d2f54 100644
--- a/src/algebra/Makefile.pamphlet
+++ b/src/algebra/Makefile.pamphlet
@@ -692,7 +692,7 @@ plot.spad.pamphlet (PLOT PLOT1)
 <<layer15>>=
 
 LAYER15=\
-  ${OUT}/DIAGG.o   ${OUT}/DIAGG-.o   ${OUT}/DSMP.o     ${OUT}/EXPUPXS.o \
+  ${OUT}/DIAGG.o   ${OUT}/DIAGG-.o   ${OUT}/DSMP.o \
   ${OUT}/FRAMALG.o ${OUT}/FRAMALG-.o ${OUT}/MDAGG.o    ${OUT}/ODPOL.o   \
   ${OUT}/PLOT.o    ${OUT}/RMCAT2.o   ${OUT}/ROIRC.o    ${OUT}/SDPOL.o   \
   ${OUT}/SMATCAT.o ${OUT}/SMATCAT-.o ${OUT}/TUBETOOL.o ${OUT}/UPXSCCA.o \
@@ -1022,6 +1022,7 @@ taylor.spad.pamphlet (ITAYLOR UTS UTS2)
 <<layer21>>=
 
 LAYER21=\
+  ${OUT}/EXPUPXS.o \
   ${OUT}/DEFINTEF.o ${OUT}/DFINTTLS.o ${OUT}/DEFINTRF.o ${OUT}/D01TRNS.o  \
   ${OUT}/EFULS.o    ${OUT}/ESCONT.o   ${OUT}/EXPR.o     ${OUT}/EXPR2UPS.o \
   ${OUT}/FDIV.o     ${OUT}/FSCINT.o   ${OUT}/FSINT.o    ${OUT}/FS2EXPXP.o \
diff --git a/src/algebra/acplot.spad.pamphlet b/src/algebra/acplot.spad.pamphlet
index f4542d7..9a79cda 100644
--- a/src/algebra/acplot.spad.pamphlet
+++ b/src/algebra/acplot.spad.pamphlet
@@ -1151,6 +1151,7 @@ PlaneAlgebraicCurvePlot(): PlottablePlaneCurveCategory _
     x1 := xCoord p1; y1 := yCoord p1
     px := ground(eval(dpdxSF,[x,y],[x1,y1]))
     py := ground(eval(dpdySF,[x,y],[x1,y1]))
+    incVar0, incVar : Symbol
     -- let m be the slope of the tangent line at p1
     -- if |m| < 1, we will increment the x-coordinate by delta
     -- (indicated by 'incVar = x'), find an approximate
diff --git a/src/algebra/allfact.spad.pamphlet b/src/algebra/allfact.spad.pamphlet
index ccc9497..c399d2b 100644
--- a/src/algebra/allfact.spad.pamphlet
+++ b/src/algebra/allfact.spad.pamphlet
@@ -291,7 +291,7 @@ MPolyCatPolyFactorizer(E,OV,R,PPR) : C == T
 
 GeneralizedMultivariateFactorize(OV,E,S,R,P) : C == T
  where
-  R          :   IntegralDomain
+  R          :   GcdDomain
                     -- with factor on R[x]
   S          :   IntegralDomain
   OV    :   OrderedSet  with  
diff --git a/src/algebra/d02agents.spad.pamphlet b/src/algebra/d02agents.spad.pamphlet
index d3e18ec..dd45a6c 100644
--- a/src/algebra/d02agents.spad.pamphlet
+++ b/src/algebra/d02agents.spad.pamphlet
@@ -281,7 +281,7 @@ d02AgentsPackage(): E == I where
         b := ((# e) >= r-1)@Boolean       
       b =>
         -- if all the eigenvalues are real, find negative ones
-        e := sort(neglist(e)$ExpertSystemToolsPackage1(FI))
+        e : List FI := sort(neglist(e)$ExpertSystemToolsPackage1(FI))
         -- if there are two or more, calculate stiffness ratio
         ((n:=#e)>1)@Boolean => [coerce(e.1/e.n)@F,0$F] 
         -- otherwise stiffness not present
diff --git a/src/algebra/efstruc.spad.pamphlet b/src/algebra/efstruc.spad.pamphlet
index 6ac57be..6e6a2ff 100644
--- a/src/algebra/efstruc.spad.pamphlet
+++ b/src/algebra/efstruc.spad.pamphlet
@@ -413,7 +413,7 @@ ElementaryFunctionStructurePackage(R,F): Exports == Implementation where
       for i in 1..n for kk in rest ker repeat
         klist := first(ker, i)
         -- NO EVALUATION ON AN EMPTY VECTOR, WILL CAUSE INFINITE LOOP
-        (c := deprel(klist, kk, v)) case vec and not empty?(c.vec) =>
+        (c : U := deprel(klist, kk, v)) case vec and not empty?(c.vec) =>
           rec := depeval(f, klist, kk, c.vec)
           rn  := rischNormalize(rec.func, v)
           return [rn.func,
diff --git a/src/algebra/polycat.spad.pamphlet b/src/algebra/polycat.spad.pamphlet
index 01cbbcc..b9bd252 100644
--- a/src/algebra/polycat.spad.pamphlet
+++ b/src/algebra/polycat.spad.pamphlet
@@ -165,7 +165,7 @@ FiniteAbelianMonoidRing(R:Ring, E:OrderedAbelianMonoid): Category ==
           -- probably not a very good definition in most special cases
           zero? x => 0
           ans:% :=0
-          t:=leadingCoefficient x exquo r
+          t : Union(R, "failed") := leadingCoefficient x exquo r
           while not (t case "failed") and not zero? x repeat
             ans:=ans+monomial(t::R,degree x)
             x:=reductum x
diff --git a/src/algebra/transsolve.spad.pamphlet b/src/algebra/transsolve.spad.pamphlet
index 168619f..7c87f95 100644
--- a/src/algebra/transsolve.spad.pamphlet
+++ b/src/algebra/transsolve.spad.pamphlet
@@ -219,6 +219,7 @@ TransSolvePackage(R) : Exports == Implementation where
         radicalSolve(nlexpr, lvar)$RadicalSolvePackage(R)
 
      tryToTrans(lside: RE, x:S) : RE ==
+       resultLside : RE
        if testTrig(lside,x) or testHTrig(lside,x) then
           convLside:=( simplify(lside) )::RE
           resultLside:=convLside
diff --git a/src/boot/Makefile.pamphlet b/src/boot/Makefile.pamphlet
index c5ebb48..fe73a76 100644
--- a/src/boot/Makefile.pamphlet
+++ b/src/boot/Makefile.pamphlet
@@ -1263,6 +1263,7 @@ and the problem appears to be that each [[.o]] file has [[init_code]].
 Until this is fixed we need to continue to use the old scheme.
 <<environment>>= 
 CMD0=(progn \
+       ${PROCLAIMS} \
        (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) \
        (system::save-system "${SAVESYS}"))
  
diff --git a/src/interp/Makefile.pamphlet b/src/interp/Makefile.pamphlet
index 49f9cc4..c794fef 100644
--- a/src/interp/Makefile.pamphlet
+++ b/src/interp/Makefile.pamphlet
@@ -396,8 +396,7 @@ into the src/interp diretory (or boot, algebra).
 
 In order for this information to be used during compiles we define
 <<environment>>=
-PROCLAIMS=(progn (load "${OUT}/sys-pkg.lsp") \
-                 (load "${IN}/interp-proclaims.lisp"))
+PROCLAIMS=(progn (load "${OUT}/sys-pkg.lsp"))
 
 @
 
@@ -864,7 +863,6 @@ ${SAVESYS}:	${DEPSYS} ${OBJS} ${OUT}/bookvol5.${O} ${OUT}/util.${O} \
 	@ echo OBJ= ${OBJ} 
 	@ echo MNT= ${MNT} 
 	@ echo O=${O} LISP=${LISP} BYE=${BYE}
-	@ cp -p ${OUT}/*.fn ${MID}
 	@ cp -p ${SRC}/doc/msgs/s2-us.msgs ${SPAD}/doc/msgs
 #	@ cp -p ${SRC}/doc/msgs/co-eng.msgs ${SPAD}/doc/msgs
 	@ echo '${PROCLAIMS}' > ${OUT}/makeint.lisp
@@ -898,8 +896,6 @@ ${SAVESYS}:	${DEPSYS} ${OBJS} ${OUT}/bookvol5.${O} ${OUT}/util.${O} \
 	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' \
                 >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
-	@ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' \
-               >> ${OUT}/makeint.lisp
 	@ (cd ${OBJ}/${SYS}/bin ; \
 	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp")' \
                  '(gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
@@ -8575,11 +8571,11 @@ ${MNT}/${SYS}/algebra/exposed.${O} : ${MID}/exposed.lsp ${LISPSYS}
 	@ if [ -z "${NOISE}" ] ; then \
 	   echo '(progn  (compile-file "${MID}/exposed.lsp"' \
              ':output-file "${MNT}/${SYS}/algebra/exposed.${O}") (${BYE}))' \
-             | ${LISPSYS} ; \
+             | ${DEPSYS} ; \
 	  else \
 	   echo '(progn  (compile-file "${MID}/exposed.lsp"' \
              ':output-file "${MNT}/${SYS}/algebra/exposed.${O}") (${BYE}))' \
-             | ${LISPSYS} >${TMP}/trace ; \
+             | ${DEPSYS} >${TMP}/trace ; \
 	  fi
 
 ${OUT}/database.date:
diff --git a/src/interp/bookvol5.pamphlet b/src/interp/bookvol5.pamphlet
index 3c4465e..e32fec3 100644
--- a/src/interp/bookvol5.pamphlet
+++ b/src/interp/bookvol5.pamphlet
@@ -674,7 +674,7 @@ allow a function to be called. In our case it is the [[restart]]
 function which is the entry to the Axiom interpreter.
 <<defun set-restart-hook>>=
 (defun set-restart-hook ()
-  #+KCL (setq system::*top-level-hook* 'restart)
+  #+:GCL (setq system::*top-level-hook* #'restart)
   #+Lucid (setq boot::restart-hook 'restart)
   'restart
  )
@@ -697,9 +697,6 @@ The [[compiler::*suppress-compiler-notes*]] flag has been set to t.
 We do not care that tail recursion occurs.
 <<defun restart>>=
 (defun restart ()
-#+:akcl
-  (init-memory-config :cons 500 :fixnum 200 :symbol 500 :package 8
-    :array 400 :string 500 :cfun 100 :cpages 3000 :rpages 1000 :hole 2000)
 #+:akcl (setq compiler::*compile-verbose* nil)
 #+:akcl (setq compiler::*suppress-compiler-warnings* t)
 #+:akcl (setq compiler::*suppress-compiler-notes* t)
@@ -736,13 +733,15 @@ We do not care that tail recursion occurs.
   (setq *default-pathname-defaults* "")
 #+:CCL
   (setq *default-pathname-defaults* (get-current-directory))
-#-(or :CCL (and :lucid :ibm/370))
+#-(or :GCL :CCL (and :lucid :ibm/370))
   (setq *default-pathname-defaults* (probe-file "./"))
 #+(and :lucid :ibm/370)
   (setq vmlisp::$current-directory "")
 #-(and :lucid :ibm/370)
   (setq vmlisp::$current-directory
      (make-directory *default-pathname-defaults*))
+#+:GCL
+  (setq vmlisp::$current-directory *default-pathname-defaults*)
   (|loadExposureGroupData|)
   (|statisticsInitialization|)
   (|initHist|)
@@ -1175,6 +1174,7 @@ where the [[${SYS}]] variable is the same one set at build time.
   (setq |$defaultMsgDatabaseName|
 	(pathname (make-absolute-filename "/doc/msgs/s2-us.msgs")))
   (setq |$msgDatabaseName| ())
+  #-:GCL
   (setq *default-pathname-defaults*
 	(pathname (make-absolute-filename "")))
   (setq $current-directory $spadroot))
@@ -4642,6 +4642,7 @@ undo(l) ==
 \end{verbatim}
 <<defun undo>>=
 (defun |undo| (l)
+ (declare (special |$options| |$InteractiveFrame|))
  (prog (tmp1 key s undoWhen n)
   (return
    (progn
@@ -5235,6 +5236,7 @@ removeUndoLines u == --called by writeInputLines
 \end{verbatim}
 <<defun removeUndoLines>>=
 (defun |removeUndoLines| (u)
+ (declare (special |$currentLine| |$IOindex|))
  (prog (xtra savedIOindex s s1 m s2 x code c n y acc)
   (return
    (seq
diff --git a/src/interp/comp.lisp.pamphlet b/src/interp/comp.lisp.pamphlet
index f822aad..7e8bf7e 100644
--- a/src/interp/comp.lisp.pamphlet
+++ b/src/interp/comp.lisp.pamphlet
@@ -374,8 +374,6 @@
   (let (u)
     (cond ((ATOM X) NIL)
           ((eq (setq U (CAR X)) 'QUOTE) NIL)
-          ((AND (eq U 'MAKEPROP) $TRACELETFLAG (RPLAC (CAR X) 'MAKEPROP-SAY) NIL)
-           NIL)
            ; temporarily make TRACELET cause MAKEPROPs to be reported
           ((MEMQ U '(DCQ RELET PRELET SPADLET SETQ LET) )
            (COND ((NOT (eq U 'DCQ))
diff --git a/src/interp/daase.lisp.pamphlet b/src/interp/daase.lisp.pamphlet
index e0c20a7..b3ff3c4 100644
--- a/src/interp/daase.lisp.pamphlet
+++ b/src/interp/daase.lisp.pamphlet
@@ -815,13 +815,11 @@ database.
 (defun |library| (args)
  (declare (special |$options|))
  (declare (special |$newConlist|))
- (setq original-directory (get-current-directory))
  (setq |$newConlist| nil)
- (localdatabase args |$options|)
-#+:CCL
- (dolist (a args) (check-module-exists a))
- (|extendLocalLibdb| |$newConlist|)
- (system::chdir original-directory)
+ (let ((original-directory (get-current-directory)))
+   (localdatabase args |$options|)
+   (|extendLocalLibdb| |$newConlist|)
+   (system::chdir original-directory))
  (tersyscommand))
 
 ;; check-module-exists looks to see if a module exists in one of the current
@@ -853,10 +851,7 @@ database.
 ;  .asy
 ;  .ao, then asharp to .asy
 
-(defun localdatabase (filelist options &optional (make-database? nil))
- "read a local filename and update the hash tables"
- (labels (
-  (processOptions (options)
+(defun processOptions (options)
    (let (only dir noexpose)
     (when (setq only (assoc '|only| options))
      (setq options (lisp::delete only options :test #'equal))
@@ -865,23 +860,24 @@ database.
      (setq options (lisp::delete dir options :test #'equal))
      (setq dir (second dir))
      (when (null dir)
-      (|sayKeyedMsg| 'S2IU0002 nil) ))
+      (|sayKeyedMsg| 'S2IU0002 nil)))
     (when (setq noexpose (assoc '|noexpose| options))
      (setq options (lisp::delete noexpose options :test #'equal))
-     (setq noexpose 't) )
+     (setq noexpose 't))
     (when options
      (format t "   Ignoring unknown )library option: ~a~%" options))
     (values only dir noexpose)))
-  (processDir (dirarg thisdir)
+
+(defun processDir (dirarg thisdir)
    (let (allfiles skipasos)
     (system:chdir (string dirarg))
-    (setq allfiles (directory "*"))
+    (setq allfiles (directory "*.nrlib/*"))
     (system:chdir thisdir)
     (values
      (mapcan #'(lambda (f)
-      (when (string-equal (pathname-type f) "nrlib")
-       (list (concatenate 'string (namestring f) "/"
-			  vmlisp::*index-filename*)))) allfiles)
+      (when (string-equal (pathname-type f) "kaf")
+        (list f)))
+      allfiles)
      (mapcan #'(lambda (f)
       (when (string= (pathname-type f) "asy")
        (push (pathname-name f) skipasos)
@@ -899,7 +895,10 @@ database.
        (list (namestring f))))
      allfiles)
 #-:CCL nil
-    ))))
+    )))
+
+(defun localdatabase (filelist options &optional (make-database? nil))
+ "read a local filename and update the hash tables"
  (let (thisdir nrlibs asos asys libs object only dir key 
       (|$forceDatabaseUpdate| t) noexpose)
   (declare (special |$forceDatabaseUpdate|))
@@ -910,7 +909,7 @@ database.
   (if make-database? (setq noexpose t))
   (when dir (multiple-value-setq (nrlibs asys asos libs) (processDir dir thisdir)))
   (dolist (file filelist)
-   (let ((filename (pathname-name file))
+   (let ((filename (pathname-name (symbol-name file)))
 	 (namedir (directory-namestring file)))
     (unless namedir (setq thisdir (concatenate 'string thisdir "/")))
     (cond
@@ -941,7 +940,7 @@ database.
    (asharp file)
    (setq file (|astran| (concatenate 'string (pathname-name file) ".asy")))
    (localasy file object only make-database? noexpose))
-  (HCLEAR |$ConstructorCache|))))
+  (HCLEAR |$ConstructorCache|)))
 
 (defun localasy (asy object only make-database? noexpose)
  "given an alist from the asyfile and the objectfile update the database"
@@ -1549,46 +1548,47 @@ Here I'll try to outline the interp database write procedure
   (princ "                              " out)
   (finish-output out)
   (dolist (constructor (|allConstructors|))
-   (let (struct)
-    (setq struct (get constructor 'database))
-    (setq opalistpos (file-position out))
-    (print (squeeze (database-operationalist struct)) out)
-    (finish-output out)
-    (setq cmodemappos (file-position out))
-    (print (squeeze (database-constructormodemap struct)) out)
-    (finish-output out)
-    (setq modemapspos (file-position out))
-    (print (squeeze (database-modemaps struct)) out)
-    (finish-output out)
-    (if (consp (database-object struct)) ; if asharp code ...
-     (setq obj
-      (cons (pathname-name (car (database-object struct)))
-            (cdr (database-object struct))))
-     (setq obj
-      (pathname-name
-        (first (last (pathname-directory (database-object struct)))))))
-    (setq concategory (squeeze (database-constructorcategory struct)))
-    (if concategory  ; if category then write data else write nil
-     (progn
-      (setq categorypos (file-position out))
-      (print concategory out)
-      (finish-output out))
-     (setq categorypos nil))
-    (setq niladic (database-niladic struct))
-    (setq abbrev (database-abbreviation struct))
-    (setq cosig (database-cosig struct))
-    (setq kind (database-constructorkind struct))
-    (setq defaultdomain (database-defaultdomain struct))
-    (setq ancestors (squeeze (gethash constructor *ancestors-hash*))) ;cattable.boot
-    (if ancestors
-     (progn
-      (setq ancestorspos (file-position out))
-      (print ancestors out)
-      (finish-output out))
-     (setq ancestorspos nil))
-    (push (list constructor opalistpos cmodemappos modemapspos
-      obj categorypos niladic abbrev cosig kind defaultdomain
-      ancestorspos) master)))
+    (let (struct)
+      (setq struct (get constructor 'database))
+      (when (database-object struct)
+        (setq opalistpos (file-position out))
+        (print (squeeze (database-operationalist struct)) out)
+        (finish-output out)
+        (setq cmodemappos (file-position out))
+        (print (squeeze (database-constructormodemap struct)) out)
+        (finish-output out)
+        (setq modemapspos (file-position out))
+        (print (squeeze (database-modemaps struct)) out)
+        (finish-output out)
+        (if (consp (database-object struct)) ; if asharp code ...
+            (setq obj
+                  (cons (pathname-name (car (database-object struct)))
+                        (cdr (database-object struct))))
+            (setq obj
+                  (pathname-name
+                   (first (last (pathname-directory (database-object struct)))))))
+        (setq concategory (squeeze (database-constructorcategory struct)))
+        (if concategory  ; if category then write data else write nil
+            (progn
+              (setq categorypos (file-position out))
+              (print concategory out)
+              (finish-output out))
+            (setq categorypos nil))
+        (setq niladic (database-niladic struct))
+        (setq abbrev (database-abbreviation struct))
+        (setq cosig (database-cosig struct))
+        (setq kind (database-constructorkind struct))
+        (setq defaultdomain (database-defaultdomain struct))
+        (setq ancestors (squeeze (gethash constructor *ancestors-hash*))) ;cattable.boot
+        (if ancestors
+            (progn
+              (setq ancestorspos (file-position out))
+              (print ancestors out)
+              (finish-output out))
+            (setq ancestorspos nil))
+        (push (list constructor opalistpos cmodemappos modemapspos
+                    obj categorypos niladic abbrev cosig kind defaultdomain
+                    ancestorspos) master))))
   (finish-output out)
   (setq masterpos (file-position out))
   (print (mapcar #'squeeze master) out)
diff --git a/src/interp/debug.lisp.pamphlet b/src/interp/debug.lisp.pamphlet
index 9a9e613..1490eaa 100644
--- a/src/interp/debug.lisp.pamphlet
+++ b/src/interp/debug.lisp.pamphlet
@@ -106,7 +106,6 @@ exit (rds ifile)
 ; PURPOSE: Debugging hooks for Boot code
  
 (in-package "BOOT")
-(use-package '("LISP" "VMLISP"))
  
 (DEFPARAMETER /COUNTLIST NIL)
 (DEFPARAMETER /TIMERLIST NIL)
@@ -187,13 +186,13 @@ exit (rds ifile)
   (PROG (FT oft SFN X EDINFILE FILE DEF KEY RECNO U W SOURCEFILES
 	 ECHOMETA SINGLINEMODE XCAPE XTOKENREADER INPUTSTREAM SPADERRORSTREAM
 	 ISID NBLNK COMMENTCHR $TOKSTACK (/SOURCEFILES |$sourceFiles|)
-	 METAKEYLST DEFINITION_NAME (|$sourceFileTypes| '(|spad| |boot| |lisp| |lsp| |meta|))
+	 DEFINITION_NAME (|$sourceFileTypes| '(|spad| |boot| |lisp| |lsp| |meta|))
 	 ($FUNCTION FN) $BOOT $NEWSPAD $LINESTACK $LINENUMBER STACK STACKX BACK OK
 	 TRAPFLAG |$InteractiveMode| TOK COUNT ERRCOL COLUMN *QUERY CHR LINE
 	 (*COMP370-APPLY* (if (eq op 'define) #'eval-defun #'compile-defun)))
 	(declare (special ECHOMETA SINGLINEMODE XCAPE XTOKENREADER INPUTSTREAM
 		     SPADERRORSTREAM ISID NBLNK COMMENTCHR $TOKSTACK /SOURCEFILES
-		     METAKEYLST DEFINITION_NAME |$sourceFileTypes|
+		     DEFINITION_NAME |$sourceFileTypes|
 		     $FUNCTION $BOOT $NEWSPAD $LINESTACK $LINENUMBER STACK STACKX BACK OK
 		     TRAPFLAG |$InteractiveMode| TOK COUNT ERRCOL COLUMN *QUERY CHR LINE))
         (if (PAIRP FN) (SETQ FN (QCAR FN)))
diff --git a/src/interp/debugsys.lisp.pamphlet b/src/interp/debugsys.lisp.pamphlet
index 7f4fa95..6b25f1a 100644
--- a/src/interp/debugsys.lisp.pamphlet
+++ b/src/interp/debugsys.lisp.pamphlet
@@ -261,8 +261,6 @@ loaded by hand we need to establish a value.
 (load (user::thepath "/int/interp/obey.lsp"))
 ;(si::multiply-bignum-stack 10)
 (si::gbc-time 0)
-(setq si::*system-directory* 
-  (user::thepath (concatenate 'string "/mnt/" *sys* "/bin/")))
 (gbc t)
 
 @
diff --git a/src/interp/define.boot.pamphlet b/src/interp/define.boot.pamphlet
index 0f2dc03..b40d2c1 100644
--- a/src/interp/define.boot.pamphlet
+++ b/src/interp/define.boot.pamphlet
@@ -376,7 +376,7 @@ compDefineFunctor1(df is ['DEF,form,signature,$functorSpecialCases,body],
                   --prevents CheckVector from printing out same message twice
     $getDomainCode: local := nil -- code for getting views
     $insideFunctorIfTrue: local:= true
-    $functorsUsed: local := nil --not currently used, finds dependent functors
+--  $functorsUsed: local := nil --not currently used, finds dependent functors
     $setelt: local :=
       $QuickCode = true => 'QSETREFV
       'SETELT
@@ -1282,7 +1282,7 @@ doIt(item,$predl) ==
          $functorLocalParameters:= [:$functorLocalParameters,lhs]
     if code is ['LET,.,rhs',:.] and isDomainForm(rhs',$e) then
       if isFunctor rhs' then
-        $functorsUsed:= insert(opOf rhs',$functorsUsed)
+--      $functorsUsed:= insert(opOf rhs',$functorsUsed)
         $packagesUsed:= insert([opOf rhs'],$packagesUsed)
       if lhs="Rep" then
         $Representation:= (get("Rep",'value,$e)).(0)
diff --git a/src/interp/foam_l.lisp.pamphlet b/src/interp/foam_l.lisp.pamphlet
index a4e1932..60b2bf0 100644
--- a/src/interp/foam_l.lisp.pamphlet
+++ b/src/interp/foam_l.lisp.pamphlet
@@ -168,7 +168,7 @@
 
 
 ;; type defs for Foam types
-(deftype |Char| () 'string-char)
+(deftype |Char| () 'character)
 (deftype |Clos| () 'list)
 (deftype |Bool| () '(member t nil))
 (deftype |Byte| () 'unsigned-byte)
diff --git a/src/interp/macros.lisp.pamphlet b/src/interp/macros.lisp.pamphlet
index 117408c..44a6d3e 100644
--- a/src/interp/macros.lisp.pamphlet
+++ b/src/interp/macros.lisp.pamphlet
@@ -126,8 +126,6 @@ ends up being [[CONTAINED |$EmptyMode| Y]].
 <<*>>=
 <<license>>
 
-(provide 'Boot)
- 
 (in-package "BOOT")
  
 (defvar |$compilingMap| ())
@@ -1673,7 +1671,8 @@ terminals and empty or at-end files.  In Common Lisp, we must assume record size
 ; (2) with possible line breaks within a;
 ; (3) otherwise display without a brace
   `(LET
-    ((state))
+    ((state) (ht (make-hash-table)))
+    (declare (special ht))
     (setq state (|saveState| 't))
     (or
       (markhash ,b 0)
diff --git a/src/interp/metalex.lisp.pamphlet b/src/interp/metalex.lisp.pamphlet
index 00f1b76..958ce34 100644
--- a/src/interp/metalex.lisp.pamphlet
+++ b/src/interp/metalex.lisp.pamphlet
@@ -194,7 +194,7 @@ empty (if File-Closed (return nil))
         (t                                                      'special-char)))
  
 (defun make-adjustable-string (n)
-  (make-array (list n) :element-type 'string-char :adjustable t))
+  (make-array (list n) :element-type 'standard-char :adjustable t))
 
 (defun get-identifier-token (token)
   "Take an identifier off the input stream."
diff --git a/src/interp/monitor.lisp.pamphlet b/src/interp/monitor.lisp.pamphlet
index 03ab46d..7e68de0 100644
--- a/src/interp/monitor.lisp.pamphlet
+++ b/src/interp/monitor.lisp.pamphlet
@@ -511,7 +511,7 @@ for example:
  (eval `(trace (,name :cond (progn (monitor-incr ',name) nil))))
  (setf (gethash name *monitor-table*)
   (make-monitor-data 
-     :name name :count 0 :monitorp t :sourcefile sourcefile)))))
+     :name name :count 0 :monitorp t :sourcefile sourcefile)))
 
 (defun monitor-delete (fn)
  "delete a function from the monitor table"
diff --git a/src/interp/nlib.lisp.pamphlet b/src/interp/nlib.lisp.pamphlet
index 482bcb9..9be8dfe 100644
--- a/src/interp/nlib.lisp.pamphlet
+++ b/src/interp/nlib.lisp.pamphlet
@@ -431,7 +431,7 @@ but has been changed to read:
 	      (string filearg)))))))
 
 (defun make-full-namestring (filearg &optional (filetype nil))
-  (namestring (merge-pathnames (make-filename filearg filetype))))
+  (namestring (merge-pathnames (make-filename filearg filetype) (truename "."))))
 
 (defun probe-name (file)
   (if (probe-file file) (namestring file) nil))
diff --git a/src/interp/parsing.lisp.pamphlet b/src/interp/parsing.lisp.pamphlet
index cce7470..d1a0b2b 100644
--- a/src/interp/parsing.lisp.pamphlet
+++ b/src/interp/parsing.lisp.pamphlet
@@ -556,7 +556,7 @@ the stack, then stack a NIL. Return the value of prod."
   (if (every #'alpha-char-p string) string
     (let* ((size (length string))
 	   (out-string (make-array (* 2 size)
-				   :element-type 'string-char
+				   :element-type 'standard-char
 				   :fill-pointer 0))
 	   next-char)
       (dotimes (i size)
@@ -689,7 +689,7 @@ is a token separator, which blank is equivalent to."
 
 (defun make-string-adjustable (s)
   (cond ((adjustable-array-p s) s)
-        (t (make-array (array-dimensions s) :element-type 'string-char
+        (t (make-array (array-dimensions s) :element-type 'standard-char
                        :adjustable t :initial-contents s))))
 
 (defun get-a-line (stream)
diff --git a/src/interp/sfsfun-l.lisp.pamphlet b/src/interp/sfsfun-l.lisp.pamphlet
index c7c992e..00e6ce1 100644
--- a/src/interp/sfsfun-l.lisp.pamphlet
+++ b/src/interp/sfsfun-l.lisp.pamphlet
@@ -76,10 +76,10 @@
 (defun rpsi      (n x)         (|rPsi|     n x) )
 (defun cpsi      (n z) (c-to-s (|cPsi|     n (s-to-c z)) ))
 
-(defun rbesselj  (n x) (c-to-r (|BesselJ| n x)) ))
+(defun rbesselj  (n x) (c-to-r (|BesselJ| n x)) )
 (defun cbesselj  (v z) (c-to-s (|BesselJ| (s-to-c v) (s-to-c z)) ))
  
-(defun rbesseli  (n x) (c-to-r (|BesselI| n x)) ))
+(defun rbesseli  (n x) (c-to-r (|BesselI| n x)) )
 (defun cbesseli  (v z) (c-to-s (|BesselI| (s-to-c v) (s-to-c z)) ))
 
 (defun chyper0f1 (a z) (c-to-s (|chebf01| (s-to-c a) (s-to-c z)) ))
diff --git a/src/interp/sockio.lisp.pamphlet b/src/interp/sockio.lisp.pamphlet
index c58f2cf..f56999c 100644
--- a/src/interp/sockio.lisp.pamphlet
+++ b/src/interp/sockio.lisp.pamphlet
@@ -266,10 +266,7 @@ resolve the problem
   )
 
 (setq |$NaNvalue| (NANQ))
-#-:ccl
-  (setq |$plusInfinity| (* 1.1  MOST-POSITIVE-LONG-FLOAT))
-#+:ccl
-  (setq |$plusInfinity| MOST-POSITIVE-LONG-FLOAT)
+(setq |$plusInfinity| MOST-POSITIVE-LONG-FLOAT)
 (setq |$minusInfinity| (- |$plusInfinity|))
 
 @
diff --git a/src/interp/sys-pkg.lisp.pamphlet b/src/interp/sys-pkg.lisp.pamphlet
index 850237d..a880c5b 100644
--- a/src/interp/sys-pkg.lisp.pamphlet
+++ b/src/interp/sys-pkg.lisp.pamphlet
@@ -41,37 +41,111 @@ We create all of the known packages here.
 <<*>>=
 <<license>>
 
+@ Towards ANSI compliance.  We need the name of the package which
+exports the standard Lisp symbols.  In a CLtL1 Lisp, these symbols
+exist in the LISP package.  For ANSI, COMMON-LISP is defined.
+<<*>>=
+(eval-when (:compile-toplevel :load-toplevel :execute)
+  (defconstant +standard-lisp-package+ 
+    (if (find-package "COMMON-LISP")
+        "COMMON-LISP"
+        "LISP")))
+
 @
 The spad compiler package. Although I believe this is a dead
 package at this point. All of the symbols from this package
 have been moved into the boot package.
 <<*>>=
-(make-package "SCRATCHPAD_COMPILER")
+(defpackage "SCRATCHPAD-COMPILER"
+    (:use #.+standard-lisp-package+))
 @
 The special functions package. There was originally lisp code
 to support hardcoded knowledge of special functions like gamma.
 This is also a dead package as the functions have been lifted
 to the algebra level.
 <<*>>=
-(make-package "SPECFNSF")
+(defpackage "SPECFNSF")
 
 @
 This is the package that originally contained the VMLisp macros
 but in fact contains macros to support several other lisps. It
 is essentially the place where most of the macros to support
 idioms from prior ports (like rdefiostream and fileactq)
+
 <<*>>=
-(make-package "VMLISP")
-(in-package "VMLISP")
-(lisp::use-package '("USER" "SYSTEM" "LISP"))
+(defpackage "VMLISP"
+  (:use #.+standard-lisp-package+)
+  #+:GCL
+  (:import-from "LISP"
+                "ALLOCATE" "BYE" "CLINES" 
+                "DEFENTRY" "DOUBLE" "GBC" 
+                "INT" "OBJECT" "SYSTEM")
+  #+GCL
+  (:import-from "SYSTEM"
+                "GETENV" "MEMQ")
+  (:export 
+   "$CLEAR" "$CURRENT-DIRECTORY" "$DIRECTORY-LIST" "$ERASE" "$FCOPY" "$FILEP"
+   "$FILETYPE-TABLE" "$FINDFILE" "$INFILEP" "$LIBRARY-DIRECTORY-LIST" "$LISTFILE"
+   "$OUTFILEP" "$REPLACE" "$SCREENSIZE" "$SHOWLINE" "$SPADROOT"
+   "$TOTAL-ELAPSED-TIME" "$TOTAL-GC-TIME" "$defaultMsgDatabaseName"
+   "$msgDatabaseName" "*COMP370-APPLY*" "*FILEACTQ-APPLY*" "*LISP-BIN-FILETYPE*"
+   "*LISP-SOURCE-FILETYPE*" "ABSVAL" "ADD1" "ADDOPTIONS" "ALLOCATE" "APPLX" 
+   "ASSEMBLE" "ASSQ" "BFP" "BINTP" "BOOLEANP" "BPINAME" "BYE" "CALLBELOW" "CATCHALL"
+   "CGREATERP" "CHANGELENGTH" "CHAR2NUM" "CHARP" "CLINES" "CLOSEDFN" "COMP370"
+   "COMPILE-LIB-FILE" "COMPRREAD" "COMPRWRITE" "CONCAT" "CONSOLE" "CONSTANT"
+   "COPY" "CREATE-SBC" "CURINSTREAM" "CUROUTSTREAM" "CURRENTTIME" "CURRINDEX"
+   "CVEC" "CVECP" "DCQ" "DEFENTRY" "DEFINE-FUNCTION" "DEFIOSTREAM" "DEVICE"
+   "DIFFERENCE" "DIG2FIX" "DIGITP" "DIVIDE" "DOUBLE" "DOWNCASE" "DSETQ" "EBCDIC"
+   "ECQ" "EFFACE" "EMBED" "EMBEDDED" "EOFP" "EQCAR" "EQQ" "EQSUBSTLIST"
+   "ERRORINSTREAM" "ERROROUTSTREAM" "EVA1" "EVA1FUN" "EVALANDFILEACTQ" "EVALFUN"
+   "EXIT" "F,PRINT-ONE" "FBPIP" "FETCHCHAR" "FILE" "FIX" "FIXP" "FLUID" "FUNARGP"
+   "GBC" "GCMSG" "GENSYMP" "GETENV" "GETFULLSTR" "GETL" "GETREFV" "GETSTR"
+   "GGREATERP" "GREATERP" "HASHCVEC" "HASHEQ" "HASHID" "HASHTABLE-CLASS"
+   "HASHTABLEP" "HASHUEQUAL" "HCLEAR" "HCOUNT" "HGET" "HKEYS" "HPUT" "HPUT*"
+   "HPUTPROP" "HREM" "HREMPROP" "I" "ID" "IDENTP" "IFCAR" "IFCDR" "INPUT" "INT"
+   "INT2RNUM" "INTERSECTIONQ" "INTP" "IOSTATE" "IS-CONSOLE" "IVECP" "KOMPILE"
+   "L-CASE" "LAM" "LAM,EVALANDFILEACTQ" "LAM,FILEACTQ" "LASTNODE" "LASTPAIR"
+   "LC2UC" "LENGTHOFBPI" "LESSP" "LEXGREATERP" "LINTP" "LISPLIB" "LIST2REFVEC"
+   "LIST2VEC" "LISTOFFLUIDS" "LISTOFFREES" "LISTOFFUNCTIONS" "LISTOFQUOTES" "LN"
+   "LOADCOND" "LOADVOL" "LOG2" "MACERR" "MACRO-INVALIDARGS" "MACRO-MISSINGARGS"
+   "MAKE-ABSOLUTE-FILENAME" "MAKE-APPENDSTREAM" "MAKE-BVEC" "MAKE-CVEC"
+   "MAKE-FILENAME" "MAKE-FULL-CVEC" "MAKE-HASHTABLE" "MAKE-INPUT-FILENAME"
+   "MAKE-INSTREAM" "MAKE-OUTSTREAM" "MAKE-VEC" "MAKEPROP" "MAKESTRING" "MAPELT"
+   "MAXINDEX" "MBPIP" "MDEF" "MDEFX" "MEMQ" "MINUS" "MLAMBDA" "MODE" "MOVEVEC"
+   "MRP" "MSUBST" "MSUBSTQ" "NAMEDERRSET" "NCONC2" "NE" "NEQ" "NEXT" "NILFN"
+   "NREMOVE" "NREMOVEQ" "NULLOUTSTREAM" "NUM2CHAR" "NUMBEROFARGS" "NUMP" "O"
+   "OBEY" "OBJECT" "ONE-OF" "OPTIONLIST" "ORADDTEMPDEFS" "OUTPUT" "PAIRP" "PAPPP"
+   "PLACEP" "PLUS" "PNAME" "POPP" "PRETTYPRIN0" "PRETTYPRINT" "PRIN0" "PRIN2CVEC"
+   "PRINTEXP" "PROPLIST" "PUT" "QASSQ" "QCAAAAR" "QCAAADR" "QCAAAR" "QCAADAR"
+   "QCAADDR" "QCAADR" "QCAAR" "QCADAAR" "QCADADR" "QCADAR" "QCADDAR" "QCADDDR"
+   "QCADDR" "QCADR" "QCAR" "QCDAAAR" "QCDAADR" "QCDAAR" "QCDADAR" "QCDADDR"
+   "QCDADR" "QCDAR" "QCDDAAR" "QCDDADR" "QCDDAR" "QCDDDAR" "QCDDDDR" "QCDDDR"
+   "QCDDR" "QCDR" "QCSIZE" "QENUM" "QEQQ" "QESET" "QLENGTH" "QMEMQ" "QREFELT"
+   "QRPLACA" "QRPLACD" "QRPLQ" "QSABSVAL" "QSADD1" "QSDEC1" "QSDIFFERENCE"
+   "QSETQ" "QSETREFV" "QSETVELT" "QSETVELT-1" "QSGREATERP" "QSINC1" "QSLEFTSHIFT"
+   "QSLESSP" "QSMAX" "QSMIN" "QSMINUS" "QSMINUSP" "QSODDP" "QSORT" "QSPLUS"
+   "QSQUOTIENT" "QSREMAINDER" "QSSUB1" "QSTIMES" "QSTRINGLENGTH" "QSZEROP"
+   "QUOTIENT" "QVELT" "QVELT-1" "QVMAXINDEX" "QVSIZE" "RCLASS" "RCOPYITEMS"
+   "RDEFIOSTREAM" "RDROPITEMS" "RE-ENABLE-INT" "RECLAIM" "RECOMPILE-DIRECTORY"
+   "RECOMPILE-LIB-FILE-IF-NECESSARY" "REFVECP" "REMAINDER" "REMOVEQ" "REROOT"
+   "RESETQ" "RKEYIDS" "RNUMP" "RPACKFILE" "RPLACSTR" "RPLNODE" "RPLPAIR" "RPLQ"
+   "RREAD" "RSETCLASS" "RSHUT" "RVECP" "RWRITE" "SEQ" "SETANDFILEQ"
+   "SETDIFFERENCE" "SETDIFFERENCEQ" "SETELT" "SETQP" "SETSIZE" "SFP" "SHUT"
+   "SINTP" "SIZE" "SMINTP" "SORTBY" "SORTGREATERP" "STACKLIFO" "STATEP" "STRCONC"
+   "STRGREATERP" "STRING2ID-N" "STRINGIMAGE" "STRINGLENGTH" "STRPOS" "STRPOSL"
+   "SUB1" "SUBLOAD" "SUBRP" "SUBSTQ" "SUBSTRING" "SUFFIX" "SYSTEM" "TAB"
+   "TEMPUS-FUGIT" "TEREAD" "THROW-PROTECT" "TIMES" "TRIMSTRING" "TRUEFN" "U-CASE"
+   "UEQUAL" "UNEMBED" "UNIONQ" "UPCASE" "USE-VMLISP-SYNTAX" "VEC-SETELT"
+   "VEC2LIST" "VECP" "VM/" "VMPRINT" "VMREAD" "assoc" "directoryp" "idChar?"
+   "intersection" "last" "log" "member" "nsubst" "read-line" "remove" 
+   "shoeInputFile" "shoeread-line" "startsId?" "union"))
 
 @
 This is the boot to lisp compiler package which contains the
 src/boot files. Tt is the boot translator package.
 <<*>>=
-(make-package "BOOTTRAN")
-(in-package "BOOTTRAN")
-(lisp::use-package '("LISP"))
+(defpackage "BOOTTRAN"
+  (:use #.+standard-lisp-package+))
 
 @
 Everything in axiom that the user references eventually shows
@@ -79,9 +153,8 @@ up here. The interpreter and the algebra are run after switching
 to the boot package (in-package "BOOT") so any symbol that the
 interpreter or algebra uses has to (cough, cough) appear here.
 <<*>>=
-(make-package "BOOT")
-(in-package "BOOT")
-(lisp::use-package '("VMLISP" "LISP"))
+(defpackage "BOOT"
+  (:use #.+standard-lisp-package+ "VMLISP"))
 
 @
 FOAM is the intermediate language for the aldor compiler. FOAM
@@ -90,987 +163,17 @@ RTL for the GCC compiler. It is a "machine" that is used as the
 target for meta-assembler level statments. These are eventually
 expanded for the real target machine (or interpreted directly)
 <<*>>=
-(make-package "FOAM")
-(in-package "FOAM")
-(lisp::use-package '("LISP"))
+(defpackage "FOAM"
+  (:use #.+standard-lisp-package+))
 
 @
 FOAM-USER is the package containing foam statements and macros
 that get inserted into user code versus the foam package which
 provides support for compiler code.
 <<*>>=
-(make-package "FOAM-USER")
-(in-package "FOAM-USER")
-(lisp::use-package '("LISP" "FOAM"))
-
-(lisp:in-package "BOOT")
-
-(lisp:import
-    '(VMLISP::ERROROUTSTREAM LISP::COUNT VMLISP::NE VMLISP::FLUID
-	 LISP:SEQUENCE VMLISP::OBEY LISP:NUMBER VMLISP::|union|
-	 LISP:STEP VMLISP::OPTIONLIST VMLISP::EXIT VMLISP::throw-protect
-<<GCL.GETENV>>
-         VMLISP::GET-CURRENT-DIRECTORY VMLISP::AXIOM-PROBE-FILE
-         VMLISP::*INDEX-FILENAME*))
-(lisp:export
-    '(BOOT::|$FormalMapVariableList| BOOT::|$userModemaps|
-	 boot::restart boot::$IEEE
-	 BOOT::|directoryp| boot::help boot::|version| boot::|pp|
-	 BOOT::POP-STACK-4 BOOT::|$BasicDomains| BOOT::|$DomainFrame|
-	 BOOT::|$SideEffectFreeFunctionList|
-	 BOOT::ATOM2STRING BOOT::|$DoubleQuote| BOOT::|$genSDVar|
-	 BOOT::GETCHARN BOOT::DROP VMLISP::ERROROUTSTREAM
-	 BOOT::MATCH-STRING BOOT::|$fromSpadTrace|
-	 BOOT::|$UserSynonyms| BOOT::%L BOOT::FLUIDVARS
-	 BOOT::/EMBEDREPLY BOOT::|$LocalFrame| BOOT::|$streamIndexing|
-	 BOOT::APPLYR BOOT::NEXTINPUTLINE BOOT::$NORMALSTRING
-	 BOOT::|$InteractiveTimingStatsIfTrue| BOOT::|$leaveLevelStack|
-	 BOOT::|$xyMin| BOOT::|lcm| BOOT::STRINGSUFFIX
-	 BOOT::|Category| BOOT::ESCAPE-CHARACTER
-	 LISP:COUNT BOOT::|break| BOOT::$DIRECTORY
-	 BOOT::CONVERSATION BOOT::|fillerSpaces|
-	 BOOT::$REVERSEVIDEOSTRING BOOT::|$DomainsInScope|
-	 BOOT::|$gauss01| BOOT::|$mostRecentOpAlist| BOOT::SUBLISLIS
-	 BOOT::QUITFILE BOOT::|PrintBox| BOOT::POP-REDUCTION
-	 BOOT::META-SYNTAX-ERROR BOOT::|$constructorInfoTable|
-	 BOOT::|$currentLine| BOOT::|$Float| BOOT::|$slamFlag|
-	 BOOT::|$SmallIntegerOpt| BOOT::$SPAD BOOT::|$timerOn|
-	 BOOT::$TRACELETFLAG VMLISP::NE BOOT::ADJCURMAXINDEX
-	 BOOT::STREAM-BUFFER BOOT::SPADSLAM BOOT::$EM
-	 BOOT::|$PositiveIntegerOpt| BOOT::THETA BOOT::READ-QUIETLY
-	 BOOT::RS BOOT::|$compUniquelyIfTrue|
-	 BOOT::|$insideExpressionIfTrue| BOOT::LE BOOT::KAR BOOT::ELEM
-	 BOOT::LASTATOM BOOT::IN-STREAM BOOT::$DELAY
-	 BOOT::QSEXPT BOOT::|$quadSymbol| BOOT::|$streamAlist|
-	 BOOT::|$SymbolOpt| BOOT::TAKE BOOT::CONSOLEINPUTP
-	 BOOT::|$hasYield| BOOT::DEBUGMODE BOOT::|$DummyFunctorNames|
-	 BOOT::|$PositiveInteger| BOOT::%D VMLISP::FLUID BOOT::TLINE
-	 BOOT::|$abbreviationTable| BOOT::|$FontTable|
-	 BOOT::|$PatternVariableList| BOOT::|$returnMode| BOOT::NEQUAL
-	 BOOT::GE BOOT::|MakeSymbol| BOOT::|$insideWhereIfTrue|
-	 BOOT::|$mapSubNameAlist| BOOT::GETCHAR BOOT::|Gaussian|
-	 BOOT::IDENTIFIER BOOT::|$LastCxArg| BOOT::|$systemCommands|
-	 BOOT::|$true| BOOT::SETANDFILE BOOT::PUSH-REDUCTION
-	 BOOT::|$BigFloat| BOOT::|$brightenCommentsFlag|
-	 BOOT::|$cacheCount| BOOT::|$exitModeStack| BOOT::|$noEnv|
-	 BOOT::|$NonPositiveIntegerOpt| BOOT::PUTGCEXIT
-	 BOOT::|$readingFile|
-	 BOOT::IS BOOT::KDR BOOT::|$quadSym| BOOT::|$BreakMode|
-	 BOOT::$TOKSTACK BOOT::DEFSTREAM BOOT::LOCVARS BOOT::NTH-STACK
-	 BOOT::$UNDERLINESTRING BOOT::|$compCount|
-	 BOOT::|$lisplibModemapAlist| BOOT::COMP BOOT::LINE
-	 BOOT::GETGENSYM BOOT::$FUNNAME BOOT::|$SystemSynonyms|
-	 BOOT::|$spadOpList| BOOT::GENERAL BOOT::|$fortranOutputStream|
-	 BOOT::META_PREFIX BOOT::|$InteractiveMode| BOOT::|strconc|
-	 BOOT::TAILFN BOOT::RPLACW BOOT::|PositiveInteger|
-	 BOOT::|$inactiveLisplibs| BOOT::|$NonPositiveInteger|
-	 BOOT::|$reportCoerceIfTrue|
-	 BOOT::|sayBrightlyNT| BOOT::NEXT-CHAR boot::|sayString|
-	 BOOT::META_ERRORS_OCCURRED BOOT::|$resolveFlag|
-	 BOOT::|$StringOpt| BOOT::|UnivariatePoly| BOOT::MATCH-TOKEN
-	 BOOT::|$createUpdateFiles| BOOT::|$noParseCommands|
-	 BOOT::FLAGP BOOT::ECHO-META BOOT::|initializeSetVariables|
-	 BOOT::|$CategoryNames| BOOT::?ORDER
-	 BOOT::$FILELINENUMBER BOOT::|$timerTicksPerSecond|
-	 BOOT::|bootUnionPrint| BOOT::|$consistencyCheck|
-	 BOOT::|$oldTime| BOOT::$NEWSPAD BOOT::NUMOFNODES
-	 BOOT::|$ResMode| BOOT::S* BOOT::TRANSPGVAR BOOT::$BOXSTRING
-	 BOOT::|$BasicPredicates| BOOT::|$eltIfNil| BOOT::$FUNNAME_TAIL
-	 BOOT::|$QuickCode| BOOT::GENVAR BOOT::|$TypeEqui|
-	 BOOT::TOKEN-TYPE BOOT::|updateSourceFiles| BOOT::|$BFtag|
-	 BOOT::|$reportBottomUpFlag| BOOT::|$SmallInteger|
-	 BOOT::|$TypeEQ| BOOT::|Boolean| BOOT::|RationalNumber|
-	 BOOT::MAKENEWOP BOOT::|$EmptyList| BOOT::|$leaveMode|
-	 BOOT::MKQ BOOT::ON BOOT::CONTAINED BOOT::|conOutStream|
-	 BOOT::POINTW BOOT::REDUCTION-POP-ELT BOOT::TOKEN-SYMBOL
-	 BOOT::ERRCOL BOOT::|$domainTraceNameAssoc| BOOT::SUBSTEQ
-	 BOOT::DELASSOS BOOT::|Size| BOOT::|$form|
-	 BOOT::|$insideCategoryIfTrue| BOOT::SUCHTHAT BOOT::|One|
-	 BOOT::ACTION BOOT::MDEFTRACE BOOT::|$BooleanOpt|
-	 BOOT::|$xyStack| BOOT::ASSOCLEFT BOOT::|sayALGEBRA|
-	 BOOT::|Coord| BOOT::IDENTIFIER-TOKEN BOOT::ADVANCE-CHAR
-	 BOOT::|$InitialDomainsInScope| BOOT::|$StringCategory|
-	 BOOT::S- BOOT::NEWLINE BOOT::|$optimizableDomainNames|
-	 BOOT::IN BOOT::COLLECTV BOOT::|$Lisp|
-	 BOOT::|$lisplibOperationAlist| BOOT::|$reportExitModeStack|
-	 BOOT::|$updateCatTableIfTrue| BOOT::NREVERSE0 BOOT::%M
-	 BOOT::|sayFORTRAN| BOOT::NEWLINECHR BOOT::|$EmptyMode|
-	 BOOT::|$Zero| BOOT::CARCDREXPAND BOOT::|IS_#GENVAR|
-	 BOOT::LISTOFATOMS BOOT::|$algebraOutputStream|
-	 BOOT::|$highlightAllowed| BOOT::|NonNegativeInteger|
-	 BOOT::/EMBED-1
-	 BOOT::|$constructorsNotInDatabase| BOOT::|$ConstructorNames|
-	 BOOT::|$Integer| BOOT::|$systemModemapsInCore| BOOT::KADDR
-	 BOOT::STAR BOOT::|$reportCompilation|
-	 BOOT::|$traceNoisely| BOOT::SPADDIFFERENCE BOOT::%B
-	 BOOT::COMMENT-CHARACTER BOOT::|$PrettyPrint| BOOT::SPADLET
-	 BOOT::|$ModemapFrame| BOOT::|$QuickLet| BOOT::SPADDO
-	 BOOT::PREDECESSOR BOOT::*EOF* BOOT::POP-STACK-1 BOOT::BANG
-	 BOOT::|$ConstructorCache| BOOT::|$printConStats|
-	 BOOT::|$RationalNumberOpt| BOOT::RESET
-	 BOOT::NLIST BOOT::NSTRCONC BOOT::TAIL BOOT::GETRULEFUNLISTS
-	 BOOT::|$IntegerOpt| BOOT::$NEWLINSTACK BOOT::|$QuietIfNil|
-	 BOOT::$SPAD_ERRORS BOOT::|$useDCQnotLET| BOOT::|$xCount|
-	 BOOT::$BOOT BOOT::POINT BOOT::OPTIONAL BOOT::PARSE-IDENTIFIER
-	 BOOT::BSTRING-TOKEN BOOT::LASTELEM BOOT::STREAM-EOF
-	 BOOT::|sayBrightly| BOOT::|$formulaOutputStream|
-	 BOOT::|BigFloat| BOOT::SLAM BOOT::$DISPLAY
-	 BOOT::|$NonMentionableDomainNames| BOOT::$OLDLINE BOOT::$TYPE
-	 BOOT::STATUS BOOT::KEYFN BOOT::|$NonNegativeIntegerOpt|
-	 BOOT::|$userConstructors| BOOT::BOOT-NEQUAL BOOT::RPLAC
-	 BOOT::GETTAIL BOOT::|QuotientField| BOOT::CURRENT-TOKEN
-	 BOOT::|$suffix| BOOT::|$VariableCount| BOOT::COMPARE
-	 LISP:SEQUENCE BOOT::|$Exit| BOOT::BOOT-EQUAL BOOT::LT
-	 VMLISP::OBEY BOOT::|UnSizedBox| BOOT::|Integer| BOOT::|Nud|
-	 BOOT::IOCLEAR BOOT::|$BigFloatOpt| BOOT::|$EmptyEnvironment|
-	 BOOT::|$forceDatabaseUpdate| BOOT::$LINESTACK BOOT::ULCASEFG
-	 BOOT::|$Boolean| BOOT::|$clamList| BOOT::COLLECT
-	 BOOT::IOSTREAMS-SET BOOT::MUST BOOT::|$FloatOpt|
-	 BOOT::|$NonNegativeInteger|
-	 BOOT::FLAG BOOT::TL BOOT::BLANKS BOOT::|$report3|
-	 BOOT::|$reportFlag| BOOT::|$xeditIsConsole| BOOT::PAIR
-	 BOOT::|$evalDomain| BOOT::|$traceletFunctions| BOOT::|$Void|
-	 BOOT::GT BOOT::MATCH-ADVANCE-STRING
-	 BOOT::|$scanModeFlag| BOOT::SUBLISNQ BOOT::LASSQ BOOT::NOTE
-	 BOOT::ILAM BOOT::CURRENT-SYMBOL
-	 BOOT::|$SetFunctions| BOOT::|$sourceFileTypes| BOOT::|String|
-	 BOOT::NUMBER-TOKEN BOOT::$LINENUMBER BOOT::$NUM_OF_META_ERRORS
-	 BOOT::|$Polvar| BOOT::|$domainsWithUnderDomains|
-	 BOOT::SPADCALL BOOT::DELASC BOOT::FAIL BOOT::$COMPILE
-	 BOOT::|$lastUntraced| BOOT::|$lisplibKind|
-	 BOOT::|$tracedModemap| BOOT::|$inputPromptType| BOOT::LASSOC
-	 LISP:NUMBER BOOT::|$prefix| BOOT::|$TranslateOnly| BOOT::SAY
-	 BOOT::|$CategoryFrame| BOOT::|$croakIfTrue| BOOT::|$exitMode|
-	 BOOT::|$lisplibDependentCategories| BOOT::|$NoValue|
-	 BOOT::MOAN BOOT::POP-STACK-2 BOOT::BAC
-	 BOOT::|$InitialModemapFrame| BOOT::$MAXLINENUMBER
-	 BOOT::$ESCAPESTRING BOOT::|$bootStrapMode|
-	 BOOT::|$compileMapFlag| BOOT::|$currentFunction|
-	 BOOT::|$DomainNames| BOOT::|$PolyMode| BOOT::|$tripleCache|
-	 BOOT::SUCHTHATCLAUSE BOOT::WHILE BOOT::S+ BOOT::|Expression|
-	 BOOT::PARSE-NUMBER BOOT::|$Index| BOOT::$NBOOT
-	 BOOT::|$PrintCompilerMessagesIfTrue| BOOT::$PROMPT
-	 BOOT::MAKE-PARSE-FUNCTION BOOT::/METAOPTION BOOT::|$topOp|
-	 BOOT::|$xyInitial| BOOT::MKPF BOOT::STRM
-	 BOOT::MATCH-NEXT-TOKEN BOOT::|pathname| BOOT::|$cacheAlist|
-	 BOOT::$FUNCTION BOOT::|$reportSpadTrace|
-	 BOOT::|$tempCategoryTable| BOOT::|$underDomainAlist|
-	 BOOT::|$whereList| BOOT::|append| BOOT::|function|
-	 BOOT::CURINPUTLINE BOOT::|sayFORMULA|
-	 BOOT::/GENVARLST BOOT::|$Category| BOOT::|$SpecialDomainNames|
-	 VMLISP::|union| BOOT::ASSOCRIGHT BOOT::CURSTRMLINE
-	 BOOT::REDUCTION BOOT::|$lisplibDomainDependents|
-	 BOOT::|OptionList| BOOT::|$postStack| BOOT::|$traceDomains|
-	 BOOT::BRIGHTPRINT BOOT::|$instantRecord|
-	 BOOT::|$NETail| BOOT::UNTIL BOOT::GET-TOKEN
-	 BOOT::|$Expression| BOOT::$LASTPREFIX BOOT::|$mathTraceList|
-	 BOOT::|$PrintOnly| BOOT::ELEMN BOOT::NILADIC
-	 BOOT::PARSE-BSTRING BOOT::/DEPTH BOOT::|$spadLibFT|
-	 BOOT::|$xyMax| BOOT::|$IOindex| BOOT::SPADCONST
-	 BOOT::|sayBrightlyI| BOOT::|SquareMatrix|
-	 BOOT::LASTTAIL
-	 BOOT::|UnboundBox| BOOT::NEXT-TOKEN
-	 BOOT::|$OutsideStringIfTrue| BOOT::|$String| BOOT::TRIMLZ
-	 BOOT::KADR BOOT::STRMBLANKLINE BOOT::STRMSKIPTOBLANK
-	 BOOT::IOSTAT BOOT::|$insideCoerceInteractiveHardIfTrue|
-	 BOOT::|$lisplibSignatureAlist| BOOT::REMFLAG BOOT::SPADREDUCE
-	 BOOT::QLASSQ BOOT::NEXTSTRMLINE BOOT::|FontTable| BOOT::|Led|
-	 BOOT::UNGET-TOKENS BOOT::|$operationNameList|
-	 BOOT::|$tokenCommands| BOOT::IS_GENVAR BOOT::INIT-RULES
-	 BOOT::|PrintItem| BOOT::$LISPLIB BOOT::|$optionAlist|
-	 BOOT::|$previousTime| BOOT::|$StreamIndex|
-	 BOOT::|$systemLisplibsWithModemapsInCore|
-	 BOOT::|$tracedSpadModemap| BOOT::ISTEP BOOT::|$warningStack|
-	 BOOT::|and| BOOT::OUT-STREAM BOOT::TOKEN
-	 BOOT::|$ConstructorDependencyAlist|
-	 BOOT::|$lisplibVariableAlist| BOOT::INTERNL BOOT::IEQUAL
-	 BOOT::|$algebraList| BOOT::|$brightenCommentsIfTrue|
-	 BOOT::|$failure| BOOT::|$Mode| BOOT::|$opFilter|
-	 BOOT::|$TraceFlag| BOOT::|Float| BOOT::POP-STACK-3
-	 BOOT::|$EmptyString| BOOT::$TOP_STACK BOOT::|$mpolyTTrules|
-	 BOOT::|$mpolyTMrules| BOOT::|$InteractiveFrame|
-	 BOOT::|$InteractiveModemapFrame| BOOT::|$letAssoc|
-	 BOOT::|$lisp2lispRenameAssoc| BOOT::|$RationalNumber|
-	 BOOT::|$ThrowAwayMode| BOOT::*PROMPT* BOOT::NUMOFARGS
-	 BOOT::|$semanticErrorStack| BOOT::|$spadSystemDisks|
-	 BOOT::$TOP_LEVEL BOOT::BUMPCOMPERRORCOUNT
-	 BOOT::|delete| BOOT::STREQ BOOT::STRING-TOKEN BOOT::XNAME
-	 BOOT::|$ExpressionOpt| BOOT::|$systemCreation| BOOT::$GENNO
-	 BOOT::CROAK BOOT::PARSE-STRING BOOT::|$genFVar|
-	 BOOT::|$lisplibModemap| BOOT::|$NoValueMode| BOOT::|$PrintBox|
-	 BOOT::ADVANCE-TOKEN BOOT::|$NegativeIntegerOpt|
-	 BOOT::|$polyDefaultAssoc| BOOT::|$PrimitiveDomainNames|
-	 LISP:STEP BOOT::|rassoc| BOOT::|$Res|
-	 BOOT::MATCH-CURRENT-TOKEN BOOT::/GENSYMLIST BOOT::|$false|
-	 BOOT::|$ignoreCommentsIfTrue| BOOT::|$ModeVariableList|
-	 BOOT::|$useBFasDefault| BOOT::|$CommonDomains|
-	 BOOT::|$printLoadMsgs| BOOT::|dataCoerce| BOOT::|$inLispVM|
-	 BOOT::|$streamCount|
-	 BOOT::|$Symbol| BOOT::|$updateIfTrue| BOOT::REMDUP
-	 BOOT::ADDASSOC BOOT::|PrintList|
-	 BOOT::SPECIAL-CHAR BOOT::XCAPE BOOT::|$EmptyVector|
-	 BOOT::REPEAT BOOT::|$NegativeInteger|
-	 BOOT::LENGTHENVEC BOOT::CURMAXINDEX BOOT::|$hasCategoryTable|
-	 BOOT::|$leftPren| BOOT::|$lisplibForm| BOOT::|$OneCoef|
-	 BOOT::|$reportCoerce| VMLISP::OPTIONLIST BOOT::META
-	 BOOT::|$insideCapsuleFunctionIfTrue|
-	 BOOT::|$insideConstructIfTrue| BOOT::$BOLDSTRING
-	 BOOT::|breaklet| BOOT::|$insideCompTypeOf|
-	 BOOT::|$rightPren|
-	 BOOT::|$systemLastChanged| BOOT::|$xyCurrent| BOOT::|Zero|
-	 BOOT::YIELD BOOT::|Polynomial| BOOT::|$Domain| BOOT::STRINGPAD
-	 BOOT::TRUNCLIST BOOT::|SmallInteger| BOOT::|$libFile|
-	 BOOT::|$mathTrace| BOOT::|$PolyDomains| BOOT::|or|
-	 BOOT::|$DomainVariableList| BOOT::|$insideFunctorIfTrue|
-	 BOOT::|$One| VMLISP::EXIT BOOT::CURRENT-CHAR BOOT::NBLNK
-	 BOOT::$DALYMODE))
-
-;;; Definitions for package VMLISP of type EXPORT
-(lisp:in-package "VMLISP")
-(lisp:import '(
-<<GCL.DEFINE-MACRO>>
-<<GCL.MEMQ>>
-<<GCL.PNAME>>
-	  BOOT:|directoryp|))
-(lisp:export
-    '(VMLISP::SINTP VMLISP::$FCOPY 
-<<GCL.DEFINE-MACRO>>
-<<GCL.MEMQ>>
-<<GCL.PNAME>>
-         VMLISP::PUT
-	 VMLISP::QVELT-1 VMLISP::QSETVELT-1 vmlisp::throw-protect
-	 VMLISP::|directoryp| VMLISP::EQCAR
-	 VMLISP::DEFIOSTREAM VMLISP::RDEFIOSTREAM VMLISP::MLAMBDA
-	 VMLISP::QSLESSP VMLISP::QSDIFFERENCE VMLISP::QSQUOTIENT
-	 VMLISP::ERROROUTSTREAM VMLISP::CREATE-SBC VMLISP::LASTPAIR
-	 VMLISP::EQSUBSTLIST VMLISP::QCAAAR VMLISP::$TOTAL-ELAPSED-TIME
-	 VMLISP::QUOTIENT VMLISP::SORTGREATERP
-	 VMLISP::QSETREFV VMLISP::QSTRINGLENGTH VMLISP::EVALFUN
-	 VMLISP::QCDAR VMLISP::TEMPUS-FUGIT VMLISP::QSPLUS VMLISP::QSABSVAL
-	 VMLISP::QSZEROP VMLISP::QSMIN VMLISP::QSLEFTSHIFT
-	 VMLISP::SETDIFFERENCE VMLISP::RPLQ VMLISP::CATCHALL
-	 VMLISP::RECOMPILE-DIRECTORY VMLISP::MDEF VMLISP::LINTP
-	 VMLISP::NILFN VMLISP::TAB VMLISP::QCDDR VMLISP::IOSTATE
-	 VMLISP::SFP VMLISP::NE VMLISP::STRGREATERP
-	 VMLISP::USE-VMLISP-SYNTAX VMLISP::RCLASS 
-	 VMLISP::SEQ VMLISP::FIXP VMLISP::MAKE-CVEC
-	 VMLISP::|F,PRINT-ONE| VMLISP::HASHUEQUAL VMLISP::$OUTFILEP
-	 VMLISP::TIMES VMLISP::DIFFERENCE VMLISP::MSUBST VMLISP::DIVIDE
-	 VMLISP::|remove| VMLISP::GETL VMLISP::QCADAR VMLISP::QCAAAAR
-	 VMLISP::RECLAIM VMLISP::ORADDTEMPDEFS VMLISP::NAMEDERRSET
-	 VMLISP::TRIMSTRING VMLISP::CURRINDEX VMLISP::EVALANDFILEACTQ
-	 VMLISP::LISPLIB VMLISP::FLUID VMLISP::MDEFX VMLISP::COMP370
-	 VMLISP::NEQ VMLISP::GETREFV VMLISP::|log| VMLISP::QVSIZE
-	 VMLISP::MBPIP VMLISP::RPLNODE VMLISP::QSORT
-	 VMLISP::PLACEP VMLISP::RREAD VMLISP::BINTP VMLISP::QSODDP
-	 VMLISP::O VMLISP::RVECP VMLISP::CHAR2NUM VMLISP::POPP
-	 VMLISP::QCDAADR VMLISP::HKEYS VMLISP::HASHCVEC VMLISP::HASHID
-	 VMLISP::REMOVEQ VMLISP::LISTOFFUNCTIONS
-	 VMLISP::QCADAAR VMLISP::ABSVAL VMLISP::VMPRINT
-	 VMLISP::MAKE-APPENDSTREAM
-	 VMLISP::MAKE-INSTREAM VMLISP::HASHTABLEP VMLISP::UPCASE
-	 VMLISP::LOADCOND VMLISP::STRPOSL VMLISP::STATEP VMLISP::QCDADR
-	 VMLISP::HREMPROP VMLISP::LAM VMLISP::FBPIP VMLISP::NCONC2
-	 VMLISP::GETFULLSTR VMLISP::I VMLISP::HREM
-	 VMLISP::*LISP-BIN-FILETYPE* VMLISP::INT2RNUM VMLISP::EBCDIC
-	 VMLISP::$INFILEP VMLISP::BFP VMLISP::NUMP VMLISP::UNEMBED
-	 VMLISP::PAIRP VMLISP::BOOLEANP VMLISP::FIX VMLISP::REMAINDER
-	 VMLISP::RE-ENABLE-INT VMLISP::QCAADDR VMLISP::QCDDADR
-	 VMLISP::$LISTFILE VMLISP::IVECP VMLISP::LIST2VEC
-	 VMLISP::|LAM,FILEACTQ| VMLISP::LISTOFQUOTES
-	 VMLISP::$ERASE VMLISP::QSDEC1
-	 VMLISP::QSSUB1 VMLISP::QCAR VMLISP::EVA1FUN VMLISP::IS-CONSOLE
-	 VMLISP::MAKESTRING VMLISP::CUROUTSTREAM VMLISP::QCDDDR
-	 VMLISP::QCDADAR VMLISP::MAKE-ABSOLUTE-FILENAME VMLISP::SUFFIX
-	 VMLISP::FUNARGP VMLISP::VM/ VMLISP::QRPLACA VMLISP::GGREATERP
-	 VMLISP::CGREATERP VMLISP::RNUMP VMLISP::RESETQ VMLISP::QRPLACD
-	 VMLISP::SORTBY VMLISP::CVECP VMLISP::SETELT VMLISP::HGET
-	 VMLISP::$DIRECTORY-LIST VMLISP::LN VMLISP::|member|
-	 VMLISP::$LIBRARY-DIRECTORY-LIST
-	 VMLISP::QCSIZE VMLISP::QCADDDR VMLISP::RWRITE VMLISP::SUBLOAD
-	 VMLISP::STRINGIMAGE VMLISP::$CLEAR VMLISP::|read-line|
-	 VMLISP::PROPLIST VMLISP::INTP VMLISP::OUTPUT VMLISP::CONSOLE
-	 VMLISP::QCDDDAR VMLISP::ADDOPTIONS VMLISP::$FILETYPE-TABLE
-	 VMLISP::QSMINUSP VMLISP::|assoc| VMLISP::SETSIZE VMLISP::QCDR
-	 VMLISP::EFFACE VMLISP::COPY VMLISP::DOWNCASE VMLISP::LC2UC
-	 VMLISP::EMBED VMLISP::SETANDFILEQ VMLISP::QSMAX
-	 VMLISP::LIST2REFVEC VMLISP::MACRO-INVALIDARGS VMLISP::EMBEDDED
-	 VMLISP::REFVECP VMLISP::CLOSEDFN VMLISP::MAKE-HASHTABLE
-	 VMLISP::MAKE-FILENAME VMLISP::|$defaultMsgDatabaseName|
-	 VMLISP::LEXGREATERP
-	 VMLISP::IDENTP VMLISP::QSINC1 VMLISP::QESET VMLISP::MRP
-	 VMLISP::LESSP VMLISP::RPLPAIR VMLISP::QVELT VMLISP::QRPLQ
-	 VMLISP::MACERR VMLISP::*FILEACTQ-APPLY* VMLISP::HPUT*
-	 VMLISP::$FILEP VMLISP::MAKE-FULL-CVEC VMLISP::HCLEAR
-	 VMLISP::ERRORINSTREAM VMLISP::HPUTPROP 
-	 VMLISP::STRING2ID-N VMLISP::CALLBELOW VMLISP::BPINAME
-	 VMLISP::CHANGELENGTH VMLISP::ECQ VMLISP::OBEY VMLISP::QASSQ
-	 VMLISP::DCQ VMLISP::SHUT VMLISP::FILE VMLISP::HPUT
-	 VMLISP::MAKEPROP VMLISP::GREATERP
-	 VMLISP::REROOT VMLISP::DIG2FIX VMLISP::L-CASE
-	 VMLISP::TEREAD VMLISP::QSREMAINDER VMLISP::$FINDFILE
-	 VMLISP::EQQ VMLISP::PRETTYPRINT VMLISP::HASHEQ VMLISP::LOG2
-	 VMLISP::U-CASE VMLISP::NREMOVE VMLISP::QREFELT VMLISP::SIZE
-	 VMLISP::EOFP VMLISP::QCDAAR VMLISP::RSHUT VMLISP::ADD1
-	 VMLISP::QMEMQ VMLISP::SUBSTRING VMLISP::LOADVOL
-	 VMLISP::QSTIMES VMLISP::STRINGLENGTH VMLISP::NEXT
-	 VMLISP::DEVICE VMLISP::MAPELT VMLISP::LENGTHOFBPI
-	 VMLISP::DIGITP VMLISP::QLENGTH VMLISP::QCAAADR VMLISP::CVEC
-	 VMLISP::VEC2LIST VMLISP::MODE VMLISP::MAKE-VEC VMLISP::GCMSG
-	 VMLISP::CONCAT VMLISP::$SHOWLINE VMLISP::QCAADR VMLISP::QCDDAR
-	 VMLISP::QCDAAAR VMLISP::RDROPITEMS VMLISP::VECP
-	 VMLISP::|union| VMLISP::ONE-OF VMLISP::NULLOUTSTREAM
-	 VMLISP::QSGREATERP VMLISP::MINUS VMLISP::MAXINDEX
-	 VMLISP::GETSTR VMLISP::QCADADR VMLISP::PRIN2CVEC
-	 VMLISP::CURRENTTIME VMLISP::$REPLACE VMLISP::UNIONQ
-	 VMLISP::NREMOVEQ VMLISP::CURINSTREAM VMLISP::MAKE-OUTSTREAM
-	 VMLISP::APPLX VMLISP::LASTNODE VMLISP::SUBSTQ VMLISP::TRUEFN
-	 VMLISP::|last| VMLISP::RPLACSTR VMLISP::SETQP VMLISP::QCADDR
-	 VMLISP::QCAADAR VMLISP::QCDDAAR VMLISP::|intersection|
-	 VMLISP::HASHTABLE-CLASS VMLISP::$CURRENT-DIRECTORY
-	 VMLISP::*COMP370-APPLY* VMLISP::QSETVELT VMLISP::MOVEVEC
-	 VMLISP::ID VMLISP::DEFINE-FUNCTION VMLISP::MSUBSTQ VMLISP::|nsubst|
-	 VMLISP::LISTOFFLUIDS VMLISP::SUB1 VMLISP::NUMBEROFARGS
-	 VMLISP::VMREAD VMLISP::SMINTP VMLISP::$SCREENSIZE
-	 VMLISP::LISTOFFREES VMLISP::QCDADDR VMLISP::COMPRREAD
-	 VMLISP::GENSYMP VMLISP::IFCAR VMLISP::QSETQ
-	 VMLISP::QCADDAR VMLISP::*LISP-SOURCE-FILETYPE* VMLISP::KOMPILE
-	 VMLISP::INPUT VMLISP::PAPPP VMLISP::UEQUAL VMLISP::COMPRWRITE
-	 VMLISP::SUBRP VMLISP::ASSEMBLE VMLISP::|LAM,EVALANDFILEACTQ|
-	 VMLISP::|$msgDatabaseName| VMLISP::IFCDR VMLISP::QVMAXINDEX
-	 VMLISP::$SPADROOT VMLISP::PRIN0 VMLISP::PRETTYPRIN0
-	 VMLISP::STACKLIFO VMLISP::ASSQ VMLISP::PRINTEXP
-	 VMLISP::QCDDDDR VMLISP::QSADD1
-	 VMLISP::SETDIFFERENCEQ VMLISP::STRPOS VMLISP::CONSTANT
-	 VMLISP::QCAAR VMLISP::HCOUNT VMLISP::RCOPYITEMS
-	 VMLISP::QSMINUS VMLISP::EVA1 VMLISP::OPTIONLIST
-	 VMLISP::NUM2CHAR VMLISP::QENUM VMLISP::QEQQ
-	 VMLISP::$TOTAL-GC-TIME VMLISP::CHARP VMLISP::QCADR
-	 VMLISP::INTERSECTIONQ VMLISP::DSETQ VMLISP::FETCHCHAR
-	 VMLISP::STRCONC VMLISP::MACRO-MISSINGARGS VMLISP::RPACKFILE
-	 VMLISP::EXIT VMLISP::PLUS VMLISP::RKEYIDS
-	 VMLISP::COMPILE-LIB-FILE VMLISP::RECOMPILE-LIB-FILE-IF-NECESSARY))
-
-;;; Definitions for package BOOT of type SHADOW
-(lisp:in-package "BOOT")
-(lisp:shadow '(BOOT::MAP))
-(lisp:import
-    '(VMLISP::ERROROUTSTREAM LISP:COUNT VMLISP::NE VMLISP::FLUID
-	 LISP:SEQUENCE VMLISP::OBEY LISP::NUMBER VMLISP::|union|
-	 LISP:STEP VMLISP::OPTIONLIST VMLISP::EXIT VMLISP::LEXGREATERP))
-(lisp:import '(vmlisp::make-input-filename))
-(lisp:import '(vmlisp::libstream-dirname))
-(lisp:import '(user::spad-save))
-(lisp:import '(vmlisp::eqcar))
-(lisp:export '(boot::eqcar))
-
-;;; Definitions for package VMLISP of type SHADOW
-(lisp:in-package "VMLISP")
-(lisp:import '(SYSTEM::DEFINE-MACRO SYSTEM::MEMQ SYSTEM::PNAME))
-
-
-(in-package "BOOT") ;; Used to be "UNCOMMON"
-
-(export '(
-	;; !! ;;; Passed on from the Lisp package
-	;; !! + * -
-
-	;;;; Operating system interface
-	|OsRunProgram| |OsRunProgramToStream| |OsProcessNumber|
-	|OsEnvGet|     |OsEnvVarCharacter|    |OsExpandString|
-
-	;;;; Time
-	|TimeStampString|
-
-	;;;; Lisp Interface
-	|LispKeyword|
-	|LispReadFromString| |LispEval|
-	|LispCompile| |LispCompileFile| |LispCompileFileQuietlyToObject|
-	|LispLoadFile| |LispLoadFileQuietly|
-
-	;;; Control
-	|funcall| |Catch| |Throw| |UnwindProtect| |CatchAsCan|
-
-	;;; General
-	|Eq| |Nil| |DeepCopy| |Sort| |SortInPlace|
-
-	|genRemoveDuplicates| |genMember|
-	|gobSharedExcluding| |gobSharedParts| |gobAlwaysShared?|
-	|gobPretty| |gobSexpr|
-
-	;;; Streams
-	|Prompt| |PlainError| |PrettyPrint| |PlainPrint| |PlainPrintOn|
-	|WithOpenStream|
-	|WriteLispExpr| |WriteByte| |WriteChar| |WriteLine| |WriteString|
-	|ReadLispExpr| |ReadByte| |ReadChar| |ReadLine|
-	|ByteFileWriteLine| |ByteFileReadLine|
-	|ReadLineIntoString| |ByteFileReadLineIntoString| |ReadBytesIntoVector|
-	|StreamCopyChars| |StreamCopyBytes|
-	|InputStream?| |OutputStream?|
-	|StreamSize| |StreamGetPosition| |StreamSetPosition|
-	|StreamEnd?| |StreamFlush| |StreamClose|
-
-	|FileLine| |StreamLine|
-
-	;;; Pathnames
-	|TempFileDirectory| |LispFileType| |FaslFileType|
-	|ToPathname| |Pathname| |NewPathname| |SessionPathname|
-	|PathnameDirectory| |PathnameName| |PathnameType|
-	|PathnameString| |PathnameAbsolute?|
-	|PathnameWithType| |PathnameWithDirectory|
-	|PathnameWithoutType| |PathnameWithoutDirectory|
-
-	|PathnameToUsualCase| |PathnameWithinDirectory|
-	|PathnameDirectoryOfDirectoryPathname| |PathnameWithinOsEnvVar|
-
-	;;; Symbols
-	|MakeSymbol| |Symbol?| |SymbolString|
-
-	;;; Bits
-	|Bit| |Bit?| |TrueBit| |FalseBit| |BitOn?| |BitOr|
-
-	;;; General Sequences
-	;; !! ;;; Passed on from the Lisp package
-	;; !! ELT SETELT
-	;; SIZE
-
-	;;; Vectors
-	|FullVector| |Vector?|
-
-	;;; Bit Vectors
-	|FullBvec|
-
-	;;; Characters
-	|char| |Char| |Char?|
-	|CharCode| |CharGreater?| |CharDigit?|
-	|SpaceChar| |NewlineChar|
-
-	;;; Character Sets
-	|Cset| |CsetMember?|
-	|CsetUnion| |CsetComplement| |CsetString|
-	|NumericCset| |LowerCaseCset| |UpperCaseCset| |WhiteSpaceCset|
-	|AlphaCset| |AlphaNumericCset|
-
-	;;; Character Strings
-	|FullString| |ToString| |StringImage| |String?|
-	|StringGetCode| |StringConcat|
-	|StringLength| |StringFromTo| |StringFromToEnd| |StringFromLong|
-	|StringGreater?| |StringPrefix?| |StringUpperCase| |StringLowerCase|
-	|StringToInteger|  |StringToFloat|
-	|StringWords|	   |StringTrim|
-	|StringPositionOf| |StringPositionOfNot|
-	|UnescapeString|   |ExpandVariablesInString|
-
-	;;; Numbers
-	|Number?| |Integer?| |SmallInteger?| |Float?| |DoublePrecision|
-	|Odd?| |Remainder|
-	|Abs| |Min| |Max|
-	|Exp| |Ln| |Log10|
-	|Sin| |Cos| |Tan| |Cotan| |Arctan|
-
-	;;; Pairs
-	|Pair?|
-
-	|car|	    |cdr|
-	|caar|	    |cadr|	|cdar|	    |cddr|
-	|caaar|	    |caadr|	|cadar|	    |caddr|
-	|cdaar|	    |cdadr|	|cddar|	    |cdddr|
-	|FastCar|   |FastCdr|
-	|FastCaar|  |FastCadr|	|FastCdar|  |FastCddr|
-	|FastCaaar| |FastCaadr| |FastCadar| |FastCaddr|
-	|FastCdaar| |FastCdadr| |FastCddar| |FastCdddr|
-	|IfCar|	    |IfCdr|
-	|EqCar|	    |EqCdr|
-
-	;;; Lists
-	|length1?| |second|
-
-	|ListIsLength?| |ListMemberQ?| |ListMember?|
-	|ListRemoveQ| |ListNRemoveQ| |ListRemoveDuplicatesQ| |ListNReverse|
-	|ListUnion| |ListUnionQ| |ListIntersection| |ListIntersectionQ|
-	|ListAdjoin| |ListAdjoinQ|
-
-	;;; Association lists
-	|AlistAssoc| |AlistRemove|
-	|AlistAssocQ| |AlistRemoveQ| |AlistAdjoinQ| |AlistUnionQ|
-
-	;;; Tables
-	|Table?|
-	|TableCount| |TableGet| |TableSet| |TableUnset| |TableKeys|
-))
-
-(in-package "BOOT")
-(lisp:export '(boot::ncloop boot::ncrecover))
-(lisp:import '(vmlisp::make-input-filename vmlisp::is-console))
-;; (lisp:import '(boot::|openServer|))
-;; (lisp:import '(boot::|sockGetInt|))
-;; (lisp:import '(boot::|sockSendInt|))
-;; (lisp:import '(boot::|sockGetInts|))
-;; (lisp:import '(boot::|sockSendInts|))
-;; (lisp:import '(boot::|sockGetString|))
-;; (lisp:import '(boot::|sockSendString|))
-;; (lisp:import '(boot::|sockGetFloat|))
-;; (lisp:import '(boot::|sockSendFloat|))
-;; (lisp:import '(boot::|sockGetFloats|))
-;; (lisp:import '(boot::|sockSendFloats|))
-;; (lisp:import '(boot::|sockSendWakeup|))
-;; (lisp:import '(boot::|sockSendSignal|))
-(lisp:import '(vmlisp::qsdifference))
-(lisp:import '(vmlisp::qsminusp))
-(lisp:import '(vmlisp::qsplus))
-(lisp:import '(vmlisp::absval))
-(lisp:import '(vmlisp::cgreaterp))
-(lisp:import '(vmlisp::char2num))
-(lisp:import '(vmlisp::charp))
-(lisp:import '(vmlisp::concat))
-(lisp:import '(vmlisp::copy))
-(lisp:import '(vmlisp::difference))
-(lisp:import '(vmlisp::digitp))
-(lisp:import '(vmlisp::divide))
-(lisp:import '(vmlisp::eqcar))
-(lisp:import '(vmlisp::fixp))
-(lisp:import '(vmlisp::greaterp))
-(lisp:import '(vmlisp::hasheq))
-(lisp:import '(vmlisp::hput))
-(lisp:import '(vmlisp::hrem))
-(lisp:import '(vmlisp::identp))
-(lisp:import '(vmlisp::lessp))
-(lisp:import '(vmlisp::ln))
-(lisp:import '(vmlisp::make-cvec))
-(lisp:import '(vmlisp::make-full-cvec))
-(lisp:import '(vmlisp::make-vec))
-#-(or :lispm :lucid) (lisp:import '(vmlisp::memq))
-#+(and :lucid (not :ibm/370)) (lisp:import '(system:memq))
-(lisp:import '(vmlisp::movevec))
-(lisp:import '(vmlisp::pname))
-(lisp:import '(vmlisp::prettyprin0))
-(lisp:import '(vmlisp::prettyprint))
-(lisp:import '(vmlisp::printexp))
-(lisp:import '(vmlisp::qassq))
-(lisp:import '(vmlisp::qcar))
-(lisp:import '(vmlisp::qcdr))
-(lisp:import '(vmlisp::qcaar))
-(lisp:import '(vmlisp::qcadr))
-(lisp:import '(vmlisp::qcdar))
-(lisp:import '(vmlisp::qcddr))
-(lisp:import '(vmlisp::qcaaar))
-(lisp:import '(vmlisp::qcaadr))
-(lisp:import '(vmlisp::qcadar))
-(lisp:import '(vmlisp::qcaddr))
-(lisp:import '(vmlisp::qcdaar))
-(lisp:import '(vmlisp::qcdadr))
-(lisp:import '(vmlisp::qcddar))
-(lisp:import '(vmlisp::qcdddr))
-(lisp:import '(vmlisp::qcaaaar))
-(lisp:import '(vmlisp::qcaaadr))
-(lisp:import '(vmlisp::qcaadar))
-(lisp:import '(vmlisp::qcaaddr))
-(lisp:import '(vmlisp::qcadaar))
-(lisp:import '(vmlisp::qcadadr))
-(lisp:import '(vmlisp::qcaddar))
-(lisp:import '(vmlisp::qcadddr))
-(lisp:import '(vmlisp::qcdaaar))
-(lisp:import '(vmlisp::qcdaadr))
-(lisp:import '(vmlisp::qcdadar))
-(lisp:import '(vmlisp::qcdaddr))
-(lisp:import '(vmlisp::qcddaar))
-(lisp:import '(vmlisp::qcddadr))
-(lisp:import '(vmlisp::qcdddar))
-(lisp:import '(vmlisp::qcddddr))
-(lisp:import '(vmlisp::qcsize))
-(lisp:import '(vmlisp::qenum))
-(lisp:import '(vmlisp::qeset))
-(lisp:import '(vmlisp::qlength))
-(lisp:import '(vmlisp::qmemq))
-(lisp:import '(vmlisp::qsadd1))
-(lisp:import '(vmlisp::qslessp))
-(lisp:import '(vmlisp::qsdec1))
-(lisp:import '(vmlisp::qsetvelt))
-(lisp:import '(vmlisp::qsgreaterp))
-(lisp:import '(vmlisp::qsinc1))
-(lisp:import '(vmlisp::qsmax))
-(lisp:import '(vmlisp::qsmin))
-(lisp:import '(vmlisp::qsoddp))
-(lisp:import '(vmlisp::qsquotient))
-(lisp:import '(vmlisp::qsremainder))
-(lisp:import '(vmlisp::qssub1))
-(lisp:import '(vmlisp::qstimes))
-(lisp:import '(vmlisp::qszerop))
-(lisp:import '(vmlisp::qszerop))
-(lisp:import '(vmlisp::qvelt))
-(lisp:import '(vmlisp::qvsize))
-(lisp:import '(vmlisp::setandfileq))
-(lisp:import '(vmlisp::sintp))
-(lisp:import '(vmlisp::size))
-(lisp:import '(vmlisp::stringimage))
-(lisp:import '(vmlisp::strpos))
-(lisp:import '(vmlisp::strposl))
-(lisp:import '(vmlisp::substring))
-;; (lisp:import '(boot::|error|))
-(lisp:import '(vmlisp::ivecp))
-(lisp:import '(vmlisp::rvecp))
-(lisp:import '(vmlisp::dig2fix))
-(lisp:import '(vmlisp::rnump))
-(lisp:import '(vmlisp::fix))
-(lisp:import '(vmlisp::sortgreaterp))
-(lisp:import '(vmlisp::qsort))
-(lisp:import '(vmlisp::sortby))
-(lisp:import '(vmlisp::make-instream))
-(lisp:import '(vmlisp::list2vec))
-(lisp:import '(vmlisp::vec2list))
-(lisp:import '(vmlisp::sub1))
-(lisp:import '(vmlisp::add1))
-(lisp:import '(vmlisp::neq))
-(lisp:import '(vmlisp::hashtable-class))
-(lisp:import '(vmlisp::maxindex))
-;; (lisp:import '(boot::remdup))
-(lisp:import '(vmlisp::upcase))
-(lisp:import '(vmlisp::downcase))
-(lisp:import '(vmlisp::vecp))
-(lisp:import '(vmlisp::strconc))
-(lisp:import '(vmlisp::defiostream))
-(lisp:import '(vmlisp::shut))
-(lisp:import '(vmlisp::prin2cvec))
-;; (lisp:import '(boot::lasttail))
-;; (lisp:import '(boot::lastpair))
-;; (lisp:import '(boot::lastatom))
-;; (lisp:import '(boot::|last|))
-(lisp:import '(vmlisp::ncons))
-(lisp:import '(vmlisp::rplpair))
-(lisp:import '(vmlisp::nump))
-(lisp:import '(vmlisp::intp))
-(lisp:import '(vmlisp::makeprop))
-(lisp:import '(vmlisp::ifcar))
-(lisp:import '(vmlisp::ifcdr))
-(lisp:import '(vmlisp::quotient))
-(lisp:import '(vmlisp::remainder))
-(lisp:import '(vmlisp::make-hashtable))
-(lisp:import '(vmlisp::hget))
-(lisp:import '(vmlisp::hkeys))
-(lisp:import '(vmlisp::$infilep))
-(lisp:import '(vmlisp::$findfile))
-(lisp:import '(vmlisp::pairp))
-(lisp:import '(vmlisp::cvec))
-(lisp:import '(vmlisp::uequal))
-(lisp:import '(vmlisp::id))
-(lisp:import '(vmlisp::vec-setelt))
-(lisp:import '(vmlisp::make-bvec))
-;; (lisp:import '(boot::bvec-make-full))
-;; (lisp:import '(boot::bvec-setelt))
-(lisp:import '(vmlisp::|shoeread-line|))
-(lisp:import '(vmlisp::|shoeInputFile|))
-(lisp:import '(vmlisp::|shoeConsole|))
-(lisp:import '(vmlisp::|startsId?|))
-(lisp:import '(vmlisp::|idChar?|))
-(lisp:import '(vmlisp::|npPC|))
-(lisp:import '(vmlisp::|npPP|))
-;; (lisp:import '(boot::mkprompt))
-;; (lisp:import '(boot::|fillerSpaces|))
-;; (lisp:import '(boot::|sayString|))
-;; (lisp:import '(boot::help))
-;; (lisp:import '(boot::|version|))
-;; (lisp:import '(boot::|pp|))
-;; (lisp:import '(boot::$dalymode))
-
-(lisp:import 'boot::$IEEE)
-
-(in-package "FOAM")
+(defpackage "FOAM-USER"
+  (:use "FOAM" #.+standard-lisp-package+))
 
-(lisp:export '(
-FOAM::|printDFloat|
-FOAM::|printSFloat|
-FOAM::|printBInt|
-FOAM::|printSInt|
-FOAM::|printString|
-FOAM::|printChar|
-FOAM::|printNewLine|
-FOAM::|MakeLit|
-FOAM::|EnvNext|
-FOAM::|EnvLevel|
-FOAM::|MakeEnv|
-FOAM::|RElt|
-FOAM::|RNew|
-FOAM::|DDecl|
-FOAM::|ClosFun|
-FOAM::|ClosEnv|
-FOAM::|CCall|
-FOAM::|ArrToBInt|
-FOAM::|ArrToSInt|
-FOAM::|ArrToDFlo|
-FOAM::|ArrToSFlo|
-FOAM::|BIntToDFlo|
-FOAM::|BIntToSFlo|
-FOAM::|SIntToDFlo|
-FOAM::|SIntToSFlo|
-FOAM::|BIntToSInt|
-FOAM::|SIntToBInt|
-FOAM::|BitToSInt|
-FOAM::|ScanBInt|
-FOAM::|ScanSInt|
-FOAM::|ScanDFlo|
-FOAM::|ScanSFlo|
-FOAM::|FormatBInt|
-FOAM::|FormatSInt|
-FOAM::|FormatDFlo|
-FOAM::|FormatSFlo|
-FOAM::|PtrEQ|
-FOAM::|PtrIsNil|
-FOAM::|PtrNil|
-FOAM::|BIntBit|
-FOAM::|BIntShift|
-FOAM::|BIntLength|
-FOAM::|BIntPower|
-FOAM::|BIntGcd|
-FOAM::|BIntDivide|
-FOAM::|BIntRem|
-FOAM::|BIntQuo|
-FOAM::|BIntMod|
-FOAM::|BIntTimes|
-FOAM::|BIntMinus|
-FOAM::|BIntPlus|
-FOAM::|BIntInc|
-FOAM::|BIntDec|
-FOAM::|BIntAbs|
-FOAM::|BIntNegate|
-FOAM::|BIntNE|
-FOAM::|BIntGT|
-FOAM::|BIntEQ|
-FOAM::|BIntLE|
-FOAM::|BIntIsSmall|
-FOAM::|BIntIsOdd|
-FOAM::|BIntIsEven|
-FOAM::|BIntIsPos|
-FOAM::|BIntIsNeg|
-FOAM::|BIntIsZero|
-FOAM::|BInt1|
-FOAM::|BInt0|
-FOAM::|SIntOr|
-FOAM::|SIntAnd|
-FOAM::|SIntNot|
-FOAM::|SIntBit|
-FOAM::|SIntShift|
-FOAM::|SIntLength|
-FOAM::|SIntTimesMod|
-FOAM::|SIntMinusMod|
-FOAM::|SIntPlusMod|
-FOAM::|SIntPower|
-FOAM::|SIntGcd|
-FOAM::|SIntDivide|
-FOAM::|SIntRem|
-FOAM::|SIntQuo|
-FOAM::|SIntMod|
-FOAM::|SIntTimes|
-FOAM::|SIntMinus|
-FOAM::|SIntPlus|
-FOAM::|SIntInc|
-FOAM::|SIntDec|
-FOAM::|SIntNegate|
-FOAM::|SIntNE|
-FOAM::|SIntGT|
-FOAM::|SIntEQ|
-FOAM::|SIntLE|
-FOAM::|SIntIsOdd|
-FOAM::|SIntIsEven|
-FOAM::|SIntIsPos|
-FOAM::|SIntIsNeg|
-FOAM::|SIntIsZero|
-FOAM::|SIntMax|
-FOAM::|SIntMin|
-FOAM::|SInt1|
-FOAM::|SInt0|
-FOAM::|HIntMax|
-FOAM::|HIntMin|
-FOAM::|HInt1|
-FOAM::|HInt0|
-FOAM::|ByteMax|
-FOAM::|ByteMin|
-FOAM::|Byte1|
-FOAM::|Byte0|
-FOAM::|DFloCeiling|
-FOAM::|DFloFloor|
-FOAM::|DFloTruncate|
-FOAM::|DFloRound|
-FOAM::|DFloIPower|
-FOAM::|DFloPower|
-FOAM::|DFloDivide|
-FOAM::|DFloTimes|
-FOAM::|DFloMinus|
-FOAM::|DFloPlus|
-FOAM::|DFloNegate|
-FOAM::OTHER-FORM
-FOAM::|DFloNE|
-FOAM::|DFloGT|
-FOAM::|DFloEQ|
-FOAM::|DFloLE|
-FOAM::|DFloIsPos|
-FOAM::|DFloIsNeg|
-FOAM::|DFloIsZero|
-FOAM::|DFloEpsilon|
-FOAM::|DFloMax|
-FOAM::|DFloMin|
-FOAM::|DFlo1|
-FOAM::|DFlo0|
-FOAM::|SFloCeiling|
-FOAM::|SFloFloor|
-FOAM::|SFloTruncate|
-FOAM::|SFloRound|
-FOAM::|SFloIPower|
-FOAM::|SFloPower|
-FOAM::|SFloDivide|
-FOAM::|SFloTimes|
-FOAM::|SFloMinus|
-FOAM::|SFloPlus|
-FOAM::|SFloNegate|
-FOAM::|SFloNE|
-FOAM::|SFloGT|
-FOAM::|SFloEQ|
-FOAM::|SFloLE|
-FOAM::|SFloIsPos|
-FOAM::|SFloIsNeg|
-FOAM::|SFloIsZero|
-FOAM::|SFloEpsilon|
-FOAM::|SFloMax|
-FOAM::|SFloMin|
-FOAM::|SFlo1|
-FOAM::|SFlo0|
-FOAM::|CharNum|
-FOAM::|CharOrd|
-FOAM::|CharUpper|
-FOAM::|CharLower|
-FOAM::|CharNE|
-FOAM::|CharGT|
-FOAM::|CharEQ|
-FOAM::|CharLE|
-FOAM::|CharIsLetter|
-FOAM::|CharIsDigit|
-FOAM::|CharMax|
-FOAM::|CharMin|
-FOAM::|CharNewline|
-FOAM::|CharSpace|
-FOAM::|BitNE|
-FOAM::|BitEQ|
-FOAM::|BitOr|
-FOAM::|BitAnd|
-FOAM::|BitNot|
-FOAM::|BitTrue|
-FOAM::|BitFalse|
-FOAM::|Clos|
-FOAM::COMPILE-AS-FILE
-FOAM::|FormatNumber|
-FOAM::AXIOMXL-GLOBAL-NAME
-FOAM::AXIOMXL-FILE-INIT-NAME
-FOAM::|BIntPrev|
-FOAM::|BIntLT|
-FOAM::|BIntIsSingle|
-FOAM::|SIntShiftDn|
-FOAM::|SIntShiftUp|
-FOAM::|SIntTimesPlus|
-FOAM::|SIntNext|
-FOAM::|SIntPrev|
-FOAM::|SIntLT|
-FOAM::|DFloAssemble|
-FOAM::|DFloDissemble|
-FOAM::|DFloRDivide|
-FOAM::|DFloRTimesPlus|
-FOAM::|DFloRTimes|
-FOAM::|DFloRMinus|
-FOAM::|DFloRPlus|
-FOAM::|DFloTimesPlus|
-FOAM::|DFloNext|
-FOAM::|DFloPrev|
-FOAM::|DFloLT|
-FOAM::|SFloAssemble|
-FOAM::|fiStrHash|
-FOAM::|SFloDissemble|
-FOAM::|SFloRDivide|
-FOAM::|SFloRTimesPlus|
-FOAM::|SFloRTimes|
-FOAM::|fiGetDebugger|
-FOAM::|SFloRMinus|
-FOAM::|fiSetDebugger|
-FOAM::|SFloRPlus|
-FOAM::|SFloTimesPlus|
-FOAM::|fiGetDebugVar|
-FOAM::|SFloNext|
-FOAM::|fiSetDebugVar|
-FOAM::|SFloPrev|
-FOAM::|atan2|
-FOAM::|SFloLT|
-FOAM::|atan|
-FOAM::|acos|
-FOAM::|CharLT|
-FOAM::|asin|
-FOAM::|BoolNE|
-FOAM::|tanh|
-FOAM::|BoolEQ|
-FOAM::|cosh|
-FOAM::|BoolOr|
-FOAM::|sinh|
-FOAM::|BoolAnd|
-FOAM::|tan|
-FOAM::|BoolNot|
-FOAM::|cos|
-FOAM::|sin|
-FOAM::|BoolTrue|
-FOAM::|exp|
-FOAM::|BoolFalse|
-FOAM::|log|
-FOAM::|pow|
-FOAM::|sqrt|
-FOAM::|fputs|
-FOAM::|fputc|
-FOAM::|stderrFile|
-FOAM::|stdoutFile|
-FOAM::|stdinFile|
-FOAM::|SetProgHashCode|
-FOAM::|ProgHashCode|
-FOAM::|formatDFloat|
-FOAM::|formatSFloat|
-FOAM::|formatBInt|
-FOAM::|formatSInt|
-FOAM::|strLength|
-FOAM::|MakeLevel|
-FOAM::|FoamEnvEnsure|
-FOAM::|SetEnvInfo|
-FOAM::|EnvInfo|
-FOAM::|SInt|
-FOAM::TYPED-LET
-FOAM::FILE-IMPORTS
-FOAM::FILE-EXPORTS
-FOAM::DEFSPECIALS
-FOAM::BLOCK-RETURN
-FOAM::CASES
-FOAM::IGNORE-VAR
-FOAM::DEFPROG
-FOAM::DECLARE-TYPE
-FOAM::DECLARE-PROG
-FOAM::|FoamFree|
-FOAM::|SetEElt|
-FOAM::|SetAElt|
-FOAM::|SetRElt|
-FOAM::|SetLex|
-FOAM::|Lex|
-FOAM::|AElt|
-FOAM::|EElt|
-FOAM::|ANew|
-FOAM::|SetClosFun|
-FOAM::|SetClosEnv|
-FOAM::|Halt|
-FOAM::|BoolToSInt|
-FOAM::|SIntToHInt|
-FOAM::|SIntToByte|
-FOAM::|ByteToSInt|
-FOAM::|fputss|
-FOAM::|fgetss|
-FOAM::|PtrNE|
-FOAM::|PtrMagicEQ|
-FOAM::|BIntShiftDn|
-FOAM::|BIntShiftUp|
-FOAM::|BIntBIPower|
-FOAM::|BIntSIPower|
-FOAM::|BIntTimesPlus|
-FOAM::|BIntNext|
-))
 @
 \section{License}
 <<license>>=
diff --git a/src/interp/topics.boot.pamphlet b/src/interp/topics.boot.pamphlet
index 6946bda..fce397e 100644
--- a/src/interp/topics.boot.pamphlet
+++ b/src/interp/topics.boot.pamphlet
@@ -86,7 +86,7 @@ mkTopicHashTable() ==                         --given $groupAssoc = ((extended .
     for item in items repeat 
       HPUT($defaultsHash,item,[kind,:HGET($defaultsHash,item)])
   $conTopicHash  := MAKE_-HASHTABLE 'EQL      --key is constructor name; value is
-  instream := OPEN '"topics.data"           
+  instream := OPEN '"../../int/algebra/topics.data"
   while not EOFP instream repeat
     line := READLINE instream
     while blankLine? line repeat line := READLINE instream
diff --git a/src/interp/unlisp.lisp.pamphlet b/src/interp/unlisp.lisp.pamphlet
index efd1e9d..894dad9 100644
--- a/src/interp/unlisp.lisp.pamphlet
+++ b/src/interp/unlisp.lisp.pamphlet
@@ -140,7 +140,7 @@ The following functions are provided:
 (defun c-to-lisp-string (ptr)
   (let (str len)
        (setq len (strlen ptr))
-       (setq str (make-array (list len) :element-type 'string-char))
+       (setq str (make-array (list len) :element-type 'standard-char))
        (sprintf str "%s" ptr)  ; Cannot use strcpy because it stops in a \0.
        str ))
 )
@@ -886,7 +886,7 @@ The following functions are provided:
 (defun |FullString| (size &optional (init #\Space))
   (make-array
    (list size)
-   :element-type 'string-char
+   :element-type 'standard-char
    :initial-element init ))
 
 (defun |ToString| (ob)
diff --git a/src/interp/util.lisp.pamphlet b/src/interp/util.lisp.pamphlet
index 85dac2f..d1881b9 100644
--- a/src/interp/util.lisp.pamphlet
+++ b/src/interp/util.lisp.pamphlet
@@ -45,7 +45,6 @@ loaded.
   (in-package "BOOT")
   (push :oldboot *features*)
   (mapcar #'load load-files)
-  (make-depsys lsp src int obj mnt sys)
   (initroot spad)
   #+:AKCL
   (init-memory-config :cons 1000 :fixnum 400 :symbol 1000 :package 16
diff --git a/src/interp/vmlisp.lisp.pamphlet b/src/interp/vmlisp.lisp.pamphlet
index 7247d7a..fe3cf7a 100644
--- a/src/interp/vmlisp.lisp.pamphlet
+++ b/src/interp/vmlisp.lisp.pamphlet
@@ -334,7 +334,7 @@ Contributed by Juergen Weiss.
 (defmacro maxindex (x)
  `(the fixnum (1- (the fixnum (length ,x)))))
 
-#-(or LispM Lucid :CCL)
+#-(or LispM Lucid :CCL :GCL)
 (defmacro memq (a b)
  `(member ,a ,b :test #'eq))
 
@@ -1186,7 +1186,7 @@ can be restored.
 
 (define-function 'strconc #'concat)
 
-(defun make-cvec (sint) (make-array sint :fill-pointer 0 :element-type 'string-char))
+(defun make-cvec (sint) (make-array sint :fill-pointer 0 :element-type 'standard-char))
 
 ;(define-function 'CVECP #'stringp)
 

\start
Date: 13 Jul 2007 19:57:30 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: Re: Unions in Spad
Cc: Gabriel Dos Reis

Regarding `rep' and `per'.

I see the issue as follows.  Ideally, a definition of type Rep in
domain context should automatically generate two functions `rep' and
`per' (I like `inj' and `prj', for inject and project, myself) with
the familiar signatures.  The compiler has special knowledge about
these functions and knows they can be applied to convert between Rep
and %.  As Gaby pointed out, these can be defaults with the
possibility to override.

Spad effectively does this, so that if you have a context like `... =
[n]', then an implicit function analogous to `per' can be selected as
a form of auto-coercion to satisfy the type.

I agree that in Spad the implicit functions should be named and
available.

Note that both Aldor and Spad try hard to infer types.  The draw back
in Aldor is that rep and per are macros, and thus do not carry any
useful semantic information and cannot be used by the compiler to
perform the conversion.

\start
Date: Fri, 13 Jul 2007 19:18:44 -0500
From: Tim Daly
To: Stephen Wilson
Subject: 2.7 build

Stephen,

I'll grab the 2.7 cvs. Which patch level of 2.7 do you use?

The way that we can add this to silver is straightforward.
The process involves making a 2.7 tgz and this set of patch 
files in zips. The user can then select this with
   make GCLVERSION=gcl.2.7

I'll prototype it here in a silver branch.

\start
Date: Sat, 14 Jul 2007 02:51:38 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: re: debugging
Cc: Camm Maguire

I wrote:
> > Greetings!  
> > 
> > Previous message a false alarm, as my fresh build just failed, though
> > not with any segfault.  Again, but in a different place:
> > 
> > (DEFUN |DFLOAT;base;Pi;7| ($)
> >   (PROG ()
> >     (RETURN
> >       (FLOAT-RADIX
> >           '#1=#((|DoubleFloat|)
> >                 (#<compiled-function |lookupComplete|> #1#
> > 
> > 
> > Same function that you found with the objnull.  Question -- what
> > function(s) write this source?
> > 
> 
> There are several functions involved.  In case of #<OBJNULL> using
> traces I see that |compDefineCapsuleFunction| function (defined
> in 'define.boot.pamphlet') gets:
> 
>  1> (|compDefineCapsuleFunction|
>          (DEF (|base|) (NIL) (NIL)
>               ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|))))
> ...
> ...
> 
> 
> It seems that (|elt| $ (|Zero|)) give us '#<OBJNULL>.  |elt| is
> handled in 'compiler.boot.pamphlet':
> 
> 
>     2> (|compForm1| ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|)))
> 
>       3> (|compElt| (|elt| $ (|Zero|)) |$EmptyMode|
> ....
> ....
>       <3 (|compElt|
>              ((|call| (XLAM |ignore| '#<OBJNULL>)) $
> 

I have narrowed down the problem:

   compiling exported base : () -> PositiveInteger
  1> (|genDeltaEntry| (|Zero| ($ $) (T (CONST $ 18))))
    2> (|optDeltaEntry| |Zero| ($) $ CONST)
      3> (|compiledLookup| |Zero| ((|DoubleFloat|))
             #<vector 0000000002b66f90>)
      <3 (|compiledLookup|
             (|makeSpadConstant|
                 #<compiled-function |DFLOAT;Zero;$;15|>
                 #<vector 0000000002b66f90> 25))
    <2 (|optDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
  <1 (|genDeltaEntry| (XLAM |ignore| '#<OBJNULL>))


|makeSpadConstant| calls its argument.  Checking this I get:

)lisp (|DFLOAT;Zero;$;15| nil)

Value = #<OBJNULL>

)lisp (disassemble '|DFLOAT;Zero;$;15|)
^M
   >> System error:
   Condition in DISASSEMBLE [or a callee]: INTERNAL-SIMPLE-END-OF-FILE: Stream error on stream #<input stream "/tmp/gazonk0.c">: Unexpected end of file:

Looking at "/tmp/gazonk0.c" I see:


#include "cmpinclude.h"
#include "gazonk0.h"
void init__tmp_gazonk0(){do_init((void *)VV);}
/*      local entry for function DFLOAT;Zero;$;15       */

static double LI1__DFLOAT$Zero$$$15___gazonk0(V2)

object V2;
{        VMB1 VMS1 VMV1
        goto TTL;
TTL:;
        /*(FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
        {fixnum V3;
        V3= (fixnum)0;
        V3= (fixnum)0;
        {double V4 = (    1.    )*((fixnum)0);VMR1
        (V4);}}
        /* END (FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
        {double V5 = lf(Cnil);VMR1
        (V5);}
}
/*      global entry for the function DFLOAT;Zero;$;15  */

static void L1__DFLOAT$Zero$$$15___gazonk0()
{       register object *base=vs_base;
        check_arg(1);
        base[0]=make_longfloat(LI1__DFLOAT$Zero$$$15___gazonk0((base[0])));
        vs_top=(vs_base=base)+1;
}

        #ifdef SYSTEM_SPECIAL_INIT
        SYSTEM_SPECIAL_INIT
        #endif


The assignment to V5 looks wrong...

The file DFLOAT.o where |DFLOAT;Zero;$;15| lives was compiled in
the previous step.

\start
Date: 13 Jul 2007 20:55:13 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: 2.7 build

Tim Daly writes:

> Stephen,
> 
> I'll grab the 2.7 cvs. Which patch level of 2.7 do you use?

Im not exactly sure!  I just do a cvs update once or twice a day and
rebuild.  So whatever cvs HEAD is, thats what you need.
 
> The way that we can add this to silver is straightforward.
> The process involves making a 2.7 tgz and this set of patch 
> files in zips. The user can then select this with
>    make GCLVERSION=gcl.2.7
> 
> I'll prototype it here in a silver branch.

Perhaps there is a way to avoid the inclusion of a gcl tarball?  Given
the regular updates to gcl it helps a great deal to link our build
image using a suitable gcl in ones path.  Thus if gcl changes we
simply remake gcl and install, rm lsp/gcldir, and remake in the Axiom
tree.

Thanks a lot for getting this into Silver!  That will help the
development along very nicely!

\start
Date: 13 Jul 2007 21:48:51 -0400
From: Stephen Wilson
To: William Sit
Subject: Re: Unions in Spad (Correction)
Cc: Gabriel Dos Reis

William Sit writes:
[...]
> (4) -> j1 case 1
> 
>    >> Error detected within library code:
>    upcase: bad Union form
> 
> protected-symbol-warn called with (NIL)
> 
> Perhaps a better error message should be given, like:
> (5) -> j1.tag2
> 
>    >> Error detected within library code:
>    (0 . 1) cannot be coerced to mode (Integer)
> 
> protected-symbol-warn called with (NIL)

I know where the second error message is generated (and I think even
that could be better).  The first I dont know off hand.  But I can put
this issue into my todo list.

[...]
> >> The construction is related to the bug in Union when the domains are not distinct (but
> >> the
> >> tags are): In Union(a:A, b:B) where A = B, the two coerce functions (one from A to %
> >> and
> >> one from B to %) coincides, with no way to distinguish the two.
> >
> 
> Should be the two "construct" functions.


Perhaps the best solution in this case is as Bill Page suggested,
implementing keyword arguments in Axiom, allowing us to write [a:1] or
[b:1] thus enabling unambiguous specification of the branch.

Note too that this, I believe, is a necessary first step in getting
defendant types working in Spad.  Currently there is no propagation of
binding information in the `modemaps' for functions.  We could look at
how is information is retained for functors and perhaps find some
inspiration for making it work in arbitrary functions (after all, the
mechanics is effectively already in place for dependent types as
handled by domain constructors).

\start
Date: Fri, 13 Jul 2007 20:50:35 -0500
From: Tim Daly
To: Stephen Wilson
Subject: compiler.boot issue #370 patch

I pushed the compiler.boot patch.

I also re-engineered the testing machinery so the unit test spad code
you wrote is included in the input test file. This unit test code is
now run during build time and then the regression machinery tests the
result. This is general purpose and we can write spad code in input 
files for unit testing, somewhat like the AldorUnit idea.

\start
Date: Fri, 13 Jul 2007 20:58:05 -0500
From: Tim Daly
To: Stephen Wilson
Subject: 2.7 build

> Perhaps there is a way to avoid the inclusion of a gcl tarball? Given
> the regular updates to gcl it helps a great deal to link our build
> image using a suitable gcl in ones path. Thus if gcl changes we
> simply remake gcl and install, rm lsp/gcldir, and remake in the Axiom
> tree.

A popular idea. Let me know when you get this working.  I'll include
the patch. Be certain that changes to gcl don't break axiom builds
under the new scheme.

\start
Date: 13 Jul 2007 22:03:41 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: compiler.boot issue #370 patch

Tim Daly writes:

> Stephen,
> 
> I pushed the compiler.boot patch.
> 
> I also re-engineered the testing machinery so the unit test spad code
> you wrote is included in the input test file. This unit test code is
> now run during build time and then the regression machinery tests the
> result. This is general purpose and we can write spad code in input 
> files for unit testing, somewhat like the AldorUnit idea.

Excellent!  Thanks a lot for implementing this!  

\start
Date: 13 Jul 2007 22:04:26 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: re: debugging

Greetings!  And thanks for the report!

Waldek Hebisch writes:

> I wrote:
> > > Greetings!  
> > > 
> > > Previous message a false alarm, as my fresh build just failed, though
> > > not with any segfault.  Again, but in a different place:
> > > 
> > > (DEFUN |DFLOAT;base;Pi;7| ($)
> > >   (PROG ()
> > >     (RETURN
> > >       (FLOAT-RADIX
> > >           '#1=#((|DoubleFloat|)
> > >                 (#<compiled-function |lookupComplete|> #1#
> > > 
> > > 
> > > Same function that you found with the objnull.  Question -- what
> > > function(s) write this source?
> > > 
> > 
> > There are several functions involved.  In case of #<OBJNULL> using
> > traces I see that |compDefineCapsuleFunction| function (defined
> > in 'define.boot.pamphlet') gets:
> > 
> >  1> (|compDefineCapsuleFunction|
> >          (DEF (|base|) (NIL) (NIL)
> >               ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|))))
> > ...
> > ...
> > 

In which package is this?  Is it present in interpsys?

> > 
> > It seems that (|elt| $ (|Zero|)) give us '#<OBJNULL>.  |elt| is
> > handled in 'compiler.boot.pamphlet':
> > 
> > 
> >     2> (|compForm1| ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|)))
> > 
> >       3> (|compElt| (|elt| $ (|Zero|)) |$EmptyMode|
> > ....
> > ....
> >       <3 (|compElt|
> >              ((|call| (XLAM |ignore| '#<OBJNULL>)) $
> > 
> 

Can you please post the full call to compElt in 3> above?

> I have narrowed down the problem:
> 
>    compiling exported base : () -> PositiveInteger
>   1> (|genDeltaEntry| (|Zero| ($ $) (T (CONST $ 18))))
>     2> (|optDeltaEntry| |Zero| ($) $ CONST)
>       3> (|compiledLookup| |Zero| ((|DoubleFloat|))
>              #<vector 0000000002b66f90>)
>       <3 (|compiledLookup|
>              (|makeSpadConstant|
>                  #<compiled-function |DFLOAT;Zero;$;15|>
>                  #<vector 0000000002b66f90> 25))
>     <2 (|optDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
>   <1 (|genDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
> 
> 
> |makeSpadConstant| calls its argument.  Checking this I get:
> 

Why are there 3 arguments above?  The definition appears to take one.

> )lisp (|DFLOAT;Zero;$;15| nil)
> 
> Value = #<OBJNULL>
> 
> )lisp (disassemble '|DFLOAT;Zero;$;15|)
> ^M
>    >> System error:
>    Condition in DISASSEMBLE [or a callee]: INTERNAL-SIMPLE-END-OF-FILE: Stream error on stream #<input stream "/tmp/gazonk0.c">: Unexpected end of file:
> 

This is a simple .h file naming bug I'll try to fix soon.


> Looking at "/tmp/gazonk0.c" I see:
> 
> 
> #include "cmpinclude.h"
> #include "gazonk0.h"
> void init__tmp_gazonk0(){do_init((void *)VV);}
> /*      local entry for function DFLOAT;Zero;$;15       */
> 
> static double LI1__DFLOAT$Zero$$$15___gazonk0(V2)
> 
> object V2;
> {        VMB1 VMS1 VMV1
>         goto TTL;
> TTL:;
>         /*(FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
>         {fixnum V3;
>         V3= (fixnum)0;
>         V3= (fixnum)0;
>         {double V4 = (    1.    )*((fixnum)0);VMR1
>         (V4);}}
>         /* END (FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
>         {double V5 = lf(Cnil);VMR1
>         (V5);}

This is correct but unpleasant C which needs tidying.  There can be
extra 'unwinds' scheduled currently in GCL -- these are harmless but
misleading.  The function returns from the macro VMR1.  I'll try to
clean this up too.

Why does this function take an argument which is ignored -- is this right? 

The compElt above, together with which package it is in, the full call
from your trace output, and at what stage the function has appeared
(and is called) will I think do the trick -- thank you so much!!

Take care,


> }
> /*      global entry for the function DFLOAT;Zero;$;15  */
> 
> static void L1__DFLOAT$Zero$$$15___gazonk0()
> {       register object *base=vs_base;
>         check_arg(1);
>         base[0]=make_longfloat(LI1__DFLOAT$Zero$$$15___gazonk0((base[0])));
>         vs_top=(vs_base=base)+1;
> }
> 
>         #ifdef SYSTEM_SPECIAL_INIT
>         SYSTEM_SPECIAL_INIT
>         #endif
> 
> 
> The assignment to V5 looks wrong...
> 
> The file DFLOAT.o where |DFLOAT;Zero;$;15| lives was compiled in
> the previous step.

\start
Date: 13 Jul 2007 22:05:00 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: Re: 2.7 build

Stephen -- you rock!  Am trying it myself now ...

\start
Date: 13 Jul 2007 22:08:58 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: 2.7 build

Tim Daly writes:

> Stephen,
> 
> > Perhaps there is a way to avoid the inclusion of a gcl tarball? Given
> > the regular updates to gcl it helps a great deal to link our build
> > image using a suitable gcl in ones path. Thus if gcl changes we
> > simply remake gcl and install, rm lsp/gcldir, and remake in the Axiom
> > tree.
> 
> A popular idea. Let me know when you get this working.  I'll include
> the patch. Be certain that changes to gcl don't break axiom builds
> under the new scheme.

Ok.  Will do.  Should be able to get something together this evening.
There is a scheme already in place in the patches I posted which
should work for silver.  Only the patches to the top-level Makefiles
need to be changed to build 2.6.8pre by default instead of the
`gclcvs' stanza.

Note that this is for the purpose of developing the patchset.  When
gcl officially goes 2.7.0 I have absolutely no issue with caching a
`known good version' in the tree for end-user purposes.

\start
Date: Fri, 13 Jul 2007 21:51:17 -0500
From: Tim Daly
To: Stephen Wilson
Subject: 2.7 build

Stephen,

> Note that this is for the purpose of developing the patchset. When
> gcl officially goes 2.7.0 I have absolutely no issue with caching a
> 'known good version' in the tree for end-user purposes.

Ok. I'll put it in a git-branch and you can push/pull it from there.
It shouldn't go into silver if it isn't intended for release.

\start
Date: 13 Jul 2007 23:31:31 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: 2.7 build

Tim Daly writes:

> Stephen,
> 
> > Note that this is for the purpose of developing the patchset. When
> > gcl officially goes 2.7.0 I have absolutely no issue with caching a
> > 'known good version' in the tree for end-user purposes.
> 
> Ok. I'll put it in a git-branch and you can push/pull it from there.
> It shouldn't go into silver if it isn't intended for release.

Yes, absolutely.  That is a much better approach for the time being.
Thanks so much Tim.

Steve




\start
Date: Fri, 13 Jul 2007 22:32:37 -0500 (CDT)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: [Gcl-devel] Re: Gcl-2.6.8 on Intel Solaris 10

On Fri, 13 Jul 2007, Camm Maguire wrote:

| Greetings, and thanks!  This is in now in Version_2_6_8pre.


Thanks!  Axiom.build-improvements was updated.

\start
Date: 13 Jul 2007 23:57:14 -0400
From: Stephen Wilson
To: William Sit
Subject: Re: Unions in Spad

William Sit writes:
> In summary, we need:
> 
> 
> (1) make a list or set of domains from SetCategory (or any category) a legal construction
> (2) SetAsDomain to convert a list or set of domains (or elements, or maps, perhaps or
> categories) as a domain of SetCategory
> (3) Record to accept dependent types, such as [i: I, x:g(i)]
> (4) maps such as g: I -> SetAsDomain([Integer, String]) should be first class objects and
> used as parameters, and definable in the Interpreter.

Ok. I believe that the IndexedUnion implementation might need to wait
until some basic support can be made available in the compiler.

I believe that 1) is realistic as a near-term extension, at least
within Spad code.  I do not know a lot about the interpreter
implementation so am unsure how much work is involved there.

Given 1), does 2) not follow by defining SetAsDomain as a domain constructor?

However, 3) and 4) might require a large amount of work.  This is
something I am more than willing to do.  However, a few notes:

Once we have a working Axiom atop GCL-2.7.0, this opens up a new world
for developers (an ANSI lisp).   I am trying to get that working with
the hopes that I can exploit the new features in an attempt to
reimplemented the compiler.  This is a huge task, of course, but I think
it is attainable.

The rewrite can attempt to accommodate the needs and issues raised by
yourself and others.  On an item by item basis, this might prove to be
easier in the context of a rewrite than trying to shoehorn more
features into the existing system, and to do so in a way such that
little or nothing else breaks.


What Im trying to decide here is how best I can focus my efforts.  I
am reluctant to invest a huge amount of time in extending a system I
have every intention of rewriting!  I realize that this is quite
selfish of me, for putting my own interests and goals first.  I do so
only because I think the returns are greater in the long run, compared
to expanding the current implementation over the course of the next
thirty years.

\start
Date: Fri, 13 Jul 2007 23:43:25 -0500 (CDT)
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: rep, per, Rep in SPAD/Aldor

Ralf --

  Sorry for the late reply: too many things to fit in only 24 hours/day.

I'll briefly address part of your posting.  I'll address the remaining
later, not that I think it is unimportant (au contraire!), but just that
a more detailled useful answer requires more time from me (which 
unfortunately I don't have right now, like most of you). I'll be going 
(again!) on travel in a few hours.   Many thanks for taking the time to 
expand on this ; it is a very important issue. 

On Fri, 13 Jul 2007, Ralf Hemmecke wrote:

| > However, I do believe that `rep' and `per' are fundamentally part
| > of the language semantics of domain.
| 
| Oh. You explicitly say "domain" (you don't include "package").

Yes, this is important only for things that provide concrete representation.

| So I somehow
| have to agree. But not really. You know that by using "pretend", I could
| remove any uses of Rep, per, rep.

Yes.  But my point is that doing that obscures the semantics.   First and
foremost, `pretend' is an act of violence in the logical conversation
with the translator/compiler: it means `shut up! This is not open for
debate; I know what I'm doing.'  That would be fine, if indeed the
writer also knows what she is doing and what she wrote is indeed what she
intended.  However, that is not true in general.  
Consequently, every use of pretend (whether hidden behind macro or not)
increases the 'trusted code base' (TCB), in addition of trusting the
compiler and other components.  From a verification point of view, that is a
serious problem (or unacceptable trend).

Secondly, what we want to convey with `rep' is not that one can take 
object foo, restrict its interpretation at type T and then do an 
`on faith interpretation of its sequence of bytes representation as 
an object at type U'.   Rather, what we want to say is that object foo 
at type T is the result of a (hopefully injective) mapping from U and we 
are interested in its pre-image.  

That is fundamental to the semantics of Spad domain.  How thar pair
of dual injections is called is really immaterial to developing the
semantics, and you're quite right that you could call it ying/yang
and as far as the semantics is concerned, nothing will change -- just like
Hilbert said one could work out geometry in terms on table and
beer mug instead of line and points.  However, there is another 
component: we need to have a standard name to designate those semantics
objects, just like we need a standard name for the sine and cosine
function to ease communication.  

In conclusion: (1) the semantics of rep/per at the source level
should not be defined in terms of pretend -- even if you could use
it to illustrate some uses (not all).  (2) We need to standardize
on common names for common semantics, and having this automatically
check is Good.


| Of course, nobody should write that code but
| rather follow the convention with Rep. What you want is to turn a convention
| into a rule.

Well, it you take it that way then we must not forget that language
is social convention.

| All I want to say is that this conflicts a bit with the design
| goals of Aldor: rather remove restrictions than introducing new features. I
| actually thought that you adhere to this principle. ;-)

Yes, I'm for removing unnecessary restrictions.  But, I do not view
the fact giving rep/per would a clearer semantics as a restriction. 

\start
Date: 14 Jul 2007 00:46:58 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: re: 2.7 build

Greetings!  Did you stop here?

      TopLevelDrawFunctions 
   Loading /fix/t1/camm/axiom/int/algebra/DRAWCFUN.nrlib/code for 
      package TopLevelDrawFunctionsForCompiledFunctions 
 
   >> System error:
   

(1) -> cp: cannot stat `/fix/t1/camm/axiom/int/algebra/*.daase': No such file or directory
make[3]: *** [/fix/t1/camm/axiom/mnt/linux/algebra/*.daase] Error 1


At some point we should discuss the replacement for emit-fn in 2.7.0.

1) If one has #+native-reloc, (si::do-recompile) in final image and
   save.  Optionally supply and argument and link with the recompiled
   source.

2) Otherwise, or if one prefers, wrap build stages in
   'with-compilation-unit, which will automatically recompile the
   original loaded compiled source files for use in a subsequent
   reload and save, or link.

The interface is still flexible -- I'd appreciate feedback in making
it optimally useful.

I take it at present, none of the patches you've made against silver
were required to workaround gcl bugs?  If you find same, please let me
know.  Thus far, I know of only Waldek's issue outstanding.

emit-fn is still there and has not been changed, but has bugs.

\start
Date: 14 Jul 2007 00:01:58 -0500
From: Gabriel Dos Reis
To: Camm Maguire
Subject: re: 2.7 build

Camm Maguire writes:

[...]

| emit-fn is still there and has not been changed, but has bugs.

I understand your discussion was in the GCL-2.7.0 context.  Is it 
advisable for Axiom to remove its use entirely -- even with
GCL-2.6.8pre?

\start
Date: 14 Jul 2007 01:30:07 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: re: 2.7 build

Camm Maguire writes:

> Greetings!  Did you stop here?
> 
>       TopLevelDrawFunctions 
>    Loading /fix/t1/camm/axiom/int/algebra/DRAWCFUN.nrlib/code for 
>       package TopLevelDrawFunctionsForCompiledFunctions 
>  
>    >> System error:
>    
> 
> (1) -> cp: cannot stat `/fix/t1/camm/axiom/int/algebra/*.daase': No such file or directory
> make[3]: *** [/fix/t1/camm/axiom/mnt/linux/algebra/*.daase] Error 1

Yes, this is where I am at.  But my goodness, you must have a fast
machine.  I started my latest build perhaps 6 hours ago and its still
on layer 14 of the algebra build.  I envy you :)

> At some point we should discuss the replacement for emit-fn in 2.7.0.
> 
> 1) If one has #+native-reloc, (si::do-recompile) in final image and
>    save.  Optionally supply and argument and link with the recompiled
>    source.
> 
> 2) Otherwise, or if one prefers, wrap build stages in
>    'with-compilation-unit, which will automatically recompile the
>    original loaded compiled source files for use in a subsequent
>    reload and save, or link.

Personally, I favor 2), insofar as there are efforts to use ASDF as a
make replacement, which automatically wraps its components in a
with-compilation-unit.  Given this is the typical procedure for Lisp
programs, perhaps the general audience for GCL would appreciate that
support.

On the other hand, I think that (si::do-recompile) is the preferred
route for Axiom when based on iterative make style builds, as is
currently the case.

So unfortunately I cant make a conclusive decision, as both seem to me
equally important.

> The interface is still flexible -- I'd appreciate feedback in making
> it optimally useful.

I am still on the extreme uphill side of understanding both Axiom and
GCL.  If I gain any potentially useful insights, I will certainly let
you know.
 
> I take it at present, none of the patches you've made against silver
> were required to workaround gcl bugs?  If you find same, please let me
> know.  Thus far, I know of only Waldek's issue outstanding.

This is correct.  Every issue I found with GCL has been fixed.  Thank
you!!!

> emit-fn is still there and has not been changed, but has bugs.

OK.  One of the challenges at this point is to convert this `base
line' patchset into one which cooperates well with both 2.7.0 and the
2.6.8pre snapshot what has served Axiom so well.  It will likely take
some time before Axiom can drop support for CLTL1 builds altogether.

Thanks again Camm for all your hard work!  It is completely pointless
to try and measure the importance of your contributions!!

\start
Date: 14 Jul 2007 02:04:49 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: compiler.boot issue #370 patch

Tim Daly writes:

> Stephen,
> 
> I pushed the compiler.boot patch.
> 
> I also re-engineered the testing machinery so the unit test spad code
> you wrote is included in the input test file. This unit test code is
> now run during build time and then the regression machinery tests the
> result. This is general purpose and we can write spad code in input 
> files for unit testing, somewhat like the AldorUnit idea.

I just pulled the changes and looked at the implementation.

Using gclweb to tangle the sources is just brilliant!!!

I am so happy we are slowly but surly getting the pieces of the puzzle
together.

\start
Date: Sat, 14 Jul 2007 01:15:07 -0500
From: Tim Daly
To: Stephen Wilson
Subject: 2.7 build

Stephen,

> Using gclweb to tangle the sources...

You'll notice that the chunk is latex syntax, not noweb syntax.
I'll have the latex chunk environment soon.

\start
Date: Sat, 14 Jul 2007 08:24:16 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: 2.7 build
Cc: list

I hope with this syntax change somebody thinks of people who use 
mmm-mode.el with noweb settings. If I don't get this I am not at all for 
  a syntax change.

And by the way. Am I actually allowed to have a word whether such a 
change should go to trunk or not?

Ralf

On 07/14/2007 08:15 AM, Tim Daly wrote:
> Stephen,
> 
>> Using gclweb to tangle the sources...
> 
> You'll notice that the chunk is latex syntax, not noweb syntax.
> I'll have the latex chunk environment soon.

\start
Date: 14 Jul 2007 08:33:57 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: disagreement and development model

Dear all, especially Tim,

unfortunately I fell sick, so I am unable to propose a development model right
now.  (I have written something, but I would like to check whether it really
would do the job.)

However, there has been quite a lot of activity on the list, and there is
especially one thing I need to comment on:

Tim Daly writes:

> You'll notice that the chunk is latex syntax, not noweb syntax.  I'll have
> the latex chunk environment soon.

Tim, as far as I recall, it was not only me who was against changing the noweb
syntax.  In any case it breaks mmm-mode (i.e., no syntax highlighting in emacs
anymore) and ALLPROSE (which will not depend on Lisp).  I hope that this is in
your local branch, not in trunk/silver?

\start
Date: 14 Jul 2007 08:41:02 +0200
From: Martin Rubey
To: Stephen Wilson
Subject: Re: keyword arguments, was: Unions in Spad (Correction)

Stephen Wilson writes:

> Perhaps the best solution in this case is as Bill Page suggested,
> implementing keyword arguments in Axiom, allowing us to write [a:1] or
> [b:1] thus enabling unambiguous specification of the branch.

Please (!) do it the aldor way, i.e., use == instead of :.  There is no reason
here to diverge from aldor syntax.

Furthermore, currently "fake" keyword arguments in SPAD are also done with
"==".  Look at my guessing package or the way options to the drawing routines
are passed.


I realize and accept that some of you are not interested in aldor at all.  But
for me and in fact, also for other people I know, but do not read this list,
aldor is a necessity.  I cannot do axiom as a hobby, it is work for me.  If
axiom and aldor diverge, I have a serious problem.

Martin




\start
Date: Sat, 14 Jul 2007 09:16:45 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: rep, per, Rep in SPAD/Aldor

Gaby,

just a short reply. As I said, I agree that Rep is an important issue. 
It would actually be good to hear what Stephen Watt has to say about 
that issue. I'd like to learn about the original intentions.

> Secondly, what we want to convey with `rep' is not that one can take 
> object foo, restrict its interpretation at type T and then do an 
> `on faith interpretation of its sequence of bytes representation as 
> an object at type U'.   Rather, what we want to say is that object foo 
> at type T is the result of a (hopefully injective) mapping from U and we 
> are interested in its pre-image.  

I don't know that I understand that paragraph. If I understand that 
correctly, then (U = Rep, T = %)

per: Rep -> %     injective map
   In general we have card(Rep)>=card(%). (If this would not always be
   true then I don't know.)

rep: % -> Rep     the "inverse" of per
   If x is from % then rep(x) should be an element from Rep such that
   per(rep x) = x. Since there might be several such elements, rep should
   choose one, and since we want rep to be a function, it should always
   choose the same element from the preimage of per.

Gaby, what you were saying is that Rep and % (in an abstract setting) 
need not be represented by the same string of bytes in memory. That is 
my interpretation of your paragraph. Abstractly seen, this seems to be 
OK, but from an efficiency point of view, it is probably always good if 
rep and per actually do nothing than changing the view on the same 
string of bytes in memory. But, I agree, that decision should be left to 
the compiler.

\start
Date: Sat, 14 Jul 2007 09:41:53 +0200
From: Christian Aistleitner
To: Ralf Hemmecke, Gabriel Dos Reis
Subject: Re: [Aldor-l] rep, per, Rep in SPAD/Aldor

On Fri, 13 Jul 2007 13:57:16 +0200, Ralf Hemmecke wro=
te:

> In Aldor we write
>
> Foo: with {
>    coerce: Integer -> %;
>    test?: % -> Boolean;
> } == add {
>    Rep == String;
>    ...
> }
>
> and mean something like
>
>    Foo = ((%, Integer, Boolean), (coerce, test?))
>
> in the multisorted algebra sense. We don't actually make Integer and
> Boolean (not String) an argument to Foo or "with", they are implicit.

I understand why String is not an (implicit) Parameter of the with part.=

I am rather convinced that it's not of importance, but why isn't String =
an  =

implicit parameter of Foo (which is made up of the with _and_ the add  =

part)?

> Now let us look to the "add" part. There we have yet another domain,
> namely Rep. Inside "add" we actually consider an algebra like
>
>    Foo' = ((%, Rep, Integer, Boolean), (coerce, test?, per, rep))
>
> Hmmm, I have just cooked that all up right now, but it seems a pretty
> coherent view on domains.

I am not too sure whether I can follow you here.
I assume you want us to assume "per" and "rep" occur in the code you gav=
e  =

for Foo some lines above.

Then by just looking at the syntax, I'd have to agree.
However, languages allowing macros typically act in two stages. One of  =

which is macro expansion/replacement.
In Aldor this is somehow hidden from the user--in languages like C, it i=
s  =

more vivid.

Before macro expansion, I'd roughly agree with your signatures. But afte=
r  =

macro expansion, I'd expect to get

     Foo' = ((%, Rep, Integer, Boolean), (coerce, test?))

. And that is just what you get when using the interactive loop:

> aldor -gloop
> %1 >> #include "aldor"
> %2 >> #include "aldorinterp"
> %3 >> add {Rep==String;coerce(z:Integer):%==per
> "int";test?(x:%):Boolean==true}
>    () @  with
>          Rep: ? == String
>          coerce: (z: AldorInteger) -> %
>          test?: (x: %) -> Boolean

No sign of rep and per, as the interpreter has expanded the macros for y=
ou.
rep and per are not functions to me. They are rewrite rules. IMHO, they =
 =

(and the other macros) act on a meta level, when looking at the Aldor  =

language.

> That is pretty close, but lacks per and rep. Gaby, I think that is one=

> point for you. Here I would like to see rep,per, Rep. Don't you agree?=


I do not agree.

> But note if we export Rep, we somehow are in conflict with "hiding the=

> representation".

No we are not.
We are exporting a constant Rep.
But you are also exporting two other constants as well, namely coerce an=
d  =

test?.

Why should Rep be the representation of the domain and not coerce or tes=
t?  =

?

Rep is nothing special. In your previous example you used Ying instead o=
f  =

Rep.
The export of Rep, Ying, or whatever does not tell "This domain uses thi=
s  =

representation". It just tells you "This domains exports a Symbol with  =

name Rep, Ying, or whatever".
A name is just a name.

\start
Date: 14 Jul 2007 06:13:19 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: rep, per, Rep in SPAD/Aldor

Ralf Hemmecke writes:

| Gaby,
| 
| just a short reply. As I said, I agree that Rep is an important
| issue. It would actually be good to hear what Stephen Watt has to say
| about that issue. I'd like to learn about the original intentions.
| 
| > Secondly, what we want to convey with `rep' is not that one can take
| > object foo, restrict its interpretation at type T and then do an `on
| > faith interpretation of its sequence of bytes representation as an
| > object at type U'.   Rather, what we want to say is that object foo
| > at type T is the result of a (hopefully injective) mapping from U
| > and we are interested in its pre-image.
| 
| I don't know that I understand that paragraph. If I understand that
| correctly, then (U = Rep, T = %)
| 
| per: Rep -> %     injective map
|    In general we have card(Rep)>=card(%). (If this would not always be
|    true then I don't know.)
| 
| rep: % -> Rep     the "inverse" of per
|    If x is from % then rep(x) should be an element from Rep such that
|    per(rep x) = x. Since there might be several such elements, rep should
|    choose one, and since we want rep to be a function, it should always
|    choose the same element from the preimage of per.
| 
| Gaby, what you were saying is that Rep and % (in an abstract setting)
| need not be represented by the same string of bytes in memory. 

You understand me correctly.

| That is
| my interpretation of your paragraph. Abstractly seen, this seems to be
| OK, but from an efficiency point of view, it is probably always good
| if rep and per actually do nothing than changing the view on the same
| string of bytes in memory.

Depending on the application, yes.

| But, I agree, that decision should be left to the compiler.

\start
Date: 14 Jul 2007 09:16:09 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: re: 2.7 build

Gabriel Dos Reis writes:

> Camm Maguire writes:
> 
> [...]
> 
> | emit-fn is still there and has not been changed, but has bugs.
> 
> I understand your discussion was in the GCL-2.7.0 context.  Is it 
> advisable for Axiom to remove its use entirely -- even with
> GCL-2.6.8pre?
> 

No, I recommend it strongly with 2.6.8 for performance reasons.  Axiom
does not run afoul of any of the weaknesses, AFAICT.

I'm also eager if anyone has comparative performance reports on 2.6
and 2.7.  Bootstraping the latter takes longer, but (I hope) all other
metrics point the other way.

\start
Date: Sat, 14 Jul 2007 08:32:54 -0500 (CDT)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: re: 2.7 build

On Sat, 14 Jul 2007, Camm Maguire wrote:

| Greetings!
| 
| Gabriel Dos Reis writes:
| 
| > Camm Maguire writes:
| > 
| > [...]
| > 
| > | emit-fn is still there and has not been changed, but has bugs.
| > 
| > I understand your discussion was in the GCL-2.7.0 context.  Is it 
| > advisable for Axiom to remove its use entirely -- even with
| > GCL-2.6.8pre?
| > 
| 
| No, I recommend it strongly with 2.6.8 for performance reasons.  Axiom
| does not run afoul of any of the weaknesses, AFAICT.

Copy that.  Thanks!
\start
Date: Sat, 14 Jul 2007 16:24:11 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: re: debugging

Camm Maguire wrote:
> Waldek Hebisch writes:
> > I wrote:
> > > There are several functions involved.  In case of #<OBJNULL> using
> > > traces I see that |compDefineCapsuleFunction| function (defined
> > > in 'define.boot.pamphlet') gets:
> > > 
> > >  1> (|compDefineCapsuleFunction|
> > >          (DEF (|base|) (NIL) (NIL)
> > >               ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|))))
> > > ...
> > > ...
> > > 
> 
> In which package is this?  Is it present in interpsys?
>

First a little correction: there are two versions on 
|compDefineCapsuleFunction|, one in 'define.boot.pamphlet' and
the second one in 'br-saturn.boot.pamphlet'.  Normally version
from 'br-saturn.boot.pamphlet' is in use.  

All functions in question are defined in "BOOT" package.  The
files are autoloaded.  To get the traces I did (in the algebra
build directory):

(export AXIOM=/h/axp62/ax-build2/target/x86_64-unknown-linux; export DAASE=/h/axp62/wh-sandbox/src/share; /h/axp62/ax-build2/build/x86_64-unknown-linux/bin/interpsys )
)lisp (|oldCompilerAutoloadOnceTrigger|)
)lisp (trace |compElt| |compileCases| |compDefineCapsuleFunction| |compForm1|)
)compile "DFLOAT.spad"
 
That produced about 150 Mb trace.

To be extra careful you may also do (before tracing):

)lisp (|browserAutoloadOnceTrigger|)

to load correct version of |compDefineCapsuleFunction|.

> > > 
> > > It seems that (|elt| $ (|Zero|)) give us '#<OBJNULL>.  |elt| is
> > > handled in 'compiler.boot.pamphlet':
> > > 
> > > 
> > >     2> (|compForm1| ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|)))
> > > 
> > >       3> (|compElt| (|elt| $ (|Zero|)) |$EmptyMode|
> > > ....
> > > ....
> > >       <3 (|compElt|
> > >              ((|call| (XLAM |ignore| '#<OBJNULL>)) $
> > > 
> > 
> 
> Can you please post the full call to compElt in 3> above?
>

The third argument is large (75 kb), so I have put call to |compElt|
and return value at:

http://www.math.uni.wroc.pl/~hebisch/compElt.txt

 
> > I have narrowed down the problem:
> > 
> >    compiling exported base : () -> PositiveInteger
> >   1> (|genDeltaEntry| (|Zero| ($ $) (T (CONST $ 18))))
> >     2> (|optDeltaEntry| |Zero| ($) $ CONST)
> >       3> (|compiledLookup| |Zero| ((|DoubleFloat|))
> >              #<vector 0000000002b66f90>)
> >       <3 (|compiledLookup|
> >              (|makeSpadConstant|
> >                  #<compiled-function |DFLOAT;Zero;$;15|>
> >                  #<vector 0000000002b66f90> 25))
> >     <2 (|optDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
> >   <1 (|genDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
> > 
> > 
> > |makeSpadConstant| calls its argument.  Checking this I get:
> > 
> 
> Why are there 3 arguments above?  The definition appears to take one.
>

(|makeSpadConstant|
                 #<compiled-function |DFLOAT;Zero;$;15|>
                 #<vector 0000000002b66f90> 25)

is not a call, it is just a list of length four.  This list is
passed to the SPADCALL macro with the effect that car of the list
is called with cdr as na argument (using SPADCALL is an abuse here...).
 
> > )lisp (|DFLOAT;Zero;$;15| nil)
> > 
> > Value = #<OBJNULL>
> > 
> > )lisp (disassemble '|DFLOAT;Zero;$;15|)
> > ^M
> >    >> System error:
> >    Condition in DISASSEMBLE [or a callee]: INTERNAL-SIMPLE-END-OF-FILE: Stream error on stream #<input stream "/tmp/gazonk0.c">: Unexpected end of file:
> > 
> 
> This is a simple .h file naming bug I'll try to fix soon.
> 
> 
> > Looking at "/tmp/gazonk0.c" I see:
> > 
> > 
> > #include "cmpinclude.h"
> > #include "gazonk0.h"
> > void init__tmp_gazonk0(){do_init((void *)VV);}
> > /*      local entry for function DFLOAT;Zero;$;15       */
> > 
> > static double LI1__DFLOAT$Zero$$$15___gazonk0(V2)
> > 
> > object V2;
> > {        VMB1 VMS1 VMV1
> >         goto TTL;
> > TTL:;
> >         /*(FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
> >         {fixnum V3;
> >         V3= (fixnum)0;
> >         V3= (fixnum)0;
> >         {double V4 = (    1.    )*((fixnum)0);VMR1
> >         (V4);}}
> >         /* END (FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
> >         {double V5 = lf(Cnil);VMR1
> >         (V5);}
> 
> This is correct but unpleasant C which needs tidying.  There can be
> extra 'unwinds' scheduled currently in GCL -- these are harmless but
> misleading.  The function returns from the macro VMR1.  I'll try to
> clean this up too.
> 

I mean that 'lf(Cnil)' looks strange -- Axiom expects double
precision 0 as the result.

> Why does this function take an argument which is ignored -- is this right? 
> 

Yes, |DFLOAT;Zero;$;15| is a Spad function.  All Spad function receive
an extra argument:  the domain or package to which they belong.  This
extra argument appears last in the argument list.  |DFLOAT;Zero;$;15|
does not need any extra information from its domain, so the
argument is ignored, but in general it may be used.  If one wants
to pass "correct" value of the argument one has to do:

)lisp (|DoubleFloat|)
)lisp (|DFLOAT;Zero;$;15| (|DoubleFloat|))

the first call to |DoubleFloat| is triggers autolading of DFLOAT.o file.

If I do the above in 2.6.8 compiled interpsys I get floating point
0.  In 2.7.0 compiled interpsys (the one from the failing build) I get
#<OBJNULL>
 
\start
Date: Sat, 14 Jul 2007 13:17:50 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: noweb syntax

Eh? I thought we HAD already discussed this on the list. We must have
discussed it since I know that Cliff's parser can handle either
syntax. gclweb works for CLtL1 and cl-web will work for ansi. I've
been working slowly on a latex chunk mode for a long time and have
discussed it here several times.



I'm not sure how changing the syntax changes the problem.
There has to be some string that any chunk parser recognizes.
So in place of

   <<this is a chunk>>=
   @

we put

   \begin{chunk}{this is a chunk}
   \end{chunk}

which is a pure syntax substitution. It has not changed the 
semantics of the problem at all. And emacs does have a latex mode.

This completely elides the need to have a weave command
and thus both simplifies and speeds up the build process.




So lets discuss the pros and cons of using latex vs noweb syntax
and make a list of advantages and disadvantages. We can discuss
points relative to the list. Please add additional points so we
can keep the discussion "on track" and rational.

A) NOWEB ADVANTAGES
  1) currently works
  2) easily recognizable syntax
  3) axiom noweb emacs mode recognizes syntax
  4) current build machinery uses noweb
  
B) NOWEB DISADVANTAGES
  1) collides with user syntax, e.g. [[1,2],[3,4]] vs [[escapedstring]]
  2) requires a weave step to get latex
  3) noweb is not as widely known as latex
  4) requires noweb
  5) requires time during build

C) LATEX ADVANTAGES
  1) pure latex files, that is pamphlet == tex
  2) latex users can use it immediately, without learning new syntax
  3) emacs has a latex mode
  4) pure latex is widely known
  5) enables latex commands within \begin{chunk} environments
  6) allows latex tools for chunks (auto-index, auto-table of contents)
  7) saves build time
  8) removes need for noweb

D) LATEX DISADVANTAGES
  1) breaks axiom noweb emacs mode
  2) requires rewrite of sources
  3) breaks ALLPROSE? (I don't know)




Of course, you've invested a lot into building ALLPROSE and have
thought quite a bit about the issues. It is not clear how a syntax
change causes a large impact but I obviously don't understand the
details. Please explain. 

The work involved to adopt latex syntax involves a rewrite of all
of the pamphlet files from <<>> to \begin{chunk} but, since it is
just a syntactic change it could be done automatically. The [[]]
syntax escapes would have to be changed to \verb. The calls to 
notangle need to be changed to calls to (tangle ...). Once that was 
done noweb could be removed from the system. This means that build
times are shorter. It removes the dependence on noweb completely.

\start
Date: 14 Jul 2007 21:38:52 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: noweb syntax

Tim Daly writes:

> A) NOWEB ADVANTAGES
>   1) currently works
>   2) easily recognizable syntax
>   3) axiom noweb emacs mode recognizes syntax
>   4) current build machinery uses noweb
>   
> B) NOWEB DISADVANTAGES
>   1) collides with user syntax, e.g. [[1,2],[3,4]] vs [[escapedstring]]
>   2) requires a weave step to get latex
>   3) noweb is not as widely known as latex
>   4) requires noweb
>   5) requires time during build
> 
> C) LATEX ADVANTAGES
>   1) pure latex files, that is pamphlet == tex
>   2) latex users can use it immediately, without learning new syntax
>   3) emacs has a latex mode
>   4) pure latex is widely known
>   5) enables latex commands within \begin{chunk} environments
>   6) allows latex tools for chunks (auto-index, auto-table of contents)

but I do not want that LaTeX mode auto indents my SPAD or Aldor commands!  The
indentation rules are different!

>   7) saves build time
>   8) removes need for noweb
> 
> D) LATEX DISADVANTAGES
>   1) breaks axiom noweb emacs mode
>   2) requires rewrite of sources
>   3) breaks ALLPROSE? (I don't know)
    4) requires more space, i.e., @ is shorter than \end{chunk}. 
    5) can it handle nested chunks?

This last point is especially important if you want to intersperse commands and
documentation, as I tend to.  To my eyes, @ looks more or less like an empty
line.  \end{chunk} requires another empty line, I feel.

Tim, I suggest that you make this change in a separate branch.  We had this
discussion once, as you said, but already then there was disagreement.  Ralf
pointed out some of the difficulties back then, but I cannot find a reply of
yours:

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

(By the way, could you please copy the "references: " field when you reply to
mail.  I find it hard to find out what mail you are replying to.)

So, how would the following code read in gclweb?

<<implementation: Compose>>=
structures(s: SetSpecies L): Generator % == generate {
        for pi in structures(s)$Partition(L) repeat {
                <<Yield elements of $F[\pi]\times\prod_{p\in\pi} {G[p]}$>>
        }
}
@

some more documentation here...

<<Yield elements of $F[\pi]\times\prod_{p\in\pi} {G[p]}$>>=
import from MachineInteger, Partition L;
arrlist: Array List L := pi::Array List L;
for f in structures(pi::SetSpecies(SetSpecies L))$F(SetSpecies L) repeat {
        for p in structures(0, arrlist) repeat yield per [pi, f, p];
}
@

\start
Date: 14 Jul 2007 22:11:09 +0200
From: Martin Rubey
To: axiom-devel <list>
Subject: Proposal for a new development model

Dear all,

below you find a first draft of a new development model I would like to propose
for axiom.  It does break with some of the current rules, but I still hope it
will be approved.  The most crucial shift is to a more democratic view, that
splits branches into two classes, according to whether decisions are taken by
the community as a whole or by the maintainer only.  In this model, there are
two special "branches", namely "Gold" and "Silver", which are both community
driven -- but possibly maintained by a single person.

I would like to emphasise that I do value branches a lot.  I think it is great
to have the axisp branch and wh-sandbox, especially because they probably
represent rather different views on how things should be done.  Accordingly, in
the model I propose, at one point in time, "trunk" can follow mostly one view,
at some later point, if it proves useful, another view.

Since decisions are taken by the community and having several branches around
is encouraged, I hope that this model minimises bad emotions and will not leave
anybody badly hurt when for some reason "her favourite code" is taken out of
trunk and replaced by somebody else's code.

I will also put this proposal on MathAction, SandboxDevelopmentModel, so that
everybody can easily comment on it, and also vote (using a comment).

Before you approve or disapprove, please try to envision how you will feel if
your favourite patch does not make it into trunk, because there is a vote
against it, and how you will feel if some large change takes place in trunk you
are not happy with.  Furthermore, will you be able to vote, independently and
without being afraid of other peoples reactions?

As I learned in the last two weeks, but also within the project together with
Ralf, emotions play a very important role, and although dictatorship has its
merits in software development, it is time to evolve.

To make my intentions clear: I will definitively stay in the axiom community,
if "silver" will be "community driven" in future.  That's the crucial point for
me, and this point is most elaborated in the model below.  Feedback is welcome.

I sincerely hope,

Martin

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

Axiom is a free computer algebra system, developed by a community of computer
scientists, mathematicians, physicists and other interested people.  On this
page we describe the development model we adhere to, in order to enable
cooperation and minimise the danger of arguments and bad emotions.

goals:

  * documentation using the ideas of literate programming.
  
  * correctness has highest priority, but usability is important.

  * attract mathematicians and computer scientists.


setting:

  * for some of us, axiom is a hobby, for others part of their work

  * the axiom community consists of all people subscribed to axiom-developer

  * the axiom foundation is a board of three members, appointed for one year


Axiom is developed in many branches, by many individuals.  We can think of two
different models for branches:

  * "community driven branches"

    although possibly maintained by a single person, decisions concerning such
    branches are taken by the community as a whole.  Patches should first be
    sent to axiom-developer.  They can be applied if nobody disagrees within a
    reasonable period of time.  If there is disagreement on whether a
    particular patch should be applied or not - especially concerning "large"
    patches, a vote among the axiom community decides.  Although everybody in
    the community can vote, we urge people to vote only on subjects they feel
    that they understand well.  In any case, care should be taken to reach
    consensus.  In some cases it may be more useful to start another branch
    that is kept in sync.  "Community driven branches" should be regularly
    synchronised with "silver".

  * "privately driven branches"

    decisions concerning such branches are taken by the maintainer.  However,
    the maintainer is encouraged to regularly synchronise with "silver".


There are two special branches that are "community driven", namely "Silver" and
"Gold":

  * "Silver" (also known as "trunk" in the subversion repository) is the stable
    branch.  Patches are eligible only if they do not break usability of axiom.

    For this branch, we strongly encourage developers to document their
    findings.  However, if a patch greatly improves the usability of axiom, it
    may still be eligible, in the hope that documentation will follow.  In
    certain cases, it may be unknown why a modification of the source fixes a
    bug.  Then, an appropriate notice should be added to the documentation.

  * "Gold" contains the latest release of axiom.  Any member of the axiom
    community may suggest on axiom-developer that "Silver" is released, i.e.,
    becomes "Gold" after a short freezing period.  It may prove useful to
    create a release branch.  The person that suggested the release is also
    responsible for picking a release number, and the creation of tarballs,
    debian packages, etc. of this particular release.  Of course, it may
    delegate the work involved.


tools:

in general, we try to accommodate different work flows if possible.  To allow
cooperation, however, we insist on the following tools:

  * for "community driven branches" we use a subversion repository

  * the documentation is written in LaTeX, using noweb or a compatible tool.
    It should not be necessary to use a special editor to modify documentation
    and sources.

  * to track issues and patches, we use the IssueTracker.  We urge contributors
    to send patches that adress a particular issue not only to axiom-developer,
    but also to IssueTracker.

\start
Date: 14 Jul 2007 16:14:14 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: re: 2.7 build

Stephen Wilson writes:

> Camm Maguire writes:
> 
> > Greetings!  Did you stop here?
> > 
> >       TopLevelDrawFunctions 
> >    Loading /fix/t1/camm/axiom/int/algebra/DRAWCFUN.nrlib/code for 
> >       package TopLevelDrawFunctionsForCompiledFunctions 
> >  
> >    >> System error:
> >    
> > 
> > (1) -> cp: cannot stat `/fix/t1/camm/axiom/int/algebra/*.daase': No such file or directory
> > make[3]: *** [/fix/t1/camm/axiom/mnt/linux/algebra/*.daase] Error 1


I believe this is the result of a GCL issue, but one I cant make heads
or tails of.


==----- test.lisp ----
(defun test (|ff| |f|) 
  (prog (|s| |r|)
     (block nil
       (setq |s| (funcall |ff| |f|))
       (setq |r| (cdr |s|)) 
       (cond ((< 1 |r|) 1)
             ((< |r| most-negative-long-float) most-positive-long-float)
             (t |r|)))))
==--------------------

This is about as simple as I could get it. Note that one can change a
large number of items in the above form and the problem disappears.
For example, comment out one of the setq's, or rewrite
most-negative-long-float as most-positive-long-float.

steve:tmp> gcl
GCL (GNU Common Lisp)  2.7.0 ANSI    Jul 12 2007 17:59:02
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

Temporary directory for compiler files set to /tmp/

>(si::use-fast-links nil)

NIL

>(load (compile-file "test.lisp"))

;; Compiling test.lisp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling test.o.
;; Loading /home/steve/tmp/test.o

Error: 
Signalled by LOAD1.
INTERNAL-SIMPLE-READER-ERROR: Stream error on stream #<input stream "/home/steve/tmp/test.o">: The default dispatch macro signalled an error.

Broken at LOAD1.  Type :H for Help.
 1 (Continue) Retry loading file NIL.
 2 Retry loading file NIL.
 3 Return to top level.
>>:bt

#0   LOAD1 {loc0=#P"/home/steve/tmp/test.o",loc1=t,loc2=nil,loc3=:error,loc4=nil,loc5=nil,l...} [ihs=4]
#1   LOAD {pn=#P"/home/steve/tmp/test.o",args=(nil nil),loc2=(#<@0128AC00> nil nil),loc3=(...} [ihs=3]
#2   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function load>} [ihs=2]
>>

\start
Date: Sun, 15 Jul 2007 15:31:48 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [664] trunk/axiom
Cc: axiom-dev <list>

Ooops.

I must have missed some link to an agreement that the Axiom community 
now prefers

\begin{chunk}{...}

\end{chunk}

instead of

<<...>>=

@

And you probably have not read Martin's post

http://lists.nongnu.org/archive/html/axiom-developer/2007-07/msg00389.html
with a link to what I have said before.

Tim, you have not actually answered my question from

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

Implicitly this commit to trunk says: *NO*. That basically tells me: 
Ralf, that is Tim's project. If you want to contribute in a different 
direction, open up a fork. (I don't want that.) I now understand, I am 
not welcome as an Axiom developer. I am simply ignored.

I hesitate to wish you good luck for the future, since with that policy 
of ignoring other developers there is no future for Axiom.

Have fun with your little Tim-Project.

Ralf

On 07/15/2007 03:10 PM, daly@users.sourceforge.net wrote:
> Revision: 664
>           http://svn.sourceforge.net/axiom/?rev=664&view=rev
> Author:   daly
> Date:     2007-07-15 06:10:14 -0700 (Sun, 15 Jul 2007)
> 
> Log Message:
> -----------
> 20070715 tpd src/input/cwmmt.input format math, latex commands in chunk env.
> 20070715 tpd src/doc/axiom.sty add \begin{chunk} environment
> 20070715 tpd src/scripts/tex/axiom.sty add \begin{chunk} environment
> 20070714 tpd src/input/gclweb.lisp adapt to latex or noweb base on chunkname
> 
> Modified Paths:
> --------------
>     trunk/axiom/changelog
>     trunk/axiom/src/doc/axiom.sty.pamphlet
>     trunk/axiom/src/input/cwmmt.input.pamphlet
>     trunk/axiom/src/scripts/tex/axiom.sty

[snip]

\start
Date: Sun, 15 Jul 2007 08:40:41 -0500
From: Tim Daly
To: list
Subject: Literate Programming

The latest changeset introduces two related changes, gclweb and
axiom.sty.  Together these changes allow optional syntactic changes to
pamphlets.  These changes will completely eliminate the need to weave
files since now a pamphlet file can be a valid latex file. Tangle is
the only remaining command and it will eventually be an option on
)compile, etc. If you don't care then these changes don't affect you.



src/interp/gclweb.lisp

The src/interp/gclweb.lisp file introduces the ability to extract code
from pamphlet files while inside Axiom. The short description is that
gclweb will now automatically distinguish the type of chunk style
(latex or noweb) based on the chunk name. It is a first step to a native
understanding of pamphlet files. Future work involves integrating it
into commands like )compile and adding commands like )tangle. 

To tangle a file from within Axiom:

  )lisp (tangle "filename.pamphlet" "<<chunkname>>")
  
which is noweb syntax. Output goes to the console. You can direct the
output to a file with the optional third argument:

  )lisp (tangle "filename.pamphlet" "<<chunkname>>" "filename.spad")


If you use the new latex chunk environment the syntax is:

  )lisp (tangle "filename.pamphlet" "chunkname")
  )lisp (tangle "filename.pamphlet" "chunkname" "filename.spad")

gclweb distinguishes the input syntax by looking at the first character
of the chunkname. If it is a '<' then noweb is used, otherwise latex.





src/doc/axiom.sty.pamphlet

This introduces the new chunk environment. This is a completely
compatible change and has no impact on existing pamphlets. The
new syntax makes pamphlet files = tex files so there is no need
to use weave. The gclweb change has a compatible tangle function
which can be invoked from inside Axiom.

Noweb syntax of:

  <<chunkname>>=
    your code goes here
  @

can also be written as:

  \begin{chunk}{chunkname}
    your code goes here
  \end{chunk}

The new syntax is entirely optional.


One new feature of the latex chunk style is that latex commands
work within the chunk. To get typeset mathematics use \( and \)

-- This will typeset in a chunk \( x^2+\epsilon \)
-- And you can format things {\bf bold}

\start
Date: Sun, 15 Jul 2007 10:22:35 -0400
From: David Bindel
To: list
Subject: Literate programming thoughts

I happened upon the discussions about literate programming on this
mailing list while figuring out why so many people were looking at my
"dsbweb" entry on my blog.  I've had some e-mail exchanges with Tim,
who suggested that I might re-post our exchanges to the
list.  Rather than re-post without context, I've decided to summarize
my thoughts on the matter in one (long) post.  I will also put a
version of this note on my blog, though it may take a week or so.

I will say in advance that different software projects have different
cultures and needs, and I know only a little about the history and
development of Axiom.  So I recognize that not all of what I write
will be relevant.  For the pieces that are (or for those that
aren't, but that you find entertaining or irritating), I welcome
your comments and criticisms.

Cheers,
David

---

I.  A little personal history

A few years ago, I was involved in SUGAR, a simulator that was meant
to play the same role for micro-electro-mechanical system designers
that SPICE plays for IC designers.  The group I worked with included
engineers (as well as other mathematicians and computer scientists)
with widely varying levels of programming experience.  For version 3.0
of this code, I decided to use noweb (on top of a mix of C, MATLAB,
and Lua codes for which a language-specific tool would have been
inappropriate).  Part of my reason for choosing this tool was
curiosity: I'd enjoyed Knuth's book on literate programming, and I
really liked Hansen's /C Interfaces and Implementations/ (also a
literate program).  I was curious how these techniques would work for
me.  The other part of the reason was that I thought a literate
programming environment would help me better convey some of the
internal structure to the others in the group.

As an experiment in literate programming, I think my effort was a
modest success.  The program was clearer than it would have been
otherwise; and by writing in that style, I did catch problems did that
I otherwise might have missed.  As an effort to convey the information
to others, the effort was a failure.  I think I was the only one to
ever read most of what I wrote or re-wrote in a literate style.

At a more concrete level, I had some problems with the structure of
noweb, with its layers of pipeline-connected filters.  I could usually
get noweb working on my system, but it broke if I moved it from the
original installation location, and it depended on the presence of
several other tools.  Getting noweb working for other people (or
getting it working for myself when I did builds on a Windows machine)
was a hassle.  With a very few exceptions, it bothered me to check
generated sources into the version control, or to send patches to
generated sources, so I wanted to have a very portable tool to take my
noweb files and produce the relevant C, MATLAB, and Lua files.
Consequently, I ended up writing a short C code to replace the tangle
phase in noweb.

I subsequently read some wry comments on various literate programming
sites to the effect that writing one's own LP tool seems like almost a
requirement for anyone who starts playing with literate programming.
Certainly this matches my experience, and it sounds as though the
Axiom group may have the same experience.


II.  Comments on documentation tools

I ultimately gave up on noweb (though if noweb 3 becomes a reality, I
may try it again).  I did try some other documentation tools, though.
I think Doxygen is cool, but it's very oriented toward C/C++.  I've
also found over time that when I read other people's C/C++ code, I
usually perfer to open the source in an Emacs session than to open the
Doxygen-generated files in a web browser.  For whatever reason, I have
found the opposite when reading Java code; I suspect this is because
of the point I alluded to earlier, that different types of
documentation are appropriate to different types of codes.

I was aware of the literate Haskell efforts, and also of documentation
tools like Schmooz.  These were, once again, language-specific tools.
But the basic ideas are independent of the language, and they are
quite straightforward.  If one is willing to give up macro expansions
(chunks) and various indexing tools (which tend to be language
specific), then a literate programming tool need do little more than
scan a file to identify which pieces should be treated as code and
which pieces as a documentation language (TeX, HTML, something else).
dsbweb is my effort at such a system, and I've summarized my rationale
for its design both on my blog and in the code.

Different documentation tools have different attributes, and I think
the ones I care about least often receive the most press.  I do not
particularly care about pretty-printing, and I mostly do not care
about cross-referencing of code names in the documentation (if such a
cross-reference is necessary, it may be a good to reorganize the
code).  I don't really care about automatically-generated class
diagrams unless I'm trying to get a feel for someone else's code, or
to reverse engineer a code that has been written obscurely.  Some
questions I *do* care about are these:

A.  What is the complexity of the meta-language?

The answer to this question really involves two features.

First, there is a question about the documentation language -- is it
HTML, LaTeX, Texinfo, or something that is supposed to generate all of
the above?  I favor LaTeX, simply because it seems to make sense for
someone writing finite elements and eigenvalue solvers to have a
documentation tool that gracefully handles mathematical notation.
Some minimal extensions (like the [[ ]] construction in noweb) can
also be handy, though there is always a danger that such constructions
will conflict with something meaningful.  (Oh, and try writing C code
with bit-shift operations using noweb, and see if either the tool or
the emacs mode doesn't get confused!)

Second, there is a question about how the documentation tool extends
the underlying programming language.  The main example of this is the
chunk system, which is ultimately a limited macro processing facility.
If you use a programming language like Pascal, a chunk-like macro
processing feature can be a blessing, because it allows one to
circumvent the strict ordering otherwise imposed by the programming
language.  I have not written Pascal code in about a decade, though,
and even then I wrote Delphi/Object Pascal -- a more forgiving dialect
than standard Pascal in so many ways.  When I write in C/C++, I have a
macro processor already, should I care to use it; and even when using
noweb, I found that if I was referenced a chunk inside a function
definition, it usually meant that I should consider rewriting the
function to be less monolithic.  For programs written in Lisp,
Haskell, or similar languages, I see few reasons for chunks at all
(feel free to disagree!).

There is a dark side to chunks, though I rarely see it discussed.  It
is the same as the dark side to other macro preprocessing systems.
The macro system typically does not enforce any of the scoping
mechanisms in the underlying language, so that a reorganization made
in the name of clarity can lead to maintenance headaches later on.

Also, there is no scoping of chunk definitions (except scoping to a
file, perhaps).  If, like me, you tend to use similar phrases to
describe similar things, this lack of scope can be a real headache.

B.  What is the canonical source?

By the canonical source, I mean the source that the user edits (as
opposed to the files that are automatically generated).  There are
really three choices here.  The first choice, which is the
conventional choice for WEB and its successors, is to generate both
the compiler/interpreter input files and the documentation files.  The
second choice, which I favor and which is the choice made by Schmooz
and by Javadoc/Doxygen/DOC++ and company, is to treate the
compiler/interpreter input files as canonical, and to generate
documentation files from structured comments.  The third choice, which
I believe Tim has proposed for Axiom, is to make the documentation file
canonical.

There are lots of tools (editors, syntax checkers, debuggers, etc)
that work on program source files.  One reason I favor putting
documentation in embedded comments is that this practice allows me to
continue using such tools without constantly switching back and forth
between a generated file and a canonical file.  For example, I find it
tremendously handy to have meaningful line numbers in the original
source file when I debug (#line helps, but is not a universal way to
achieve this for generated sources -- not all the world's a C program,
nor are all the tools completely preprocessor-aware).

There are also tools that understand LaTeX, which is itself a flavor
of programming language.  One argument I can see for putting
everything into a LaTeX file is that there would be tool support.  I
have colleagues who would undoubtedly write their code with LyX or
Scientific Workplace if they had a tool that would let them.  I'm not
convinced that this is a good thing, but to each his own.  I can
certainly see the value of having a meaningful documentation source
file line number when LaTeX told me that I was missing a math-mode
terminator or had a runaway argument.

Another argument for making the LaTeX format canonical is that you
could arrange the documentation in ways in some ways that would be
difficult to manage with noweb or related tools.  For example, if an
example or a graph that really belonged in a figure was produced by
some short code fragment, you could perhaps do something like

\begin{figure}
\input{somegraph}
\caption{
Graph produced by the function
\begin{chunk}{graphs.lisp}
   (some-example "somegraph.tex" ...)
\end{chunk}
}
\end{figure}

On the other hand, I'm not sure whether the above would count as a
good thing or an evil thing.

Using a completely separate canonical source file adds inconvenience
to using tools for either the programming language(s) or the
documentation language(s) used in the system.  On the other hand,
it also means that the meta-language provided by the documentation tool
can be more powerful.

C.  Will this tool complicate my life during the support phase?

I want people (not necessarily highly computer-literate people) to be
able to use my software without asking me a lot of questions about how
to configure, build, and use it.  Consequently, I value the fact that
dsbweb consists of a single file of portable C code, and found the
dependencies required by noweb to be a nuisance.

I'm willing to use a more complicated tool that treats the programming
language source files as canonical, but only because I figure that
someone who is just trying to get the code to run will probably be willing
to put off compiling the detailed documentation.

If I'm lucky enough to have users willing to contribute and/or
document contributions, I would like to give them a documentation
system that does not have a steep learning curve (which was one of the
things I liked about noweb).


III.  Comments on documentation habits

These thoughts are less organized and sound more self-important than I
would like, but...

Literate programming is no excuse not to strive for self-documenting
code (even if the ideal of completely self-documenting code is likely
never to be realized).  Indeed, I think one of the advantages of
literate programming practices is that it the prospect of having to
explain my code makes me write simpler, clearer code.  This may be
self-evident.

English is richer than programming languages are.  It is also more
redundant and ambiguous.  Concisely-written code fragments mean a lot
to me, and I think the goal of explaining code to humans should not be
confused with "explaining the code in English."  I mention this only
because some of the worst code I've ever read has also been the
subject of some of the most detailed English documentation (the
associated data structures were not so well documented).  Neither the
documentation nor the code for that library made much sense -- which
probably explains why it consistently computed incorrect answers.

Knuth wrote that he wants to be able to treat programs like essays.  I
think this is a good analogy, and a telling one.  An essay need not be
short -- throughout /The Structure of Scientific Revolutions/, Kuhn
refers to his book as "this essay."  But essays are typically
self-contained, and are typically written by one author on one theme.
This is not to say that large, varied literate programs are
intrinsically bad or difficult, but that there are bound to be
organizational challenges involved in going from a collection of
essays/modules to a fully integrated system.  There are organizational
challenges in organizing any large system, but I think large literate
systems pose some special challenges.  I have always found it more
difficult to organize disparate text fragments by different authors
than to organize disparate code fragments by different authors.  I
wonder sometimes whether others don't feel the same, and if this is
part of why I know so few multi-developer projects based on literate
programming techniques.

\start
Date: 15 Jul 2007 16:35:41 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Time to say good bye to Tim.
Cc: Gabriel Dos Reis, Waldek Hebisch, Bill Page,

Ralf Hemmecke writes:

> I hesitate to wish you good luck for the future, since with that policy of
> ignoring other developers there is no future for Axiom.
> 
> Have fun with your little Tim-Project.

Tim, I'm leaving, too.  I don't want to be part of a project anymore where I'm
simply ignored, after having contributed for several years, after having
organised two workshops, after having promoted axiom at several faculties and
won quite a few users, mostly well known researchers in combinatorics.  I
really find it hard not to send you some four letter words.

William, Waldek, Gaby, Bill, I value your work a lot.  Would you agree to start
a community driven project along the lines of my proposal?  Again, the crucial
point for me is that decisions on what goes into trunk are not taken by an
individual person.  

Furthermore, I would like to keep the idea of literate programming, even if not
taken to the extremes.

Therefore, I would like to cooperate closely with FriCAS, but the goals are not
identical.  Of course, I'd be happy to have FriCAS as one "privately driven"
branch, which may well be the most heavily promoted branch at the moment.

If you agree, I'd suggest to start with either build-improvements or wh-sandbox
as silver and gold, and continue work in a democratic setting for these two
special branches.

\start
Date: Sun, 15 Jul 2007 11:20:14 -0500
From: Tim Daly
To: Ralf Hemmecke, Martin Rubey
Subject: Axiom community goals

Ralf, Martin,

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

\start
Date: 15 Jul 2007 17:04:03 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: re: debugging

Greetings, and thanks!  The problem is that the global entries to the
functions returning double float etc. are not being writtin into
DFLOAT.c.  I'm trying to debug by reproducing the compile-file step on
DFLOAT.lsp.  This fails at the lisp prompt:

(compile-file "DFLOAT.NRLIB/DFLOAT.lsp")

; (DEFUN |DFLOAT;manexp| ...) is being compiled.
;;; The tag #:G2017215 is undefined.
; (DEFUN |DFLOAT;rationalApproximation;$2NniF;84| ...) is being compiled.
;;; The tag #:G2017237 is undefined.
;;; The tag G190 is undefined.
; (DEFUN |DFLOAT;**;$F$;85| ...) is being compiled.
;;; The tag #:G2017246 is undefined.
;;; The tag #:G2017246 is undefined.
No FASL generated.

Error: 
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by BREAK.
Condition in BREAK [or a callee]: INTERNAL-SIMPLE-PROGRAM-ERROR: Compilation of "DFLOAT.NRLIB/DFLOAT.lsp" failed.

Broken at BREAK.  Type :H for Help.
 1 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
 2 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
 3 (Abort) Return to debug level 2.
 4 (Continue) Return from break.
 5 Return to top level.
COMPILER>>

Then I try )co "DFLOAT.spad" from the axiom prompt:

)co "DFLOAT.spad"
   Your command is ambiguous. The following are abbreviated by co :
      compiler 
      copyright 
(1) -> )quit
   Please enter y or yes if you really want to leave the interactive 
      environment and return to the operating system:
y
   You have chosen to remain in the AXIOM interactive environment.
(1) -> 
(1) -> 
Program exited normally.

So I try a fresh interpsys, set the stage 1 bootstrap mode flag, And
find a very long chain of compiles which must proceed before I can
compile DFLOAT.  

I'm sure I'm just making some simple mistake, but how can one rebuild
just DFLOAT from any given stage in the build?  This will enable me to
fix this.

Take care,


Waldek Hebisch writes:

> Camm Maguire wrote:
> > Waldek Hebisch writes:
> > > I wrote:
> > > > There are several functions involved.  In case of #<OBJNULL> using
> > > > traces I see that |compDefineCapsuleFunction| function (defined
> > > > in 'define.boot.pamphlet') gets:
> > > > 
> > > >  1> (|compDefineCapsuleFunction|
> > > >          (DEF (|base|) (NIL) (NIL)
> > > >               ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|))))
> > > > ...
> > > > ...
> > > > 
> > 
> > In which package is this?  Is it present in interpsys?
> >
> 
> First a little correction: there are two versions on 
> |compDefineCapsuleFunction|, one in 'define.boot.pamphlet' and
> the second one in 'br-saturn.boot.pamphlet'.  Normally version
> from 'br-saturn.boot.pamphlet' is in use.  
> 
> All functions in question are defined in "BOOT" package.  The
> files are autoloaded.  To get the traces I did (in the algebra
> build directory):
> 
> (export AXIOM=/h/axp62/ax-build2/target/x86_64-unknown-linux; export DAASE=/h/axp62/wh-sandbox/src/share; /h/axp62/ax-build2/build/x86_64-unknown-linux/bin/interpsys )
> )lisp (|oldCompilerAutoloadOnceTrigger|)
> )lisp (trace |compElt| |compileCases| |compDefineCapsuleFunction| |compForm1|)
> )compile "DFLOAT.spad"
>  
> That produced about 150 Mb trace.
> 
> To be extra careful you may also do (before tracing):
> 
> )lisp (|browserAutoloadOnceTrigger|)
> 
> to load correct version of |compDefineCapsuleFunction|.
> 
> > > > 
> > > > It seems that (|elt| $ (|Zero|)) give us '#<OBJNULL>.  |elt| is
> > > > handled in 'compiler.boot.pamphlet':
> > > > 
> > > > 
> > > >     2> (|compForm1| ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|)))
> > > > 
> > > >       3> (|compElt| (|elt| $ (|Zero|)) |$EmptyMode|
> > > > ....
> > > > ....
> > > >       <3 (|compElt|
> > > >              ((|call| (XLAM |ignore| '#<OBJNULL>)) $
> > > > 
> > > 
> > 
> > Can you please post the full call to compElt in 3> above?
> >
> 
> The third argument is large (75 kb), so I have put call to |compElt|
> and return value at:
> 
> http://www.math.uni.wroc.pl/~hebisch/compElt.txt
> 
>  
> > > I have narrowed down the problem:
> > > 
> > >    compiling exported base : () -> PositiveInteger
> > >   1> (|genDeltaEntry| (|Zero| ($ $) (T (CONST $ 18))))
> > >     2> (|optDeltaEntry| |Zero| ($) $ CONST)
> > >       3> (|compiledLookup| |Zero| ((|DoubleFloat|))
> > >              #<vector 0000000002b66f90>)
> > >       <3 (|compiledLookup|
> > >              (|makeSpadConstant|
> > >                  #<compiled-function |DFLOAT;Zero;$;15|>
> > >                  #<vector 0000000002b66f90> 25))
> > >     <2 (|optDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
> > >   <1 (|genDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
> > > 
> > > 
> > > |makeSpadConstant| calls its argument.  Checking this I get:
> > > 
> > 
> > Why are there 3 arguments above?  The definition appears to take one.
> >
> 
> (|makeSpadConstant|
>                  #<compiled-function |DFLOAT;Zero;$;15|>
>                  #<vector 0000000002b66f90> 25)
> 
> is not a call, it is just a list of length four.  This list is
> passed to the SPADCALL macro with the effect that car of the list
> is called with cdr as na argument (using SPADCALL is an abuse here...).
>  
> > > )lisp (|DFLOAT;Zero;$;15| nil)
> > > 
> > > Value = #<OBJNULL>
> > > 
> > > )lisp (disassemble '|DFLOAT;Zero;$;15|)
> > > ^M
> > >    >> System error:
> > >    Condition in DISASSEMBLE [or a callee]: INTERNAL-SIMPLE-END-OF-FILE: Stream error on stream #<input stream "/tmp/gazonk0.c">: Unexpected end of file:
> > > 
> > 
> > This is a simple .h file naming bug I'll try to fix soon.
> > 
> > 
> > > Looking at "/tmp/gazonk0.c" I see:
> > > 
> > > 
> > > #include "cmpinclude.h"
> > > #include "gazonk0.h"
> > > void init__tmp_gazonk0(){do_init((void *)VV);}
> > > /*      local entry for function DFLOAT;Zero;$;15       */
> > > 
> > > static double LI1__DFLOAT$Zero$$$15___gazonk0(V2)
> > > 
> > > object V2;
> > > {        VMB1 VMS1 VMV1
> > >         goto TTL;
> > > TTL:;
> > >         /*(FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
> > >         {fixnum V3;
> > >         V3= (fixnum)0;
> > >         V3= (fixnum)0;
> > >         {double V4 = (    1.    )*((fixnum)0);VMR1
> > >         (V4);}}
> > >         /* END (FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
> > >         {double V5 = lf(Cnil);VMR1
> > >         (V5);}
> > 
> > This is correct but unpleasant C which needs tidying.  There can be
> > extra 'unwinds' scheduled currently in GCL -- these are harmless but
> > misleading.  The function returns from the macro VMR1.  I'll try to
> > clean this up too.
> > 
> 
> I mean that 'lf(Cnil)' looks strange -- Axiom expects double
> precision 0 as the result.
> 
> > Why does this function take an argument which is ignored -- is this right? 
> > 
> 
> Yes, |DFLOAT;Zero;$;15| is a Spad function.  All Spad function receive
> an extra argument:  the domain or package to which they belong.  This
> extra argument appears last in the argument list.  |DFLOAT;Zero;$;15|
> does not need any extra information from its domain, so the
> argument is ignored, but in general it may be used.  If one wants
> to pass "correct" value of the argument one has to do:
> 
> )lisp (|DoubleFloat|)
> )lisp (|DFLOAT;Zero;$;15| (|DoubleFloat|))
> 
> the first call to |DoubleFloat| is triggers autolading of DFLOAT.o file.
> 
> If I do the above in 2.6.8 compiled interpsys I get floating point
> 0.  In 2.7.0 compiled interpsys (the one from the failing build) I get
> #<OBJNULL>
>  
\start
Date: Sun, 15 Jul 2007 17:28:47 -0400
From: William Sit
To: Stephen Wilson
Subject: Re: Unions in Spad

> William Sit writes:
> > In summary, we need:
> >
> >
> > (1) make a list or set of domains from SetCategory (or any category) a legal construction
> > (2) SetAsDomain to convert a list or set of domains (or elements, or maps, perhaps or
> > categories) as a domain of SetCategory
> > (3) Record to accept dependent types, such as [i: I, x:g(i)]
> > (4) maps such as g: I -> SetAsDomain([Integer, String]) should be first class objects and
> > used as parameters, and definable in the Interpreter.
>
> Ok. I believe that the IndexedUnion implementation might need to wait
> until some basic support can be made available in the compiler.

At first, I wrote down "True."  After finishing writing up most of this message, I have second
thoughts. See discussions below.

> I believe that 1) is realistic as a near-term extension, at least
> within Spad code.  I do not know a lot about the interpreter
> implementation so am unsure how much work is involved there.

Well, would making it work for the compiler be any easier? The difficulty I found regarding (1)
(after trying for two days, crashing Axiom time and again: see

      http://wiki.axiom-developer.org/AxiomColloquium/IndexedUnion

) is the following. The user can only input a list of domains as a string input, like
"[Integer, SQMATRIX(5, INT)]".  We need to translate this into a list of domains, and I mean
each is a genuine domain, not as an SExpression as in

dom(sample()$Integer)  -- this gives (Integer) where Integer is a Symbol
dom(sample()$SQMATRIX(5,INT) -- this gives (SquareMatrix (5 (Integer)))

Here is an example of a genuine domain:
p:=POLY FRAC INT
a:p := (2*x+1)

p is typed Domain in the interpreter, and I can find no way to make a SExpression like
(Polynomial (Fraction (Integer))) into the *domain* p.  Question: how is a domain represented
internally in Lisp? It seems something like (|Integer|) but that is just a symbol, not the real
McCoy. So for example, how is p above represented? In general, it seems some type of parsing is
needed to unwind the pieces building up to say SquareMatrix(5, Integer). What are the lisp
functions that does the parsing? (I can only find an unparse function in InputForm). Also, what
lisp function translate the abbreviation to the full domain name?

Is Domain really a domain? category? Is it a primitive type like Union? If so, what are its
exports?

> Given 1), does 2) not follow by defining SetAsDomain as a domain constructor?

(1) simply asks to construct say [Integer, String] or {Integer, String}, which is a list or a
set whose elements are domains (not just domain identifiers, see above). That means the result
has to belong to (or be an element of) a containing domain (but the result itself is not a
domain) such as List Domain or Set Domain (these only allow finite sets), and more generally,
List SetCategory and Set SetCategory.  (2) makes a domain of SetCategory consisting of
elements that are domains, possibly anonymous as in SetAsDomain({Integer, String}) which
returns a domain with only two elements, namely, the domains Integer, and String. This domain
is needed so that we can code signatures of maps into this two-element set (in the example),
such as
       g: I -> SetAsDomain([Integer,String]).
Thus SetAsDomain is a domain constructor, whereas {Integer, String} is just a list (element
constructor). Of course, mathematically, we view
       g:I->{Integer,String}
as valid but this is "by abuse of language" (the reason I did not notice the mistake at first
-- a key observation, by the way). It would seem fairly easy to turn elements of Set S or List
S into a domain for any given S: BasicType. I tried, see above URL, not easy at all for me.
Moreover, we are now at one level higher where S is a category, and we can't even talk about
List SetCategory or Set SetCategory, yet.  Here, I have "lowered" the status of the map g to a
function instead of a domain constructor. Maybe that is where the problems lie.
Ideally, mathematics requires even another higher level, to talk about sets of (small)
categories.

> However, 3) and 4) might require a large amount of work.  This is
> something I am more than willing to do.

Thank you. It affects something very basic (and the solution may be ... read on).

> However, a few notes:
>
> Once we have a working Axiom atop GCL-2.7.0, this opens up a new world
> for developers (an ANSI lisp).   I am trying to get that working with
> the hopes that I can exploit the new features in an attempt to
> reimplemented the compiler.  This is a huge task, of course, but I think
> it is attainable.
>
> The rewrite can attempt to accommodate the needs and issues raised by
> yourself and others.  On an item by item basis, this might prove to be
> easier in the context of a rewrite than trying to shoehorn more
> features into the existing system, and to do so in a way such that
> little or nothing else breaks.
>
> What Im trying to decide here is how best I can focus my efforts.  I
> am reluctant to invest a huge amount of time in extending a system I
> have every intention of rewriting!  I realize that this is quite
> selfish of me, for putting my own interests and goals first.  I do so
> only because I think the returns are greater in the long run, compared
> to expanding the current implementation over the course of the next
> thirty years.

Well, I no longer expect this to be simple. The original implementers probably also were
unwilling to attempt such a generality and hence settled for two versions. Maybe Union can be
modified just to enforce the current restrictions and to fix the problem about repeated domains
with distinct tags. (Otherwise, users need just be aware of the problems. I don't think the
generality is needed soon.)

> > (4) -> j1 case 1
> >
> >    >> Error detected within library code:
> >    upcase: bad Union form
> >
> > protected-symbol-warn called with (NIL)
> >
> > Perhaps a better error message should be given, like:
> > (5) -> j1.tag2
> >
> >    >> Error detected within library code:
> >    (0 . 1) cannot be coerced to mode (Integer)
> >
> > protected-symbol-warn called with (NIL)
>
> I know where the second error message is generated (and I think even
> that could be better).  The first I dont know off hand.  But I can put
> this issue into my todo list.

Thanks.

> [...]
> > >> The construction is related to the bug in Union when the domains are not distinct (but
> > >> the
> > >> tags are): In Union(a:A, b:B) where A = B, the two coerce functions (one from A to %
> > >> and
> > >> one from B to %) coincides, with no way to distinguish the two.
> > >
> >
> > Should be the two "construct" functions.
>
>
> Perhaps the best solution in this case is as Bill Page suggested,
> implementing keyword arguments in Axiom, allowing us to write [a:1] or
> [b:1] thus enabling unambiguous specification of the branch.

The solution is simpler than that. Currently, in Union(a:Integer, b:Integer), we already have:
 ?=? : (%,%) -> Boolean                ?case? : (%,a) -> Boolean
 ?case? : (%,b) -> Boolean             coerce : % -> OutputForm
 construct : Integer -> %              construct : Integer -> %
 ?.? : (%,a) -> Integer                ?.? : (%,b) -> Integer

So all it takes is to replace the two "construct" to become:

construct: (Integer, a) -> %
construct: (Integer, b) -> %

Granted, when we have more domains in the Union, this is clumsy (that is the reason to
introduce the more general set up IndexedUnion).

WAIT! These signatures in tagged Union are outrageous (abuse of language)! Neither identifier a
nor identifier b is a domain! The implementers again finessed the difficult problems raised in
(1) to (4). They are more pragmatic than you think.

By the way, in untagged Union, we already require domains to be distinct. For example,
Union(Integer, String), we have:

 ?=? : (%,%) -> Boolean                autoCoerce : % -> Integer
 autoCoerce : % -> String              autoCoerce : Integer -> %
 autoCoerce : String -> %              ?case? : (%,Integer) -> Boolean
 ?case? : (%,String) -> Boolean        coerce : % -> Integer
 coerce : % -> OutputForm              coerce : % -> String

I don't know why there are autoCoerce:%->Integer and coerce:%->Integer (similarly for String).
Indeed, there is NO autoCoerce! It is not clear to me how an element from Integer or String is
coerced into the Union (that is, what function performs the coercion? most likely, "pretend"?)

(1) -> dom:=Union(Integer, String)

   (1)  Union(Integer,String)
                                                                 Type: Domain
(2) -> )set mess auto off
(2) -> )set mess bot on
(2) -> a:dom:=5

   (2)  5
                                                     Type: Union(Integer,...)
(3) -> b:dom:="5"

   (3)  "5"
                                                      Type: Union(String,...)
(4) -> a::Integer

   (4)  5
                                                                Type: Integer
(5) -> autoCoerce(a)@Integer

 Function Selection for autoCoerce
      Arguments: INT
      Target type: INT
   -> no appropriate autoCoerce found in Integer
   -> no appropriate autoCoerce found in Integer
   -> no function autoCoerce found for arguments INT
   There are no library operations named autoCoerce
      Use HyperDoc Browse or issue
                             )what op autoCoerce
      to learn if there is any operation containing " autoCoerce " in
      its name.

   Cannot find a definition or applicable library operation named
      autoCoerce with argument type(s)
                                   Integer

      Perhaps you should use "@" to indicate the required return type,
      or "$" to specify which version of the function you need.
(5) -> )di op autoCoerce
   autoCoerce is not a known function. AXIOM will try to list its
      functions which contain autoCoerce in their names. This is the
      same output you would get by issuing
                         )what operations autoCoerce

   There are no operations containing those patterns

(5) -> c:=autoCoerce("5")$dom

   The function autoCoerce is not implemented in Union(Integer,String)
      .
(5) -> c:=coerce("5")$dom

   The function coerce is not implemented in Union(Integer,String) .


> Note too that this, I believe, is a necessary first step in getting
> defendant types working in Spad.  Currently there is no propagation of
> binding information in the `modemaps' for functions.

I'm surprised. In tagged Union, the tags are somehow memorized by the system and hard wired
into the signatures (recall: by abuse of language). They are thus "local".  Continuing with the
previous Axiom session:

(9) -> dom3:=Union(a:Integer, b:Integer)

   (9)  Union(a: Integer,b: Integer)
                                                                 Type: Domain
(10) -> a3:dom3:=a

   (10)  5
                                       Type: Union(a: Integer,b: Integer,...)
(11) -> a3 case a

   (11)  true
                                                                Type: Boolean
(12) -> a3 case b

   (12)  false
                                                                Type: Boolean
(13) -> a

   (13)  5
                                                     Type: Union(Integer,...)
(14) -> b

   (14)  "5"
                                                      Type: Union(String,...)
(15) -> a3 case Integer

   >> Error detected within library code:
   upcase: bad Union form

protected-symbol-warn called with (NIL)

The tags in Union (and similarly for Record) seem to be local, but may be overshadowed if the
tags are used as identifiers (see another example in
http://wiki.axiom-developer.org/AxiomColloquium/IndexedUnion). I think the current choice of
implementing Union and Record as primitive types is simpler than keyword arguments (which seems
to add another indirect layer). As primitive types, abuse of language is allowed (or rather,
there is no language to abuse at pre-algebra time)!

> We could look at
> how is information is retained for functors and perhaps find some
> inspiration for making it work in arbitrary functions (after all, the
> mechanics is effectively already in place for dependent types as
> handled by domain constructors).

Yes, that is probably because such dependencies can be handled without regard to language
restrictions. If we want to have this at the algebra level (or rather non primitive type
level), it would be quite difficult. The" mechanics" are very different.

In view of the "abuse of language" observation, I think it should be possible to implement the
"tools" for (1)-(4) by creating a few (perhaps primitive) types:

(a) a primitive type Domain:SetCategory  which contains as its elements all domains (including
of course, those constructed using domain constructors and their arguments). This is probably
already available as "Domain" mentioned earlier, but perhaps not "formally" exported and the
interpreter does not recognize it. If we do dom(x::Any), the interpreter will return the domain
of x, but only as an SExpression. However, "Domain" is not even a valid type!  So we need to
make this available at the algebra level and to be able to use it as any other domain. Not that
while in principle, the set of domains should really be a category, but that would make it
harder to interface (List Domain or Set Domain would not parse if Domain is a category). For
data representation of a domain in Domain, we probably can get away with just retaining the
necessary identifiers needed to construct and thus SExpression should be good enough (much like
in Any). Equality would be equality of SExpression. The key point is to restrict these
SExpressions to those defining valid domains only.

The difficulty with this representation, as mentioned earlier, is how to convert SExpression
for domain into the real domain. (b) Given (a), we can safely construct Set Domain and List
Domain for finite lists and sets of domains, This satisfies (1).

(c) A domain for SetAsDomain.  I tested some algebra level code in two domains MyDomain and
ListAsDomain, on the AxiomColloquium page. I need help to fix some crashes in SetAsDomain and
List MyDomain.

(d) A domain for the set of maps g: I ->SetCategory.  Not sure about this yet. I tested a
lowered g:I->List MyDomain instead (it's a function rather than the domain constructor).

Will try some more when I have more time. Meanwhile, any help is welcome.

\start
Date: Sun, 15 Jul 2007 16:59:00 -0500
From: Tim Daly
To: William Sit, Stephen Wilson
Subject: Lisp representation of Union, Record, etc

William, Stephen,

In the src/doc/developernotes.pamphlet (mnt/linux/doc/developernotes.dvi)
you'll find a section on Axiom Internal Representation that might be of
interest.

\start
Date: 15 Jul 2007 22:25:41 -0400
From: Stephen Wilson
To: William Sit
Subject: Re: Unions in Spad

Hello William,

This is excellent!  Thanks for all the work here!

I am going to keep going over these issues, and do my best to think
about the possible solutions.  I will just mention the things which I
can make a bit of sense of at the moment.

William Sit writes:
[...]
> ) is the following. The user can only input a list of domains as a string input, like
> "[Integer, SQMATRIX(5, INT)]".  We need to translate this into a list of domains, and I mean
> each is a genuine domain, not as an SExpression as in
> 
> dom(sample()$Integer)  -- this gives (Integer) where Integer is a Symbol
> dom(sample()$SQMATRIX(5,INT) -- this gives (SquareMatrix (5 (Integer)))
> 
> Here is an example of a genuine domain:
> p:=POLY FRAC INT
> a:p := (2*x+1)
> 
> p is typed Domain in the interpreter, and I can find no way to make a SExpression like
> (Polynomial (Fraction (Integer))) into the *domain* p.  Question: how is a domain represented
> internally in Lisp? It seems something like (|Integer|) but that is just a symbol, not the real
> McCoy. So for example, how is p above represented? 

Well, since you asked, I will try and give a partial answer (I cannot
yet give a full one).

There are two ways.  (|Integer|) evaluates to a domain vector.
This is an efficient but hairy representation used by the compiler
runtime:

  (1) -> )lisp (|Integer|)
  
  Value = #<vector 08b4b8a4>

I need to write down the details I know about this structure, and
figure out the details Im still clueless about.

Thats half the story, as far as the compiler is concerned.  We also
have the database:

  (1) -> )lisp (pprint (getdatabase '|Integer| 'constructormodemap))

  (((|Integer|)
    (|Join| (|IntegerNumberSystem|) (|ConvertibleTo| (|String|))
            (|OpenMath|)
            (CATEGORY |domain| (SIGNATURE |random| ($ $))
                (ATTRIBUTE |canonical|) (ATTRIBUTE |canonicalsClosed|)
                (ATTRIBUTE |noetherian|) (ATTRIBUTE |infinite|))))
   (T |Integer|))
  Value = NIL

This is an example of the ambient information the compiler has
available to reason about types.


To make matters more confusing, the interpreter deals with things in
its own set of data structures.  So if you start Axiom afresh:

  (1) -> p := POLY FRAC INT

     (1)  Polynomial Fraction Integer
                                                                 Type: Domain
  (2) ->  )lisp (let ((*print-circle* t)) (pprint |$interpreterFrameRing|))

  ((|initial|
       ((((% (|value|
              . #0=(#1=(|Domain|) WRAPPED
                    . #2=(|Polynomial| (|Fraction| (|Integer|))))))
          (|p| (|value| . #3=(#1# . #2#))))))
       2 T
       #4=(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL
               NIL NIL NIL NIL NIL ((|p| (|value|))) . #4#)
       20 1 NIL
       ((1 "p := POLY FRAC INT" (% (|value| . #0#))
         (|p| (|value| . #3#))))
       #<vector 08c9fbec>))
  Value = NIL

As I mentioned, I dont know a lot about the interpreter, but:

      (|p| (|value| . #3=(#1# . #2#)))

means, basically:

      (|p| (|value| |Domain| |Polynomial| (|Fraction| (|Integer|))))

So we can see that the information about p is available.  Combined
with the domain vector and the database, the Interpreter has all the
information it needs in the above.

> In general, it seems some type of parsing is needed to unwind the
> pieces building up to say SquareMatrix(5, Integer). What are the
> lisp functions that does the parsing? (I can only find an unparse
> function in InputForm). Also, what lisp function translate the
> abbreviation to the full domain name?

We should investigate the following:

   (1) -> )lisp (|ncParseFromString| "SquareMatrix(5, Integer)")

   Value = (|SquareMatrix| 5 |Integer|)

As for abbreviations, one could do:

   (1) -> )lisp (get 'INT 'ABBREVIATIONFOR)

   Value = |Integer|


> Is Domain really a domain? category? Is it a primitive type like Union? If so, what are its
> exports?

Its not really anything that has a proper name, as far as I know.  Its
not a primitive in the same way Union is, nor is it defined with
exports from what I can see.  Its just a `special case'.

> > Given 1), does 2) not follow by defining SetAsDomain as a domain constructor?
> 
> (1) simply asks to construct say [Integer, String] or {Integer, String}, which is a list or a
> set whose elements are domains (not just domain identifiers, see above). That means the result
> has to belong to (or be an element of) a containing domain (but the result itself is not a
> domain) such as List Domain or Set Domain (these only allow finite sets), and more generally,
> List SetCategory and Set SetCategory (2) makes a domain of SetCategory consisting of
> elements that are domains, possibly anonymous as in SetAsDomain({Integer, String}) which
> returns a domain with only two elements, namely, the domains Integer, and String. 

OK.  Many thanks for the clarification. 

[...]
> Well, I no longer expect this to be simple. The original implementers probably also were
> unwilling to attempt such a generality and hence settled for two versions. Maybe Union can be
> modified just to enforce the current restrictions and to fix the problem about repeated domains
> with distinct tags. (Otherwise, users need just be aware of the problems. I don't think the
> generality is needed soon.)

Yes.  This is definitely workable in the short term.  I will get this
done over the next few weeks along side finishing the gcl-2.7.0 port.

[...]
> > Perhaps the best solution in this case is as Bill Page suggested,
> > implementing keyword arguments in Axiom, allowing us to write [a:1] or
> > [b:1] thus enabling unambiguous specification of the branch.
> 
> The solution is simpler than that. Currently, in Union(a:Integer, b:Integer), we already have:
>  ?=? : (%,%) -> Boolean                ?case? : (%,a) -> Boolean
>  ?case? : (%,b) -> Boolean             coerce : % -> OutputForm
>  construct : Integer -> %              construct : Integer -> %
>  ?.? : (%,a) -> Integer                ?.? : (%,b) -> Integer
> 
> So all it takes is to replace the two "construct" to become:
> 
> construct: (Integer, a) -> %
> construct: (Integer, b) -> %

OK.  I can look into this too.  Axiom has a lot of undocumented
assumptions built in but with any luck this might be doable.

> Granted, when we have more domains in the Union, this is clumsy (that is the reason to
> introduce the more general set up IndexedUnion).

Absolutely agreed.

[...]
> I don't know why there are autoCoerce:%->Integer and coerce:%->Integer (similarly for String).
> Indeed, there is NO autoCoerce! It is not clear to me how an element from Integer or String is
> coerced into the Union (that is, what function performs the coercion? most likely, "pretend"?)

There is a one line comment in the code (buildom.boot.pamphlet):

     ['autoCoerce,[t,g],downFun], --this should be removed eventually

So obviously the original implementers didnt want autocoerce around.

I notices the lack of coerce: % -> Integer, and it struck me as
lacking symmetry, but I thought that the `.' operators would handle
that case.  Also, for coercion from integer or string into the Union
one can use construct equivalently I believe.  Perhaps I am
overlooking something?

[...]
> The tags in Union (and similarly for Record) seem to be local, but may be overshadowed if the
> tags are used as identifiers (see another example in
> http://wiki.axiom-developer.org/AxiomColloquium/IndexedUnion). I think the current choice of
> implementing Union and Record as primitive types is simpler than keyword arguments (which seems
> to add another indirect layer). As primitive types, abuse of language is allowed (or rather,
> there is no language to abuse at pre-algebra time)!

I did not notice the shadowing before.  Thanks!  

I completely agree that working at the level of primitive types is the
simplest approach.

[...]
> In view of the "abuse of language" observation, I think it should be possible to implement the
> "tools" for (1)-(4) by creating a few (perhaps primitive) types:
> 
> (a) a primitive type Domain:SetCategory  which contains as its elements all domains (including
> of course, those constructed using domain constructors and their arguments). This is probably
> already available as "Domain" mentioned earlier, but perhaps not "formally" exported and the
> interpreter does not recognize it. If we do dom(x::Any), the interpreter will return the domain
> of x, but only as an SExpression. However, "Domain" is not even a valid type!  So we need to
> make this available at the algebra level and to be able to use it as any other domain. Not that
> while in principle, the set of domains should really be a category, but that would make it
> harder to interface (List Domain or Set Domain would not parse if Domain is a category). For
> data representation of a domain in Domain, we probably can get away with just retaining the
> necessary identifiers needed to construct and thus SExpression should be good enough (much like
> in Any). Equality would be equality of SExpression. The key point is to restrict these
> SExpressions to those defining valid domains only.
> 
> The difficulty with this representation, as mentioned earlier, is how to convert SExpression
> for domain into the real domain. (b) Given (a), we can safely construct Set Domain and List
> Domain for finite lists and sets of domains, This satisfies (1).
> 
> (c) A domain for SetAsDomain.  I tested some algebra level code in two domains MyDomain and
> ListAsDomain, on the AxiomColloquium page. I need help to fix some crashes in SetAsDomain and
> List MyDomain.
> 
> (d) A domain for the set of maps g: I ->SetCategory.  Not sure about this yet. I tested a
> lowered g:I->List MyDomain instead (it's a function rather than the domain constructor).
> 
> Will try some more when I have more time. Meanwhile, any help is welcome.

I will see if I can get a sense of direction for possible solutions.
Looking at the AxiomColloquium page and experimenting with the code
you have there will give me some `hands on' examples to work with. Of
course I will let you know of any progress.

\start
Date: 15 Jul 2007 23:21:40 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: re: 2.7 build

Greetings!  This should be working now, though the fix could be
better.  Please let me know if problems persist.

Stephen Wilson writes:

> Hello Camm,
> 
> Stephen Wilson writes:
> 
> > Camm Maguire writes:
> > 
> > > Greetings!  Did you stop here?
> > > 
> > >       TopLevelDrawFunctions 
> > >    Loading /fix/t1/camm/axiom/int/algebra/DRAWCFUN.nrlib/code for 
> > >       package TopLevelDrawFunctionsForCompiledFunctions 
> > >  
> > >    >> System error:
> > >    
> > > 
> > > (1) -> cp: cannot stat `/fix/t1/camm/axiom/int/algebra/*.daase': No such file or directory
> > > make[3]: *** [/fix/t1/camm/axiom/mnt/linux/algebra/*.daase] Error 1
> 
> 
> I believe this is the result of a GCL issue, but one I cant make heads
> or tails of.
> 
> 
> ==----- test.lisp ----
> (defun test (|ff| |f|) 
>   (prog (|s| |r|)
>      (block nil
>        (setq |s| (funcall |ff| |f|))
>        (setq |r| (cdr |s|)) 
>        (cond ((< 1 |r|) 1)
>              ((< |r| most-negative-long-float) most-positive-long-float)
>              (t |r|)))))
> ==--------------------
> 
> This is about as simple as I could get it. Note that one can change a
> large number of items in the above form and the problem disappears.
> For example, comment out one of the setq's, or rewrite
> most-negative-long-float as most-positive-long-float.
> 
> steve:tmp> gcl
> GCL (GNU Common Lisp)  2.7.0 ANSI    Jul 12 2007 17:59:02
> Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> 
> Temporary directory for compiler files set to /tmp/
> 
> >(si::use-fast-links nil)
> 
> NIL
> 
> >(load (compile-file "test.lisp"))
> 
> ;; Compiling test.lisp.
> ;; End of Pass 1.  
> ;; End of Pass 2.  
> ;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
> ;; Finished compiling test.o.
> ;; Loading /home/steve/tmp/test.o
> 
> Error: 
> Signalled by LOAD1.
> INTERNAL-SIMPLE-READER-ERROR: Stream error on stream #<input stream "/home/steve/tmp/test.o">: The default dispatch macro signalled an error.
> 
> Broken at LOAD1.  Type :H for Help.
>  1 (Continue) Retry loading file NIL.
>  2 Retry loading file NIL.
>  3 Return to top level.
> >>:bt
> 
> #0   LOAD1 {loc0=#P"/home/steve/tmp/test.o",loc1=t,loc2=nil,loc3=:error,loc4=nil,loc5=nil,l...} [ihs=4]
> #1   LOAD {pn=#P"/home/steve/tmp/test.o",args=(nil nil),loc2=(#<@0128AC00> nil nil),loc3=(...} [ihs=3]
> #2   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function load>} [ihs=2]
> >>

\start
Date: Sun, 15 Jul 2007 22:37:19 -0500
From: Tim Daly
To: William Sit, Stephen Wilson
Subject: Lisp representation of Union, Record, etc

Steven,

The function |Integer| is defined in int/algebra/INT.lsp.

The first time the function is executed it replaces itself in the
$ConstructorCache. The real |Integer| function is called |Integer;|
This function constructs the domain $

All of the function lookup for the function in Integer are actually
indexes into the |infovec|. In fact, almost all of the interesting
information about |Integer| lives on the property list. Try:

 )lisp (symbol-plist '|Integer|)

Integer is actually a bad example as it is preloaded. If we look at
DenavitHartenbergMatrix when we first start we see:

 )lisp (symbol-plist '|DenavitHartenbergMatrix|)

and you can see that the property list contains only one element.
This element is the DATABASE vector which contains information
enabling lookups in various databases. There are some numbers as the
value of some slots (e.g. CONSTRUCTORMODEMAP 383583) and these are
absolute byte offsets into the various databases. If you say

 )lisp (setq *miss* t)

you can see all of the attempts to look up information. This tells you
the domain being looked up and the property being requested. Doing

 a:DHMATRIX(FLOAT)
 )lisp (symbol-plist '|DenavitHartenbergMatrix|)

you'll see that the CONSTRUCTORMODEMAP property was looked up in
the database (as well as the ABBREVIATION, COSIG, CONSTRUCTORKIND).
Now do 

 )lisp (symbol-plist '|DenavitHartenbergMatrix|)

and you can see these fields have been populated.

 m := new(4,4,0)$DHMATRIX(DoubleFloat)
 )lisp (symbol-plist '|DenavitHartenbergMatrix|)

you can see that the property list has been further populated.
Now we see the OPERATIONALIST has been populated.


Further details are in src/doc/developernotes.pamphlet.

\start
Date: 15 Jul 2007 23:48:21 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: re: debugging

Greetings!  The disassemble bug we saw earlier (end of file) is due to
a redefinition of compiler::gazonk-name somewhere in your tree.  (We
now have a different format for temporary file names.)

Would it be possible to summarize any gcl lisp functions for which
patching/redefinition is felt necessary in axiom, and work toward
eliminating same?  The current situation will just create more work as
GCL and axiom evolve.

\start
Date: 16 Jul 2007 00:18:03 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Lisp representation of Union, Record, etc

Tim,

Thanks so much for the details!  In some ways, I was aware of the
objects you detail, but am still working on the mental model that
might actually lead so some sort of understanding.  Your writeup was
most helpful in that regard!

Tim Daly writes:
[...]
>  )lisp (setq *miss* t)

This one I was unaware of.  Thanks!

> Further details are in src/doc/developernotes.pamphlet.

I have read this several times, but with wide spans of time in between
readings.  Certainly not committed to memory, by any stretch.

\start
Date: Sun, 15 Jul 2007 23:31:14 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Lisp representation of Union, Record, etc.

As these discussions proceed I'm trying to write up the details we
discover in the developer notes so other people can follow when these
things come up again. I'd like make a whole section devoted to a
couple interesting domains (e.g. Integer, DHMATRIX), peel them open
completely, and show exactly what the fields mean, how the interpreter
uses them, where the data comes from, how the compiler constructs the
domain, etc. However, caching these discussions is an epsilon move
closer to that goal. With pictures, circle and arrows, and a paragraph
on the back explaining each one. :-)

\start
Date: 16 Jul 2007 00:35:24 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: re: debugging

Camm Maguire writes:

> Greetings!  The disassemble bug we saw earlier (end of file) is due to
> a redefinition of compiler::gazonk-name somewhere in your tree.  (We
> now have a different format for temporary file names.)
> 
> Would it be possible to summarize any gcl lisp functions for which
> patching/redefinition is felt necessary in axiom, and work toward
> eliminating same?  The current situation will just create more work as
> GCL and axiom evolve.

Pending a full audit, I believe that with the current patchset against
silver there is no trampling on GCL functions or symbols.  Between
compiler:link and exported syms there is no reason, as far as I can
tell, for Axiom to insist on trying to manage GCL internals or patch.

We can always work towards enriching exported interfaces if needed in
the future.

\start
Date: 16 Jul 2007 00:40:56 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Lisp representation of Union, Record, etc.

Indeed, I was thinking about adding to developernotes as well.

Its a personal wish that GIT was a bit more widely used, thus enabling
an arbitrary number of topic branches so that we can all participate
in specific efforts together.

But perhaps it is not such a difficult thing, as I am not familiar
with the compatibility tools which would allow an SVN user, say, to
follow that kind of development in a convenient way.

\start
Date: Mon, 16 Jul 2007 01:15:52 -0400
From: William Sit
To: Martin Rubey
Subject: Re: [NOT :-)] Time to say good bye to Tim.
Cc: Gabriel Dos Reis, Waldek Hebisch, Bill Page,

Dear Martin:

Thanks for your trust in me and I also value your deep
investment in the Axiom project and don't want to see you
(or anyone else) leave.

I am truly sorry that the community has split up like this,
all due to my naive believe that Tim was willing to really
do according to a "vote" on the merging issue. No doubt, Tim
has irritated almost everyone else save Stephen Wilson or CY
perhaps. He is, however, to be admired for his stubbornness
to hold onto his principles. Of course, I, like you and some
others, would much prefer him to be more flexible. (Tim, I
hope you are listening.)

Perhaps that's what Axiom is destined to be. I have far more
confidence in the more pragmatic approach that myself and
others have expressed (and there are other "silent" souls
out there too). As someone who only knows a small part of
the Axiom algebra world, I do not carry any "weight" whether
I stay or leave the community but I have not thought about
leaving (this is clear from my reply to Tim's "contribution"
message.)  I would very much like everyone to calm down and
arrive at a cooperating solution. But with egos flying, and
"principles" that are non-negotiable, it would be too much
to ask, but I sincerely hope that we write with less
threatening tones.

I feel sad that Tim has such a narrow mind that the only
thing that counts as "contribution" is "commit a patch" (or
"diff -Naur").  He has neglected the technical difficulties
when the patch is massive, unfinished, while the Gold branch
keeps shifting. He has been unfair to Waldek and Gaby.
Surely, Bill Page has contributed a lot by maintaining the
website as the de facto webmaster.   Bill has been very open
and generous to accept comments and helpful to explore new
ideas. How can these developers be accused of not
contributing to the project? Perhaps Tim can learn a bit
from Bill (as a "manager", Tim: time to get a raise! )?

We have to step back far enough to visualize what Axiom
would be like a few years down the road (not 30 years, I
know I won't be around). If Waldek, Gaby and Bill leave
entirely, what would happen? First they need to re-establish
the entire data-base for the website and create a new one.
Financially, it is not a real problem assuming people have
the will. But it has taken us a few years to build this and
it would take at least a year to recreate and build up
support again. Given so few are active, do you have
confidence? Is it worth someone, as an example, to build a
comparable website, say for FriCAS?  Would another split
happen with FriCAS? No one can tell.

You and Ralf (and Waldek) have painted yourselves into a
corner. Unlike Waldek, you and Ralf probably have not yet
gained the skills (nor would be interested in gaining them
as far as I can guess) to maintain the internals of Axiom.
Thus, like me, you will be dependent on people like Waldek,
Gaby, Stephen and Camm, and perhaps some newer developers. I
don't think Stephen and Gaby will " jump ship".  Gaby is
willing to put up with Tim by preparing patches. I have no
experience on such matter, but I do believe Tim is right on
insisting submission of patches. Tim is just too slow and
wants to be 100% sure committed changes will only fix
things, not break them (good luck, of course, but the goal
itself is admirable.)  I wish he has more trust in and
courtesy for the others.  But I digressed.  For you, Ralf
and me, and other algebra-level users/developers, all we can
do is to raise the algebra issues and hope that someone will
listen and help us. At this stage, those "someone" are all
working to improve the internals, with only marginal
interests (but certainly eventual interest) on the algebra
side. With this assumption, I believe "jumping ship" is not
to our best interest, at least not for the near future.

Consider one of two scenarios: (a) Waldek remains the only
guru on his branch. Everything you like to happen in
language improvement, bug fixes, new algebra code addition,
etc., has to depend on him. (b) Someone like a Waldek2 (or
Waldek3) comes along in a year or so, knows the ins and outs
well, but decides to do some other things, or do things some
other ways. Waldek2 does not have to split, but it is enough
that he would be interested, at least for the short (that's
two to three years) term to concentrate on things "of
interest" to him. We welcome such people, and we can't blame
anyone being interested only in "things of interest". An
example of that kind of skilled person is Stephen, who wants
to rewrite the compiler. I am grateful he discovered, and is
interested in fixing the Union problems and thanks his
willingness to consider about my proposals. But I shouldn't
ask (and certainly not threaten) him to take that as his
priority. Some one else may want to rewrite the interpreter
and others go about user interface projects. Independent of
which branch they will finally merge their efforts (perhaps
both), the fact remains, we, the algebraists, would still be
waiting. (A clarification is perhaps needed here: I do not
mean to separate the community into algebraist and
non-algebraists: I understand that Waldek, Gaby, and others
are also mathematicians (perhaps not algebraists in the
mathematical sense) and they are interested in using the
Axiom Computer *Algebra* System. They certainly wear two
hats, while I only wear one. But like we three, they also
have to wait.)

So my own solution to this situation is: if I ever develop
more Axiom code, I'll develop them not assuming the newest
language features that are still to be, but use what is old
fashioned well tested constructs. That is the only way to
produce working algebra code *right now*. It does not mean I
won't participate is discussions and experimentation of new
ideas (like the IndexedUnion or Unit and Dimension
subprojects), but just that I won't view that as my main
bread and butter.
For me, if I only work on algebra code under the current
language constraints, I don't have to worry about code
obsolescence. If my code is useful to others, someone will
use it and maintain and improve it (I hear Tim:
documentation!). If not, let it die a deserved death.

If I were to worry about the future of Axiom, there are
other issues that I did not emphasize but in my guts I feel
are the Achille's heels for Axiom. It took me this whole
week to write up and LEARN about *how to implement* this
very simple mathematical concept of Union and I am not a
newcomer. There is just so much more computer science
involved.  I am sure, as one of the few Algebra developers
around, you know what these issues are. When will a stable,
usable Axiom be available (under whatever name)? And how
many more years before the younger generation will embrace
it enough to contribute more algebra code? Those are my
worries. They are the reasons I prefer a more pragmatic
approach, and I join others' plead for continued unity.

Would it be too much to ask that you and Ralf (and Waldek,
and Tim) to put your egos behind and withdraw your threats
(and be more flexible)? I have faith that Waldek will try to
merge his with Tim's once things become stable and Tim will
accept them.

Martin, I hope you don't get too upset with Tim. He is only
one in the community. Don't blame him for all the ills. You
have an otherwise very cooperative community and no reason
to leave it.

Enjoy your vacation, in any case. I wish I have one.

\start
Date: 16 Jul 2007 08:13:40 +0200
From: Martin Rubey
To: William Sit
Subject: Re: [NOT :-)] Time to say good bye to Tim.
Cc: Gabriel Dos Reis, Waldek Hebisch, Bill Page,

Dear William,

thanks for your long reply.  However, it seems to me that you missed that Tim
submitted patches yesterday (and several times before) that

* break the system

* are not documented

* and against which several people (yesterday: Ralf and myself) protested
  against *before* Tim commited.

I cannot "contribute" if somebody else is running amok.

\start
Date: 16 Jul 2007 08:45:11 +0200
From: Martin Rubey
To: William Sit
Subject: Re: [NOT :-)] Time to say good bye to Tim.
Cc: Gabriel Dos Reis, Waldek Hebisch, Bill Page,

Sorry, I forgot to mention two things, lest somebody follows your
argumentation:

> If Waldek, Gaby and Bill leave entirely, what would happen? First they need
> to re-establish the entire data-base for the website and create a new one.

No. Ralf has already agreed to me that it would be possible to decouple the
MathAction page hosted by RISC from the one hosted at axiom-developer.  Since
the contents is to a large extend content that I and Bill contributed, it is in
my opinion even questionable whether Tim would have any moral rights to use it.
(In fact, he doesn't use it.  I don't see any edits signed Tim Daly.)

> You and Ralf (and Waldek) have painted yourselves into a corner. Unlike
> Waldek, you and Ralf probably have not yet gained the skills (nor would be
> interested in gaining them as far as I can guess) to maintain the internals
> of Axiom.  Thus, like me, you will be dependent on people like Waldek,

I have no problem being dependent on Gaby or Waldek.  I would find it slightly
irritating to depend on only one of them, but two is OK.

And, by the way, who is going to provide algebra fixes?  Yes, axiom cannot live
without compiler, interpreter etc.  But the same is true for the algebra.  And
as far as I remember, there have been exactly two people who provided more than
one fix for the algebra so far: Waldek and myself.

But really, most important is that 

> He [Tim] is, however, to be admired for his stubbornness to hold onto his
> principles. 

is just completely misleading.  He puts up principles for others, but himself
commits happily undocumented and broken code.

\start
Date: Mon, 16 Jul 2007 09:21:48 -0400
From: William Sit
To: Martin Rubey
Subject: Re: [NOT :-)] Time to say good bye to Tim.
Cc: Gabriel Dos Reis, Waldek Hebisch, Bill Page,

Dear All:

It appears to me that there has been quite a lot of
misunderstandings among the regulars. At least, I have
misunderstood Tim and I have publicly used adjectives on him
that are inaccurate (narrow-minded, slow, inflexible, and
having an ego). For these inaccuracies, I might have added
to, or even created the impression to others unfamiliar with
the inner workings (myself included) that Tim is what those
words describe and I sincerely apologize to Tim and you for
carelessness.  But my intention is certainly not any kind of
personal attack at Tim. (I blame Tim :-) for leaving me with
those impressions and am glad to have a chance to correct
them!)

But Tim deserves a clarification:

On narrow-mindedness and inflexibity:
Tim has been open-minded (perhaps with some proding) to try,
or allow others to try, or continues to use despite personal
frustration, or facilitate others to continue to use: SVN,
wiki, aldor, and silver, despite personal disagreement.
The only things he seems inflexible about are literate
programming methods and quality control.

On slowness:
This should be put in perspective: Tim is worried about the
quality of the results and has tried his best to maintain
the system. In his 30 year horizon, things are not slow and
Tim is not slow, just meticulous (I hope this word is okay).

On having an ego:
We all do, except Tim :-).

I probably (with my big mouth) also have described others,
particularly Waldek, Bill, Martin and Ralf, inaccurately. To
them I also offer my apologies. Again, my intention is not
personal attack. I promise to be more careful to avoid
judging others (or I'll be judged).

And as to Martin's accusations of Tim's recent actions, Tim
has to answer them (at least that would clarify things and
remove possible misunderstandings).

\start
Date: 16 Jul 2007 22:36:00 -0400
From: Stephen Wilson
To: axiom-devel <list>
Subject: Re: 2.7 build
Cc: Camm Maguire, Gabriel Dos Reis

--=-=-=

Hello,

The patch silver-gclcvs-2.patch below is to be applied on top of the
original patchset (silver-gclcvs-1.patch, also included) against
the latest silver for running atop gclcvs-2.7.0.

It cleans up one temporary fix from the previous patchset, and works
around a bug in in axioms )read command.

This allows the build to complete and enter the test suite.
Unfortunately I am experiencing a segfault at this stage:

   steve:silver-gclcvs> AXIOMsys
   [...]
   (1) -> )read mnt/linux/input/easter.input
   [...]
   --S 182 of 201
   T:= (f, xx, a) +-> subst((DD**0)(f(x)), x = a)/factorial(0) * (xx - a)**0 + _
                      subst((DD**1)(f(x)), x = a)/factorial(1) * (xx - a)**1 + _
                      subst((DD**2)(f(x)), x = a)/factorial(2) * (xx - a)**2
 

   Segmentation violation: c stack ok:signalling error
   Unrecoverable error: Segmentation violation..
   zsh: abort      AXIOMsys


And similarly for elemnum.input.  Will look into this.


A further patch, input-workarounds.patch, simply removes these failing
input cases from the makefiles to allow the build to complete.


Moreover, Hyperdoc is not working.  On startup theHyperdoc window
flashes on the screen and bails with the message:

   steve:build-silver> axiom
   [...]
   (1) -> 
   (1) -> syntax error: expected a newcommand
   not a word
   (HyperDoc) While parsing RootPage on line 1
           in the file /home/steve/development/axiom/build-silver/mnt/linux/doc/hypertex/pages/rootpage.ht
   
   (1) -> )q

Has anyone seen the likes of this before?  Im relatively clueless about
Hyperdoc.  !!!!Any help here would be very much appreciated!!!!


Some very good news, however.  Atop gcl-2.6.8pre in ANSI, I could get
the build to complete but had a large number of failures in the
regression suite.  There appears to be only a handful of failures with
2.7.0 -- most appear to be the result of a simple printing error,
where 100 is printed as 10, 1000 as 100, etc.  I think we are just
around the corner from a full featured Axiom working on 2.7.0.


Again, apply the patches like so, against the latest silver:

  svn co https://axiom.svn.sourceforge.net/svnroot/axiom/trunk/axiom silver
  
  cd silver

  patch -p1 < ../silver-gclcvs-1.patch
  patch -p1 < ../silver-gclcvs-2.patch

And similar if you wish to apply the makefile changes included with
input-workarounds.patch.


Sincerely,
Steve




--=-=-=

diff --git a/Makefile b/Makefile
index 86c7905..8503293 100644
--- a/Makefile
+++ b/Makefile
@@ -14,8 +14,9 @@ LSP=${SPD}/lsp
 #GCLVERSION=gcl-2.6.6
 #GCLVERSION=gcl-2.6.7pre
 #GCLVERSION=gcl-2.6.7
-GCLVERSION=gcl-2.6.8pre
+#GCLVERSION=gcl-2.6.8pre
 #GCLVERSION=gcl-2.6.8pre2
+GCLVERSION=gclcvs
 AWK=gawk
 GCLDIR=${LSP}/${GCLVERSION}
 SRC=${SPD}/src
@@ -147,3 +148,4 @@ clean:
 	@ for i in `find src -name "Makefile"` ; do rm -f $$i ; done
 	@ for i in `find src -name "Makefile.dvi"` ; do rm -f $$i ; done
 	@ rm -f lastBuildDate
+
diff --git a/Makefile.pamphlet b/Makefile.pamphlet
index 2109665..7b4a675 100644
--- a/Makefile.pamphlet
+++ b/Makefile.pamphlet
@@ -748,8 +748,9 @@ forget to erase the lsp/Makefile the wrong patches will be applied.
 #GCLVERSION=gcl-2.6.6
 #GCLVERSION=gcl-2.6.7pre
 #GCLVERSION=gcl-2.6.7
-GCLVERSION=gcl-2.6.8pre
+#GCLVERSION=gcl-2.6.8pre
 #GCLVERSION=gcl-2.6.8pre2
+GCLVERSION=gclcvs
 @
 
 \subsubsection{The [[GCLOPTS]] configure variable}
diff --git a/lsp/Makefile.pamphlet b/lsp/Makefile.pamphlet
index 4a2d3fb..17b8b06 100644
--- a/lsp/Makefile.pamphlet
+++ b/lsp/Makefile.pamphlet
@@ -1176,6 +1176,31 @@ clean:
 	@( cd ccl ; ${ENV} ${MAKE} clean )
 
 @
+\subsection{The gclcvs stanza}
+This stanza will be written when the GCLVERSION variable is
+``gclcvs''. It will overwrite the default version. See the 
+top level Makefile.pamphlet.
+
+<<gclcvs>>=
+# gcl version gclcvs
+OUT=${OBJ}/${SYS}/bin
+OBLIB=${OBJ}/${SYS}/lib
+LINKOBJECTS= ${OBLIB}/bsdsignal.o \
+	     ${OBLIB}/cfuns-c.o   \
+	     ${OBLIB}/sockio-c.o
+
+all:
+	@echo 1 building ${LSP} ${GCLVERSION}
+
+gcldir: 
+	@echo 2 building ${GCLVERSION}
+	@echo '(let ((si::*disable-recompile* t))' \
+	         '(compiler::link nil "${OUT}/lisp" nil "${LINKOBJECTS}"))' | gcl
+	@echo 13 finished system build on `date` | tee >gcldir
+
+clean:
+
+@
 \section{Gnu Common Lisp 2.5}
 GCL 2.5 requires a different Makefile. In particular, GCL 2.5
 has a different method of building the lisp image. And, just to
diff --git a/src/algebra/Makefile.pamphlet b/src/algebra/Makefile.pamphlet
index 987ea71..e0d2f54 100644
--- a/src/algebra/Makefile.pamphlet
+++ b/src/algebra/Makefile.pamphlet
@@ -692,7 +692,7 @@ plot.spad.pamphlet (PLOT PLOT1)
 <<layer15>>=
 
 LAYER15=\
-  ${OUT}/DIAGG.o   ${OUT}/DIAGG-.o   ${OUT}/DSMP.o     ${OUT}/EXPUPXS.o \
+  ${OUT}/DIAGG.o   ${OUT}/DIAGG-.o   ${OUT}/DSMP.o \
   ${OUT}/FRAMALG.o ${OUT}/FRAMALG-.o ${OUT}/MDAGG.o    ${OUT}/ODPOL.o   \
   ${OUT}/PLOT.o    ${OUT}/RMCAT2.o   ${OUT}/ROIRC.o    ${OUT}/SDPOL.o   \
   ${OUT}/SMATCAT.o ${OUT}/SMATCAT-.o ${OUT}/TUBETOOL.o ${OUT}/UPXSCCA.o \
@@ -1022,6 +1022,7 @@ taylor.spad.pamphlet (ITAYLOR UTS UTS2)
 <<layer21>>=
 
 LAYER21=\
+  ${OUT}/EXPUPXS.o \
   ${OUT}/DEFINTEF.o ${OUT}/DFINTTLS.o ${OUT}/DEFINTRF.o ${OUT}/D01TRNS.o  \
   ${OUT}/EFULS.o    ${OUT}/ESCONT.o   ${OUT}/EXPR.o     ${OUT}/EXPR2UPS.o \
   ${OUT}/FDIV.o     ${OUT}/FSCINT.o   ${OUT}/FSINT.o    ${OUT}/FS2EXPXP.o \
diff --git a/src/algebra/acplot.spad.pamphlet b/src/algebra/acplot.spad.pamphlet
index f4542d7..9a79cda 100644
--- a/src/algebra/acplot.spad.pamphlet
+++ b/src/algebra/acplot.spad.pamphlet
@@ -1151,6 +1151,7 @@ PlaneAlgebraicCurvePlot(): PlottablePlaneCurveCategory _
     x1 := xCoord p1; y1 := yCoord p1
     px := ground(eval(dpdxSF,[x,y],[x1,y1]))
     py := ground(eval(dpdySF,[x,y],[x1,y1]))
+    incVar0, incVar : Symbol
     -- let m be the slope of the tangent line at p1
     -- if |m| < 1, we will increment the x-coordinate by delta
     -- (indicated by 'incVar = x'), find an approximate
diff --git a/src/algebra/allfact.spad.pamphlet b/src/algebra/allfact.spad.pamphlet
index ccc9497..c399d2b 100644
--- a/src/algebra/allfact.spad.pamphlet
+++ b/src/algebra/allfact.spad.pamphlet
@@ -291,7 +291,7 @@ MPolyCatPolyFactorizer(E,OV,R,PPR) : C == T
 
 GeneralizedMultivariateFactorize(OV,E,S,R,P) : C == T
  where
-  R          :   IntegralDomain
+  R          :   GcdDomain
                     -- with factor on R[x]
   S          :   IntegralDomain
   OV    :   OrderedSet  with  
diff --git a/src/algebra/d02agents.spad.pamphlet b/src/algebra/d02agents.spad.pamphlet
index d3e18ec..dd45a6c 100644
--- a/src/algebra/d02agents.spad.pamphlet
+++ b/src/algebra/d02agents.spad.pamphlet
@@ -281,7 +281,7 @@ d02AgentsPackage(): E == I where
         b := ((# e) >= r-1)@Boolean       
       b =>
         -- if all the eigenvalues are real, find negative ones
-        e := sort(neglist(e)$ExpertSystemToolsPackage1(FI))
+        e : List FI := sort(neglist(e)$ExpertSystemToolsPackage1(FI))
         -- if there are two or more, calculate stiffness ratio
         ((n:=#e)>1)@Boolean => [coerce(e.1/e.n)@F,0$F] 
         -- otherwise stiffness not present
diff --git a/src/algebra/efstruc.spad.pamphlet b/src/algebra/efstruc.spad.pamphlet
index 6ac57be..6e6a2ff 100644
--- a/src/algebra/efstruc.spad.pamphlet
+++ b/src/algebra/efstruc.spad.pamphlet
@@ -413,7 +413,7 @@ ElementaryFunctionStructurePackage(R,F): Exports == Implementation where
       for i in 1..n for kk in rest ker repeat
         klist := first(ker, i)
         -- NO EVALUATION ON AN EMPTY VECTOR, WILL CAUSE INFINITE LOOP
-        (c := deprel(klist, kk, v)) case vec and not empty?(c.vec) =>
+        (c : U := deprel(klist, kk, v)) case vec and not empty?(c.vec) =>
           rec := depeval(f, klist, kk, c.vec)
           rn  := rischNormalize(rec.func, v)
           return [rn.func,
diff --git a/src/algebra/polycat.spad.pamphlet b/src/algebra/polycat.spad.pamphlet
index 01cbbcc..b9bd252 100644
--- a/src/algebra/polycat.spad.pamphlet
+++ b/src/algebra/polycat.spad.pamphlet
@@ -165,7 +165,7 @@ FiniteAbelianMonoidRing(R:Ring, E:OrderedAbelianMonoid): Category ==
           -- probably not a very good definition in most special cases
           zero? x => 0
           ans:% :=0
-          t:=leadingCoefficient x exquo r
+          t : Union(R, "failed") := leadingCoefficient x exquo r
           while not (t case "failed") and not zero? x repeat
             ans:=ans+monomial(t::R,degree x)
             x:=reductum x
diff --git a/src/algebra/transsolve.spad.pamphlet b/src/algebra/transsolve.spad.pamphlet
index 168619f..7c87f95 100644
--- a/src/algebra/transsolve.spad.pamphlet
+++ b/src/algebra/transsolve.spad.pamphlet
@@ -219,6 +219,7 @@ TransSolvePackage(R) : Exports == Implementation where
         radicalSolve(nlexpr, lvar)$RadicalSolvePackage(R)
 
      tryToTrans(lside: RE, x:S) : RE ==
+       resultLside : RE
        if testTrig(lside,x) or testHTrig(lside,x) then
           convLside:=( simplify(lside) )::RE
           resultLside:=convLside
diff --git a/src/boot/Makefile.pamphlet b/src/boot/Makefile.pamphlet
index c5ebb48..fe73a76 100644
--- a/src/boot/Makefile.pamphlet
+++ b/src/boot/Makefile.pamphlet
@@ -1263,6 +1263,7 @@ and the problem appears to be that each [[.o]] file has [[init_code]].
 Until this is fixed we need to continue to use the old scheme.
 <<environment>>= 
 CMD0=(progn \
+       ${PROCLAIMS} \
        (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) \
        (system::save-system "${SAVESYS}"))
  
diff --git a/src/interp/Makefile.pamphlet b/src/interp/Makefile.pamphlet
index 49f9cc4..c794fef 100644
--- a/src/interp/Makefile.pamphlet
+++ b/src/interp/Makefile.pamphlet
@@ -396,8 +396,7 @@ into the src/interp diretory (or boot, algebra).
 
 In order for this information to be used during compiles we define
 <<environment>>=
-PROCLAIMS=(progn (load "${OUT}/sys-pkg.lsp") \
-                 (load "${IN}/interp-proclaims.lisp"))
+PROCLAIMS=(progn (load "${OUT}/sys-pkg.lsp"))
 
 @
 
@@ -864,7 +863,6 @@ ${SAVESYS}:	${DEPSYS} ${OBJS} ${OUT}/bookvol5.${O} ${OUT}/util.${O} \
 	@ echo OBJ= ${OBJ} 
 	@ echo MNT= ${MNT} 
 	@ echo O=${O} LISP=${LISP} BYE=${BYE}
-	@ cp -p ${OUT}/*.fn ${MID}
 	@ cp -p ${SRC}/doc/msgs/s2-us.msgs ${SPAD}/doc/msgs
 #	@ cp -p ${SRC}/doc/msgs/co-eng.msgs ${SPAD}/doc/msgs
 	@ echo '${PROCLAIMS}' > ${OUT}/makeint.lisp
@@ -898,8 +896,6 @@ ${SAVESYS}:	${DEPSYS} ${OBJS} ${OUT}/bookvol5.${O} ${OUT}/util.${O} \
 	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' \
                 >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
-	@ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' \
-               >> ${OUT}/makeint.lisp
 	@ (cd ${OBJ}/${SYS}/bin ; \
 	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp")' \
                  '(gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
@@ -8575,11 +8571,11 @@ ${MNT}/${SYS}/algebra/exposed.${O} : ${MID}/exposed.lsp ${LISPSYS}
 	@ if [ -z "${NOISE}" ] ; then \
 	   echo '(progn  (compile-file "${MID}/exposed.lsp"' \
              ':output-file "${MNT}/${SYS}/algebra/exposed.${O}") (${BYE}))' \
-             | ${LISPSYS} ; \
+             | ${DEPSYS} ; \
 	  else \
 	   echo '(progn  (compile-file "${MID}/exposed.lsp"' \
              ':output-file "${MNT}/${SYS}/algebra/exposed.${O}") (${BYE}))' \
-             | ${LISPSYS} >${TMP}/trace ; \
+             | ${DEPSYS} >${TMP}/trace ; \
 	  fi
 
 ${OUT}/database.date:
diff --git a/src/interp/bookvol5.pamphlet b/src/interp/bookvol5.pamphlet
index 3c4465e..e32fec3 100644
--- a/src/interp/bookvol5.pamphlet
+++ b/src/interp/bookvol5.pamphlet
@@ -674,7 +674,7 @@ allow a function to be called. In our case it is the [[restart]]
 function which is the entry to the Axiom interpreter.
 <<defun set-restart-hook>>=
 (defun set-restart-hook ()
-  #+KCL (setq system::*top-level-hook* 'restart)
+  #+:GCL (setq system::*top-level-hook* #'restart)
   #+Lucid (setq boot::restart-hook 'restart)
   'restart
  )
@@ -697,9 +697,6 @@ The [[compiler::*suppress-compiler-notes*]] flag has been set to t.
 We do not care that tail recursion occurs.
 <<defun restart>>=
 (defun restart ()
-#+:akcl
-  (init-memory-config :cons 500 :fixnum 200 :symbol 500 :package 8
-    :array 400 :string 500 :cfun 100 :cpages 3000 :rpages 1000 :hole 2000)
 #+:akcl (setq compiler::*compile-verbose* nil)
 #+:akcl (setq compiler::*suppress-compiler-warnings* t)
 #+:akcl (setq compiler::*suppress-compiler-notes* t)
@@ -736,13 +733,15 @@ We do not care that tail recursion occurs.
   (setq *default-pathname-defaults* "")
 #+:CCL
   (setq *default-pathname-defaults* (get-current-directory))
-#-(or :CCL (and :lucid :ibm/370))
+#-(or :GCL :CCL (and :lucid :ibm/370))
   (setq *default-pathname-defaults* (probe-file "./"))
 #+(and :lucid :ibm/370)
   (setq vmlisp::$current-directory "")
 #-(and :lucid :ibm/370)
   (setq vmlisp::$current-directory
      (make-directory *default-pathname-defaults*))
+#+:GCL
+  (setq vmlisp::$current-directory *default-pathname-defaults*)
   (|loadExposureGroupData|)
   (|statisticsInitialization|)
   (|initHist|)
@@ -1175,6 +1174,7 @@ where the [[${SYS}]] variable is the same one set at build time.
   (setq |$defaultMsgDatabaseName|
 	(pathname (make-absolute-filename "/doc/msgs/s2-us.msgs")))
   (setq |$msgDatabaseName| ())
+  #-:GCL
   (setq *default-pathname-defaults*
 	(pathname (make-absolute-filename "")))
   (setq $current-directory $spadroot))
@@ -4642,6 +4642,7 @@ undo(l) ==
 \end{verbatim}
 <<defun undo>>=
 (defun |undo| (l)
+ (declare (special |$options| |$InteractiveFrame|))
  (prog (tmp1 key s undoWhen n)
   (return
    (progn
@@ -5235,6 +5236,7 @@ removeUndoLines u == --called by writeInputLines
 \end{verbatim}
 <<defun removeUndoLines>>=
 (defun |removeUndoLines| (u)
+ (declare (special |$currentLine| |$IOindex|))
  (prog (xtra savedIOindex s s1 m s2 x code c n y acc)
   (return
    (seq
diff --git a/src/interp/comp.lisp.pamphlet b/src/interp/comp.lisp.pamphlet
index f822aad..7e8bf7e 100644
--- a/src/interp/comp.lisp.pamphlet
+++ b/src/interp/comp.lisp.pamphlet
@@ -374,8 +374,6 @@
   (let (u)
     (cond ((ATOM X) NIL)
           ((eq (setq U (CAR X)) 'QUOTE) NIL)
-          ((AND (eq U 'MAKEPROP) $TRACELETFLAG (RPLAC (CAR X) 'MAKEPROP-SAY) NIL)
-           NIL)
            ; temporarily make TRACELET cause MAKEPROPs to be reported
           ((MEMQ U '(DCQ RELET PRELET SPADLET SETQ LET) )
            (COND ((NOT (eq U 'DCQ))
diff --git a/src/interp/daase.lisp.pamphlet b/src/interp/daase.lisp.pamphlet
index e0c20a7..b3ff3c4 100644
--- a/src/interp/daase.lisp.pamphlet
+++ b/src/interp/daase.lisp.pamphlet
@@ -815,13 +815,11 @@ database.
 (defun |library| (args)
  (declare (special |$options|))
  (declare (special |$newConlist|))
- (setq original-directory (get-current-directory))
  (setq |$newConlist| nil)
- (localdatabase args |$options|)
-#+:CCL
- (dolist (a args) (check-module-exists a))
- (|extendLocalLibdb| |$newConlist|)
- (system::chdir original-directory)
+ (let ((original-directory (get-current-directory)))
+   (localdatabase args |$options|)
+   (|extendLocalLibdb| |$newConlist|)
+   (system::chdir original-directory))
  (tersyscommand))
 
 ;; check-module-exists looks to see if a module exists in one of the current
@@ -853,10 +851,7 @@ database.
 ;  .asy
 ;  .ao, then asharp to .asy
 
-(defun localdatabase (filelist options &optional (make-database? nil))
- "read a local filename and update the hash tables"
- (labels (
-  (processOptions (options)
+(defun processOptions (options)
    (let (only dir noexpose)
     (when (setq only (assoc '|only| options))
      (setq options (lisp::delete only options :test #'equal))
@@ -865,23 +860,24 @@ database.
      (setq options (lisp::delete dir options :test #'equal))
      (setq dir (second dir))
      (when (null dir)
-      (|sayKeyedMsg| 'S2IU0002 nil) ))
+      (|sayKeyedMsg| 'S2IU0002 nil)))
     (when (setq noexpose (assoc '|noexpose| options))
      (setq options (lisp::delete noexpose options :test #'equal))
-     (setq noexpose 't) )
+     (setq noexpose 't))
     (when options
      (format t "   Ignoring unknown )library option: ~a~%" options))
     (values only dir noexpose)))
-  (processDir (dirarg thisdir)
+
+(defun processDir (dirarg thisdir)
    (let (allfiles skipasos)
     (system:chdir (string dirarg))
-    (setq allfiles (directory "*"))
+    (setq allfiles (directory "*.nrlib/*"))
     (system:chdir thisdir)
     (values
      (mapcan #'(lambda (f)
-      (when (string-equal (pathname-type f) "nrlib")
-       (list (concatenate 'string (namestring f) "/"
-			  vmlisp::*index-filename*)))) allfiles)
+      (when (string-equal (pathname-type f) "kaf")
+        (list f)))
+      allfiles)
      (mapcan #'(lambda (f)
       (when (string= (pathname-type f) "asy")
        (push (pathname-name f) skipasos)
@@ -899,7 +895,10 @@ database.
        (list (namestring f))))
      allfiles)
 #-:CCL nil
-    ))))
+    )))
+
+(defun localdatabase (filelist options &optional (make-database? nil))
+ "read a local filename and update the hash tables"
  (let (thisdir nrlibs asos asys libs object only dir key 
       (|$forceDatabaseUpdate| t) noexpose)
   (declare (special |$forceDatabaseUpdate|))
@@ -910,7 +909,7 @@ database.
   (if make-database? (setq noexpose t))
   (when dir (multiple-value-setq (nrlibs asys asos libs) (processDir dir thisdir)))
   (dolist (file filelist)
-   (let ((filename (pathname-name file))
+   (let ((filename (pathname-name (symbol-name file)))
 	 (namedir (directory-namestring file)))
     (unless namedir (setq thisdir (concatenate 'string thisdir "/")))
     (cond
@@ -941,7 +940,7 @@ database.
    (asharp file)
    (setq file (|astran| (concatenate 'string (pathname-name file) ".asy")))
    (localasy file object only make-database? noexpose))
-  (HCLEAR |$ConstructorCache|))))
+  (HCLEAR |$ConstructorCache|)))
 
 (defun localasy (asy object only make-database? noexpose)
  "given an alist from the asyfile and the objectfile update the database"
@@ -1549,46 +1548,47 @@ Here I'll try to outline the interp database write procedure
   (princ "                              " out)
   (finish-output out)
   (dolist (constructor (|allConstructors|))
-   (let (struct)
-    (setq struct (get constructor 'database))
-    (setq opalistpos (file-position out))
-    (print (squeeze (database-operationalist struct)) out)
-    (finish-output out)
-    (setq cmodemappos (file-position out))
-    (print (squeeze (database-constructormodemap struct)) out)
-    (finish-output out)
-    (setq modemapspos (file-position out))
-    (print (squeeze (database-modemaps struct)) out)
-    (finish-output out)
-    (if (consp (database-object struct)) ; if asharp code ...
-     (setq obj
-      (cons (pathname-name (car (database-object struct)))
-            (cdr (database-object struct))))
-     (setq obj
-      (pathname-name
-        (first (last (pathname-directory (database-object struct)))))))
-    (setq concategory (squeeze (database-constructorcategory struct)))
-    (if concategory  ; if category then write data else write nil
-     (progn
-      (setq categorypos (file-position out))
-      (print concategory out)
-      (finish-output out))
-     (setq categorypos nil))
-    (setq niladic (database-niladic struct))
-    (setq abbrev (database-abbreviation struct))
-    (setq cosig (database-cosig struct))
-    (setq kind (database-constructorkind struct))
-    (setq defaultdomain (database-defaultdomain struct))
-    (setq ancestors (squeeze (gethash constructor *ancestors-hash*))) ;cattable.boot
-    (if ancestors
-     (progn
-      (setq ancestorspos (file-position out))
-      (print ancestors out)
-      (finish-output out))
-     (setq ancestorspos nil))
-    (push (list constructor opalistpos cmodemappos modemapspos
-      obj categorypos niladic abbrev cosig kind defaultdomain
-      ancestorspos) master)))
+    (let (struct)
+      (setq struct (get constructor 'database))
+      (when (database-object struct)
+        (setq opalistpos (file-position out))
+        (print (squeeze (database-operationalist struct)) out)
+        (finish-output out)
+        (setq cmodemappos (file-position out))
+        (print (squeeze (database-constructormodemap struct)) out)
+        (finish-output out)
+        (setq modemapspos (file-position out))
+        (print (squeeze (database-modemaps struct)) out)
+        (finish-output out)
+        (if (consp (database-object struct)) ; if asharp code ...
+            (setq obj
+                  (cons (pathname-name (car (database-object struct)))
+                        (cdr (database-object struct))))
+            (setq obj
+                  (pathname-name
+                   (first (last (pathname-directory (database-object struct)))))))
+        (setq concategory (squeeze (database-constructorcategory struct)))
+        (if concategory  ; if category then write data else write nil
+            (progn
+              (setq categorypos (file-position out))
+              (print concategory out)
+              (finish-output out))
+            (setq categorypos nil))
+        (setq niladic (database-niladic struct))
+        (setq abbrev (database-abbreviation struct))
+        (setq cosig (database-cosig struct))
+        (setq kind (database-constructorkind struct))
+        (setq defaultdomain (database-defaultdomain struct))
+        (setq ancestors (squeeze (gethash constructor *ancestors-hash*))) ;cattable.boot
+        (if ancestors
+            (progn
+              (setq ancestorspos (file-position out))
+              (print ancestors out)
+              (finish-output out))
+            (setq ancestorspos nil))
+        (push (list constructor opalistpos cmodemappos modemapspos
+                    obj categorypos niladic abbrev cosig kind defaultdomain
+                    ancestorspos) master))))
   (finish-output out)
   (setq masterpos (file-position out))
   (print (mapcar #'squeeze master) out)
diff --git a/src/interp/debug.lisp.pamphlet b/src/interp/debug.lisp.pamphlet
index 9a9e613..1490eaa 100644
--- a/src/interp/debug.lisp.pamphlet
+++ b/src/interp/debug.lisp.pamphlet
@@ -106,7 +106,6 @@ exit (rds ifile)
 ; PURPOSE: Debugging hooks for Boot code
  
 (in-package "BOOT")
-(use-package '("LISP" "VMLISP"))
  
 (DEFPARAMETER /COUNTLIST NIL)
 (DEFPARAMETER /TIMERLIST NIL)
@@ -187,13 +186,13 @@ exit (rds ifile)
   (PROG (FT oft SFN X EDINFILE FILE DEF KEY RECNO U W SOURCEFILES
 	 ECHOMETA SINGLINEMODE XCAPE XTOKENREADER INPUTSTREAM SPADERRORSTREAM
 	 ISID NBLNK COMMENTCHR $TOKSTACK (/SOURCEFILES |$sourceFiles|)
-	 METAKEYLST DEFINITION_NAME (|$sourceFileTypes| '(|spad| |boot| |lisp| |lsp| |meta|))
+	 DEFINITION_NAME (|$sourceFileTypes| '(|spad| |boot| |lisp| |lsp| |meta|))
 	 ($FUNCTION FN) $BOOT $NEWSPAD $LINESTACK $LINENUMBER STACK STACKX BACK OK
 	 TRAPFLAG |$InteractiveMode| TOK COUNT ERRCOL COLUMN *QUERY CHR LINE
 	 (*COMP370-APPLY* (if (eq op 'define) #'eval-defun #'compile-defun)))
 	(declare (special ECHOMETA SINGLINEMODE XCAPE XTOKENREADER INPUTSTREAM
 		     SPADERRORSTREAM ISID NBLNK COMMENTCHR $TOKSTACK /SOURCEFILES
-		     METAKEYLST DEFINITION_NAME |$sourceFileTypes|
+		     DEFINITION_NAME |$sourceFileTypes|
 		     $FUNCTION $BOOT $NEWSPAD $LINESTACK $LINENUMBER STACK STACKX BACK OK
 		     TRAPFLAG |$InteractiveMode| TOK COUNT ERRCOL COLUMN *QUERY CHR LINE))
         (if (PAIRP FN) (SETQ FN (QCAR FN)))
diff --git a/src/interp/debugsys.lisp.pamphlet b/src/interp/debugsys.lisp.pamphlet
index 7f4fa95..6b25f1a 100644
--- a/src/interp/debugsys.lisp.pamphlet
+++ b/src/interp/debugsys.lisp.pamphlet
@@ -261,8 +261,6 @@ loaded by hand we need to establish a value.
 (load (user::thepath "/int/interp/obey.lsp"))
 ;(si::multiply-bignum-stack 10)
 (si::gbc-time 0)
-(setq si::*system-directory* 
-  (user::thepath (concatenate 'string "/mnt/" *sys* "/bin/")))
 (gbc t)
 
 @
diff --git a/src/interp/define.boot.pamphlet b/src/interp/define.boot.pamphlet
index 0f2dc03..b40d2c1 100644
--- a/src/interp/define.boot.pamphlet
+++ b/src/interp/define.boot.pamphlet
@@ -376,7 +376,7 @@ compDefineFunctor1(df is ['DEF,form,signature,$functorSpecialCases,body],
                   --prevents CheckVector from printing out same message twice
     $getDomainCode: local := nil -- code for getting views
     $insideFunctorIfTrue: local:= true
-    $functorsUsed: local := nil --not currently used, finds dependent functors
+--  $functorsUsed: local := nil --not currently used, finds dependent functors
     $setelt: local :=
       $QuickCode = true => 'QSETREFV
       'SETELT
@@ -1282,7 +1282,7 @@ doIt(item,$predl) ==
          $functorLocalParameters:= [:$functorLocalParameters,lhs]
     if code is ['LET,.,rhs',:.] and isDomainForm(rhs',$e) then
       if isFunctor rhs' then
-        $functorsUsed:= insert(opOf rhs',$functorsUsed)
+--      $functorsUsed:= insert(opOf rhs',$functorsUsed)
         $packagesUsed:= insert([opOf rhs'],$packagesUsed)
       if lhs="Rep" then
         $Representation:= (get("Rep",'value,$e)).(0)
diff --git a/src/interp/foam_l.lisp.pamphlet b/src/interp/foam_l.lisp.pamphlet
index a4e1932..60b2bf0 100644
--- a/src/interp/foam_l.lisp.pamphlet
+++ b/src/interp/foam_l.lisp.pamphlet
@@ -168,7 +168,7 @@
 
 
 ;; type defs for Foam types
-(deftype |Char| () 'string-char)
+(deftype |Char| () 'character)
 (deftype |Clos| () 'list)
 (deftype |Bool| () '(member t nil))
 (deftype |Byte| () 'unsigned-byte)
diff --git a/src/interp/macros.lisp.pamphlet b/src/interp/macros.lisp.pamphlet
index 117408c..44a6d3e 100644
--- a/src/interp/macros.lisp.pamphlet
+++ b/src/interp/macros.lisp.pamphlet
@@ -126,8 +126,6 @@ ends up being [[CONTAINED |$EmptyMode| Y]].
 <<*>>=
 <<license>>
 
-(provide 'Boot)
- 
 (in-package "BOOT")
  
 (defvar |$compilingMap| ())
@@ -1673,7 +1671,8 @@ terminals and empty or at-end files.  In Common Lisp, we must assume record size
 ; (2) with possible line breaks within a;
 ; (3) otherwise display without a brace
   `(LET
-    ((state))
+    ((state) (ht (make-hash-table)))
+    (declare (special ht))
     (setq state (|saveState| 't))
     (or
       (markhash ,b 0)
diff --git a/src/interp/metalex.lisp.pamphlet b/src/interp/metalex.lisp.pamphlet
index 00f1b76..958ce34 100644
--- a/src/interp/metalex.lisp.pamphlet
+++ b/src/interp/metalex.lisp.pamphlet
@@ -194,7 +194,7 @@ empty (if File-Closed (return nil))
         (t                                                      'special-char)))
  
 (defun make-adjustable-string (n)
-  (make-array (list n) :element-type 'string-char :adjustable t))
+  (make-array (list n) :element-type 'standard-char :adjustable t))
 
 (defun get-identifier-token (token)
   "Take an identifier off the input stream."
diff --git a/src/interp/monitor.lisp.pamphlet b/src/interp/monitor.lisp.pamphlet
index 03ab46d..7e68de0 100644
--- a/src/interp/monitor.lisp.pamphlet
+++ b/src/interp/monitor.lisp.pamphlet
@@ -511,7 +511,7 @@ for example:
  (eval `(trace (,name :cond (progn (monitor-incr ',name) nil))))
  (setf (gethash name *monitor-table*)
   (make-monitor-data 
-     :name name :count 0 :monitorp t :sourcefile sourcefile)))))
+     :name name :count 0 :monitorp t :sourcefile sourcefile)))
 
 (defun monitor-delete (fn)
  "delete a function from the monitor table"
diff --git a/src/interp/nlib.lisp.pamphlet b/src/interp/nlib.lisp.pamphlet
index 482bcb9..9be8dfe 100644
--- a/src/interp/nlib.lisp.pamphlet
+++ b/src/interp/nlib.lisp.pamphlet
@@ -431,7 +431,7 @@ but has been changed to read:
 	      (string filearg)))))))
 
 (defun make-full-namestring (filearg &optional (filetype nil))
-  (namestring (merge-pathnames (make-filename filearg filetype))))
+  (namestring (merge-pathnames (make-filename filearg filetype) (truename "."))))
 
 (defun probe-name (file)
   (if (probe-file file) (namestring file) nil))
diff --git a/src/interp/parsing.lisp.pamphlet b/src/interp/parsing.lisp.pamphlet
index cce7470..d1a0b2b 100644
--- a/src/interp/parsing.lisp.pamphlet
+++ b/src/interp/parsing.lisp.pamphlet
@@ -556,7 +556,7 @@ the stack, then stack a NIL. Return the value of prod."
   (if (every #'alpha-char-p string) string
     (let* ((size (length string))
 	   (out-string (make-array (* 2 size)
-				   :element-type 'string-char
+				   :element-type 'standard-char
 				   :fill-pointer 0))
 	   next-char)
       (dotimes (i size)
@@ -689,7 +689,7 @@ is a token separator, which blank is equivalent to."
 
 (defun make-string-adjustable (s)
   (cond ((adjustable-array-p s) s)
-        (t (make-array (array-dimensions s) :element-type 'string-char
+        (t (make-array (array-dimensions s) :element-type 'standard-char
                        :adjustable t :initial-contents s))))
 
 (defun get-a-line (stream)
diff --git a/src/interp/sfsfun-l.lisp.pamphlet b/src/interp/sfsfun-l.lisp.pamphlet
index c7c992e..00e6ce1 100644
--- a/src/interp/sfsfun-l.lisp.pamphlet
+++ b/src/interp/sfsfun-l.lisp.pamphlet
@@ -76,10 +76,10 @@
 (defun rpsi      (n x)         (|rPsi|     n x) )
 (defun cpsi      (n z) (c-to-s (|cPsi|     n (s-to-c z)) ))
 
-(defun rbesselj  (n x) (c-to-r (|BesselJ| n x)) ))
+(defun rbesselj  (n x) (c-to-r (|BesselJ| n x)) )
 (defun cbesselj  (v z) (c-to-s (|BesselJ| (s-to-c v) (s-to-c z)) ))
  
-(defun rbesseli  (n x) (c-to-r (|BesselI| n x)) ))
+(defun rbesseli  (n x) (c-to-r (|BesselI| n x)) )
 (defun cbesseli  (v z) (c-to-s (|BesselI| (s-to-c v) (s-to-c z)) ))
 
 (defun chyper0f1 (a z) (c-to-s (|chebf01| (s-to-c a) (s-to-c z)) ))
diff --git a/src/interp/sockio.lisp.pamphlet b/src/interp/sockio.lisp.pamphlet
index c58f2cf..f56999c 100644
--- a/src/interp/sockio.lisp.pamphlet
+++ b/src/interp/sockio.lisp.pamphlet
@@ -266,10 +266,7 @@ resolve the problem
   )
 
 (setq |$NaNvalue| (NANQ))
-#-:ccl
-  (setq |$plusInfinity| (* 1.1  MOST-POSITIVE-LONG-FLOAT))
-#+:ccl
-  (setq |$plusInfinity| MOST-POSITIVE-LONG-FLOAT)
+(setq |$plusInfinity| MOST-POSITIVE-LONG-FLOAT)
 (setq |$minusInfinity| (- |$plusInfinity|))
 
 @
diff --git a/src/interp/sys-pkg.lisp.pamphlet b/src/interp/sys-pkg.lisp.pamphlet
index 850237d..a880c5b 100644
--- a/src/interp/sys-pkg.lisp.pamphlet
+++ b/src/interp/sys-pkg.lisp.pamphlet
@@ -41,37 +41,111 @@ We create all of the known packages here.
 <<*>>=
 <<license>>
 
+@ Towards ANSI compliance.  We need the name of the package which
+exports the standard Lisp symbols.  In a CLtL1 Lisp, these symbols
+exist in the LISP package.  For ANSI, COMMON-LISP is defined.
+<<*>>=
+(eval-when (:compile-toplevel :load-toplevel :execute)
+  (defconstant +standard-lisp-package+ 
+    (if (find-package "COMMON-LISP")
+        "COMMON-LISP"
+        "LISP")))
+
 @
 The spad compiler package. Although I believe this is a dead
 package at this point. All of the symbols from this package
 have been moved into the boot package.
 <<*>>=
-(make-package "SCRATCHPAD_COMPILER")
+(defpackage "SCRATCHPAD-COMPILER"
+    (:use #.+standard-lisp-package+))
 @
 The special functions package. There was originally lisp code
 to support hardcoded knowledge of special functions like gamma.
 This is also a dead package as the functions have been lifted
 to the algebra level.
 <<*>>=
-(make-package "SPECFNSF")
+(defpackage "SPECFNSF")
 
 @
 This is the package that originally contained the VMLisp macros
 but in fact contains macros to support several other lisps. It
 is essentially the place where most of the macros to support
 idioms from prior ports (like rdefiostream and fileactq)
+
 <<*>>=
-(make-package "VMLISP")
-(in-package "VMLISP")
-(lisp::use-package '("USER" "SYSTEM" "LISP"))
+(defpackage "VMLISP"
+  (:use #.+standard-lisp-package+)
+  #+:GCL
+  (:import-from "LISP"
+                "ALLOCATE" "BYE" "CLINES" 
+                "DEFENTRY" "DOUBLE" "GBC" 
+                "INT" "OBJECT" "SYSTEM")
+  #+GCL
+  (:import-from "SYSTEM"
+                "GETENV" "MEMQ")
+  (:export 
+   "$CLEAR" "$CURRENT-DIRECTORY" "$DIRECTORY-LIST" "$ERASE" "$FCOPY" "$FILEP"
+   "$FILETYPE-TABLE" "$FINDFILE" "$INFILEP" "$LIBRARY-DIRECTORY-LIST" "$LISTFILE"
+   "$OUTFILEP" "$REPLACE" "$SCREENSIZE" "$SHOWLINE" "$SPADROOT"
+   "$TOTAL-ELAPSED-TIME" "$TOTAL-GC-TIME" "$defaultMsgDatabaseName"
+   "$msgDatabaseName" "*COMP370-APPLY*" "*FILEACTQ-APPLY*" "*LISP-BIN-FILETYPE*"
+   "*LISP-SOURCE-FILETYPE*" "ABSVAL" "ADD1" "ADDOPTIONS" "ALLOCATE" "APPLX" 
+   "ASSEMBLE" "ASSQ" "BFP" "BINTP" "BOOLEANP" "BPINAME" "BYE" "CALLBELOW" "CATCHALL"
+   "CGREATERP" "CHANGELENGTH" "CHAR2NUM" "CHARP" "CLINES" "CLOSEDFN" "COMP370"
+   "COMPILE-LIB-FILE" "COMPRREAD" "COMPRWRITE" "CONCAT" "CONSOLE" "CONSTANT"
+   "COPY" "CREATE-SBC" "CURINSTREAM" "CUROUTSTREAM" "CURRENTTIME" "CURRINDEX"
+   "CVEC" "CVECP" "DCQ" "DEFENTRY" "DEFINE-FUNCTION" "DEFIOSTREAM" "DEVICE"
+   "DIFFERENCE" "DIG2FIX" "DIGITP" "DIVIDE" "DOUBLE" "DOWNCASE" "DSETQ" "EBCDIC"
+   "ECQ" "EFFACE" "EMBED" "EMBEDDED" "EOFP" "EQCAR" "EQQ" "EQSUBSTLIST"
+   "ERRORINSTREAM" "ERROROUTSTREAM" "EVA1" "EVA1FUN" "EVALANDFILEACTQ" "EVALFUN"
+   "EXIT" "F,PRINT-ONE" "FBPIP" "FETCHCHAR" "FILE" "FIX" "FIXP" "FLUID" "FUNARGP"
+   "GBC" "GCMSG" "GENSYMP" "GETENV" "GETFULLSTR" "GETL" "GETREFV" "GETSTR"
+   "GGREATERP" "GREATERP" "HASHCVEC" "HASHEQ" "HASHID" "HASHTABLE-CLASS"
+   "HASHTABLEP" "HASHUEQUAL" "HCLEAR" "HCOUNT" "HGET" "HKEYS" "HPUT" "HPUT*"
+   "HPUTPROP" "HREM" "HREMPROP" "I" "ID" "IDENTP" "IFCAR" "IFCDR" "INPUT" "INT"
+   "INT2RNUM" "INTERSECTIONQ" "INTP" "IOSTATE" "IS-CONSOLE" "IVECP" "KOMPILE"
+   "L-CASE" "LAM" "LAM,EVALANDFILEACTQ" "LAM,FILEACTQ" "LASTNODE" "LASTPAIR"
+   "LC2UC" "LENGTHOFBPI" "LESSP" "LEXGREATERP" "LINTP" "LISPLIB" "LIST2REFVEC"
+   "LIST2VEC" "LISTOFFLUIDS" "LISTOFFREES" "LISTOFFUNCTIONS" "LISTOFQUOTES" "LN"
+   "LOADCOND" "LOADVOL" "LOG2" "MACERR" "MACRO-INVALIDARGS" "MACRO-MISSINGARGS"
+   "MAKE-ABSOLUTE-FILENAME" "MAKE-APPENDSTREAM" "MAKE-BVEC" "MAKE-CVEC"
+   "MAKE-FILENAME" "MAKE-FULL-CVEC" "MAKE-HASHTABLE" "MAKE-INPUT-FILENAME"
+   "MAKE-INSTREAM" "MAKE-OUTSTREAM" "MAKE-VEC" "MAKEPROP" "MAKESTRING" "MAPELT"
+   "MAXINDEX" "MBPIP" "MDEF" "MDEFX" "MEMQ" "MINUS" "MLAMBDA" "MODE" "MOVEVEC"
+   "MRP" "MSUBST" "MSUBSTQ" "NAMEDERRSET" "NCONC2" "NE" "NEQ" "NEXT" "NILFN"
+   "NREMOVE" "NREMOVEQ" "NULLOUTSTREAM" "NUM2CHAR" "NUMBEROFARGS" "NUMP" "O"
+   "OBEY" "OBJECT" "ONE-OF" "OPTIONLIST" "ORADDTEMPDEFS" "OUTPUT" "PAIRP" "PAPPP"
+   "PLACEP" "PLUS" "PNAME" "POPP" "PRETTYPRIN0" "PRETTYPRINT" "PRIN0" "PRIN2CVEC"
+   "PRINTEXP" "PROPLIST" "PUT" "QASSQ" "QCAAAAR" "QCAAADR" "QCAAAR" "QCAADAR"
+   "QCAADDR" "QCAADR" "QCAAR" "QCADAAR" "QCADADR" "QCADAR" "QCADDAR" "QCADDDR"
+   "QCADDR" "QCADR" "QCAR" "QCDAAAR" "QCDAADR" "QCDAAR" "QCDADAR" "QCDADDR"
+   "QCDADR" "QCDAR" "QCDDAAR" "QCDDADR" "QCDDAR" "QCDDDAR" "QCDDDDR" "QCDDDR"
+   "QCDDR" "QCDR" "QCSIZE" "QENUM" "QEQQ" "QESET" "QLENGTH" "QMEMQ" "QREFELT"
+   "QRPLACA" "QRPLACD" "QRPLQ" "QSABSVAL" "QSADD1" "QSDEC1" "QSDIFFERENCE"
+   "QSETQ" "QSETREFV" "QSETVELT" "QSETVELT-1" "QSGREATERP" "QSINC1" "QSLEFTSHIFT"
+   "QSLESSP" "QSMAX" "QSMIN" "QSMINUS" "QSMINUSP" "QSODDP" "QSORT" "QSPLUS"
+   "QSQUOTIENT" "QSREMAINDER" "QSSUB1" "QSTIMES" "QSTRINGLENGTH" "QSZEROP"
+   "QUOTIENT" "QVELT" "QVELT-1" "QVMAXINDEX" "QVSIZE" "RCLASS" "RCOPYITEMS"
+   "RDEFIOSTREAM" "RDROPITEMS" "RE-ENABLE-INT" "RECLAIM" "RECOMPILE-DIRECTORY"
+   "RECOMPILE-LIB-FILE-IF-NECESSARY" "REFVECP" "REMAINDER" "REMOVEQ" "REROOT"
+   "RESETQ" "RKEYIDS" "RNUMP" "RPACKFILE" "RPLACSTR" "RPLNODE" "RPLPAIR" "RPLQ"
+   "RREAD" "RSETCLASS" "RSHUT" "RVECP" "RWRITE" "SEQ" "SETANDFILEQ"
+   "SETDIFFERENCE" "SETDIFFERENCEQ" "SETELT" "SETQP" "SETSIZE" "SFP" "SHUT"
+   "SINTP" "SIZE" "SMINTP" "SORTBY" "SORTGREATERP" "STACKLIFO" "STATEP" "STRCONC"
+   "STRGREATERP" "STRING2ID-N" "STRINGIMAGE" "STRINGLENGTH" "STRPOS" "STRPOSL"
+   "SUB1" "SUBLOAD" "SUBRP" "SUBSTQ" "SUBSTRING" "SUFFIX" "SYSTEM" "TAB"
+   "TEMPUS-FUGIT" "TEREAD" "THROW-PROTECT" "TIMES" "TRIMSTRING" "TRUEFN" "U-CASE"
+   "UEQUAL" "UNEMBED" "UNIONQ" "UPCASE" "USE-VMLISP-SYNTAX" "VEC-SETELT"
+   "VEC2LIST" "VECP" "VM/" "VMPRINT" "VMREAD" "assoc" "directoryp" "idChar?"
+   "intersection" "last" "log" "member" "nsubst" "read-line" "remove" 
+   "shoeInputFile" "shoeread-line" "startsId?" "union"))
 
 @
 This is the boot to lisp compiler package which contains the
 src/boot files. Tt is the boot translator package.
 <<*>>=
-(make-package "BOOTTRAN")
-(in-package "BOOTTRAN")
-(lisp::use-package '("LISP"))
+(defpackage "BOOTTRAN"
+  (:use #.+standard-lisp-package+))
 
 @
 Everything in axiom that the user references eventually shows
@@ -79,9 +153,8 @@ up here. The interpreter and the algebra are run after switching
 to the boot package (in-package "BOOT") so any symbol that the
 interpreter or algebra uses has to (cough, cough) appear here.
 <<*>>=
-(make-package "BOOT")
-(in-package "BOOT")
-(lisp::use-package '("VMLISP" "LISP"))
+(defpackage "BOOT"
+  (:use #.+standard-lisp-package+ "VMLISP"))
 
 @
 FOAM is the intermediate language for the aldor compiler. FOAM
@@ -90,987 +163,17 @@ RTL for the GCC compiler. It is a "machine" that is used as the
 target for meta-assembler level statments. These are eventually
 expanded for the real target machine (or interpreted directly)
 <<*>>=
-(make-package "FOAM")
-(in-package "FOAM")
-(lisp::use-package '("LISP"))
+(defpackage "FOAM"
+  (:use #.+standard-lisp-package+))
 
 @
 FOAM-USER is the package containing foam statements and macros
 that get inserted into user code versus the foam package which
 provides support for compiler code.
 <<*>>=
-(make-package "FOAM-USER")
-(in-package "FOAM-USER")
-(lisp::use-package '("LISP" "FOAM"))
-
-(lisp:in-package "BOOT")
-
-(lisp:import
-    '(VMLISP::ERROROUTSTREAM LISP::COUNT VMLISP::NE VMLISP::FLUID
-	 LISP:SEQUENCE VMLISP::OBEY LISP:NUMBER VMLISP::|union|
-	 LISP:STEP VMLISP::OPTIONLIST VMLISP::EXIT VMLISP::throw-protect
-<<GCL.GETENV>>
-         VMLISP::GET-CURRENT-DIRECTORY VMLISP::AXIOM-PROBE-FILE
-         VMLISP::*INDEX-FILENAME*))
-(lisp:export
-    '(BOOT::|$FormalMapVariableList| BOOT::|$userModemaps|
-	 boot::restart boot::$IEEE
-	 BOOT::|directoryp| boot::help boot::|version| boot::|pp|
-	 BOOT::POP-STACK-4 BOOT::|$BasicDomains| BOOT::|$DomainFrame|
-	 BOOT::|$SideEffectFreeFunctionList|
-	 BOOT::ATOM2STRING BOOT::|$DoubleQuote| BOOT::|$genSDVar|
-	 BOOT::GETCHARN BOOT::DROP VMLISP::ERROROUTSTREAM
-	 BOOT::MATCH-STRING BOOT::|$fromSpadTrace|
-	 BOOT::|$UserSynonyms| BOOT::%L BOOT::FLUIDVARS
-	 BOOT::/EMBEDREPLY BOOT::|$LocalFrame| BOOT::|$streamIndexing|
-	 BOOT::APPLYR BOOT::NEXTINPUTLINE BOOT::$NORMALSTRING
-	 BOOT::|$InteractiveTimingStatsIfTrue| BOOT::|$leaveLevelStack|
-	 BOOT::|$xyMin| BOOT::|lcm| BOOT::STRINGSUFFIX
-	 BOOT::|Category| BOOT::ESCAPE-CHARACTER
-	 LISP:COUNT BOOT::|break| BOOT::$DIRECTORY
-	 BOOT::CONVERSATION BOOT::|fillerSpaces|
-	 BOOT::$REVERSEVIDEOSTRING BOOT::|$DomainsInScope|
-	 BOOT::|$gauss01| BOOT::|$mostRecentOpAlist| BOOT::SUBLISLIS
-	 BOOT::QUITFILE BOOT::|PrintBox| BOOT::POP-REDUCTION
-	 BOOT::META-SYNTAX-ERROR BOOT::|$constructorInfoTable|
-	 BOOT::|$currentLine| BOOT::|$Float| BOOT::|$slamFlag|
-	 BOOT::|$SmallIntegerOpt| BOOT::$SPAD BOOT::|$timerOn|
-	 BOOT::$TRACELETFLAG VMLISP::NE BOOT::ADJCURMAXINDEX
-	 BOOT::STREAM-BUFFER BOOT::SPADSLAM BOOT::$EM
-	 BOOT::|$PositiveIntegerOpt| BOOT::THETA BOOT::READ-QUIETLY
-	 BOOT::RS BOOT::|$compUniquelyIfTrue|
-	 BOOT::|$insideExpressionIfTrue| BOOT::LE BOOT::KAR BOOT::ELEM
-	 BOOT::LASTATOM BOOT::IN-STREAM BOOT::$DELAY
-	 BOOT::QSEXPT BOOT::|$quadSymbol| BOOT::|$streamAlist|
-	 BOOT::|$SymbolOpt| BOOT::TAKE BOOT::CONSOLEINPUTP
-	 BOOT::|$hasYield| BOOT::DEBUGMODE BOOT::|$DummyFunctorNames|
-	 BOOT::|$PositiveInteger| BOOT::%D VMLISP::FLUID BOOT::TLINE
-	 BOOT::|$abbreviationTable| BOOT::|$FontTable|
-	 BOOT::|$PatternVariableList| BOOT::|$returnMode| BOOT::NEQUAL
-	 BOOT::GE BOOT::|MakeSymbol| BOOT::|$insideWhereIfTrue|
-	 BOOT::|$mapSubNameAlist| BOOT::GETCHAR BOOT::|Gaussian|
-	 BOOT::IDENTIFIER BOOT::|$LastCxArg| BOOT::|$systemCommands|
-	 BOOT::|$true| BOOT::SETANDFILE BOOT::PUSH-REDUCTION
-	 BOOT::|$BigFloat| BOOT::|$brightenCommentsFlag|
-	 BOOT::|$cacheCount| BOOT::|$exitModeStack| BOOT::|$noEnv|
-	 BOOT::|$NonPositiveIntegerOpt| BOOT::PUTGCEXIT
-	 BOOT::|$readingFile|
-	 BOOT::IS BOOT::KDR BOOT::|$quadSym| BOOT::|$BreakMode|
-	 BOOT::$TOKSTACK BOOT::DEFSTREAM BOOT::LOCVARS BOOT::NTH-STACK
-	 BOOT::$UNDERLINESTRING BOOT::|$compCount|
-	 BOOT::|$lisplibModemapAlist| BOOT::COMP BOOT::LINE
-	 BOOT::GETGENSYM BOOT::$FUNNAME BOOT::|$SystemSynonyms|
-	 BOOT::|$spadOpList| BOOT::GENERAL BOOT::|$fortranOutputStream|
-	 BOOT::META_PREFIX BOOT::|$InteractiveMode| BOOT::|strconc|
-	 BOOT::TAILFN BOOT::RPLACW BOOT::|PositiveInteger|
-	 BOOT::|$inactiveLisplibs| BOOT::|$NonPositiveInteger|
-	 BOOT::|$reportCoerceIfTrue|
-	 BOOT::|sayBrightlyNT| BOOT::NEXT-CHAR boot::|sayString|
-	 BOOT::META_ERRORS_OCCURRED BOOT::|$resolveFlag|
-	 BOOT::|$StringOpt| BOOT::|UnivariatePoly| BOOT::MATCH-TOKEN
-	 BOOT::|$createUpdateFiles| BOOT::|$noParseCommands|
-	 BOOT::FLAGP BOOT::ECHO-META BOOT::|initializeSetVariables|
-	 BOOT::|$CategoryNames| BOOT::?ORDER
-	 BOOT::$FILELINENUMBER BOOT::|$timerTicksPerSecond|
-	 BOOT::|bootUnionPrint| BOOT::|$consistencyCheck|
-	 BOOT::|$oldTime| BOOT::$NEWSPAD BOOT::NUMOFNODES
-	 BOOT::|$ResMode| BOOT::S* BOOT::TRANSPGVAR BOOT::$BOXSTRING
-	 BOOT::|$BasicPredicates| BOOT::|$eltIfNil| BOOT::$FUNNAME_TAIL
-	 BOOT::|$QuickCode| BOOT::GENVAR BOOT::|$TypeEqui|
-	 BOOT::TOKEN-TYPE BOOT::|updateSourceFiles| BOOT::|$BFtag|
-	 BOOT::|$reportBottomUpFlag| BOOT::|$SmallInteger|
-	 BOOT::|$TypeEQ| BOOT::|Boolean| BOOT::|RationalNumber|
-	 BOOT::MAKENEWOP BOOT::|$EmptyList| BOOT::|$leaveMode|
-	 BOOT::MKQ BOOT::ON BOOT::CONTAINED BOOT::|conOutStream|
-	 BOOT::POINTW BOOT::REDUCTION-POP-ELT BOOT::TOKEN-SYMBOL
-	 BOOT::ERRCOL BOOT::|$domainTraceNameAssoc| BOOT::SUBSTEQ
-	 BOOT::DELASSOS BOOT::|Size| BOOT::|$form|
-	 BOOT::|$insideCategoryIfTrue| BOOT::SUCHTHAT BOOT::|One|
-	 BOOT::ACTION BOOT::MDEFTRACE BOOT::|$BooleanOpt|
-	 BOOT::|$xyStack| BOOT::ASSOCLEFT BOOT::|sayALGEBRA|
-	 BOOT::|Coord| BOOT::IDENTIFIER-TOKEN BOOT::ADVANCE-CHAR
-	 BOOT::|$InitialDomainsInScope| BOOT::|$StringCategory|
-	 BOOT::S- BOOT::NEWLINE BOOT::|$optimizableDomainNames|
-	 BOOT::IN BOOT::COLLECTV BOOT::|$Lisp|
-	 BOOT::|$lisplibOperationAlist| BOOT::|$reportExitModeStack|
-	 BOOT::|$updateCatTableIfTrue| BOOT::NREVERSE0 BOOT::%M
-	 BOOT::|sayFORTRAN| BOOT::NEWLINECHR BOOT::|$EmptyMode|
-	 BOOT::|$Zero| BOOT::CARCDREXPAND BOOT::|IS_#GENVAR|
-	 BOOT::LISTOFATOMS BOOT::|$algebraOutputStream|
-	 BOOT::|$highlightAllowed| BOOT::|NonNegativeInteger|
-	 BOOT::/EMBED-1
-	 BOOT::|$constructorsNotInDatabase| BOOT::|$ConstructorNames|
-	 BOOT::|$Integer| BOOT::|$systemModemapsInCore| BOOT::KADDR
-	 BOOT::STAR BOOT::|$reportCompilation|
-	 BOOT::|$traceNoisely| BOOT::SPADDIFFERENCE BOOT::%B
-	 BOOT::COMMENT-CHARACTER BOOT::|$PrettyPrint| BOOT::SPADLET
-	 BOOT::|$ModemapFrame| BOOT::|$QuickLet| BOOT::SPADDO
-	 BOOT::PREDECESSOR BOOT::*EOF* BOOT::POP-STACK-1 BOOT::BANG
-	 BOOT::|$ConstructorCache| BOOT::|$printConStats|
-	 BOOT::|$RationalNumberOpt| BOOT::RESET
-	 BOOT::NLIST BOOT::NSTRCONC BOOT::TAIL BOOT::GETRULEFUNLISTS
-	 BOOT::|$IntegerOpt| BOOT::$NEWLINSTACK BOOT::|$QuietIfNil|
-	 BOOT::$SPAD_ERRORS BOOT::|$useDCQnotLET| BOOT::|$xCount|
-	 BOOT::$BOOT BOOT::POINT BOOT::OPTIONAL BOOT::PARSE-IDENTIFIER
-	 BOOT::BSTRING-TOKEN BOOT::LASTELEM BOOT::STREAM-EOF
-	 BOOT::|sayBrightly| BOOT::|$formulaOutputStream|
-	 BOOT::|BigFloat| BOOT::SLAM BOOT::$DISPLAY
-	 BOOT::|$NonMentionableDomainNames| BOOT::$OLDLINE BOOT::$TYPE
-	 BOOT::STATUS BOOT::KEYFN BOOT::|$NonNegativeIntegerOpt|
-	 BOOT::|$userConstructors| BOOT::BOOT-NEQUAL BOOT::RPLAC
-	 BOOT::GETTAIL BOOT::|QuotientField| BOOT::CURRENT-TOKEN
-	 BOOT::|$suffix| BOOT::|$VariableCount| BOOT::COMPARE
-	 LISP:SEQUENCE BOOT::|$Exit| BOOT::BOOT-EQUAL BOOT::LT
-	 VMLISP::OBEY BOOT::|UnSizedBox| BOOT::|Integer| BOOT::|Nud|
-	 BOOT::IOCLEAR BOOT::|$BigFloatOpt| BOOT::|$EmptyEnvironment|
-	 BOOT::|$forceDatabaseUpdate| BOOT::$LINESTACK BOOT::ULCASEFG
-	 BOOT::|$Boolean| BOOT::|$clamList| BOOT::COLLECT
-	 BOOT::IOSTREAMS-SET BOOT::MUST BOOT::|$FloatOpt|
-	 BOOT::|$NonNegativeInteger|
-	 BOOT::FLAG BOOT::TL BOOT::BLANKS BOOT::|$report3|
-	 BOOT::|$reportFlag| BOOT::|$xeditIsConsole| BOOT::PAIR
-	 BOOT::|$evalDomain| BOOT::|$traceletFunctions| BOOT::|$Void|
-	 BOOT::GT BOOT::MATCH-ADVANCE-STRING
-	 BOOT::|$scanModeFlag| BOOT::SUBLISNQ BOOT::LASSQ BOOT::NOTE
-	 BOOT::ILAM BOOT::CURRENT-SYMBOL
-	 BOOT::|$SetFunctions| BOOT::|$sourceFileTypes| BOOT::|String|
-	 BOOT::NUMBER-TOKEN BOOT::$LINENUMBER BOOT::$NUM_OF_META_ERRORS
-	 BOOT::|$Polvar| BOOT::|$domainsWithUnderDomains|
-	 BOOT::SPADCALL BOOT::DELASC BOOT::FAIL BOOT::$COMPILE
-	 BOOT::|$lastUntraced| BOOT::|$lisplibKind|
-	 BOOT::|$tracedModemap| BOOT::|$inputPromptType| BOOT::LASSOC
-	 LISP:NUMBER BOOT::|$prefix| BOOT::|$TranslateOnly| BOOT::SAY
-	 BOOT::|$CategoryFrame| BOOT::|$croakIfTrue| BOOT::|$exitMode|
-	 BOOT::|$lisplibDependentCategories| BOOT::|$NoValue|
-	 BOOT::MOAN BOOT::POP-STACK-2 BOOT::BAC
-	 BOOT::|$InitialModemapFrame| BOOT::$MAXLINENUMBER
-	 BOOT::$ESCAPESTRING BOOT::|$bootStrapMode|
-	 BOOT::|$compileMapFlag| BOOT::|$currentFunction|
-	 BOOT::|$DomainNames| BOOT::|$PolyMode| BOOT::|$tripleCache|
-	 BOOT::SUCHTHATCLAUSE BOOT::WHILE BOOT::S+ BOOT::|Expression|
-	 BOOT::PARSE-NUMBER BOOT::|$Index| BOOT::$NBOOT
-	 BOOT::|$PrintCompilerMessagesIfTrue| BOOT::$PROMPT
-	 BOOT::MAKE-PARSE-FUNCTION BOOT::/METAOPTION BOOT::|$topOp|
-	 BOOT::|$xyInitial| BOOT::MKPF BOOT::STRM
-	 BOOT::MATCH-NEXT-TOKEN BOOT::|pathname| BOOT::|$cacheAlist|
-	 BOOT::$FUNCTION BOOT::|$reportSpadTrace|
-	 BOOT::|$tempCategoryTable| BOOT::|$underDomainAlist|
-	 BOOT::|$whereList| BOOT::|append| BOOT::|function|
-	 BOOT::CURINPUTLINE BOOT::|sayFORMULA|
-	 BOOT::/GENVARLST BOOT::|$Category| BOOT::|$SpecialDomainNames|
-	 VMLISP::|union| BOOT::ASSOCRIGHT BOOT::CURSTRMLINE
-	 BOOT::REDUCTION BOOT::|$lisplibDomainDependents|
-	 BOOT::|OptionList| BOOT::|$postStack| BOOT::|$traceDomains|
-	 BOOT::BRIGHTPRINT BOOT::|$instantRecord|
-	 BOOT::|$NETail| BOOT::UNTIL BOOT::GET-TOKEN
-	 BOOT::|$Expression| BOOT::$LASTPREFIX BOOT::|$mathTraceList|
-	 BOOT::|$PrintOnly| BOOT::ELEMN BOOT::NILADIC
-	 BOOT::PARSE-BSTRING BOOT::/DEPTH BOOT::|$spadLibFT|
-	 BOOT::|$xyMax| BOOT::|$IOindex| BOOT::SPADCONST
-	 BOOT::|sayBrightlyI| BOOT::|SquareMatrix|
-	 BOOT::LASTTAIL
-	 BOOT::|UnboundBox| BOOT::NEXT-TOKEN
-	 BOOT::|$OutsideStringIfTrue| BOOT::|$String| BOOT::TRIMLZ
-	 BOOT::KADR BOOT::STRMBLANKLINE BOOT::STRMSKIPTOBLANK
-	 BOOT::IOSTAT BOOT::|$insideCoerceInteractiveHardIfTrue|
-	 BOOT::|$lisplibSignatureAlist| BOOT::REMFLAG BOOT::SPADREDUCE
-	 BOOT::QLASSQ BOOT::NEXTSTRMLINE BOOT::|FontTable| BOOT::|Led|
-	 BOOT::UNGET-TOKENS BOOT::|$operationNameList|
-	 BOOT::|$tokenCommands| BOOT::IS_GENVAR BOOT::INIT-RULES
-	 BOOT::|PrintItem| BOOT::$LISPLIB BOOT::|$optionAlist|
-	 BOOT::|$previousTime| BOOT::|$StreamIndex|
-	 BOOT::|$systemLisplibsWithModemapsInCore|
-	 BOOT::|$tracedSpadModemap| BOOT::ISTEP BOOT::|$warningStack|
-	 BOOT::|and| BOOT::OUT-STREAM BOOT::TOKEN
-	 BOOT::|$ConstructorDependencyAlist|
-	 BOOT::|$lisplibVariableAlist| BOOT::INTERNL BOOT::IEQUAL
-	 BOOT::|$algebraList| BOOT::|$brightenCommentsIfTrue|
-	 BOOT::|$failure| BOOT::|$Mode| BOOT::|$opFilter|
-	 BOOT::|$TraceFlag| BOOT::|Float| BOOT::POP-STACK-3
-	 BOOT::|$EmptyString| BOOT::$TOP_STACK BOOT::|$mpolyTTrules|
-	 BOOT::|$mpolyTMrules| BOOT::|$InteractiveFrame|
-	 BOOT::|$InteractiveModemapFrame| BOOT::|$letAssoc|
-	 BOOT::|$lisp2lispRenameAssoc| BOOT::|$RationalNumber|
-	 BOOT::|$ThrowAwayMode| BOOT::*PROMPT* BOOT::NUMOFARGS
-	 BOOT::|$semanticErrorStack| BOOT::|$spadSystemDisks|
-	 BOOT::$TOP_LEVEL BOOT::BUMPCOMPERRORCOUNT
-	 BOOT::|delete| BOOT::STREQ BOOT::STRING-TOKEN BOOT::XNAME
-	 BOOT::|$ExpressionOpt| BOOT::|$systemCreation| BOOT::$GENNO
-	 BOOT::CROAK BOOT::PARSE-STRING BOOT::|$genFVar|
-	 BOOT::|$lisplibModemap| BOOT::|$NoValueMode| BOOT::|$PrintBox|
-	 BOOT::ADVANCE-TOKEN BOOT::|$NegativeIntegerOpt|
-	 BOOT::|$polyDefaultAssoc| BOOT::|$PrimitiveDomainNames|
-	 LISP:STEP BOOT::|rassoc| BOOT::|$Res|
-	 BOOT::MATCH-CURRENT-TOKEN BOOT::/GENSYMLIST BOOT::|$false|
-	 BOOT::|$ignoreCommentsIfTrue| BOOT::|$ModeVariableList|
-	 BOOT::|$useBFasDefault| BOOT::|$CommonDomains|
-	 BOOT::|$printLoadMsgs| BOOT::|dataCoerce| BOOT::|$inLispVM|
-	 BOOT::|$streamCount|
-	 BOOT::|$Symbol| BOOT::|$updateIfTrue| BOOT::REMDUP
-	 BOOT::ADDASSOC BOOT::|PrintList|
-	 BOOT::SPECIAL-CHAR BOOT::XCAPE BOOT::|$EmptyVector|
-	 BOOT::REPEAT BOOT::|$NegativeInteger|
-	 BOOT::LENGTHENVEC BOOT::CURMAXINDEX BOOT::|$hasCategoryTable|
-	 BOOT::|$leftPren| BOOT::|$lisplibForm| BOOT::|$OneCoef|
-	 BOOT::|$reportCoerce| VMLISP::OPTIONLIST BOOT::META
-	 BOOT::|$insideCapsuleFunctionIfTrue|
-	 BOOT::|$insideConstructIfTrue| BOOT::$BOLDSTRING
-	 BOOT::|breaklet| BOOT::|$insideCompTypeOf|
-	 BOOT::|$rightPren|
-	 BOOT::|$systemLastChanged| BOOT::|$xyCurrent| BOOT::|Zero|
-	 BOOT::YIELD BOOT::|Polynomial| BOOT::|$Domain| BOOT::STRINGPAD
-	 BOOT::TRUNCLIST BOOT::|SmallInteger| BOOT::|$libFile|
-	 BOOT::|$mathTrace| BOOT::|$PolyDomains| BOOT::|or|
-	 BOOT::|$DomainVariableList| BOOT::|$insideFunctorIfTrue|
-	 BOOT::|$One| VMLISP::EXIT BOOT::CURRENT-CHAR BOOT::NBLNK
-	 BOOT::$DALYMODE))
-
-;;; Definitions for package VMLISP of type EXPORT
-(lisp:in-package "VMLISP")
-(lisp:import '(
-<<GCL.DEFINE-MACRO>>
-<<GCL.MEMQ>>
-<<GCL.PNAME>>
-	  BOOT:|directoryp|))
-(lisp:export
-    '(VMLISP::SINTP VMLISP::$FCOPY 
-<<GCL.DEFINE-MACRO>>
-<<GCL.MEMQ>>
-<<GCL.PNAME>>
-         VMLISP::PUT
-	 VMLISP::QVELT-1 VMLISP::QSETVELT-1 vmlisp::throw-protect
-	 VMLISP::|directoryp| VMLISP::EQCAR
-	 VMLISP::DEFIOSTREAM VMLISP::RDEFIOSTREAM VMLISP::MLAMBDA
-	 VMLISP::QSLESSP VMLISP::QSDIFFERENCE VMLISP::QSQUOTIENT
-	 VMLISP::ERROROUTSTREAM VMLISP::CREATE-SBC VMLISP::LASTPAIR
-	 VMLISP::EQSUBSTLIST VMLISP::QCAAAR VMLISP::$TOTAL-ELAPSED-TIME
-	 VMLISP::QUOTIENT VMLISP::SORTGREATERP
-	 VMLISP::QSETREFV VMLISP::QSTRINGLENGTH VMLISP::EVALFUN
-	 VMLISP::QCDAR VMLISP::TEMPUS-FUGIT VMLISP::QSPLUS VMLISP::QSABSVAL
-	 VMLISP::QSZEROP VMLISP::QSMIN VMLISP::QSLEFTSHIFT
-	 VMLISP::SETDIFFERENCE VMLISP::RPLQ VMLISP::CATCHALL
-	 VMLISP::RECOMPILE-DIRECTORY VMLISP::MDEF VMLISP::LINTP
-	 VMLISP::NILFN VMLISP::TAB VMLISP::QCDDR VMLISP::IOSTATE
-	 VMLISP::SFP VMLISP::NE VMLISP::STRGREATERP
-	 VMLISP::USE-VMLISP-SYNTAX VMLISP::RCLASS 
-	 VMLISP::SEQ VMLISP::FIXP VMLISP::MAKE-CVEC
-	 VMLISP::|F,PRINT-ONE| VMLISP::HASHUEQUAL VMLISP::$OUTFILEP
-	 VMLISP::TIMES VMLISP::DIFFERENCE VMLISP::MSUBST VMLISP::DIVIDE
-	 VMLISP::|remove| VMLISP::GETL VMLISP::QCADAR VMLISP::QCAAAAR
-	 VMLISP::RECLAIM VMLISP::ORADDTEMPDEFS VMLISP::NAMEDERRSET
-	 VMLISP::TRIMSTRING VMLISP::CURRINDEX VMLISP::EVALANDFILEACTQ
-	 VMLISP::LISPLIB VMLISP::FLUID VMLISP::MDEFX VMLISP::COMP370
-	 VMLISP::NEQ VMLISP::GETREFV VMLISP::|log| VMLISP::QVSIZE
-	 VMLISP::MBPIP VMLISP::RPLNODE VMLISP::QSORT
-	 VMLISP::PLACEP VMLISP::RREAD VMLISP::BINTP VMLISP::QSODDP
-	 VMLISP::O VMLISP::RVECP VMLISP::CHAR2NUM VMLISP::POPP
-	 VMLISP::QCDAADR VMLISP::HKEYS VMLISP::HASHCVEC VMLISP::HASHID
-	 VMLISP::REMOVEQ VMLISP::LISTOFFUNCTIONS
-	 VMLISP::QCADAAR VMLISP::ABSVAL VMLISP::VMPRINT
-	 VMLISP::MAKE-APPENDSTREAM
-	 VMLISP::MAKE-INSTREAM VMLISP::HASHTABLEP VMLISP::UPCASE
-	 VMLISP::LOADCOND VMLISP::STRPOSL VMLISP::STATEP VMLISP::QCDADR
-	 VMLISP::HREMPROP VMLISP::LAM VMLISP::FBPIP VMLISP::NCONC2
-	 VMLISP::GETFULLSTR VMLISP::I VMLISP::HREM
-	 VMLISP::*LISP-BIN-FILETYPE* VMLISP::INT2RNUM VMLISP::EBCDIC
-	 VMLISP::$INFILEP VMLISP::BFP VMLISP::NUMP VMLISP::UNEMBED
-	 VMLISP::PAIRP VMLISP::BOOLEANP VMLISP::FIX VMLISP::REMAINDER
-	 VMLISP::RE-ENABLE-INT VMLISP::QCAADDR VMLISP::QCDDADR
-	 VMLISP::$LISTFILE VMLISP::IVECP VMLISP::LIST2VEC
-	 VMLISP::|LAM,FILEACTQ| VMLISP::LISTOFQUOTES
-	 VMLISP::$ERASE VMLISP::QSDEC1
-	 VMLISP::QSSUB1 VMLISP::QCAR VMLISP::EVA1FUN VMLISP::IS-CONSOLE
-	 VMLISP::MAKESTRING VMLISP::CUROUTSTREAM VMLISP::QCDDDR
-	 VMLISP::QCDADAR VMLISP::MAKE-ABSOLUTE-FILENAME VMLISP::SUFFIX
-	 VMLISP::FUNARGP VMLISP::VM/ VMLISP::QRPLACA VMLISP::GGREATERP
-	 VMLISP::CGREATERP VMLISP::RNUMP VMLISP::RESETQ VMLISP::QRPLACD
-	 VMLISP::SORTBY VMLISP::CVECP VMLISP::SETELT VMLISP::HGET
-	 VMLISP::$DIRECTORY-LIST VMLISP::LN VMLISP::|member|
-	 VMLISP::$LIBRARY-DIRECTORY-LIST
-	 VMLISP::QCSIZE VMLISP::QCADDDR VMLISP::RWRITE VMLISP::SUBLOAD
-	 VMLISP::STRINGIMAGE VMLISP::$CLEAR VMLISP::|read-line|
-	 VMLISP::PROPLIST VMLISP::INTP VMLISP::OUTPUT VMLISP::CONSOLE
-	 VMLISP::QCDDDAR VMLISP::ADDOPTIONS VMLISP::$FILETYPE-TABLE
-	 VMLISP::QSMINUSP VMLISP::|assoc| VMLISP::SETSIZE VMLISP::QCDR
-	 VMLISP::EFFACE VMLISP::COPY VMLISP::DOWNCASE VMLISP::LC2UC
-	 VMLISP::EMBED VMLISP::SETANDFILEQ VMLISP::QSMAX
-	 VMLISP::LIST2REFVEC VMLISP::MACRO-INVALIDARGS VMLISP::EMBEDDED
-	 VMLISP::REFVECP VMLISP::CLOSEDFN VMLISP::MAKE-HASHTABLE
-	 VMLISP::MAKE-FILENAME VMLISP::|$defaultMsgDatabaseName|
-	 VMLISP::LEXGREATERP
-	 VMLISP::IDENTP VMLISP::QSINC1 VMLISP::QESET VMLISP::MRP
-	 VMLISP::LESSP VMLISP::RPLPAIR VMLISP::QVELT VMLISP::QRPLQ
-	 VMLISP::MACERR VMLISP::*FILEACTQ-APPLY* VMLISP::HPUT*
-	 VMLISP::$FILEP VMLISP::MAKE-FULL-CVEC VMLISP::HCLEAR
-	 VMLISP::ERRORINSTREAM VMLISP::HPUTPROP 
-	 VMLISP::STRING2ID-N VMLISP::CALLBELOW VMLISP::BPINAME
-	 VMLISP::CHANGELENGTH VMLISP::ECQ VMLISP::OBEY VMLISP::QASSQ
-	 VMLISP::DCQ VMLISP::SHUT VMLISP::FILE VMLISP::HPUT
-	 VMLISP::MAKEPROP VMLISP::GREATERP
-	 VMLISP::REROOT VMLISP::DIG2FIX VMLISP::L-CASE
-	 VMLISP::TEREAD VMLISP::QSREMAINDER VMLISP::$FINDFILE
-	 VMLISP::EQQ VMLISP::PRETTYPRINT VMLISP::HASHEQ VMLISP::LOG2
-	 VMLISP::U-CASE VMLISP::NREMOVE VMLISP::QREFELT VMLISP::SIZE
-	 VMLISP::EOFP VMLISP::QCDAAR VMLISP::RSHUT VMLISP::ADD1
-	 VMLISP::QMEMQ VMLISP::SUBSTRING VMLISP::LOADVOL
-	 VMLISP::QSTIMES VMLISP::STRINGLENGTH VMLISP::NEXT
-	 VMLISP::DEVICE VMLISP::MAPELT VMLISP::LENGTHOFBPI
-	 VMLISP::DIGITP VMLISP::QLENGTH VMLISP::QCAAADR VMLISP::CVEC
-	 VMLISP::VEC2LIST VMLISP::MODE VMLISP::MAKE-VEC VMLISP::GCMSG
-	 VMLISP::CONCAT VMLISP::$SHOWLINE VMLISP::QCAADR VMLISP::QCDDAR
-	 VMLISP::QCDAAAR VMLISP::RDROPITEMS VMLISP::VECP
-	 VMLISP::|union| VMLISP::ONE-OF VMLISP::NULLOUTSTREAM
-	 VMLISP::QSGREATERP VMLISP::MINUS VMLISP::MAXINDEX
-	 VMLISP::GETSTR VMLISP::QCADADR VMLISP::PRIN2CVEC
-	 VMLISP::CURRENTTIME VMLISP::$REPLACE VMLISP::UNIONQ
-	 VMLISP::NREMOVEQ VMLISP::CURINSTREAM VMLISP::MAKE-OUTSTREAM
-	 VMLISP::APPLX VMLISP::LASTNODE VMLISP::SUBSTQ VMLISP::TRUEFN
-	 VMLISP::|last| VMLISP::RPLACSTR VMLISP::SETQP VMLISP::QCADDR
-	 VMLISP::QCAADAR VMLISP::QCDDAAR VMLISP::|intersection|
-	 VMLISP::HASHTABLE-CLASS VMLISP::$CURRENT-DIRECTORY
-	 VMLISP::*COMP370-APPLY* VMLISP::QSETVELT VMLISP::MOVEVEC
-	 VMLISP::ID VMLISP::DEFINE-FUNCTION VMLISP::MSUBSTQ VMLISP::|nsubst|
-	 VMLISP::LISTOFFLUIDS VMLISP::SUB1 VMLISP::NUMBEROFARGS
-	 VMLISP::VMREAD VMLISP::SMINTP VMLISP::$SCREENSIZE
-	 VMLISP::LISTOFFREES VMLISP::QCDADDR VMLISP::COMPRREAD
-	 VMLISP::GENSYMP VMLISP::IFCAR VMLISP::QSETQ
-	 VMLISP::QCADDAR VMLISP::*LISP-SOURCE-FILETYPE* VMLISP::KOMPILE
-	 VMLISP::INPUT VMLISP::PAPPP VMLISP::UEQUAL VMLISP::COMPRWRITE
-	 VMLISP::SUBRP VMLISP::ASSEMBLE VMLISP::|LAM,EVALANDFILEACTQ|
-	 VMLISP::|$msgDatabaseName| VMLISP::IFCDR VMLISP::QVMAXINDEX
-	 VMLISP::$SPADROOT VMLISP::PRIN0 VMLISP::PRETTYPRIN0
-	 VMLISP::STACKLIFO VMLISP::ASSQ VMLISP::PRINTEXP
-	 VMLISP::QCDDDDR VMLISP::QSADD1
-	 VMLISP::SETDIFFERENCEQ VMLISP::STRPOS VMLISP::CONSTANT
-	 VMLISP::QCAAR VMLISP::HCOUNT VMLISP::RCOPYITEMS
-	 VMLISP::QSMINUS VMLISP::EVA1 VMLISP::OPTIONLIST
-	 VMLISP::NUM2CHAR VMLISP::QENUM VMLISP::QEQQ
-	 VMLISP::$TOTAL-GC-TIME VMLISP::CHARP VMLISP::QCADR
-	 VMLISP::INTERSECTIONQ VMLISP::DSETQ VMLISP::FETCHCHAR
-	 VMLISP::STRCONC VMLISP::MACRO-MISSINGARGS VMLISP::RPACKFILE
-	 VMLISP::EXIT VMLISP::PLUS VMLISP::RKEYIDS
-	 VMLISP::COMPILE-LIB-FILE VMLISP::RECOMPILE-LIB-FILE-IF-NECESSARY))
-
-;;; Definitions for package BOOT of type SHADOW
-(lisp:in-package "BOOT")
-(lisp:shadow '(BOOT::MAP))
-(lisp:import
-    '(VMLISP::ERROROUTSTREAM LISP:COUNT VMLISP::NE VMLISP::FLUID
-	 LISP:SEQUENCE VMLISP::OBEY LISP::NUMBER VMLISP::|union|
-	 LISP:STEP VMLISP::OPTIONLIST VMLISP::EXIT VMLISP::LEXGREATERP))
-(lisp:import '(vmlisp::make-input-filename))
-(lisp:import '(vmlisp::libstream-dirname))
-(lisp:import '(user::spad-save))
-(lisp:import '(vmlisp::eqcar))
-(lisp:export '(boot::eqcar))
-
-;;; Definitions for package VMLISP of type SHADOW
-(lisp:in-package "VMLISP")
-(lisp:import '(SYSTEM::DEFINE-MACRO SYSTEM::MEMQ SYSTEM::PNAME))
-
-
-(in-package "BOOT") ;; Used to be "UNCOMMON"
-
-(export '(
-	;; !! ;;; Passed on from the Lisp package
-	;; !! + * -
-
-	;;;; Operating system interface
-	|OsRunProgram| |OsRunProgramToStream| |OsProcessNumber|
-	|OsEnvGet|     |OsEnvVarCharacter|    |OsExpandString|
-
-	;;;; Time
-	|TimeStampString|
-
-	;;;; Lisp Interface
-	|LispKeyword|
-	|LispReadFromString| |LispEval|
-	|LispCompile| |LispCompileFile| |LispCompileFileQuietlyToObject|
-	|LispLoadFile| |LispLoadFileQuietly|
-
-	;;; Control
-	|funcall| |Catch| |Throw| |UnwindProtect| |CatchAsCan|
-
-	;;; General
-	|Eq| |Nil| |DeepCopy| |Sort| |SortInPlace|
-
-	|genRemoveDuplicates| |genMember|
-	|gobSharedExcluding| |gobSharedParts| |gobAlwaysShared?|
-	|gobPretty| |gobSexpr|
-
-	;;; Streams
-	|Prompt| |PlainError| |PrettyPrint| |PlainPrint| |PlainPrintOn|
-	|WithOpenStream|
-	|WriteLispExpr| |WriteByte| |WriteChar| |WriteLine| |WriteString|
-	|ReadLispExpr| |ReadByte| |ReadChar| |ReadLine|
-	|ByteFileWriteLine| |ByteFileReadLine|
-	|ReadLineIntoString| |ByteFileReadLineIntoString| |ReadBytesIntoVector|
-	|StreamCopyChars| |StreamCopyBytes|
-	|InputStream?| |OutputStream?|
-	|StreamSize| |StreamGetPosition| |StreamSetPosition|
-	|StreamEnd?| |StreamFlush| |StreamClose|
-
-	|FileLine| |StreamLine|
-
-	;;; Pathnames
-	|TempFileDirectory| |LispFileType| |FaslFileType|
-	|ToPathname| |Pathname| |NewPathname| |SessionPathname|
-	|PathnameDirectory| |PathnameName| |PathnameType|
-	|PathnameString| |PathnameAbsolute?|
-	|PathnameWithType| |PathnameWithDirectory|
-	|PathnameWithoutType| |PathnameWithoutDirectory|
-
-	|PathnameToUsualCase| |PathnameWithinDirectory|
-	|PathnameDirectoryOfDirectoryPathname| |PathnameWithinOsEnvVar|
-
-	;;; Symbols
-	|MakeSymbol| |Symbol?| |SymbolString|
-
-	;;; Bits
-	|Bit| |Bit?| |TrueBit| |FalseBit| |BitOn?| |BitOr|
-
-	;;; General Sequences
-	;; !! ;;; Passed on from the Lisp package
-	;; !! ELT SETELT
-	;; SIZE
-
-	;;; Vectors
-	|FullVector| |Vector?|
-
-	;;; Bit Vectors
-	|FullBvec|
-
-	;;; Characters
-	|char| |Char| |Char?|
-	|CharCode| |CharGreater?| |CharDigit?|
-	|SpaceChar| |NewlineChar|
-
-	;;; Character Sets
-	|Cset| |CsetMember?|
-	|CsetUnion| |CsetComplement| |CsetString|
-	|NumericCset| |LowerCaseCset| |UpperCaseCset| |WhiteSpaceCset|
-	|AlphaCset| |AlphaNumericCset|
-
-	;;; Character Strings
-	|FullString| |ToString| |StringImage| |String?|
-	|StringGetCode| |StringConcat|
-	|StringLength| |StringFromTo| |StringFromToEnd| |StringFromLong|
-	|StringGreater?| |StringPrefix?| |StringUpperCase| |StringLowerCase|
-	|StringToInteger|  |StringToFloat|
-	|StringWords|	   |StringTrim|
-	|StringPositionOf| |StringPositionOfNot|
-	|UnescapeString|   |ExpandVariablesInString|
-
-	;;; Numbers
-	|Number?| |Integer?| |SmallInteger?| |Float?| |DoublePrecision|
-	|Odd?| |Remainder|
-	|Abs| |Min| |Max|
-	|Exp| |Ln| |Log10|
-	|Sin| |Cos| |Tan| |Cotan| |Arctan|
-
-	;;; Pairs
-	|Pair?|
-
-	|car|	    |cdr|
-	|caar|	    |cadr|	|cdar|	    |cddr|
-	|caaar|	    |caadr|	|cadar|	    |caddr|
-	|cdaar|	    |cdadr|	|cddar|	    |cdddr|
-	|FastCar|   |FastCdr|
-	|FastCaar|  |FastCadr|	|FastCdar|  |FastCddr|
-	|FastCaaar| |FastCaadr| |FastCadar| |FastCaddr|
-	|FastCdaar| |FastCdadr| |FastCddar| |FastCdddr|
-	|IfCar|	    |IfCdr|
-	|EqCar|	    |EqCdr|
-
-	;;; Lists
-	|length1?| |second|
-
-	|ListIsLength?| |ListMemberQ?| |ListMember?|
-	|ListRemoveQ| |ListNRemoveQ| |ListRemoveDuplicatesQ| |ListNReverse|
-	|ListUnion| |ListUnionQ| |ListIntersection| |ListIntersectionQ|
-	|ListAdjoin| |ListAdjoinQ|
-
-	;;; Association lists
-	|AlistAssoc| |AlistRemove|
-	|AlistAssocQ| |AlistRemoveQ| |AlistAdjoinQ| |AlistUnionQ|
-
-	;;; Tables
-	|Table?|
-	|TableCount| |TableGet| |TableSet| |TableUnset| |TableKeys|
-))
-
-(in-package "BOOT")
-(lisp:export '(boot::ncloop boot::ncrecover))
-(lisp:import '(vmlisp::make-input-filename vmlisp::is-console))
-;; (lisp:import '(boot::|openServer|))
-;; (lisp:import '(boot::|sockGetInt|))
-;; (lisp:import '(boot::|sockSendInt|))
-;; (lisp:import '(boot::|sockGetInts|))
-;; (lisp:import '(boot::|sockSendInts|))
-;; (lisp:import '(boot::|sockGetString|))
-;; (lisp:import '(boot::|sockSendString|))
-;; (lisp:import '(boot::|sockGetFloat|))
-;; (lisp:import '(boot::|sockSendFloat|))
-;; (lisp:import '(boot::|sockGetFloats|))
-;; (lisp:import '(boot::|sockSendFloats|))
-;; (lisp:import '(boot::|sockSendWakeup|))
-;; (lisp:import '(boot::|sockSendSignal|))
-(lisp:import '(vmlisp::qsdifference))
-(lisp:import '(vmlisp::qsminusp))
-(lisp:import '(vmlisp::qsplus))
-(lisp:import '(vmlisp::absval))
-(lisp:import '(vmlisp::cgreaterp))
-(lisp:import '(vmlisp::char2num))
-(lisp:import '(vmlisp::charp))
-(lisp:import '(vmlisp::concat))
-(lisp:import '(vmlisp::copy))
-(lisp:import '(vmlisp::difference))
-(lisp:import '(vmlisp::digitp))
-(lisp:import '(vmlisp::divide))
-(lisp:import '(vmlisp::eqcar))
-(lisp:import '(vmlisp::fixp))
-(lisp:import '(vmlisp::greaterp))
-(lisp:import '(vmlisp::hasheq))
-(lisp:import '(vmlisp::hput))
-(lisp:import '(vmlisp::hrem))
-(lisp:import '(vmlisp::identp))
-(lisp:import '(vmlisp::lessp))
-(lisp:import '(vmlisp::ln))
-(lisp:import '(vmlisp::make-cvec))
-(lisp:import '(vmlisp::make-full-cvec))
-(lisp:import '(vmlisp::make-vec))
-#-(or :lispm :lucid) (lisp:import '(vmlisp::memq))
-#+(and :lucid (not :ibm/370)) (lisp:import '(system:memq))
-(lisp:import '(vmlisp::movevec))
-(lisp:import '(vmlisp::pname))
-(lisp:import '(vmlisp::prettyprin0))
-(lisp:import '(vmlisp::prettyprint))
-(lisp:import '(vmlisp::printexp))
-(lisp:import '(vmlisp::qassq))
-(lisp:import '(vmlisp::qcar))
-(lisp:import '(vmlisp::qcdr))
-(lisp:import '(vmlisp::qcaar))
-(lisp:import '(vmlisp::qcadr))
-(lisp:import '(vmlisp::qcdar))
-(lisp:import '(vmlisp::qcddr))
-(lisp:import '(vmlisp::qcaaar))
-(lisp:import '(vmlisp::qcaadr))
-(lisp:import '(vmlisp::qcadar))
-(lisp:import '(vmlisp::qcaddr))
-(lisp:import '(vmlisp::qcdaar))
-(lisp:import '(vmlisp::qcdadr))
-(lisp:import '(vmlisp::qcddar))
-(lisp:import '(vmlisp::qcdddr))
-(lisp:import '(vmlisp::qcaaaar))
-(lisp:import '(vmlisp::qcaaadr))
-(lisp:import '(vmlisp::qcaadar))
-(lisp:import '(vmlisp::qcaaddr))
-(lisp:import '(vmlisp::qcadaar))
-(lisp:import '(vmlisp::qcadadr))
-(lisp:import '(vmlisp::qcaddar))
-(lisp:import '(vmlisp::qcadddr))
-(lisp:import '(vmlisp::qcdaaar))
-(lisp:import '(vmlisp::qcdaadr))
-(lisp:import '(vmlisp::qcdadar))
-(lisp:import '(vmlisp::qcdaddr))
-(lisp:import '(vmlisp::qcddaar))
-(lisp:import '(vmlisp::qcddadr))
-(lisp:import '(vmlisp::qcdddar))
-(lisp:import '(vmlisp::qcddddr))
-(lisp:import '(vmlisp::qcsize))
-(lisp:import '(vmlisp::qenum))
-(lisp:import '(vmlisp::qeset))
-(lisp:import '(vmlisp::qlength))
-(lisp:import '(vmlisp::qmemq))
-(lisp:import '(vmlisp::qsadd1))
-(lisp:import '(vmlisp::qslessp))
-(lisp:import '(vmlisp::qsdec1))
-(lisp:import '(vmlisp::qsetvelt))
-(lisp:import '(vmlisp::qsgreaterp))
-(lisp:import '(vmlisp::qsinc1))
-(lisp:import '(vmlisp::qsmax))
-(lisp:import '(vmlisp::qsmin))
-(lisp:import '(vmlisp::qsoddp))
-(lisp:import '(vmlisp::qsquotient))
-(lisp:import '(vmlisp::qsremainder))
-(lisp:import '(vmlisp::qssub1))
-(lisp:import '(vmlisp::qstimes))
-(lisp:import '(vmlisp::qszerop))
-(lisp:import '(vmlisp::qszerop))
-(lisp:import '(vmlisp::qvelt))
-(lisp:import '(vmlisp::qvsize))
-(lisp:import '(vmlisp::setandfileq))
-(lisp:import '(vmlisp::sintp))
-(lisp:import '(vmlisp::size))
-(lisp:import '(vmlisp::stringimage))
-(lisp:import '(vmlisp::strpos))
-(lisp:import '(vmlisp::strposl))
-(lisp:import '(vmlisp::substring))
-;; (lisp:import '(boot::|error|))
-(lisp:import '(vmlisp::ivecp))
-(lisp:import '(vmlisp::rvecp))
-(lisp:import '(vmlisp::dig2fix))
-(lisp:import '(vmlisp::rnump))
-(lisp:import '(vmlisp::fix))
-(lisp:import '(vmlisp::sortgreaterp))
-(lisp:import '(vmlisp::qsort))
-(lisp:import '(vmlisp::sortby))
-(lisp:import '(vmlisp::make-instream))
-(lisp:import '(vmlisp::list2vec))
-(lisp:import '(vmlisp::vec2list))
-(lisp:import '(vmlisp::sub1))
-(lisp:import '(vmlisp::add1))
-(lisp:import '(vmlisp::neq))
-(lisp:import '(vmlisp::hashtable-class))
-(lisp:import '(vmlisp::maxindex))
-;; (lisp:import '(boot::remdup))
-(lisp:import '(vmlisp::upcase))
-(lisp:import '(vmlisp::downcase))
-(lisp:import '(vmlisp::vecp))
-(lisp:import '(vmlisp::strconc))
-(lisp:import '(vmlisp::defiostream))
-(lisp:import '(vmlisp::shut))
-(lisp:import '(vmlisp::prin2cvec))
-;; (lisp:import '(boot::lasttail))
-;; (lisp:import '(boot::lastpair))
-;; (lisp:import '(boot::lastatom))
-;; (lisp:import '(boot::|last|))
-(lisp:import '(vmlisp::ncons))
-(lisp:import '(vmlisp::rplpair))
-(lisp:import '(vmlisp::nump))
-(lisp:import '(vmlisp::intp))
-(lisp:import '(vmlisp::makeprop))
-(lisp:import '(vmlisp::ifcar))
-(lisp:import '(vmlisp::ifcdr))
-(lisp:import '(vmlisp::quotient))
-(lisp:import '(vmlisp::remainder))
-(lisp:import '(vmlisp::make-hashtable))
-(lisp:import '(vmlisp::hget))
-(lisp:import '(vmlisp::hkeys))
-(lisp:import '(vmlisp::$infilep))
-(lisp:import '(vmlisp::$findfile))
-(lisp:import '(vmlisp::pairp))
-(lisp:import '(vmlisp::cvec))
-(lisp:import '(vmlisp::uequal))
-(lisp:import '(vmlisp::id))
-(lisp:import '(vmlisp::vec-setelt))
-(lisp:import '(vmlisp::make-bvec))
-;; (lisp:import '(boot::bvec-make-full))
-;; (lisp:import '(boot::bvec-setelt))
-(lisp:import '(vmlisp::|shoeread-line|))
-(lisp:import '(vmlisp::|shoeInputFile|))
-(lisp:import '(vmlisp::|shoeConsole|))
-(lisp:import '(vmlisp::|startsId?|))
-(lisp:import '(vmlisp::|idChar?|))
-(lisp:import '(vmlisp::|npPC|))
-(lisp:import '(vmlisp::|npPP|))
-;; (lisp:import '(boot::mkprompt))
-;; (lisp:import '(boot::|fillerSpaces|))
-;; (lisp:import '(boot::|sayString|))
-;; (lisp:import '(boot::help))
-;; (lisp:import '(boot::|version|))
-;; (lisp:import '(boot::|pp|))
-;; (lisp:import '(boot::$dalymode))
-
-(lisp:import 'boot::$IEEE)
-
-(in-package "FOAM")
+(defpackage "FOAM-USER"
+  (:use "FOAM" #.+standard-lisp-package+))
 
-(lisp:export '(
-FOAM::|printDFloat|
-FOAM::|printSFloat|
-FOAM::|printBInt|
-FOAM::|printSInt|
-FOAM::|printString|
-FOAM::|printChar|
-FOAM::|printNewLine|
-FOAM::|MakeLit|
-FOAM::|EnvNext|
-FOAM::|EnvLevel|
-FOAM::|MakeEnv|
-FOAM::|RElt|
-FOAM::|RNew|
-FOAM::|DDecl|
-FOAM::|ClosFun|
-FOAM::|ClosEnv|
-FOAM::|CCall|
-FOAM::|ArrToBInt|
-FOAM::|ArrToSInt|
-FOAM::|ArrToDFlo|
-FOAM::|ArrToSFlo|
-FOAM::|BIntToDFlo|
-FOAM::|BIntToSFlo|
-FOAM::|SIntToDFlo|
-FOAM::|SIntToSFlo|
-FOAM::|BIntToSInt|
-FOAM::|SIntToBInt|
-FOAM::|BitToSInt|
-FOAM::|ScanBInt|
-FOAM::|ScanSInt|
-FOAM::|ScanDFlo|
-FOAM::|ScanSFlo|
-FOAM::|FormatBInt|
-FOAM::|FormatSInt|
-FOAM::|FormatDFlo|
-FOAM::|FormatSFlo|
-FOAM::|PtrEQ|
-FOAM::|PtrIsNil|
-FOAM::|PtrNil|
-FOAM::|BIntBit|
-FOAM::|BIntShift|
-FOAM::|BIntLength|
-FOAM::|BIntPower|
-FOAM::|BIntGcd|
-FOAM::|BIntDivide|
-FOAM::|BIntRem|
-FOAM::|BIntQuo|
-FOAM::|BIntMod|
-FOAM::|BIntTimes|
-FOAM::|BIntMinus|
-FOAM::|BIntPlus|
-FOAM::|BIntInc|
-FOAM::|BIntDec|
-FOAM::|BIntAbs|
-FOAM::|BIntNegate|
-FOAM::|BIntNE|
-FOAM::|BIntGT|
-FOAM::|BIntEQ|
-FOAM::|BIntLE|
-FOAM::|BIntIsSmall|
-FOAM::|BIntIsOdd|
-FOAM::|BIntIsEven|
-FOAM::|BIntIsPos|
-FOAM::|BIntIsNeg|
-FOAM::|BIntIsZero|
-FOAM::|BInt1|
-FOAM::|BInt0|
-FOAM::|SIntOr|
-FOAM::|SIntAnd|
-FOAM::|SIntNot|
-FOAM::|SIntBit|
-FOAM::|SIntShift|
-FOAM::|SIntLength|
-FOAM::|SIntTimesMod|
-FOAM::|SIntMinusMod|
-FOAM::|SIntPlusMod|
-FOAM::|SIntPower|
-FOAM::|SIntGcd|
-FOAM::|SIntDivide|
-FOAM::|SIntRem|
-FOAM::|SIntQuo|
-FOAM::|SIntMod|
-FOAM::|SIntTimes|
-FOAM::|SIntMinus|
-FOAM::|SIntPlus|
-FOAM::|SIntInc|
-FOAM::|SIntDec|
-FOAM::|SIntNegate|
-FOAM::|SIntNE|
-FOAM::|SIntGT|
-FOAM::|SIntEQ|
-FOAM::|SIntLE|
-FOAM::|SIntIsOdd|
-FOAM::|SIntIsEven|
-FOAM::|SIntIsPos|
-FOAM::|SIntIsNeg|
-FOAM::|SIntIsZero|
-FOAM::|SIntMax|
-FOAM::|SIntMin|
-FOAM::|SInt1|
-FOAM::|SInt0|
-FOAM::|HIntMax|
-FOAM::|HIntMin|
-FOAM::|HInt1|
-FOAM::|HInt0|
-FOAM::|ByteMax|
-FOAM::|ByteMin|
-FOAM::|Byte1|
-FOAM::|Byte0|
-FOAM::|DFloCeiling|
-FOAM::|DFloFloor|
-FOAM::|DFloTruncate|
-FOAM::|DFloRound|
-FOAM::|DFloIPower|
-FOAM::|DFloPower|
-FOAM::|DFloDivide|
-FOAM::|DFloTimes|
-FOAM::|DFloMinus|
-FOAM::|DFloPlus|
-FOAM::|DFloNegate|
-FOAM::OTHER-FORM
-FOAM::|DFloNE|
-FOAM::|DFloGT|
-FOAM::|DFloEQ|
-FOAM::|DFloLE|
-FOAM::|DFloIsPos|
-FOAM::|DFloIsNeg|
-FOAM::|DFloIsZero|
-FOAM::|DFloEpsilon|
-FOAM::|DFloMax|
-FOAM::|DFloMin|
-FOAM::|DFlo1|
-FOAM::|DFlo0|
-FOAM::|SFloCeiling|
-FOAM::|SFloFloor|
-FOAM::|SFloTruncate|
-FOAM::|SFloRound|
-FOAM::|SFloIPower|
-FOAM::|SFloPower|
-FOAM::|SFloDivide|
-FOAM::|SFloTimes|
-FOAM::|SFloMinus|
-FOAM::|SFloPlus|
-FOAM::|SFloNegate|
-FOAM::|SFloNE|
-FOAM::|SFloGT|
-FOAM::|SFloEQ|
-FOAM::|SFloLE|
-FOAM::|SFloIsPos|
-FOAM::|SFloIsNeg|
-FOAM::|SFloIsZero|
-FOAM::|SFloEpsilon|
-FOAM::|SFloMax|
-FOAM::|SFloMin|
-FOAM::|SFlo1|
-FOAM::|SFlo0|
-FOAM::|CharNum|
-FOAM::|CharOrd|
-FOAM::|CharUpper|
-FOAM::|CharLower|
-FOAM::|CharNE|
-FOAM::|CharGT|
-FOAM::|CharEQ|
-FOAM::|CharLE|
-FOAM::|CharIsLetter|
-FOAM::|CharIsDigit|
-FOAM::|CharMax|
-FOAM::|CharMin|
-FOAM::|CharNewline|
-FOAM::|CharSpace|
-FOAM::|BitNE|
-FOAM::|BitEQ|
-FOAM::|BitOr|
-FOAM::|BitAnd|
-FOAM::|BitNot|
-FOAM::|BitTrue|
-FOAM::|BitFalse|
-FOAM::|Clos|
-FOAM::COMPILE-AS-FILE
-FOAM::|FormatNumber|
-FOAM::AXIOMXL-GLOBAL-NAME
-FOAM::AXIOMXL-FILE-INIT-NAME
-FOAM::|BIntPrev|
-FOAM::|BIntLT|
-FOAM::|BIntIsSingle|
-FOAM::|SIntShiftDn|
-FOAM::|SIntShiftUp|
-FOAM::|SIntTimesPlus|
-FOAM::|SIntNext|
-FOAM::|SIntPrev|
-FOAM::|SIntLT|
-FOAM::|DFloAssemble|
-FOAM::|DFloDissemble|
-FOAM::|DFloRDivide|
-FOAM::|DFloRTimesPlus|
-FOAM::|DFloRTimes|
-FOAM::|DFloRMinus|
-FOAM::|DFloRPlus|
-FOAM::|DFloTimesPlus|
-FOAM::|DFloNext|
-FOAM::|DFloPrev|
-FOAM::|DFloLT|
-FOAM::|SFloAssemble|
-FOAM::|fiStrHash|
-FOAM::|SFloDissemble|
-FOAM::|SFloRDivide|
-FOAM::|SFloRTimesPlus|
-FOAM::|SFloRTimes|
-FOAM::|fiGetDebugger|
-FOAM::|SFloRMinus|
-FOAM::|fiSetDebugger|
-FOAM::|SFloRPlus|
-FOAM::|SFloTimesPlus|
-FOAM::|fiGetDebugVar|
-FOAM::|SFloNext|
-FOAM::|fiSetDebugVar|
-FOAM::|SFloPrev|
-FOAM::|atan2|
-FOAM::|SFloLT|
-FOAM::|atan|
-FOAM::|acos|
-FOAM::|CharLT|
-FOAM::|asin|
-FOAM::|BoolNE|
-FOAM::|tanh|
-FOAM::|BoolEQ|
-FOAM::|cosh|
-FOAM::|BoolOr|
-FOAM::|sinh|
-FOAM::|BoolAnd|
-FOAM::|tan|
-FOAM::|BoolNot|
-FOAM::|cos|
-FOAM::|sin|
-FOAM::|BoolTrue|
-FOAM::|exp|
-FOAM::|BoolFalse|
-FOAM::|log|
-FOAM::|pow|
-FOAM::|sqrt|
-FOAM::|fputs|
-FOAM::|fputc|
-FOAM::|stderrFile|
-FOAM::|stdoutFile|
-FOAM::|stdinFile|
-FOAM::|SetProgHashCode|
-FOAM::|ProgHashCode|
-FOAM::|formatDFloat|
-FOAM::|formatSFloat|
-FOAM::|formatBInt|
-FOAM::|formatSInt|
-FOAM::|strLength|
-FOAM::|MakeLevel|
-FOAM::|FoamEnvEnsure|
-FOAM::|SetEnvInfo|
-FOAM::|EnvInfo|
-FOAM::|SInt|
-FOAM::TYPED-LET
-FOAM::FILE-IMPORTS
-FOAM::FILE-EXPORTS
-FOAM::DEFSPECIALS
-FOAM::BLOCK-RETURN
-FOAM::CASES
-FOAM::IGNORE-VAR
-FOAM::DEFPROG
-FOAM::DECLARE-TYPE
-FOAM::DECLARE-PROG
-FOAM::|FoamFree|
-FOAM::|SetEElt|
-FOAM::|SetAElt|
-FOAM::|SetRElt|
-FOAM::|SetLex|
-FOAM::|Lex|
-FOAM::|AElt|
-FOAM::|EElt|
-FOAM::|ANew|
-FOAM::|SetClosFun|
-FOAM::|SetClosEnv|
-FOAM::|Halt|
-FOAM::|BoolToSInt|
-FOAM::|SIntToHInt|
-FOAM::|SIntToByte|
-FOAM::|ByteToSInt|
-FOAM::|fputss|
-FOAM::|fgetss|
-FOAM::|PtrNE|
-FOAM::|PtrMagicEQ|
-FOAM::|BIntShiftDn|
-FOAM::|BIntShiftUp|
-FOAM::|BIntBIPower|
-FOAM::|BIntSIPower|
-FOAM::|BIntTimesPlus|
-FOAM::|BIntNext|
-))
 @
 \section{License}
 <<license>>=
diff --git a/src/interp/topics.boot.pamphlet b/src/interp/topics.boot.pamphlet
index 6946bda..fce397e 100644
--- a/src/interp/topics.boot.pamphlet
+++ b/src/interp/topics.boot.pamphlet
@@ -86,7 +86,7 @@ mkTopicHashTable() ==                         --given $groupAssoc = ((extended .
     for item in items repeat 
       HPUT($defaultsHash,item,[kind,:HGET($defaultsHash,item)])
   $conTopicHash  := MAKE_-HASHTABLE 'EQL      --key is constructor name; value is
-  instream := OPEN '"topics.data"           
+  instream := OPEN '"../../int/algebra/topics.data"
   while not EOFP instream repeat
     line := READLINE instream
     while blankLine? line repeat line := READLINE instream
diff --git a/src/interp/unlisp.lisp.pamphlet b/src/interp/unlisp.lisp.pamphlet
index efd1e9d..894dad9 100644
--- a/src/interp/unlisp.lisp.pamphlet
+++ b/src/interp/unlisp.lisp.pamphlet
@@ -140,7 +140,7 @@ The following functions are provided:
 (defun c-to-lisp-string (ptr)
   (let (str len)
        (setq len (strlen ptr))
-       (setq str (make-array (list len) :element-type 'string-char))
+       (setq str (make-array (list len) :element-type 'standard-char))
        (sprintf str "%s" ptr)  ; Cannot use strcpy because it stops in a \0.
        str ))
 )
@@ -886,7 +886,7 @@ The following functions are provided:
 (defun |FullString| (size &optional (init #\Space))
   (make-array
    (list size)
-   :element-type 'string-char
+   :element-type 'standard-char
    :initial-element init ))
 
 (defun |ToString| (ob)
diff --git a/src/interp/util.lisp.pamphlet b/src/interp/util.lisp.pamphlet
index 85dac2f..d1881b9 100644
--- a/src/interp/util.lisp.pamphlet
+++ b/src/interp/util.lisp.pamphlet
@@ -45,7 +45,6 @@ loaded.
   (in-package "BOOT")
   (push :oldboot *features*)
   (mapcar #'load load-files)
-  (make-depsys lsp src int obj mnt sys)
   (initroot spad)
   #+:AKCL
   (init-memory-config :cons 1000 :fixnum 400 :symbol 1000 :package 16
diff --git a/src/interp/vmlisp.lisp.pamphlet b/src/interp/vmlisp.lisp.pamphlet
index 7247d7a..fe3cf7a 100644
--- a/src/interp/vmlisp.lisp.pamphlet
+++ b/src/interp/vmlisp.lisp.pamphlet
@@ -334,7 +334,7 @@ Contributed by Juergen Weiss.
 (defmacro maxindex (x)
  `(the fixnum (1- (the fixnum (length ,x)))))
 
-#-(or LispM Lucid :CCL)
+#-(or LispM Lucid :CCL :GCL)
 (defmacro memq (a b)
  `(member ,a ,b :test #'eq))
 
@@ -1186,7 +1186,7 @@ can be restored.
 
 (define-function 'strconc #'concat)
 
-(defun make-cvec (sint) (make-array sint :fill-pointer 0 :element-type 'string-char))
+(defun make-cvec (sint) (make-array sint :fill-pointer 0 :element-type 'standard-char))
 
 ;(define-function 'CVECP #'stringp)
 

--=-=-=

diff --git a/src/interp/daase.lisp.pamphlet b/src/interp/daase.lisp.pamphlet
index b3ff3c4..5254256 100644
--- a/src/interp/daase.lisp.pamphlet
+++ b/src/interp/daase.lisp.pamphlet
@@ -869,33 +869,21 @@ database.
     (values only dir noexpose)))
 
 (defun processDir (dirarg thisdir)
-   (let (allfiles skipasos)
-    (system:chdir (string dirarg))
-    (setq allfiles (directory "*.nrlib/*"))
-    (system:chdir thisdir)
-    (values
-     (mapcan #'(lambda (f)
-      (when (string-equal (pathname-type f) "kaf")
-        (list f)))
-      allfiles)
-     (mapcan #'(lambda (f)
-      (when (string= (pathname-type f) "asy")
-       (push (pathname-name f) skipasos)
-       (list (namestring f)))) allfiles)
-     (mapcan #'(lambda (f)
-      (when (and (string= (pathname-type f) "ao")
-	     (not (member (pathname-name f) skipasos :test #'string=)))
-       (list (namestring f))))
-     allfiles)
-     ;; At the moment we will only look for user.lib: others are taken care
-     ;; of by localasy and localnrlib.
-#+:CCL
-     (mapcan #'(lambda (f)
-      (when (and (string= (pathname-type f) "lib") (string= (pathname-name f) "user"))
-       (list (namestring f))))
-     allfiles)
-#-:CCL nil
-    )))
+  (unwind-protect
+       (progn
+         (system:chdir (string dirarg))
+         (let* ((index-files
+                 (directory (concatenate 'string "*.nrlib/" vmlisp:*index-filename*)))
+                (asy-files
+                 (directory "*.asy"))
+                (aso-files
+                 (let ((asy-names (mapcar #'pathname-name asy-files)))
+                   (mapcan (lambda (f)
+                             (unless (member (pathname-name f) asy-names :test #'equal)
+                               (list f)))
+                           (directory "*.ao")))))
+           (values index-files asy-files aso-files nil)))
+    (system:chdir thisdir)))
 
 (defun localdatabase (filelist options &optional (make-database? nil))
  "read a local filename and update the hash tables"
diff --git a/src/interp/i-syscmd.boot.pamphlet b/src/interp/i-syscmd.boot.pamphlet
index 3f3e57b..081be73 100644
--- a/src/interp/i-syscmd.boot.pamphlet
+++ b/src/interp/i-syscmd.boot.pamphlet
@@ -1277,12 +1277,15 @@ readSpad2Cmd l ==
     fullopt := selectOptionLC(opt,'(quiet test ifthere),'optionError)
     fullopt = 'ifthere => ifthere  := true
     fullopt = 'quiet   => quiet := true
-
-  ef := pathname _/EDITFILE
-  if pathnameTypeId(ef) = 'SPAD then
-    ef := makePathname(pathnameName ef,'"*",'"*")
+  ef := 
+    _/EDITFILE => pathname _/EDITFILE
+    NIL
+  ef := 
+     ef and pathnameTypeId(ef) = 'SPAD => 
+         makePathname(pathnameName ef,'"*",'"*")
+     pathname "."
   if l then
-    l := mergePathnames(pathname l,ef)
+     l := mergePathnames(pathname l,ef)
   else
     l := ef
   devFTs := '("input" "INPUT" "boot" "BOOT" "lisp" "LISP")
diff --git a/src/interp/sys-pkg.lisp.pamphlet b/src/interp/sys-pkg.lisp.pamphlet
index a880c5b..6ac6d4f 100644
--- a/src/interp/sys-pkg.lisp.pamphlet
+++ b/src/interp/sys-pkg.lisp.pamphlet
@@ -88,12 +88,12 @@ idioms from prior ports (like rdefiostream and fileactq)
    "$FILETYPE-TABLE" "$FINDFILE" "$INFILEP" "$LIBRARY-DIRECTORY-LIST" "$LISTFILE"
    "$OUTFILEP" "$REPLACE" "$SCREENSIZE" "$SHOWLINE" "$SPADROOT"
    "$TOTAL-ELAPSED-TIME" "$TOTAL-GC-TIME" "$defaultMsgDatabaseName"
-   "$msgDatabaseName" "*COMP370-APPLY*" "*FILEACTQ-APPLY*" "*LISP-BIN-FILETYPE*"
-   "*LISP-SOURCE-FILETYPE*" "ABSVAL" "ADD1" "ADDOPTIONS" "ALLOCATE" "APPLX" 
-   "ASSEMBLE" "ASSQ" "BFP" "BINTP" "BOOLEANP" "BPINAME" "BYE" "CALLBELOW" "CATCHALL"
-   "CGREATERP" "CHANGELENGTH" "CHAR2NUM" "CHARP" "CLINES" "CLOSEDFN" "COMP370"
-   "COMPILE-LIB-FILE" "COMPRREAD" "COMPRWRITE" "CONCAT" "CONSOLE" "CONSTANT"
-   "COPY" "CREATE-SBC" "CURINSTREAM" "CUROUTSTREAM" "CURRENTTIME" "CURRINDEX"
+   "$msgDatabaseName" "*COMP370-APPLY*" "*FILEACTQ-APPLY*" "*INDEX-FILENAME*"
+   "*LISP-BIN-FILETYPE*" "*LISP-SOURCE-FILETYPE*" "ABSVAL" "ADD1" "ADDOPTIONS" 
+   "ALLOCATE" "APPLX" "ASSEMBLE" "ASSQ" "BFP" "BINTP" "BOOLEANP" "BPINAME" "BYE" 
+   "CALLBELOW" "CATCHALL" "CGREATERP" "CHANGELENGTH" "CHAR2NUM" "CHARP" "CLINES" 
+   "CLOSEDFN" "COMP370" "COMPILE-LIB-FILE" "COMPRREAD" "COMPRWRITE" "CONCAT" "CONSOLE" 
+   "CONSTANT" "COPY" "CREATE-SBC" "CURINSTREAM" "CUROUTSTREAM" "CURRENTTIME" "CURRINDEX"
    "CVEC" "CVECP" "DCQ" "DEFENTRY" "DEFINE-FUNCTION" "DEFIOSTREAM" "DEVICE"
    "DIFFERENCE" "DIG2FIX" "DIGITP" "DIVIDE" "DOUBLE" "DOWNCASE" "DSETQ" "EBCDIC"
    "ECQ" "EFFACE" "EMBED" "EMBEDDED" "EOFP" "EQCAR" "EQQ" "EQSUBSTLIST"

--=-=-=

diff --git a/src/input/Makefile.pamphlet b/src/input/Makefile.pamphlet
index 6a2bc3a..11daff0 100644
--- a/src/input/Makefile.pamphlet
+++ b/src/input/Makefile.pamphlet
@@ -301,8 +301,8 @@ REGRES= algaggr.regress algbrbf.regress  algfacob.regress alist.regress  \
     cycles1.regress   cycles.regress   cyfactor.regress \
     danzwill.regress  decimal.regress  defintef.regress defintrf.regress \
     derham.regress    dfloat.regress   dhtri.regress    divisor.regress \
-    dmp.regress       dpol.regress     easter.regress   efi.regress \
-    eigen.regress     elemfun.regress  elemnum.regress  elfuts.regress \
+    dmp.regress       dpol.regress        efi.regress \
+    eigen.regress     elemfun.regress  elfuts.regress \
     elt.regress       eq.regress       eqtbl.regress    equation2.regress \
     equation.regress  evalex.regress   eval.regress     exdiff.regress \
     exint.regress     exit.regress     exlap.regress    exlimit.regress \
@@ -505,9 +505,9 @@ FILES= ${OUT}/algaggr.input  ${OUT}/algbrbf.input    ${OUT}/algfacob.input \
        ${OUT}/drawcfun.input ${OUT}/drawcurv.input \
        ${OUT}/draw.input     ${OUT}/drawcx.input     ${OUT}/drawex.input \
        ${OUT}/drawpoly.input ${OUT}/drawx.input    \
-       ${OUT}/easter.input   ${OUT}/efi.input        ${OUT}/egg.input      \
+       ${OUT}/efi.input        ${OUT}/egg.input      \
        ${OUT}/eigen.input \
-       ${OUT}/elemfun.input  ${OUT}/elemnum.input    ${OUT}/elfuts.input \
+       ${OUT}/elemfun.input  ${OUT}/elfuts.input \
        ${OUT}/elt.input \
        ${OUT}/eq.input       ${OUT}/eqtbl.input      ${OUT}/equation.input \
        ${OUT}/errortrap.input \
@@ -721,10 +721,10 @@ DOCFILES= \
   ${DOC}/e04fdf.input.dvi      ${DOC}/e04gcf.input.dvi     \
   ${DOC}/e04jaf.input.dvi      ${DOC}/e04mbf.input.dvi     \
   ${DOC}/e04naf.input.dvi      ${DOC}/e04ucf.input.dvi     \
-  ${DOC}/e04ycf.input.dvi      ${DOC}/easter.input.dvi     \
+  ${DOC}/e04ycf.input.dvi           \
   ${DOC}/ecfact.as.dvi         ${DOC}/efi.input.dvi        \
   ${DOC}/egg.input.dvi         ${DOC}/eigen.input.dvi      \
-  ${DOC}/elemfun.input.dvi     ${DOC}/elemnum.input.dvi    \
+  ${DOC}/elemfun.input.dvi      \
   ${DOC}/elfuts.input.dvi      ${DOC}/elt.input.dvi        \
   ${DOC}/eq.input.dvi          ${DOC}/eqtbl.input.dvi      \
   ${DOC}/equation2.input.dvi   ${DOC}/equation.input.dvi   \

--=-=-=--

\start
Date: Mon, 16 Jul 2007 22:26:42 -0500
From: Tim Daly
To: Stephen Wilson
Subject: hyperdoc

The hyperdoc error occurs occurs because ht.db is incorrect.
You can rebuild ht.db by changing to the hyper/pages directory
and typing

   htadd *.ht *.pht

\start
Date: 16 Jul 2007 23:50:54 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: gclcvs-2.7.0 sputc error

Camm,

Another slight problem.  Would appear compiler::sputc is not being
inlined to glibc's putc (if I am reading cmpnew/gcl_cmpopt.lsp and the
session below correctly).


==-- test.lisp -------
(defun doit (in out)
  (write-char (read-char in) out))

(defun test ()
  (with-input-from-string (in "TEST")
    (with-open-file (out "test.txt" :if-exists :error :direction :output)
      (doit in out))))
==--------------------


steve:tmp> gcl
GCL (GNU Common Lisp)  2.7.0 ANSI    Jul 16 2007 22:45:53
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

Temporary directory for compiler files set to /tmp/

>(si:use-fast-links nil)

NIL

>(load (compile-file "test.lisp"))

;; Compiling test.lisp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling test.o.
;; Loading /home/steve/tmp/test.o
 ;; start address -T 0xa63c80 ;; Finished loading /home/steve/tmp/test.o
1352

>(test)

Error: 
Signalled by DOIT.
Condition in DOIT [or a callee]: INTERNAL-SIMPLE-TYPE-ERROR: COMPILER::SPUTC is not of type FUNCTION: 

Broken at DOIT.  Type :H for Help.
 1 (Continue) Return to top level.
>>:bt

#0   DOIT {loc0=#<string-input stream  from "TEST">,loc1=#<output stream "test.txt">,loc2=...} [ihs=4]
#1   TEST {loc0=#<string-input stream  from "TEST">,loc1=#<output stream "test.txt">,loc2=...} [ihs=3]
#2   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function test>} [ihs=2]
>>(disassemble 'doit)

;; Compiling /tmp/gazonk_11505_0.lsp.
;; End of Pass 1.  
;; End of Pass 2.  
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_11505_0.o.

#include "gazonk_11505_0.h"
void init_code(){do_init((void *)VV);}
/*      local entry for function DOIT   */

static object LI1__DOIT___gazonk_11505_0(V3,V4)

object V3;object V4;
{        VMB1 VMS1 VMV1
        goto TTL;
TTL:;
        {object V5;
        base[0]= (V3);
        vs_top=(vs_base=base+0)+1;
        Lread_char();
        vs_top=sup;
        V5= ({register object _z=vs_base[0];_z;});
        if(!((type_of((V4))==t_stream? (((V4))->sm.sm_fp)!=0: 0 ))){
        goto T5;}
        (void)((VFUN_NARGS=2,(/* SPUTC */(*LnkLI0)((fixnum)0,(V5),(V4)))));
        goto T3;
        goto T5;
T5:;
        base[0]= (V5);
        base[1]= (V4);
        vs_top=(vs_base=base+0)+2;
        Lwrite_char();
        vs_top=sup;
        goto T3;
T3:;
        {object V6 = (V5);VMR1
        (V6);}}
        base[0]=base[0];
        return Cnil;
}
static object  LnkTLI0(object first,...){object V1;va_list ap;va_start(ap,first);V1=(object )call_vproc_new(((object)VV[0]),0,32,(void **)(void *)&LnkLI0,first,ap);va_end(ap);return V1;} /* SPUTC */
#(#(SPUTC
    (%INIT
     . #((LET ((*DISABLE-RECOMPILE* T))
           (MFSFUN 'DOIT 0 2 0)
           (ADD-HASH 'DOIT '((T T) T)
               '((SPUTC (*) *) (FP-OKP (*) *) (READ-CHAR (*) T)
                 (WRITE-CHAR (T *) T))
COMMON-LISP-USER
LISPLAMBD!
          IN!
             OU,DECLA,OPTIMIZ,SAFETY    ,BLOCK
                                              DOIT
,WRITE-CHAR     ,READ-CHAR-. '/tmp/gazonk_11505_0.lsp))
         (DO-RECOMPILE)))))
static object LI1__DOIT___gazonk_11505_0();
#define VMB1 register object *base=vs_top;
#define VMS1 register object *sup=vs_top+2;vs_top=sup;
#define VMV1 vs_check;
#define VMR1(VMT1) vs_top=base ; return(VMT1);
#define VM1 2
static void * VVi[2]={
#define Cdata VV[1]
(void *)(LI1__DOIT___gazonk_11505_0)
};
#define VV (VVi)
static object  LnkTLI0(object,...);
static object  (*LnkLI0)() = (object (*)()) LnkTLI0;

/tmp/gazonk_11505_0.o:     file format elf32-i386

Disassembly of section .text:

00000000 <init_code>:
   0:   68 00 00 00 00          push   $0x0
   5:   e8 fc ff ff ff          call   6 <init_code+0x6>
   a:   58                      pop    %eax
   b:   c3                      ret    

0000000c <LI1__DOIT___gazonk_11505_0>:
   c:   55                      push   %ebp
   d:   57                      push   %edi
   e:   56                      push   %esi
   f:   53                      push   %ebx
  10:   8b 1d 00 00 00 00       mov    0x0,%ebx
  16:   8d 7b 08                lea    0x8(%ebx),%edi
  19:   3b 3d 00 00 00 00       cmp    0x0,%edi
  1f:   8b 74 24 18             mov    0x18(%esp),%esi
  23:   89 3d 00 00 00 00       mov    %edi,0x0
  29:   72 05                   jb     30 <LI1__DOIT___gazonk_11505_0+0x24>
  2b:   e8 fc ff ff ff          call   2c <LI1__DOIT___gazonk_11505_0+0x20>
  30:   8b 44 24 14             mov    0x14(%esp),%eax
  34:   89 03                   mov    %eax,(%ebx)
  36:   8d 43 04                lea    0x4(%ebx),%eax
  39:   a3 00 00 00 00          mov    %eax,0x0
  3e:   89 1d 00 00 00 00       mov    %ebx,0x0
  44:   e8 fc ff ff ff          call   45 <LI1__DOIT___gazonk_11505_0+0x39>
  49:   a1 00 00 00 00          mov    0x0,%eax
  4e:   81 fe 00 00 00 00       cmp    $0x0,%esi
  54:   89 3d 00 00 00 00       mov    %edi,0x0
  5a:   8b 28                   mov    (%eax),%ebp
  5c:   74 39                   je     97 <LI1__DOIT___gazonk_11505_0+0x8b>
  5e:   81 fe ff ff ff bf       cmp    $0xbfffffff,%esi
  64:   77 31                   ja     97 <LI1__DOIT___gazonk_11505_0+0x8b>
  66:   f6 06 01                testb  $0x1,(%esi)
  69:   74 2c                   je     97 <LI1__DOIT___gazonk_11505_0+0x8b>
  6b:   81 3e ff ff ff bf       cmpl   $0xbfffffff,(%esi)
  71:   77 24                   ja     97 <LI1__DOIT___gazonk_11505_0+0x8b>
  73:   80 7e 01 11             cmpb   $0x11,0x1(%esi)
  77:   75 1e                   jne    97 <LI1__DOIT___gazonk_11505_0+0x8b>
  79:   83 7e 04 00             cmpl   $0x0,0x4(%esi)
  7d:   74 18                   je     97 <LI1__DOIT___gazonk_11505_0+0x8b>
  7f:   56                      push   %esi
  80:   55                      push   %ebp
  81:   6a 00                   push   $0x0
  83:   66 c7 05 04 00 00 00    movw   $0x2,0x4
  8a:   02 00 
  8c:   ff 15 08 00 00 00       call   *0x8
  92:   83 c4 0c                add    $0xc,%esp
  95:   eb 1e                   jmp    b5 <LI1__DOIT___gazonk_11505_0+0xa9>
  97:   8d 43 08                lea    0x8(%ebx),%eax
  9a:   89 2b                   mov    %ebp,(%ebx)
  9c:   89 73 04                mov    %esi,0x4(%ebx)
  9f:   89 1d 00 00 00 00       mov    %ebx,0x0
  a5:   a3 00 00 00 00          mov    %eax,0x0
  aa:   e8 fc ff ff ff          call   ab <LI1__DOIT___gazonk_11505_0+0x9f>
  af:   89 3d 00 00 00 00       mov    %edi,0x0
  b5:   89 1d 00 00 00 00       mov    %ebx,0x0
  bb:   5b                      pop    %ebx
  bc:   5e                      pop    %esi
  bd:   5f                      pop    %edi
  be:   89 e8                   mov    %ebp,%eax
  c0:   5d                      pop    %ebp
  c1:   c3                      ret    

000000c2 <LnkTLI0>:
  c2:   8d 44 24 08             lea    0x8(%esp),%eax
  c6:   50                      push   %eax
  c7:   ff 74 24 08             pushl  0x8(%esp)
  cb:   68 08 00 00 00          push   $0x8
  d0:   6a 20                   push   $0x20
  d2:   6a 00                   push   $0x0
  d4:   ff 35 00 00 00 00       pushl  0x0
  da:   e8 fc ff ff ff          call   db <LnkTLI0+0x19>
  df:   83 c4 18                add    $0x18,%esp
  e2:   c3                      ret    
NIL

\start
Date: 16 Jul 2007 23:58:56 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: hyperdoc

Tim Daly writes:

> The hyperdoc error occurs occurs because ht.db is incorrect.
> You can rebuild ht.db by changing to the hyper/pages directory
> and typing
> 
>    htadd *.ht *.pht

Excellent!  Thanks!

Perhaps this is an issue with my restarting the build several times while
working around the segfault issue.  I might ask you for more advice if
the problem persists after a make clean.

\start
Date: 17 Jul 2007 10:23:33 -0400
From: Camm Maguire
To: Stephen Wilson
Subject: Re: gclcvs-2.7.0 sputc error

Greetings, and thanks!  Should be fixed now.  At some point the io
functions need writing to take advantage of the new inlining
capability, so this is a bit of a temporary fix.

Take care,

Stephen Wilson writes:

> Camm,
> 
> Another slight problem.  Would appear compiler::sputc is not being
> inlined to glibc's putc (if I am reading cmpnew/gcl_cmpopt.lsp and the
> session below correctly).
> 
> 
> ==-- test.lisp -------
> (defun doit (in out)
>   (write-char (read-char in) out))
> 
> (defun test ()
>   (with-input-from-string (in "TEST")
>     (with-open-file (out "test.txt" :if-exists :error :direction :output)
>       (doit in out))))
> ==--------------------
> 
> 
> steve:tmp> gcl
> GCL (GNU Common Lisp)  2.7.0 ANSI    Jul 16 2007 22:45:53
> Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> 
> Temporary directory for compiler files set to /tmp/
> 
> >(si:use-fast-links nil)
> 
> NIL
> 
> >(load (compile-file "test.lisp"))
> 
> ;; Compiling test.lisp.
> ;; End of Pass 1.  
> ;; End of Pass 2.  
> ;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
> ;; Finished compiling test.o.
> ;; Loading /home/steve/tmp/test.o
>  ;; start address -T 0xa63c80 ;; Finished loading /home/steve/tmp/test.o
> 1352
> 
> >(test)
> 
> Error: 
> Signalled by DOIT.
> Condition in DOIT [or a callee]: INTERNAL-SIMPLE-TYPE-ERROR: COMPILER::SPUTC is not of type FUNCTION: 
> 
> Broken at DOIT.  Type :H for Help.
>  1 (Continue) Return to top level.
> >>:bt
> 
> #0   DOIT {loc0=#<string-input stream  from "TEST">,loc1=#<output stream "test.txt">,loc2=...} [ihs=4]
> #1   TEST {loc0=#<string-input stream  from "TEST">,loc1=#<output stream "test.txt">,loc2=...} [ihs=3]
> #2   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function test>} [ihs=2]
> >>(disassemble 'doit)
> 
> ;; Compiling /tmp/gazonk_11505_0.lsp.
> ;; End of Pass 1.  
> ;; End of Pass 2.  
> ;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
> ;; Finished compiling /tmp/gazonk_11505_0.o.
> 
> #include "gazonk_11505_0.h"
> void init_code(){do_init((void *)VV);}
> /*      local entry for function DOIT   */
> 
> static object LI1__DOIT___gazonk_11505_0(V3,V4)
> 
> object V3;object V4;
> {        VMB1 VMS1 VMV1
>         goto TTL;
> TTL:;
>         {object V5;
>         base[0]= (V3);
>         vs_top=(vs_base=base+0)+1;
>         Lread_char();
>         vs_top=sup;
>         V5= ({register object _z=vs_base[0];_z;});
>         if(!((type_of((V4))==t_stream? (((V4))->sm.sm_fp)!=0: 0 ))){
>         goto T5;}
>         (void)((VFUN_NARGS=2,(/* SPUTC */(*LnkLI0)((fixnum)0,(V5),(V4)))));
>         goto T3;
>         goto T5;
> T5:;
>         base[0]= (V5);
>         base[1]= (V4);
>         vs_top=(vs_base=base+0)+2;
>         Lwrite_char();
>         vs_top=sup;
>         goto T3;
> T3:;
>         {object V6 = (V5);VMR1
>         (V6);}}
>         base[0]=base[0];
>         return Cnil;
> }
> static object  LnkTLI0(object first,...){object V1;va_list ap;va_start(ap,first);V1=(object )call_vproc_new(((object)VV[0]),0,32,(void **)(void *)&LnkLI0,first,ap);va_end(ap);return V1;} /* SPUTC */
> #(#(SPUTC
>     (%INIT
>      . #((LET ((*DISABLE-RECOMPILE* T))
>            (MFSFUN 'DOIT 0 2 0)
>            (ADD-HASH 'DOIT '((T T) T)
>                '((SPUTC (*) *) (FP-OKP (*) *) (READ-CHAR (*) T)
>                  (WRITE-CHAR (T *) T))
> COMMON-LISP-USER
> LISPLAMBD!
>           IN!
>              OU,DECLA,OPTIMIZ,SAFETY    ,BLOCK
>                                               DOIT
> ,WRITE-CHAR     ,READ-CHAR-. '/tmp/gazonk_11505_0.lsp))
>          (DO-RECOMPILE)))))
> static object LI1__DOIT___gazonk_11505_0();
> #define VMB1 register object *base=vs_top;
> #define VMS1 register object *sup=vs_top+2;vs_top=sup;
> #define VMV1 vs_check;
> #define VMR1(VMT1) vs_top=base ; return(VMT1);
> #define VM1 2
> static void * VVi[2]={
> #define Cdata VV[1]
> (void *)(LI1__DOIT___gazonk_11505_0)
> };
> #define VV (VVi)
> static object  LnkTLI0(object,...);
> static object  (*LnkLI0)() = (object (*)()) LnkTLI0;
> 
> /tmp/gazonk_11505_0.o:     file format elf32-i386
> 
> Disassembly of section .text:
> 
> 00000000 <init_code>:
>    0:   68 00 00 00 00          push   $0x0
>    5:   e8 fc ff ff ff          call   6 <init_code+0x6>
>    a:   58                      pop    %eax
>    b:   c3                      ret    
> 
> 0000000c <LI1__DOIT___gazonk_11505_0>:
>    c:   55                      push   %ebp
>    d:   57                      push   %edi
>    e:   56                      push   %esi
>    f:   53                      push   %ebx
>   10:   8b 1d 00 00 00 00       mov    0x0,%ebx
>   16:   8d 7b 08                lea    0x8(%ebx),%edi
>   19:   3b 3d 00 00 00 00       cmp    0x0,%edi
>   1f:   8b 74 24 18             mov    0x18(%esp),%esi
>   23:   89 3d 00 00 00 00       mov    %edi,0x0
>   29:   72 05                   jb     30 <LI1__DOIT___gazonk_11505_0+0x24>
>   2b:   e8 fc ff ff ff          call   2c <LI1__DOIT___gazonk_11505_0+0x20>
>   30:   8b 44 24 14             mov    0x14(%esp),%eax
>   34:   89 03                   mov    %eax,(%ebx)
>   36:   8d 43 04                lea    0x4(%ebx),%eax
>   39:   a3 00 00 00 00          mov    %eax,0x0
>   3e:   89 1d 00 00 00 00       mov    %ebx,0x0
>   44:   e8 fc ff ff ff          call   45 <LI1__DOIT___gazonk_11505_0+0x39>
>   49:   a1 00 00 00 00          mov    0x0,%eax
>   4e:   81 fe 00 00 00 00       cmp    $0x0,%esi
>   54:   89 3d 00 00 00 00       mov    %edi,0x0
>   5a:   8b 28                   mov    (%eax),%ebp
>   5c:   74 39                   je     97 <LI1__DOIT___gazonk_11505_0+0x8b>
>   5e:   81 fe ff ff ff bf       cmp    $0xbfffffff,%esi
>   64:   77 31                   ja     97 <LI1__DOIT___gazonk_11505_0+0x8b>
>   66:   f6 06 01                testb  $0x1,(%esi)
>   69:   74 2c                   je     97 <LI1__DOIT___gazonk_11505_0+0x8b>
>   6b:   81 3e ff ff ff bf       cmpl   $0xbfffffff,(%esi)
>   71:   77 24                   ja     97 <LI1__DOIT___gazonk_11505_0+0x8b>
>   73:   80 7e 01 11             cmpb   $0x11,0x1(%esi)
>   77:   75 1e                   jne    97 <LI1__DOIT___gazonk_11505_0+0x8b>
>   79:   83 7e 04 00             cmpl   $0x0,0x4(%esi)
>   7d:   74 18                   je     97 <LI1__DOIT___gazonk_11505_0+0x8b>
>   7f:   56                      push   %esi
>   80:   55                      push   %ebp
>   81:   6a 00                   push   $0x0
>   83:   66 c7 05 04 00 00 00    movw   $0x2,0x4
>   8a:   02 00 
>   8c:   ff 15 08 00 00 00       call   *0x8
>   92:   83 c4 0c                add    $0xc,%esp
>   95:   eb 1e                   jmp    b5 <LI1__DOIT___gazonk_11505_0+0xa9>
>   97:   8d 43 08                lea    0x8(%ebx),%eax
>   9a:   89 2b                   mov    %ebp,(%ebx)
>   9c:   89 73 04                mov    %esi,0x4(%ebx)
>   9f:   89 1d 00 00 00 00       mov    %ebx,0x0
>   a5:   a3 00 00 00 00          mov    %eax,0x0
>   aa:   e8 fc ff ff ff          call   ab <LI1__DOIT___gazonk_11505_0+0x9f>
>   af:   89 3d 00 00 00 00       mov    %edi,0x0
>   b5:   89 1d 00 00 00 00       mov    %ebx,0x0
>   bb:   5b                      pop    %ebx
>   bc:   5e                      pop    %esi
>   bd:   5f                      pop    %edi
>   be:   89 e8                   mov    %ebp,%eax
>   c0:   5d                      pop    %ebp
>   c1:   c3                      ret    
> 
> 000000c2 <LnkTLI0>:
>   c2:   8d 44 24 08             lea    0x8(%esp),%eax
>   c6:   50                      push   %eax
>   c7:   ff 74 24 08             pushl  0x8(%esp)
>   cb:   68 08 00 00 00          push   $0x8
>   d0:   6a 20                   push   $0x20
>   d2:   6a 00                   push   $0x0
>   d4:   ff 35 00 00 00 00       pushl  0x0
>   da:   e8 fc ff ff ff          call   db <LnkTLI0+0x19>
>   df:   83 c4 18                add    $0x18,%esp
>   e2:   c3                      ret    
> NIL
> 

\start
Date: 17 Jul 2007 12:29:33 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Pamphlets and LaTex

Tim,

I have been trying to get a clear picture of the literate future for
Axiom.

I have been thinking about the pamphlet files as pure LaTeX, and have
some concerns.

The basic issue for me is loosing the weave step.  I believe that a
lisp based noweb replacement could make good use of such a stage.
Just like how a lisp based replacement could make use of the tangle
stage (by sorting the chunks and compiling the lisp/boot/spad code on
the fly, for example).

In noweb, we have the basic syntax that <<chunk>>= starts a block of
code, and @ starts a block of documentation.

On the documentation side, I think having @ as an escape character is
very important for long term goals.  It allows us to embed commands
and information at a meta level, without needing to rely on TeX macros
to communicate all the information we need somehow.  Similar to
CWEB. Of course we could scan the latex for individual items, but
latex is complex and it would be a very difficult task, I think, to
write a robust tool which copes with all the details well.

So, the simple noweb syntax we can extend for our own purposes and we
can manipulate the information contained therein directly using Axiom.
I think there is some real potential here which would be awkward to
achieve with latex only pamphlets.

In the latex only approach, I cannot find any gains in flexibility.

In short, I am advocating we stick with noweb syntax with a view
towards extending the capabilities as demanded by future needs.

Of course, I am still open to being convinced otherwise.

\start
Date: Tue, 17 Jul 2007 16:27:14 -0500
From: Tim Daly
To: Martin Rubey
Subject: votes

There are 97 people subscribed to the Axiom mailing list.
Please explain how you plan to garner 49 votes for anything.

\start
Date: Tue, 17 Jul 2007 16:32:54 -0500
From: Tim Daly
To: Martin Rubey
Subject: votes

In a model that encourages 97 branches (I have more than a dozen
locally) and any one branch can be the next Gold, how do you 
propose that a developer contribute a change? Where would they
contribute it to?

\start
Date: Tue, 17 Jul 2007 16:34:02 -0500
From: Tim Daly
To: Martin Rubey
Subject: votes

You've made the claim twice that the gclweb change broke code.
Please give an example of something that broke due to the gclweb change.

\start
Date: Tue, 17 Jul 2007 16:45:27 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Pamphlets and Latex

> I believe you already have a good idea of the concepts involved here.
> Your trying to do the same thing but using LaTeX syntax. That would
> be fine with me if it were not for the fat that it is not,
> conceptually, pure LaTeX.

Eh? Please explain what you could possibly mean. If I run latex on
a file and it generates a dvi file it cannot be anything but pure
latex. I'm unable to understand what that statement could mean.


> The distinct advantage here is that we are using a syntax which is 
> special to a pamphlet. 

<<name>>= <==> \begin{chunk}{name}
@         <==> \end{chunk}
<<name>>  <==> \chunk{name}

This is a bijection. It is entirely unambiguous. If it were not
against my religion I could write a sed script to make the change.
Pure syntax. Period.



> We need a weave stage and we need an 
> unambiguous notation which we can accurately parse and transform.

We do not need a weave step except where we plan to do things like
create hyperdoc pages from the latex file. Ordinary documentation,
like the published bookvol1 is pure, unwoven latex. 




> Using latex syntax is ambiguous. Thats the main advantage, but a big
> one with real technical advantages

Please explain why you think latex syntax is ambiguous.

\start
Date: 17 Jul 2007 23:46:12 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: votes

Tim Daly writes:

> There are 97 people subscribed to the Axiom mailing list.
> Please explain how you plan to garner 49 votes for anything.

It is quite OK to abstain.  I'd suggest to

* have no vote for trivial patches (fix typos, for example) or if nobody
  disagrees.

* have a short voting period for small and medium size patches.  Say, 24 or
  maybe 48 hours for the patch concerning the Taylor series powering.

* have longer voting period for large and huge patches. Say one week, or maybe
  10 days for voting on changing the build system to autotools, or to switch
  from autoconf to asdf.

A vote is triggered by anybody on axiom-developer saying: stop, I'd like to
vote.

If somebody says that a patch breaks this or that, this would be discussed
first.  Sometimes it will be possible to agree whether this or that was broken
before the patch and the patch only surfaced it, or whether this or that was
ok, but the patch breaks it.  Only if such an agreement is not found, a vote is
necessary.

Consensus remains most important, i.e., if a vote is not absolutely clear, it
may be better simply to start a new branch and keep it in sync.  subversion or
svk should make that quite easy.  (In any case, I'd like to reduce branching
and merging to an entirely technical, not emotional issue.)

Three remarks:

1) thanks for asking for clarification
2) interesting to know that there are already 97 subscribers.  I would have
   guessed fifty.
3) I'm open to discuss any other democratic system.  However, I would like to
   keep refereeing and voting two distinct processes.  Peer review is a great
   thing, but it's not a substitute for democracy.

\start
Date: 17 Jul 2007 23:56:57 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: votes

Tim Daly writes:

> In a model that encourages 97 branches (I have more than a dozen
> locally) and any one branch can be the next Gold, how do you 
> propose that a developer contribute a change? Where would they
> contribute it to?

To any branch she likes.  In fact, fortunately axiom is relatively modular,
contrary to most other CAS I know.  So, if I post a patch to axiom-developer,
it should be quite easy to adapt it to any branch, as long as branches do not
break this modularity.  If we go with the model I proposed on MathAction,
patches against trunk would be picked up "semi-automatically" by all others,
since "staying in sync with trunk within reason" is recommended for "community
driven branches" anyhow.  And the incentive to stay in sync with trunk is huge,
since otherwise it is quite unlikely that the branch will ever be merged into
trunk.

I didn't suggest that any branch could be next Gold, by the way.  Rather, in a
private mail, I wrote:

  I would, in fact, also agree to an even more drastic model, namely, that
  there is no trunk, but only Gold, and popular vote decides what's going to be
  next Gold.  That way one looses some stability, though.

\start
Date: 17 Jul 2007 18:09:37 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Pamphlets and Latex

Tim Daly writes:

> > I believe you already have a good idea of the concepts involved here.
> > Your trying to do the same thing but using LaTeX syntax. That would
> > be fine with me if it were not for the fat that it is not,
> > conceptually, pure LaTeX.
> 
> Eh? Please explain what you could possibly mean. If I run latex on
> a file and it generates a dvi file it cannot be anything but pure
> latex. I'm unable to understand what that statement could mean.

OK.  Lets assume for the purposes of this discussion that one type of
operation we wish to perform on a pamphlet is to find the set of
documentation chunks which relate to a particular domain.

The goal is to be able to type a command at the axiom prompt, or click
on a button, and have the relevant information organized and available
to the user.

Now in pure LaTeX, we can embed cross references, generate an index,
build a section hierarchies and create a particular view of the
information ideally suited to the reader of an article or book.  But
this is not what we want while sitting at the axiom prompt.

Now you could argue that we could scan the latex file and infer the
information from the markup therein.  This will fail as we would need
to write a full TeX parser to do that.

We could overload specific LaTeX markup which means one thing to LaTeX
and something completely different to a weave tool.  Im arguing that
that is bad design.

What we need is an unambiguous markup which has clear semantics and
that will allow us to do complex operations over a pamphlet.

We need to be able to represent a pamphlet in a file which a human can
edit.  We also need a representation in code which Axiom can manipulate.

LaTeX is one of many possible forms of output.  LaTeX does not live in
the same domain as pamphlets should.


> > The distinct advantage here is that we are using a syntax which is 
> > special to a pamphlet. 
> 
> <<name>>= <==> \begin{chunk}{name}
> @         <==> \end{chunk}
> <<name>>  <==> \chunk{name}
> 
> This is a bijection. It is entirely unambiguous. If it were not
> against my religion I could write a sed script to make the change.
> Pure syntax. Period.

Nope. <<name>>=  denotes a concept which a weave tool processes, can
manipulate in a copious number of different ways.

\begin{chunk}{name} denotes a construct useful to typeset a
document.

It just so happens that the semantics of the former permits the
syntactic substitution into the latter.

> > We need a weave stage and we need an 
> > unambiguous notation which we can accurately parse and transform.
> 
> We do not need a weave step except where we plan to do things like
> create hyperdoc pages from the latex file. Ordinary documentation,
> like the published bookvol1 is pure, unwoven latex. 

Right.  And that would be just be one simple output of the weave
stage.  Pamphlets are more than documentation!!  Pamphlets can, in
principle, produce several kinds of documents from the same source,
among other things, like executable code.  Thats not LaTeX.

> > Using latex syntax is ambiguous. Thats the main advantage, but a big
> > one with real technical advantages
> 
> Please explain why you think latex syntax is ambiguous.

LaTeX does not express a pamphlet.  It expresses a document.  So long
as we wish to work towards concepts such as the Crystal, we need
pamphlets.  Embedding the concept of a pamphlet in LaTeX, which itself
does not understand the term... therein lies the ambiguity.

\start
Date: Tue, 17 Jul 2007 17:15:50 -0500
From: Tim Daly
To: Martin Rubey
Subject: votes

The current widespread model is that a project maintains a stable
distribution (Gold) and an unstable distribution (silver). Silver
changes are proposed using diff-Naur patches. Silver commits are
done by a very limited number of people (usually one).

Every other project I'm associated currently associated with, 
every other project I've worked on large (Fedora) or small (Common 
Lisp Library) uses the same model. Even super-large projects like
Linux and Firefox use this model.

GCL, for instance, uses this model. Camm has recently made changes
on the ANSI branch which are distinctly non-ansi (e.g. *safety-level* 4)
and this raises no comment.

Up until November of 2006 I was publishing Axiom Gold releases on a
best-effort, two-month schedule using the same model. It worked 
perfectly well to get us up to the last Gold.

Please explain why you think Axiom should be a democratic model.

Please explain why you feel, as a self-declared algebra developer,
you have a need to vote on machinery (gclweb.lisp) below the algebra
which enables function you will never use.

\start
Date: Tue, 17 Jul 2007 17:25:29 -0500
From: Tim Daly
To: Martin Rubey
Subject: votes

> A vote is triggered by anybody on axiom-developer saying: stop, I'd like to
> vote.

How practical is this? Have you given any careful thought to the
way that Axiom will be developed and maintained in 30 years? Do you 
relate your objections to the long term goals? Or is the issue that
the change breaks syntax highlighting in a special axiom emacs mode?

Lets try a thought experiment. 
Suppose you propose that Fricas should now be democratic. 
Suppose you suggest that Waldek's trunk should become a branch. 
Suppose you suggest that only approved changes go into Fricas. 
Suppose you don't approve of the new non-literate changes.
Suppose you reject changes that Waldek has made. 

What would you feel would be a rational response from Waldek?

\start
Date: Tue, 17 Jul 2007 17:26:45 -0500
From: Tim Daly
To: list
Subject: availability

I'm going off-list at 7pm EST and will be away on business until
friday. Since my mail server cannot be reached externally I won't
be able to read or respond to emails.

\start
Date: Wed, 18 Jul 2007 00:27:37 +0200
From: Ondrej Certik
To: Tim Daly
Subject: Re: votes

I think this quote from Karl Fogel's book (http://producingoss.com/)
answers your question:

The transience, or rather the potential transience, of relationships
is perhaps the single most daunting task facing a new project. What
will persuade all these people to stick together long enough to
produce something useful? The answer to that question is complex
enough to occupy the rest of this book, but if it had to be expressed
in one sentence, it would be this:

    People should feel that their connection to a project, and
influence over it, is directly proportional to their contributions.

No class of developers, or potential developers, should ever feel
discounted or discriminated against for non-technical reasons.

Ondrej

On 7/18/07, Tim Daly wrote:
> The current widespread model is that a project maintains a stable
> distribution (Gold) and an unstable distribution (silver). Silver
> changes are proposed using diff-Naur patches. Silver commits are
> done by a very limited number of people (usually one).
>
> Every other project I'm associated currently associated with,
> every other project I've worked on large (Fedora) or small (Common
> Lisp Library) uses the same model. Even super-large projects like
> Linux and Firefox use this model.
>
> GCL, for instance, uses this model. Camm has recently made changes
> on the ANSI branch which are distinctly non-ansi (e.g. *safety-level* 4)
> and this raises no comment.
>
> Up until November of 2006 I was publishing Axiom Gold releases on a
> best-effort, two-month schedule using the same model. It worked
> perfectly well to get us up to the last Gold.
>
> Please explain why you think Axiom should be a democratic model.
>
> Please explain why you feel, as a self-declared algebra developer,
> you have a need to vote on machinery (gclweb.lisp) below the algebra
> which enables function you will never use.

\start
Date: Tue, 17 Jul 2007 17:35:17 -0500
From: Tim Daly
To: Stephen Wilson
Subject: availability

> Now you could argue that we could scan the latex file and infer the
> information from the markup therein. This will fail as we would need
> to write a full TeX parser to do that.

As indicated before I have this working in a branch. You don't need to
do anything except indicate which latex command you'd like to process
and which function you'd like to apply. Thus

\spadcommand{a^2+b^2=c^2} 

is handled by a dynamic table-lookup. You associate a latex command
with a lisp command so

("spadcommand" "lispspadcommand") 

means that

\spadcommand    calls  (lispspadcommand ....)

Simple. No magic. No effort. In fact, there is no reason why you
couldn't call spad functions directly. Just set up the list and do

  )lisp (weave "foo.pamphlet")

eventually it should be

  )weave foo



I though I explained this clearly in the prior, unintentionall offlist notes.

\start
Date: 17 Jul 2007 18:49:54 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: availability

Tim Daly writes:
> I though I explained this clearly in the prior, unintentionall offlist notes.

Yes, I understand the explanation.  But your example clearly shows
that a pamphlet file is not a LaTeX file.  The LaTex is but a facet,
to borrow from the Crystal terminology.

If you choose to associate meta-level operations with LaTeX commands,
then you loose flexibility. 

Can you say with certainty that every meta-level (or, more properly,
pamphlet-level) operation has a sensible, corresponding latex command?

Or do you just make those special cases and effectively define the
command in the .sty file as a no-op?

I agree with everything your trying to accomplish.  I just want the
concepts to be clear.  We latex .tex files.  We tangle, weave, and
transform .pamphlets.


your leaving for a trip, so we can pick back up on this latter in the
week.

Thanks for taking the time to engage in this discussion.

\start
Date: 17 Jul 2007 18:52:43 -0400
From: Stephen Wilson
To: axiom-devel <list>
Subject: Re: Pamphlets and LaTex

*,

A few items in this exchange were lost to axiom-devel due to an
omission in the CC field.  Am forwarding what I think are the missed
messages.


Stephen Wilson writes:

> Tim,
> 
> Thanks for your detailed reply.  Im glad this discussion is happening
> as its making many things clear to me.
> 
> Tim Daly writes:
> > > I have been trying to get a clear picture of the literate future for
> > > Axiom.
> > 
> > My plan, and I emphasize the "my" because I appear to be alone in this,
> > is to document axiom along the lines of the Lisp in Small Pieces book.
> > 
> > My plan shows 10 volumes,
> >  1) A tutorial -- written an published, needs rework
> >  2) Users Guide -- the Jenks book, redone with a different focus
> >  3) Programmers Guide -- how to write spad 
> >  4) Developers Notes -- how to understand the internals, etc
> >  5) The interpreter
> >  6) The spad compiler
> >  7) Hyperdoc
> >  8) Graphics
> >  9) Sman
> > 10) The algebra -- a multivolume, ongoing work
> 
> The idea of organizing axiom into a set of volumes makes perfect sense
> to me.  One needs a hierarchical structure to work with, period.  It
> should be reflected in the documentation as `volumes', the the source
> tree as `directories', etc.  I dont think your alone in that kind of
> goal.
> 
> [...]
> > > The basic issue for me is loosing the weave step. I believe that a
> > > lisp based noweb replacement could make good use of such a stage.
> > > Just like how a lisp based replacement could make use of the tangle
> > > stage (by sorting the chunks and compiling the lisp/boot/spad/code on
> > > the fly, for example).
> > 
> > Actually I have a lisp-based weave in the works. It just isn't ready
> > for publishing. It's pretty simple in concept, using the same kind
> > of scanning the tangle step uses. 
> > 
> > All you need to do is associate a lisp function with the latex
> > command. Thus 
> > 
> > \spadcommand{a+b=c} calls (spadcommand ("a+b=c")...)
> 
> This is where you loose me.  I _like_ the idea.  Its exactly the kind
> of thing I want to see.  But then the pamphlet is no longer `pure
> LaTeX', it just looks that way.
> 
> For example, we could have @(spadcommand "a+b=c").
> 
> If we need a weave stage, the file is not `pure' latex.  Using the "@
> character in the first column position" as a convention for the format
> of a _pamphlet_ file makes sense to me.  Stepping on the equivalent
> Latex construct `\' would lead to confusion, IMHO.
> 
> > The lisp function gets the latex command arguments.
> > A simple table lookup. How hard is that? If we wanted to be fancy
> > in an ANSI lisp we could use clos-like handling.
> >
> > We need this in cases like the jenks books where there are 
> > \spadcommand{some axom command}
> > and we want to process them dynamically and insert the results
> > into the final document.
> 
> Absolutely.
> 
> > But I see the weave step being used for things like Axiom-internal
> > documentation, not for things like literate papers. So you would
> > use weave 
> >   -- to create hyperdoc pages, 
> >   -- to merge pamphlets into booklets,
> >   -- to include/exclude text blocks, etc.
> > 
> > If you'll notice I've been trying to document some of the new input
> > files (see chtheorem.input, just published) in a way that will allow
> > them to become "example sections" in a tutorial book and in the
> > algebra volume. The new weave would process these documents to combine
> > them automatically. Think about this for a second... it means that the
> > documentation as well as the code becomes "chunks". This is
> > potentially a paradigm-changing difference. This chunking can be done
> > without doing special-case syntax.
> 
> noweb effectively deals with its input in this way, its just so simple
> there is nothing paradigm-changing about it.  Noweb does not delimit
> code chunks, it provides a code block header and documentation block
> header.  So chunks can follow chunks and `@'s can follow `@'s.
> 
> I wrote a noweb style processor in lisp over the weekend that respects
> this `chunking' of documents.  Its one of the reasons I wrote about
> this issue, as I too believe that it is a potentially powerful
> approach.
> 
> 
> > But this new weave use is internal-documentation only. 
> 
> Agreed. `@' should be like `\par' or some near equivalent for pure
> documentation.
> 
> > I want to be able to send and receive standard latex files that 
> > contain axiom code and process them. That requires using standard
> > latex syntax.
> 
> But your not sending and receiving standard LateX, as far as I
> understand.  What is \spadcommand{a+b=c} going to do when typeset?
> How do you write a document which uses these kinds of constructions
> yet cant make use of them without a weave step?
> 
> > You can't expect the world to adopt noweb. We can't even get the
> > developers to use it.
> 
> Its not so much about convincing the world to use noweb.  We need
> something better but nowebs simplicity serves as a good starting
> point.
> 
> What we have a hard time with is getting people excited about literate
> programming.  We are going to have an even harder time if we go the
> LaTeX route because even developers familiar with literate programming
> are going to have a hard time making the connections. I believe we
> should build off of familiar concepts if they prove sufficient.
> 
> > > In noweb, we have the basic syntax that <<chunk>>= starts a block of 
> > > code, and @ starts a block of documentation.
> > 
> > Yep. except that in NATIVE noweb << needs to be escaped (try writing
> > shift code in C which is where it bites me). Axiom's noweb is patched
> > to skip the escape, another rejected patch, another source of contention.
> 
> Right.  It would bite aldor code too and possibly spad code in the
> future. I like CWEBS @< ... @> convention more myself. Not so much
> room for conflict.
> 
> > Code IS documentation, it just needs special processing. Just like
> > quotes. Just like equations. Just like figures. Just like hyperlinks.
> > None of those other ones require non-latex preprocessors. And they
> > all work magically and correctly when made into pdf files, web pages,
> > journal files, books, etc. 
> 
> Absolutely, no disagreement there.  However, on the other side,
> pamphlets define Axiom, a program, not `just' a set of book volumes.
> We need the pamphlet format expressive to define a massively complex
> system, not just a massively extensive piece of literature.  Latex is
> not the tool for this (of course you know this already, I just felt
> the point needed to be made).
> 
> > > On the documentation side, I think having @ as an escape character is
> > > very important for long term goals. It allows us to embed commands
> > > and information at a meta level, without needing to rely on TeX macros
> > > to communicate all the information we need somehow. Similar to
> > > CWEB. Of course, we could scan the latex for individual items, but
> > > latex is complex and it would be a very difficult task, I think, to
> > > write a robust tool which copes with all the details well.
> > 
> > Actually, it gets in the way. It breaks things like latex-mode in
> > emacs or latex processing tools like lyx. It forces special handling
> > of otherwise-standard latex files.
> 
> How does \spadcommand differ in the special handling case?
> 
> Breaking latex-mode is fine.  I really dont think all files in Axiom
> should have the extension ".tex", ".pamphlet" is what we need, and a
> pamphlet.el mode to go along with it.  
> 
> 
> > Exactly how is latex complex? If the weave processor recognizes a
> > latex command and calls a lisp function why is that complex?
> 
> Because its not latex.  Take the \begin{chunk}{foo} ... \end{chunk}
> example.  You want to reference chunks with the sequence \chunk{foo}.
> I am _not_ a latex expert by any stretch, so this might be wrong in
> some details, but:
> 
>       {\chunk{foo} ...}   ==>   \begin{chunk}{foo} ... \end{chunk}
> 
> as far as latex handling of environments is concerned.  _Already_
> there is a confusion between what is latex and what is _not_ latex.
> 
> 
> > > So, the simple noweb syntax we can extend for our own purposes and we
> > > can manupulate the information contained therein directly using Axiom.
> > > I think there is some real potential here which would be awkward to
> > > achieve with latex-only pamphlets.
> > 
> > This is a standard argument, that noweb can by extended. Yes, it can.
> > 
> > In fact, Bill Page wrote a version of my special escape [[, << patch
> > in "standard noweb", that is, using perl. Of course, he didn't get the
> > "standard noweb patch" accepted upstream either. So both are "axiom-only"
> > extensions.
> 
> Sure.  I think Noweb is a good starting point.  As I said, I already
> reimplemented it in lisp.  I dont like the <<chunk>>= thing and would
> like it to go.  What I do like is the fact that an `@' character can
> serve as a reasonable escape, as reasonable a choice there is I think,
> allowing for unambiguous statements to be introduced for the purposes
> of weaving the document.
> 
> > But Bill makes the argument that we could use "standard noweb" and
> > have our own extension. How this differs from using the patched
> > version is unclear to me in any practical sense since I cannot ship
> > you a pamphlet file using "axiom noweb" and expect it to work for you.
> > Unless you are root and have perl installed you can't use it. Windows
> > users rarely have perl installed.  Nobody expects to install a perl
> > function to read a document.
> > 
> > However, latex-only pamphlets work everywhere. People expect and
> > understand style files so needing axiom.sty is normal. I have to do
> > this when I review conference papers that use a special style file.
> 
> Well, I have my doubts about it working everywhere without a special
> weave program to go along with it.
> 
> Of course, one could weave a latex file and share that.
> 
> > > In the latex only approach, I cannot find any gains in flexibility.
> > 
> > The new latex chunk mechanism allows latex format commands within
> > the chunk if desired. Thus if you want to embed equations in your
> > axiom ++ function comments it just works. If you want to use hyperlinks
> > in your code it just works. If you want to use \spadcommands they
> > also work.
> 
> We can do that anyways.  This is not a gain in flexibility.  Noweb is
> inflexible,  and so is `pure' latex.  Pamphlets (I use the term
> somewhat provocatively:) are not inflexible.  We just need a tool to
> process them.
> 
> > > In short I am advocating we stick with noweb syntax with a view
> > > towards extending the capabilities as demanded by future needs.
> > 
> > > Of course, I am still open to being convinced otherwise.
> > 
> > Noweb is "ok". I use it. But it has shortcomings. 
> > Have you tried to use it to document your work? 
> > Use it on a daily basis and I think you'll be convinced otherwise.
> 
> Noweb sucks (for my purposes).  Im going to keep extending my lisp
> tool to get the features I need.
> 
> 
> > Now for some of my motivations to get rid of noweb:
> > 
> > The ESCAPE issue
> 
> OK. Lets solve this with our own, smarter, tool. 
> 
> > The TIME issue
> > 
> > It is not obvious to everyone but noweb is slow. Very slow. 
> > My current pamphlet for work is 217905 lines long (a small book).
> > Noweb takes approximately 5 minutes to generate 53790 lines of lisp.
> > Latex takes approximately 28 seconds to generate 5278 pages of documentation.
> > (This on a 3.4Ghz machine). Latex-only documents gains 4.5 minutes for
> > every rebuild/test cycle.
> 
> The code I wrote is not designed with efficiency as the #1 priority,
> the tangle operation on a 23000 line file with 1000 chunks takes half
> a second (and I have a slow machine).  The weave step takes a second
> longer.  Good enough for me.
> 
> 
> [...]
> 
> I was going to reply to the points you follow with but I hope the main
> argument is already clear from the above.
> 
> 
> So.  We need to have a weave step, which implies the files are not
> latex files.  Lets work with pamphlets and have latex output but one
> of many possible transformations we can perform on such an object.  We
> only gain flexibility by taking that approach.
> 
> Tim, I really think we are on the same page here, we both see the same
> kinds of possibilities.  Please reconsider the LateX only approach.
> Its but one facet of a pamphlet.

\start
Date: Tue, 17 Jul 2007 18:53:37 -0400
From: Stephen Wilson
To: list
Subject: Re: Pamphlets and LaTex

Forward to axiom-devel:

From: Stephen Wilson
Date: 17 Jul 2007 18:53:39 -0400
--text follows this line--
Tim Daly writes:

> I'm puzzled. Why do you say that
> 
> \spadcommand{}
> 
> and
> 
> \begin{chunk}
> \end{chunk} 
> 
> is not latex? The \spadcommand occurs in the published tutorial
> book, bookvol1.pamphlet, which is formatted by standard latex.
> 
> Why do you believe otherwise?
> 

\start
Date: 17 Jul 2007 18:54:21 -0400
From: Stephen Wilson
To: list
Subject: Re: Pamphlets and LaTex

Forward:
Stephen Wilson writes:

> Tim Daly writes:
> 
> > I'm puzzled. Why do you say that
> > 
> > \spadcommand{}
> > 
> > and
> > 
> > \begin{chunk}
> > \end{chunk} 
> > 
> > is not latex? The \spadcommand occurs in the published tutorial
> > book, bookvol1.pamphlet, which is formatted by standard latex.
> > 
> > Why do you believe otherwise?
> 
> I was under the impression that \spadcommand{"a+b=c"} would execute
> its argument in Axiom.  Latex cannot do that.
> 
> I belive we need to distinguish explicitly the differences.  A weave
> stage within a custom tool could perform the evaluation and substitue
> the result into pure LaTeX.

\start
Date: 17 Jul 2007 18:55:17 -0400
From: Stephen Wilson
To: axiom-devel <list>
Subject: Re: Pamphlets and LaTex

Forward:
Tim Daly writes:

> >>The ESCAPE issue
> 
> > Ok. Lets solve this with our own, smarter, tool.
> 
> We did. The mailing list discussion was endless.
> Check the archives.

\start
Date: 17 Jul 2007 18:55:36 -0400
From: Stephen Wilson
To: list
Subject: Re: Pamphlets and LaTex

Forward:
Stephen Wilson writes:

> Tim Daly writes:
> 
> > >>The ESCAPE issue
> > 
> > > Ok. Lets solve this with our own, smarter, tool.
> > 
> > We did. The mailing list discussion was endless.
> > Check the archives.
> 
> I am familiar with previous debates.
> 
> According to your last few postings, its not an ideal solution.  And I
> subscribe to that opinion as well.  Its a workaround as a consequence
> of using a tool (noweb) which does not satisfy our requirements.
> 
> Moreover, we are still using a tool which does not satisfy our
> requirements.  The hacked version of noweb we use does not qualify in
> my mind as being a smarter tool.

\start
Date: 17 Jul 2007 18:55:58 -0400
From: Stephen Wilson
To: list
Subject: Re: Pamphlets and LaTex

Forward:
Tim Daly writes:

> > I like the '@'
> 
> So you're proposing yet another syntax? Non-noweb, non-latex?
> How would it work? What are the advantages/disadvantages.
> 

\start
Date: 17 Jul 2007 18:56:27 -0400
From: Stephen Wilson
To: list
Subject: Re: Pamphlets and LaTex

Forward:
Stephen Wilson writes:

> Tim Daly writes:
> 
> > > I like the '@'
> > 
> > So you're proposing yet another syntax? Non-noweb, non-latex?
> > How would it work? What are the advantages/disadvantages.
> 
> I believe you already have a good idea of the concepts involved here.
> Your trying to do the same thing but using LaTeX syntax.  That would
> be fine with me if it were not for the fact that it is not,
> conceptually, pure LaTeX.
> 
> I would propose that we use a variant of noweb syntax to start.
> Perhaps replace <<chunk>>= and the corresponding reference <<chunk>>
> with @<chunk@>= and @<chunk@> respectively.  These are less likely
> candidates for collision with program constructs.
> 
> As far as what other escape terms we could introduce with the @
> convention,  that is open to wide debate.  The spadcommand notion is a
> good example of one thing we can do.
> 
> The distinct advantage here is that we are using a syntax which is
> special to a pamphlet.  We need a weave stage, and we need an
> unambiguous notation which we can accurately parse and transform.
> Using latex syntax is ambiguous.  Thats the main advantage, but a big
> one with real technical advantages.

\start
Date: 17 Jul 2007 18:56:49 -0400
From: Stephen Wilson
To: list
Subject: Re: Pamphlets and LaTex

Forward:
Tim Daly writes:

> > So. We need to have a weave step, which implies the files are not 
> > latex files.
> 
> The files are latex. Pure, valid latex. I'm puzzled why you don't 
> agree. 
> 
> Weave is only required to generate axiom-internal documentation
> when we want to do special case work. Even if the weave step is
> not performed the files are still pure latex. Thus, 
> 
> \spadcommand{$a^2+b^2=c^2$}
> 
> is perfectly valid latex (and is used in my published book).
> Anyone can latex the file and see typeset math as:
> 
>   2    2    2
>  a  + b  = c
> 
> but the weave step, would also allow us to input such a command
> to axiom and use it to create hyperdoc pages.

\start
Date: 17 Jul 2007 18:57:14 -0400
From: Stephen Wilson
To: list
Subject: Re: Pamphlets and LaTex

Forward:
Stephen Wilson writes:

> Tim Daly writes:
> 
> > Weave is only required to generate axiom-internal documentation
> > when we want to do special case work. Even if the weave step is
> > not performed the files are still pure latex. Thus, 
> > 
> > \spadcommand{$a^2+b^2=c^2$}
> > 
> > is perfectly valid latex (and is used in my published book).
> > Anyone can latex the file and see typeset math as:
> > 
> >   2    2    2
> >  a  + b  = c
> > 
> > but the weave step, would also allow us to input such a command
> > to axiom and use it to create hyperdoc pages.
> 
> OK.  I understand.  I was confused, and for good reason, I think.  The
> construct itself is confusing.
> 
> \spadcommand{...}  means one thing when TeX sees it, and something
> else when the weave translator sees it.  We should not confuse such
> things.
> 
> 
> I cannot remember the terms, but hyperdoc has the ability, as you
> know, to perform evaluations which reference previous results.
> 
> You cannot have a pure latex file which typesets itself and exploits
> that kind of evaluation.  However a weave stage can connect with
> axiom, perform the evaluation, and insert pure latex which is a result
> of the evaluation.
> 
> Lets not overload the meaning of constructs used to write pamphlets.
> 
> I understand the convenience of being able to share a file which can
> be processed by anyone.  But what are the advantages of disguising
> meta information in that file?  What are the disadvantages of needing
> to weave a pamphlet to get that one thing you need to share?

\start
Date: Wed, 18 Jul 2007 01:31:59 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: re: debugging

> Greetings!  The disassemble bug we saw earlier (end of file) is due to
> a redefinition of compiler::gazonk-name somewhere in your tree.  (We
> now have a different format for temporary file names.)
>

gazonk-name is redefined in file 'util.lisp.pamphlet' at line 1531.
I considered removing this definition -- currently GCL version
is better.   However, currently I decided to keep Axiom version,
because I belive that GCL version would just mask (but does not
really solve) problems with gazonk names.

Namely, there is a bug, see:

http://www.mail-archive.com/list/msg09476.html

With GCL version we still would have a bug, just one extremally unlikely
(due to random names) to bite.  As I wrote in the message at URL
above, I belive that for Axiom the best way would be to create
a gazonk directory, making sure it is owned by the user running Axiom
and to put gazonk file there.


> Would it be possible to summarize any gcl lisp functions for which
> patching/redefinition is felt necessary in axiom, and work toward
> eliminating same?  The current situation will just create more work as
> GCL and axiom evolve.

The general direction is to use umodified/unpatched gcl, and in general
to limit dependency on GCL internals.  I belive that currently almost
all dependencies are conditional (otherwise sbcl/clisp port would not
work).  My intension is keep non-portable (using conditionals) code
separately from the rest of Axiom.

\start
Date: Tue, 17 Jul 2007 16:36:14 -0700 (PDT)
From: Cliff Yapp
To: Stephen Wilson
Subject: re: Pamphlets and LaTex

I'll confess I'm a bit confused, but that may be my fault.  Questions:

1)  How does going from noweb to LaTeX syntax change anything, besides
what needs to be typed to ID a chunk?  I don't know about noweb, but
the whole point of wrapping the cl-web state machine in macros was to
be able to handle arbitrary delimiters.  If everything works as
expected, the options should be:

a.  (tangle <pamphlet>) -> source code
b.  latex pamphlet -> DVI document according to the abilities defined
in axiom.sty
c.  (weave <pamphlet>) -> TeX document with additional markup provided
by the weave logic in the WEB program.

This is the same regardless of what strings denote chunks - in theory
with enough work you could probably teach LaTeX to typeset straight
from the noweb syntax.  It just happens to be easier to have it in a
more LaTeX like form - that makes writing the style file for option b
much simpler.

It is highly unlikely that a pure LaTeX solution can supply all of the
features a weave step can provide.  Some of the more advanced ones
require full awareness of the source code.  cl-web doesn't have any of
this yet - in theory pure LaTeX processing could do everything the
current weave command can do in cl-web - but that doesn't mean it won't
in the future.

2.  Y'all ARE aware that cl-web already has a very basic weave
functionality, correct?  The cl-web pdf file was built from a TeX file
generated by cl-web itself, without noweb.  It's nothing spectacular
but I am using it to work on asdf-literate.  Extending it shouldn't be
too difficult, except for the whole source-code-reference bit (which to
do correctly will require cooperation from the Lisp compiler.)

3.  Is the intent still to move to the cl-web code once we get to ANSI,
or is gclweb the direction of the future?  If the latter I need to take
a closer look at that codebase.

4.  Do I understand correctly that a design goal here is to add
commands to the pamphlet files that will not be tangled but instead
executed in an Axiom environment?  There are two ways to interpret
that:

   a.  Provide a special LaTeX style that is aware of SPAD/interpreter
language syntax and typesets, but don't execute the code unless the
file is specifically processed with that intent (tangle, weave, and
run-spad?)

   b.  Process the commands during the LaTeX process and incorporate
the results of Axiom's evaluation automatically into the document. 
This is a bit more like the EMaxima functionality.  This is useful in
some situations but I am not sure we need to be worrying about it at
this stage.

Can someone provide me with some usage scenarios here?  What are the
goals?

5.  I'm a bit dubious about the possibility of treating documentation
as chunks - I tend to view documentation of .spad.pamphlet files as
indivisible conceptually (not just technically.)  To me the best bet is
to go with what is already done in the academic world - combine papers
into volumes in the "conference proceeding" fashion.  There will be
many different writing styles at work in the Axiom system, and it's
almost certain they won't "flow" in such a fashion as to lend
themselves to having pieces mixed and matched.

Am I missing something here?  Help!

\start
Date: 17 Jul 2007 19:40:50 -0400
From: Stephen Wilson
To: Waldek Hebisch
Subject: re: debugging

Waldek Hebisch writes:
> ... I belive that for Axiom the best way would be to create
> a gazonk directory, making sure it is owned by the user running Axiom
> and to put gazonk file there.

Any reason why the exported si:*tmp-dir* does not suffice?

\start
Date: 17 Jul 2007 20:25:37 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: re: Pamphlets and LaTex

Cliff Yapp writes:

> I'll confess I'm a bit confused, but that may be my fault.  Questions:
> 
> 1)  How does going from noweb to LaTeX syntax change anything, besides
> what needs to be typed to ID a chunk? 

The critical and (as I am now seeing) subtle point is that latex only
sees the markup as a typesetting construct, where in fact the
construct means a completely different thing to the absolutely
necessary tools like weave and tangle.

So when you write \chunk{foo}, you dont mean "LaTeX, please typeset
this reference to foo".  You mean "Pamphlet, this is a chunk named
foo, as you can see by the executable code to which it points, it
connects with the domain Foo, please update the runtime representation
of the domain Foo with a link to the surrounding context. Please
inform hyperdoc of the connection. Please ...".

And since LaTeX is a language designed with the express purpose of
writing documents, not pamphlets, it does not mesh well with our
needs.

What if \chunk{foo} resulted in referencing the Foo domain defined in
another file?  For a competent weave tool which understands the
problem domain, this is not an issue, it can look up the reference.
Now what does latex think about this \chunk{foo} construct?  Will it
typeset "cannot find chunk foo", will it bail out in error?  The
answer is that there is no sensible solution, but to do what the
construct is asking, and weave it properly and into a form which LaTeX
can digest.


> I don't know about noweb, but the whole point of wrapping the cl-web
> state machine in macros was to be able to handle arbitrary
> delimiters.  If everything works as expected, the options should be:

Right.  But you dont need a state machine to do that. You just need a
variable holding a string, cl:string=, and cl:subsequence. 

Its much harder to transform that state machine into one which can
deal with the reorganization of chunk structure.  For example, noweb
markup like:

    @
      Introduction.
    <<chunk1>>=
        (code here)
    <<chunk2>>=
        (more code)
    @
       Some documentation
    <<chunk3>>=
         (etc...)
     EOF

The state machine hard wires code blocks:

      <<chunk>>=
          (code)
      @

State machines are fine if your modeling transistor networks.  Not
when parsing dirt simple noweb-like markup, IMHO.

[...]
> 2.  Y'all ARE aware that cl-web already has a very basic weave
> functionality, correct?  The cl-web pdf file was built from a TeX file
> generated by cl-web itself, without noweb.  It's nothing spectacular
> but I am using it to work on asdf-literate.  Extending it shouldn't be
> too difficult, except for the whole source-code-reference bit (which to
> do correctly will require cooperation from the Lisp compiler.)

Yes.  I am aware for that.  Note that you need cooperation from the
Lisp compiler.  Again, another non-latex component to the process.
Another reason not to have pamphlet markup masquerade as latex.

> 3.  Is the intent still to move to the cl-web code once we get to ANSI,
> or is gclweb the direction of the future?  If the latter I need to take
> a closer look at that codebase.

I have some issues with the code in cl-web, as noted above,
unfortunately. (again, please dont take this personally!  These are
just dry technical observations!)

> 4.  Do I understand correctly that a design goal here is to add
> commands to the pamphlet files that will not be tangled but instead
> executed in an Axiom environment?  There are two ways to interpret
> that:
> 
>    a.  Provide a special LaTeX style that is aware of SPAD/interpreter
> language syntax and typesets, but don't execute the code unless the
> file is specifically processed with that intent (tangle, weave, and
> run-spad?)

The correct solution is to have a pamphlet command which can either:
   - executes the code and generates the appropriate latex as output
   - or replace the command with a simple latex expression without
     doing any on-the fly evaluation.

Either behavior, and perhaps others, can be specified to weave the
document.

>    b.  Process the commands during the LaTeX process and incorporate
> the results of Axiom's evaluation automatically into the document. 
> This is a bit more like the EMaxima functionality.  This is useful in
> some situations but I am not sure we need to be worrying about it at
> this stage.

This is not enough.  Axiom should be able to read pamphlets, and have
them exist as live objects in the system.  Should we actually require
that axiom write a file and call LaTeX to call itself in order to
weave a document?

LaTeX processes latex files, not pamphlets.

> Can someone provide me with some usage scenarios here?  What are the
> goals?

The Crystal, where we can view an object through a multitude of
facets.  We can see the API, the theorems and proofs, the category
hierarchy, the dependents and dependees, etc, etc...  All these things
have been discussed before, there are many other options.  I mention
these in particular because they are all candidates for generating
LaTeX output, but would ultimately be inferred from a set of
pamphlets.  You cant just run LaTeX on a pamphlet and obtain that
result, because pamphlets are not LaTeX.

> 5.  I'm a bit dubious about the possibility of treating documentation
> as chunks - I tend to view documentation of .spad.pamphlet files as
> indivisible conceptually (not just technically.)  To me the best bet is
> to go with what is already done in the academic world - combine papers
> into volumes in the "conference proceeding" fashion.  There will be
> many different writing styles at work in the Axiom system, and it's
> almost certain they won't "flow" in such a fashion as to lend
> themselves to having pieces mixed and matched.

Whats wrong with associating a documentation chunk as the formal proof
of a particular code chunks correctness?  Or as the API doc which gets
displayed when you pass the wrong type to factorGroebnerBasis?

> Am I missing something here?  Help!

I hope that helps clarify my position a bit.  Lets keep discussing
this as I think it is of hugely important for Axiom!

\start
Date: Wed, 18 Jul 2007 02:49:08 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: re: debugging

Camm Maguire wrote:
> Greetings, and thanks!  The problem is that the global entries to the
> functions returning double float etc. are not being writtin into
> DFLOAT.c.  I'm trying to debug by reproducing the compile-file step on
> DFLOAT.lsp.  This fails at the lisp prompt:
> 
> (compile-file "DFLOAT.NRLIB/DFLOAT.lsp")
> 
> ; (DEFUN |DFLOAT;manexp| ...) is being compiled.
> ;;; The tag #:G2017215 is undefined.
> ; (DEFUN |DFLOAT;rationalApproximation;$2NniF;84| ...) is being compiled.
> ;;; The tag #:G2017237 is undefined.
> ;;; The tag G190 is undefined.
> ; (DEFUN |DFLOAT;**;$F$;85| ...) is being compiled.
> ;;; The tag #:G2017246 is undefined.
> ;;; The tag #:G2017246 is undefined.
> No FASL generated.
> 
> Error: 
> Fast links are on: do (si::use-fast-links nil) for debugging
> Signalled by BREAK.
> Condition in BREAK [or a callee]: INTERNAL-SIMPLE-PROGRAM-ERROR: Compilation of "DFLOAT.NRLIB/DFLOAT.lsp" failed.
> 
> Broken at BREAK.  Type :H for Help.
>  1 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
>  2 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
>  3 (Abort) Return to debug level 2.
>  4 (Continue) Return from break.
>  5 Return to top level.
> COMPILER>>
>
> Then I try )co "DFLOAT.spad" from the axiom prompt:
> 
> )co "DFLOAT.spad"
>    Your command is ambiguous. The following are abbreviated by co :
>       compiler 
>       copyright 
> (1) -> )quit
>    Please enter y or yes if you really want to leave the interactive 
>       environment and return to the operating system:
> y
>    You have chosen to remain in the AXIOM interactive environment.
> (1) -> 
> (1) -> 
> Program exited normally.
> 
> So I try a fresh interpsys, set the stage 1 bootstrap mode flag, And
> find a very long chain of compiles which must proceed before I can
> compile DFLOAT.  
> 
> I'm sure I'm just making some simple mistake, but how can one rebuild
> just DFLOAT from any given stage in the build?  This will enable me to
> fix this.
>

All Axiom generated Lisp file use special macros, present in interpsys.
Theoretically all macros are also present in depsys image, but I did
not check if depsys works for Lisp compilation of algebra files.
Error messages from Lisp compilation probably can be explained by lack
of macros.  But behavoir of ')co' (and also ')quit') command looks
strange -- I prefer to always use full version ')compile', but for
me ')co' starts compilation.  Also the

"You have chosen to remain in the AXIOM interactive environment."

message looks like a bug.

Spad compilation is slightly more tricky: given spad file may require
that several other files are compiled earlier.  When Spad compiler
operates in default mode there are cyclic dependencies.  Basically the
whole bootstrap procedure is to fight with those cyclic dependencies.
Stage 1 of bootstrap must go in a rather rigid order.  After stage 1 of
bootstrap it should be possible to compile all Spad files using special
|$bootstrapDomains| flag.  Once Stage 2 is finished it should be
possible to compile all normal mode.  

If you want to compile a single file after stage 1 finished do the following.

1) start interpsys, you need to correctly set up AXIOM and DAASE variables,
   for me the it is below:

( export AXIOM=/h/axp62/ax-build2/target/x86_64-unknown-linux; export DAASE=/h/axp62/wh-sandbox/src/share; /h/axp62/ax-build2/build/x86_64-unknown-linux/bin/interpsys )

2) for stage 2 compilation set the |$bootstrapDomains| flag:

)lisp (setf |$bootstrapDomains| t)

Value = T

3) issue compilation command:

(2) -> )compile "DFLOAT.spad"


If you want you can also do Lisp compilation:

(1) -> )lisp (compile-file "DFLOAT.NRLIB/DFLOAT.lsp")

Value = #P"/h/axp62/ax-build2/src/algebra/DFLOAT.NRLIB/DFLOAT.o"
(1) ->

Trying the above I noticed that doing by hand stage 2 compilation of
"DFLOAT.spad" I can also do stage 3 compilation of "DFLOAT.spad".
So the problem seem to appear only if I do all compilations in a
single image...

Normally Lisp files from stage 2 compilation are deleted before
starting stage 3 compilation.  I changed the Makefile to capture
the result from stage 2 compilation.  Comparing with the Lisp file
obtained separately I see some differences, but none which can explain
different behavior of object code.

\start
Date: Tue, 17 Jul 2007 20:49:12 -0700 (PDT)
From: Cliff Yapp
To: Stephen Wilson
Subject: re: Pamphlets and LaTex

--- Stephen Wilson wrote:

> What if \chunk{foo} resulted in referencing the Foo domain defined in
> another file?

I personally didn't consider it desirable to reference chunks outside
of a particular file - it makes it that much harder to understand.  If
the idea is to tangle something, I don't really like the idea of
tangling a source file out of multiple pamphlets.  In my opinion that
level of complexity is always going to cause more difficulties than any
advantages it might give.  I would be interested in use cases that can
demonstrate the benefits of such an approach - just because I can't
think of any certainly doesn't mean there aren't any.

> Its much harder to transform that state machine into one which can
> deal with the reorganization of chunk structure.  For example, noweb
> markup like:
> 
>     @
>       Introduction.
>     <<chunk1>>=
>         (code here)
>     <<chunk2>>=
>         (more code)
>     @
>        Some documentation
>     <<chunk3>>=
>          (etc...)
>      EOF

Erm.  Do we want to support a style like that?  My first thought upon
seeing that would be to think "badly formatted, hard to understand."
 
> The state machine hard wires code blocks:
> 
>       <<chunk>>=
>           (code)
>       @

Yes.  Personally I consider this a Good Thing - the visual signature of
a chunk is always consistent and unique.  This makes for easier
pamphlet editing, in my opinion - the above example would have me
wondering if I was in chunk1 or chunk 2.

> State machines are fine if your modeling transistor networks.  Not
> when parsing dirt simple noweb-like markup, IMHO.

Probably the Best Way to handle this would be to use some sort of BNF
parser generator and define the pamphlet grammar - then let the parser
generator write us a parser.  That would of course lose us some speed,
but if we're opening up pamphlet syntax I would say the tradeoff would
be well worth it.  Making a literate BNF tool might also be useful down
the line for other applications in Axiom.

Of course, the speed request didn't originally come from me - Tim? 
What would your take on this issue be?

> Yes.  I am aware for that.  Note that you need cooperation from the
> Lisp compiler.  Again, another non-latex component to the process.
> Another reason not to have pamphlet markup masquerade as latex.

Sure :-).  But if you don't like the LaTeX syntax, just weave it into
something else ;-).
 
> > 3.  Is the intent still to move to the cl-web code once we get to
> > ANSI, or is gclweb the direction of the future?  If the latter I
> > need to take a closer look at that codebase.
> 
> I have some issues with the code in cl-web, as noted above,
> unfortunately. (again, please dont take this personally!  These are
> just dry technical observations!)

Of course - not a problem :-).  My only concern is that the
documentation of cl-web was a non-trivial exercise (for me, at least
:-/) and if we are going to have to re-do this again I want to make
sure the direction chosen is the final direction. 

> > 4.  Do I understand correctly that a design goal here is to add
> > commands to the pamphlet files that will not be tangled but instead
> > executed in an Axiom environment?  There are two ways to interpret
> > that:
> > 
> >    a.  Provide a special LaTeX style that is aware of
> SPAD/interpreter
> > language syntax and typesets, but don't execute the code unless the
> > file is specifically processed with that intent (tangle, weave, and
> > run-spad?)
> 
> The correct solution is to have a pamphlet command which can either:
>    - executes the code and generates the appropriate latex as output
>    - or replace the command with a simple latex expression without
>      doing any on-the fly evaluation.
> 
> Either behavior, and perhaps others, can be specified to weave the
> document.

Steve, are you thinking to have chunks identify their language to the
scanner?  Otherwise I'm not sure how the scanner will distinguish
between input, lisp, spad, etc. in the chunk and know to evaluate only
the input expressions.

> >    b.  Process the commands during the LaTeX process and
> incorporate
> > the results of Axiom's evaluation automatically into the document. 
> > This is a bit more like the EMaxima functionality.  This is useful
> > in
> > some situations but I am not sure we need to be worrying about it
> at this stage.
> 
> This is not enough.  Axiom should be able to read pamphlets, and have
> them exist as live objects in the system.  Should we actually require
> that axiom write a file and call LaTeX to call itself in order to
> weave a document?

I'm not sure what you mean by "live object".  I was viewing it as
follows:

1. .lisp.pamphlet and .spad.pamphlet files are loaded just as
functionality is loaded now from these files.

2. Axiom IO sessions inside LaTeX documents are typeset in a way
similar to the way EMaxima handles things.  There could perhaps be an
"evaluate all axiom expressions in this latex file" command or some
such, but I'm not quite clear how this would make the document "live".

> The Crystal, where we can view an object through a multitude of
> facets.  We can see the API, the theorems and proofs, the category
> hierarchy, the dependents and dependees, etc, etc...

Perhaps how we view these things is relevant to this.  For myself, most
of these things are deduced and documents describing them can be
generated "on the fly" with specific commands inside Axiom -
GenerateProof(a=b,COQ) or CategoryTree(PositiveInteger) or )show api
integrate or something like that.  I hadn't viewed the tangle/weave
part of the system as directly having anything to do with it.

> All these things
> have been discussed before, there are many other options.  I mention
> these in particular because they are all candidates for generating
> LaTeX output, but would ultimately be inferred from a set of
> pamphlets.  You cant just run LaTeX on a pamphlet and obtain that
> result, because pamphlets are not LaTeX.

Correct.  I would expect to do some interactive work to obtain those
documents or at the very least run some special tools (not tangle or
weave as such, maybe (prove-all "file.input.pamphlet") or some other
command that builds on top of the basic scanner ability.)

> Whats wrong with associating a documentation chunk as the formal
> proof of a particular code chunks correctness?

My current (half formed) thought on that issue was to have
pseudo-databases of the proofs themselves and get them at need (for
generating an actual proof, or for insertion into some document).  I
didn't figure to have every chunk and its correctness proof next to
each other in the documents, simply because of the likely size of many
of them (check out metamath).

> Or as the API doc which gets displayed when you pass the wrong type
> to factorGroebnerBasis?

I thought API docs were very specificly terse, syntax focused messages
that would have to be written with the idea of appearing as "error
messages" rather than the more verbose research-paper style
explanations.  (I'm probably missing something again, sorry...)
 
> > Am I missing something here?  Help!
> 
> I hope that helps clarify my position a bit.  Lets keep discussing
> this as I think it is of hugely important for Axiom!

It sounds like the design decision here is how much responsibility for
processing do we specifically want to put into the weave tools.  My
thought would be minimalist - strictly enforce the chunk style, and
prepare additional tools/logic for operations beyond basic code
extraction and LaTeX translation.  Which is not to say powerful tools
aren't good, but I think they should either be inside Axiom or built as
discrete functionality on top of the basic chunk style.

What about this - we could add an optional options container to the
chunk style - e.g.

<<chunkname>>=[options]

@

where things in the options container are simply stored in the chunk
structure in the scan.  Then, if the scan function is being called by a
command other than the basic tangle and weave, the callee could look
for options pertaining to its particular function.

\start
Date: Wed, 18 Jul 2007 10:58:11 +0700 (NOVST)
From: Andrey G. Grozin
To: Stephen Wilson
Subject: re: Pamphlets and LaTex

On Wed, 17 Jul 2007, Stephen Wilson wrote:
> Cliff Yapp writes:
>> I'll confess I'm a bit confused, but that may be my fault.  Questions:
>>
>> 1)  How does going from noweb to LaTeX syntax change anything, besides
>> what needs to be typed to ID a chunk?
> The critical and (as I am now seeing) subtle point is that latex only
> sees the markup as a typesetting construct, where in fact the
> construct means a completely different thing to the absolutely
> necessary tools like weave and tangle.
No, I absolutely disagree with the above statement. LaTeX commands and 
environments are *not* typesetting constructs! Their puropse is to encode 
the logical structure of the document, not its visual (typesetting) form. 
Styles associate some visual meaning with various logical concept; one can 
easily change the style, and get a different typeset output from the same 
(logically) document.

> So when you write \chunk{foo}, you dont mean "LaTeX, please typeset
> this reference to foo".  You mean "Pamphlet, this is a chunk named
> foo, as you can see by the executable code to which it points, it
> connects with the domain Foo, please update the runtime representation
> of the domain Foo with a link to the surrounding context. Please
> inform hyperdoc of the connection. Please ...".
Exactly. When I say \chunk{foo}, I don't want to inform LaTeX that it 
should typeset the reference in some font. I want to say that this is 
*logically* a reference to a chunk. Typesetting issue is secondary.

> And since LaTeX is a language designed with the express purpose of
> writing documents, not pamphlets, it does not mesh well with our
> needs.
LaTeX is a language for writing documents according to their logical 
structure (meaning). Pamphlets are a particular case of such structured 
documents.

If there will be a vote :-), please count my vote for the pure LaTeX 
syntax of pamphlets. This eliminates a lot of complexity: one more syntax 
to learn (with all its warts to escape << and >>, etc.), one tool which is 
no longer needed. It is easier to use the familiar LaTeX syntax (which was 
designed to encode structure, i.e., the meaning, of any concept). We can 
add as many concepts as we need. In fact, any author writing any 
non-trivial text in LaTeX always adds some new concepts, and this is the 
the use for which LaTeX has been designed. Some LaTeX command may mean 
"run this command through Axiom", when used in a proper context. Why not?

Entities should not be multiplied beyond necessity.

Andrey

P.S. Currently, I see just one (temporary) disadvantage: this new syntax 
breaks a syntax highlighting mode in emacs. This disadvantage is real: I 
use emacs all the time, and I like syntax highlighting. But I think it is 
rather easy to teach this emacs mode to recognize \begin{chunk}{foo} and 
\end{chunk} instead of <<foo>>= and @.

\start
Date: 18 Jul 2007 01:04:37 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: re: Pamphlets and LaTex

Cliff Yapp writes:

> --- Stephen Wilson wrote:
> 
> > What if \chunk{foo} resulted in referencing the Foo domain defined in
> > another file?
> 
> I personally didn't consider it desirable to reference chunks outside
> of a particular file - it makes it that much harder to understand.  If
> the idea is to tangle something, I don't really like the idea of
> tangling a source file out of multiple pamphlets.  In my opinion that
> level of complexity is always going to cause more difficulties than any
> advantages it might give.  I would be interested in use cases that can
> demonstrate the benefits of such an approach - just because I can't
> think of any certainly doesn't mean there aren't any.

Look at the algebra, for example.  Look at the interrelationships.  Do
you want to write your algebra for Boolean in the _same_ pamphlet for
the rest of the system which depends on it?  Do ( untested :)

     cd ./src/algebra && cat *.pamphlet > algebra.pamphlet

I expect that is the situation we would have.

[...]
> >     @
> >       Introduction.
> >     <<chunk1>>=
> >         (code here)
> >     <<chunk2>>=
> >         (more code)
> >     @
> >        Some documentation
> >     <<chunk3>>=
> >          (etc...)
> >      EOF
> 
> Erm.  Do we want to support a style like that?  My first thought upon
> seeing that would be to think "badly formatted, hard to understand."

Why?
          @
          The following two routines enables one to add integers, and
          subtract them.

          <<add>>=
              (defun add (x y) (+ x y))
          
          <<subtract>>=
              (defun subtract (x y) (- x y))

I gives you freedom to organize your code in a fashion which might be
suitable for your problem.  Note that there is absolutely no
requirement that you must format your code that way.  The point is
that you can, if needed.

> > The state machine hard wires code blocks:
> > 
> >       <<chunk>>=
> >           (code)
> >       @
> 
> Yes.  Personally I consider this a Good Thing - the visual signature of
> a chunk is always consistent and unique.  This makes for easier
> pamphlet editing, in my opinion - the above example would have me
> wondering if I was in chunk1 or chunk 2.

Its like as we have in LaTeX, \section{FOO}.  Its a header.  And as I
said, if you want to structure your code in a way which reads more
easily for you, there is nothing standing in your way.

> > State machines are fine if your modeling transistor networks.  Not
> > when parsing dirt simple noweb-like markup, IMHO.
> 
> Probably the Best Way to handle this would be to use some sort of BNF
> parser generator and define the pamphlet grammar - then let the parser
> generator write us a parser.  That would of course lose us some speed,
> but if we're opening up pamphlet syntax I would say the tradeoff would
> be well worth it.  Making a literate BNF tool might also be useful down
> the line for other applications in Axiom.

I would object to that.  This is very, very, simple syntax.  You can
parse the expressions involved by hand almost as easily as you could
specify them in BNF notation -- perhaps easier.

Of course, a BNF parser-generator would be useful for other problems.

[...]
> > Yes.  I am aware for that.  Note that you need cooperation from the
> > Lisp compiler.  Again, another non-latex component to the process.
> > Another reason not to have pamphlet markup masquerade as latex.
> 
> Sure :-).  But if you don't like the LaTeX syntax, just weave it into
> something else ;-).

I would rather weave the pamphlet syntax into LaTeX, if it is LaTeX I
am interested in.

If one is convinced that latex syntax is the best, then that is fine
with me.  I really do not care that much about the syntax.  Just dont
call the file a latex file.  Call it a pamphlet, which must be
explicitly woven to generate "real" latex.

[...]
> > I have some issues with the code in cl-web, as noted above,
> > unfortunately. (again, please dont take this personally!  These are
> > just dry technical observations!)
> 
> Of course - not a problem :-).  My only concern is that the
> documentation of cl-web was a non-trivial exercise (for me, at least
> :-/) and if we are going to have to re-do this again I want to make
> sure the direction chosen is the final direction. 

We can reuse a huge part of that documentation effort.  What I am
advocating does not conflict with the traditional noweb notion.  It
expands on it.  Thus, a great deal of what you wrote applies to this
situation equally well.  I am indebted to your efforts in this
respect, as it greatly eased the prototype tool I just started working
on.

[...]
> > The correct solution is to have a pamphlet command which can either:
> >    - executes the code and generates the appropriate latex as output
> >    - or replace the command with a simple latex expression without
> >      doing any on-the fly evaluation.
> > 
> > Either behavior, and perhaps others, can be specified to weave the
> > document.
> 
> Steve, are you thinking to have chunks identify their language to the
> scanner?  Otherwise I'm not sure how the scanner will distinguish
> between input, lisp, spad, etc. in the chunk and know to evaluate only
> the input expressions.

Well, for lisp it is easy.  

If the code starts with a `(', it is Lisp :).

Seriously though.  My first response is to look at the pamphlet file
name itself.  foo.lisp.pamphlet denotes a lisp pamphlet, for example.
However, I certainly would want to be able to override the defaults
which a weave or tangle command would assume by convention.  So, yes,
I would like to have the option to say "<<chunk:boot>>=" or some such.


There is also a real advantage to be able to make these kinds of
specifications in the pamphlet file itself.

Consider how we do it today in make, where a pamphlet contains both
the boot code and the cached Lisp.  These are foo.boot.pamphlet files.
Currently, we lift the information that the root chunk <<*>> denotes
boot code and the root chunk <<clisp>> contains lisp into a the
makefiles.  Would it not be nice, for example, to have that
information available in the pamphlet itself and allow cooperation
between ASDF, say, and a Lisp based weave command to infer the the
situation itself?  Why code the same information in two places??

Note that this is not a pipe-dream.  I am working on real code which
does this reliably.

[...]
> > Axiom should be able to read pamphlets, and have them exist as
> > live objects in the system.  Should we actually require that axiom
> > write a file and call LaTeX to call itself in order to weave a
> > document?
> 
> I'm not sure what you mean by "live object".  I was viewing it as
> follows:
> 
> 1. .lisp.pamphlet and .spad.pamphlet files are loaded just as
> functionality is loaded now from these files.
> 
> 2. Axiom IO sessions inside LaTeX documents are typeset in a way
> similar to the way EMaxima handles things.  There could perhaps be an
> "evaluate all axiom expressions in this latex file" command or some
> such, but I'm not quite clear how this would make the document "live".

Consider this.  Someone is creating a new detailed algebra domain in a
fancy GUI interface which allows then to inspect and modify their
creation as they work.  This should be a familiar experience for
someone who codes in lisp or smalltalk or similar.

Our author gets their new domain working.  They click save.  A
"pamphlet" is written -- a representation of their efforts which can
be viewed just as easily in dome fancy GUI as it can in an Emacs
buffer.

In the above, where did the pamphlet originate?  I say it was a "live
object", capable of being modified and inspected by running code, by
dynamic human interaction.  The representation of a pamphlet as a file
is just a special case.

> > The Crystal, where we can view an object through a multitude of
> > facets.  We can see the API, the theorems and proofs, the category
> > hierarchy, the dependents and dependees, etc, etc...
> 
> Perhaps how we view these things is relevant to this.  For myself, most
> of these things are deduced and documents describing them can be
> generated "on the fly" with specific commands inside Axiom -
> GenerateProof(a=b,COQ) or CategoryTree(PositiveInteger) or )show api
> integrate or something like that.  I hadn't viewed the tangle/weave
> part of the system as directly having anything to do with it.

tangle/weave only have a small roll to play.  They just happen to be
the most familiar because the other operations (like dynamicly infering
the `types' of code chunks at build time),  have not yet been
invented yet.  But they will be, in time.

> > All these things have been discussed before, there are many other
> > options.  I mention these in particular because they are all
> > candidates for generating LaTeX output, but would ultimately be
> > inferred from a set of pamphlets.  You cant just run LaTeX on a
> > pamphlet and obtain that result, because pamphlets are not LaTeX.
> 
> Correct.  I would expect to do some interactive work to obtain those
> documents or at the very least run some special tools (not tangle or
> weave as such, maybe (prove-all "file.input.pamphlet") or some other
> command that builds on top of the basic scanner ability.)

Now your getting it! :)  This is precisely what I am saying.

> > Whats wrong with associating a documentation chunk as the formal
> > proof of a particular code chunks correctness?
> 
> My current (half formed) thought on that issue was to have
> pseudo-databases of the proofs themselves and get them at need (for
> generating an actual proof, or for insertion into some document).  I
> didn't figure to have every chunk and its correctness proof next to
> each other in the documents, simply because of the likely size of many
> of them (check out metamath).

How do you define the database?  How is it going to be constructed,
defined?  You need to write it down somewhere, and in the case of
axiom, it will be written down in a pamphlet.  May as well let the
pamphlets communicate the structure.

> > Or as the API doc which gets displayed when you pass the wrong type
> > to factorGroebnerBasis?
> 
> I thought API docs were very specificly terse, syntax focused messages
> that would have to be written with the idea of appearing as "error
> messages" rather than the more verbose research-paper style
> explanations.  (I'm probably missing something again, sorry...)

No, you are not missing anything.  Hence the idea of a documentation
`chunk'.  You will want to specify the API somewhere.  It could appear
in a research paper as an appendix or nowhere at all.  The very fact
that it is an option suggests to me that LaTeX is not the proper
primitive to encapsulate all that data.

For example, assume we can assign a type to a chunk, as I mentioned
above.  Then if the chunk type is Spad, feed it to the parser and ask
not for the AST, but for a list of export/documentation pairs,
extracted from the traditional +++ notation used in spad.  The +++
construct can be viewed as a special case of a "documentation chunk".

> > > Am I missing something here?  Help!
> > 
> > I hope that helps clarify my position a bit.  Lets keep discussing
> > this as I think it is of hugely important for Axiom!
> 
> It sounds like the design decision here is how much responsibility for
> processing do we specifically want to put into the weave tools.  My
> thought would be minimalist - strictly enforce the chunk style, and
> prepare additional tools/logic for operations beyond basic code
> extraction and LaTeX translation.  Which is not to say powerful tools
> aren't good, but I think they should either be inside Axiom or built as
> discrete functionality on top of the basic chunk style.

With some thought, we can define the primitives very specifically.
Indeed, weave and tangle might appear very 'high level'.

However, using just the raw notion of a `chunk' is not enough.  It
would be like trying to define mathematics using the single axiom "if
a < b and a > b, then a = b" (well, maybe not quite that extreme :).

\start
Date: 18 Jul 2007 01:18:12 -0400
From: Stephen Wilson
To: Andrey G. Grozin
Subject: re: Pamphlets and LaTex

Andrey G. Grozin writes:
[...]
> > The critical and (as I am now seeing) subtle point is that latex only
> > sees the markup as a typesetting construct, where in fact the
> > construct means a completely different thing to the absolutely
> > necessary tools like weave and tangle.
> No, I absolutely disagree with the above statement. LaTeX commands and
> environments are *not* typesetting constructs! Their puropse is to
> encode the logical structure of the document, not its visual
> (typesetting) form. Styles associate some visual meaning with various
> logical concept; one can easily change the style, and get a different
> typeset output from the same (logically) document.

Run latex on any .tex file.  You get a dvi.  I agree that latex does
an exceedingly good job of abstracting away the details of typesetting
proper.  But that ability is what makes it an extremely good
typesetter.

[...]
> If there will be a vote :-), please count my vote for the pure LaTeX
> syntax of pamphlets. This eliminates a lot of complexity: one more
> syntax to learn (with all its warts to escape << and >>, etc.), one
> tool which is no longer needed. It is easier to use the familiar LaTeX
> syntax (which was designed to encode structure, i.e., the meaning, of
> any concept). We can add as many concepts as we need. In fact, any
> author writing any non-trivial text in LaTeX always adds some new
> concepts, and this is the the use for which LaTeX has been
> designed. Some LaTeX command may mean "run this command through
> Axiom", when used in a proper context. Why not?

Why not?  Beacuse latex typesets documents.

You can use C++ templates to calculate all the prime numbers at
compile time. That does not make it the best solution to the problem.

> Entities should not be multiplied beyond necessity.

Of course not.  That is one of my main points.  Why specify something
in latex, claim that it is latex, and yet require a tool other than
latex to make use of it?  The duplicity is not that it is written down
twice rather than just once, the duplicity is that the entities needed
to describe what you wrote are replicated in various software tools,
with no clean unifying relationship.

\start
Date: Wed, 18 Jul 2007 02:30:57 -0400
From: Cliff Yapp
To: Stephen Wilson
Subject: re: Pamphlets and LaTex

Stephen Wilson wrote:
> Cliff Yapp writes:
> 
>> --- Stephen Wilson wrote:
>>
>>> What if \chunk{foo} resulted in referencing the Foo domain defined in
>>> another file?
>> I personally didn't consider it desirable to reference chunks outside
>> of a particular file - it makes it that much harder to understand.  If
>> the idea is to tangle something, I don't really like the idea of
>> tangling a source file out of multiple pamphlets.  In my opinion that
>> level of complexity is always going to cause more difficulties than any
>> advantages it might give.  I would be interested in use cases that can
>> demonstrate the benefits of such an approach - just because I can't
>> think of any certainly doesn't mean there aren't any.
> 
> Look at the algebra, for example.  Look at the interrelationships.  Do
> you want to write your algebra for Boolean in the _same_ pamphlet for
> the rest of the system which depends on it?  Do ( untested :)
> 
>      cd ./src/algebra && cat *.pamphlet > algebra.pamphlet
> 
> I expect that is the situation we would have.

No.  What I would do is have Boolean defined where it logically makes sense,
and then have Axiom itself determine inter-relatedness if I were interested
in it.  I might also include a bibtex reference to the pamphlet containing
Boolean if it were of immediate interest to the concept I happened to be
working on at the time.  Chunk level references shouldn't be necessary.


>>>     @
>>>       Introduction.
>>>     <<chunk1>>=
>>>         (code here)
>>>     <<chunk2>>=
>>>         (more code)
>>>     @
>>>        Some documentation
>>>     <<chunk3>>=
>>>          (etc...)
>>>      EOF
>> Erm.  Do we want to support a style like that?  My first thought upon
>> seeing that would be to think "badly formatted, hard to understand."
> 
> Why?

My eye is looking for chunk start -> chunk end.  Here I see chunk start
-> chunk start -> chunk end -> chunk start ...

>           @
>           The following two routines enables one to add integers, and
>           subtract them.
> 
>           <<add>>=
>               (defun add (x y) (+ x y))
>           
>           <<subtract>>=
>               (defun subtract (x y) (- x y))
> 
> I gives you freedom to organize your code in a fashion which might be
> suitable for your problem.  Note that there is absolutely no
> requirement that you must format your code that way.  The point is
> that you can, if needed.

I would find either:

           <<add>>=
               (defun add (x y) (+ x y))
           @

           <<subtract>>=
               (defun subtract (x y) (- x y))
           @

or

           <<add and substract>>=
               (defun add (x y) (+ x y))
               (defun subtract (x y) (- x y))
           @

preferable in such a case, personally - the legality of other options
just invites code that is more difficult to parse.  Just MHO of course.
 As the tool complexity required to handle the alternatives increases,
and/or the speed of processing decreases.  Is it worth the extra complexity?

We really need the guys who wanted the fast cl-web to weigh in here.
Which tradeoff do y'all want?


>>> The state machine hard wires code blocks:
>>>
>>>       <<chunk>>=
>>>           (code)
>>>       @
>> Yes.  Personally I consider this a Good Thing - the visual signature of
>> a chunk is always consistent and unique.  This makes for easier
>> pamphlet editing, in my opinion - the above example would have me
>> wondering if I was in chunk1 or chunk 2.
> 
> Its like as we have in LaTeX, \section{FOO}.  Its a header.

That syntax threw me for a loop when I was learning LaTeX, too ;-).  It
just seems tidier to me to clearly denote the beginning and end of
chunks - it aids the eye in parsing the text and keeps processing simpler.

> And as I
> said, if you want to structure your code in a way which reads more
> easily for you, there is nothing standing in your way.

Certainly.  My concern (as you have correctly noted) is that expanding
the finite state machine is a complex undertaking and most other
alternatives will lose us the speed, which I was told is quite
important.  We need more opinions here guys - speak up!


> I would object to that.  This is very, very, simple syntax.  You can
> parse the expressions involved by hand almost as easily as you could
> specify them in BNF notation -- perhaps easier.

But can we parse it with the speed the finite state machine shows?  I
don't expect a BNF parser generator could do quite as well, but perhaps
it could get close?

> Of course, a BNF parser-generator would be useful for other problems.

I think there may be a couple young efforts floating around out there.
More goodies to add to the list...

 > If one is convinced that latex syntax is the best, then that is fine
> with me.  I really do not care that much about the syntax.  Just dont
> call the file a latex file.  Call it a pamphlet, which must be
> explicitly woven to generate "real" latex.

So if I'm not mistaken, you are concerned that the assumption that LaTeX
can directly handle pamphlet files with no weave step will constrain our
options with pamphlet style later on?  That does make sense.

> Seriously though.  My first response is to look at the pamphlet file
> name itself.  foo.lisp.pamphlet denotes a lisp pamphlet, for example.
> However, I certainly would want to be able to override the defaults
> which a weave or tangle command would assume by convention.  So, yes,
> I would like to have the option to say "<<chunk:boot>>=" or some such.

Right

> There is also a real advantage to be able to make these kinds of
> specifications in the pamphlet file itself.

It makes many things easier.

> Consider how we do it today in make, where a pamphlet contains both
> the boot code and the cached Lisp.  These are foo.boot.pamphlet files.
> Currently, we lift the information that the root chunk <<*>> denotes
> boot code and the root chunk <<clisp>> contains lisp into a the
> makefiles.  Would it not be nice, for example, to have that
> information available in the pamphlet itself and allow cooperation
> between ASDF, say, and a Lisp based weave command to infer the the
> situation itself?  Why code the same information in two places??

I'm not quite sure yet how to handle weave in ASDF.  My guess is once
the pamphlet is woven operation-done-p for any other chunks in that
pamphlet will simply check, see that it's done, and move on.  Language
details shouldn't enter into it for now - maybe later that will some up.

> Note that this is not a pipe-dream.  I am working on real code which
> does this reliably.

Most impressive!

> Consider this.  Someone is creating a new detailed algebra domain in a
> fancy GUI interface which allows then to inspect and modify their
> creation as they work.  This should be a familiar experience for
> someone who codes in lisp or smalltalk or similar.

That's a programming scenario though, which is different again.  When I
think of CAS use I tend to think of the Mathematica notebook - physics
student sits down and runs his calculations.  That's why I think we need
 as many concrete usage scenarios as we can scare up here.  (I know my
thinking runs along a particular set of rails.)

> Our author gets their new domain working.  They click save.  A
> "pamphlet" is written -- a representation of their efforts which can
> be viewed just as easily in dome fancy GUI as it can in an Emacs
> buffer.

OK.

> In the above, where did the pamphlet originate?  I say it was a "live
> object", capable of being modified and inspected by running code, by
> dynamic human interaction.  The representation of a pamphlet as a file
> is just a special case.

I think there are two cases here - pamphlet writing and "end user" CAS
usage.  In the latter case, pamphlets don't even enter into it - they
just want to solve a few equations for a problem they are working on.
For pamphlet creation, I agree interactive tools are a good thing.

>>> All these things have been discussed before, there are many other
>>> options.  I mention these in particular because they are all
>>> candidates for generating LaTeX output, but would ultimately be
>>> inferred from a set of pamphlets.  You cant just run LaTeX on a
>>> pamphlet and obtain that result, because pamphlets are not LaTeX.
>>>
>> Correct.  I would expect to do some interactive work to obtain those
>> documents or at the very least run some special tools (not tangle or
>> weave as such, maybe (prove-all "file.input.pamphlet") or some other
>> command that builds on top of the basic scanner ability.)
> 
> Now your getting it! :)  This is precisely what I am saying.

OK.  I think I'm getting at an assumption I was making unconsciously.
You are proposing to include all forms of documentation associated with
a particular "chunk" of code in a single pamphlet, and depending on the
type of chunk do different processing steps to obtain different output
documents.  This is a departure from the model I was using, which was
one document for research paper, another for API only (no embedded code
chunks, just a general reference to the research paper containing the code.)

Is there a particular reason why we can't simply do something like:

asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf
asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf

<<chunkfoo>>[api]=
apiapiapiapiapiapiapi
@

<<chunkfoo>>[whatever]=
whateverwhateverwhatever
@

asdfasdfasdfasdfasdfasdfasdf

<<chunkfoo>>[spad]=
codecodecodecodecode
@

asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf
asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf


> How do you define the database?  How is it going to be constructed,
> defined?  You need to write it down somewhere, and in the case of
> axiom, it will be written down in a pamphlet.  May as well let the
> pamphlets communicate the structure.

I had envisioned it working the same way Axiom does now to load
functionality it needs - the "pseudo-database" lookup abilities.  I am
not sure that proofs will be in pamphlets, actually - there is some
question as to whether they are intended primarily as human readable
documents or tools for mechanical verification of correctness.  In the
latter case they will most likely be automatically generated and never
reach pamphlet stage.  More thinking needs to be done here.

> No, you are not missing anything.  Hence the idea of a documentation
> `chunk'.  You will want to specify the API somewhere.  It could appear
> in a research paper as an appendix or nowhere at all.  The very fact
> that it is an option suggests to me that LaTeX is not the proper
> primitive to encapsulate all that data.

Assuming you want all information pertaining to a particular code chunk
in the same pamphlet and in the same location.

> For example, assume we can assign a type to a chunk, as I mentioned
> above.  Then if the chunk type is Spad, feed it to the parser and ask
> not for the AST, but for a list of export/documentation pairs,
> extracted from the traditional +++ notation used in spad.  The +++
> construct can be viewed as a special case of a "documentation chunk".

An interesting possibility.  My only request in that respect would be to
select and stick with a single consistent method for such documentation
per-language.

> However, using just the raw notion of a `chunk' is not enough.  It
> would be like trying to define mathematics using the single axiom "if
> a < b and a > b, then a = b" (well, maybe not quite that extreme :).

I think I'm beginning to see - does the above roughly represent what
you're thinking?

\start
Date: 18 Jul 2007 08:58:56 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: votes

Tim Daly writes:

> You've made the claim twice that the gclweb change broke code.  Please give
> an example of something that broke due to the gclweb change.

LaTeX style chunk delimiters break

* Definitively mmm-mode for editing pamphlets.
* Possibly they break nested chunks.  
* Possibly they also break usage of \/ (= or) and /\ (= and) in code.

\start
Date: 18 Jul 2007 09:11:52 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: votes

Ondrej has already answered for the emotional side.  I try to add a tiny bit on
the rational side:

> Lets try a thought experiment. 
> Suppose you propose that Fricas should now be democratic. 

I would not suggest that FriCAS should become democratic.  I said I would in
fact like to have democratic and non-democratic branches side by side.  

> Suppose you suggest that Waldek's trunk should become a branch. 

Yes, that's what I would like to have.  Just as we had wh-sandbox for a long
time.  Note: I did not suggest to make wh-sandbox trunk. (Possibly once when I
was very emotional.  I apologize in case.) 

> Suppose you suggest that only approved changes go into Fricas. 

wh-sandbox always was non-democratic, and I believe it works well that way.
However, moving changes from wh-sandbox into trunk should happen in a
democratic way.

Tim Daly writes:

> Please explain why you think Axiom should be a democratic model.

Because at least three developers are fed up with the current model.  And
because I think that accomodating many different beliefs and many
uncertainities are best handled by an open, democratic model, that allows or
even encourages subcultures.

> Please explain why you feel, as a self-declared algebra developer, you have a
> need to vote on machinery (gclweb.lisp) below the algebra which enables
> function you will never use.

Because it happens to break my setup, and I feel that my setup is OK and that
LaTeX style chunk delimiters are unwise.  Since it is difficult to argue about
that on a technical level, democracy (that allows and encourages subcultures !)
may be an alternative.

Same thing goes for other decisions, for example lispifying parts of the Boot
code.  I did not protest then because I did not realize that we could have
both: an experimental branch without Boot, trunk with Boot.  And I do think
that this experimental Branch may be a *very* good thing.

I'll leave until August 9 today evening, and will not have access to mail.

\start
Date: Wed, 18 Jul 2007 13:21:55 +0200 (CEST)
From: Ayal Pinkus
To: Martin Rubey
Subject: re: votes

Hi,
As a fellow maintainer of a competing CAS system (Yacas) I have been
following recent discussions on this mailing list with great interest. It
is not unlikely that I might run in to similar problems in the future.

For what it is worth, here are a few thoughts I had.

Democracy in an open-source project
===================================
A democracy is not always the best approach. Most successful open-content
projects out there (Linux, Wiki, Slashdot, ...) have a form of moderating
system where 'trusted lieutenants' determine what goes in and what
doesn't. These people need to know what they are talking about. Linux is
complex enough that you don't want a beginner messing up the code. A CAS
is quite complex too, you need to know what you are doing. You need the
lead maintainer and his trusted lieutenants to verify that patches adhere to the long-term vision of the
system.

They are end-responsible for it in the end, including maintaining the
system. You also have the case that people add things to the system, and
then go do something else, leaving the maintainer to maintain their code.
With CAS this can be very sophisticated code rooted in deep mathematics.
The people committed to maintaining the system (for the next 30 years no
less!) *have* to understand all the parts of the system, and agree with
how it is set up.

The trusted lieutenants are not voted in through a democracy, but assigned
the role by the lead maintainer, the leader, the visionary, the owner of
the branch, who calls the shots in the end. This sounds a bit pompous,
but in practice this *is* what is needed, I believe. A democracy will not automatically lead to
better decisions per se in *every* situation. More specifically, when you
have a situation where a certain group is better informed than another
group, you need to have the better-informed group make the decisions. A
good example is an army. There you have uninformed soldiers in the field,
and informed officers (went through training in strategic warfare and get
intelligence on what the enemy is doing) at the center.

I am not suggesting that developing a CAS is similar to warfare, but one
aspect of it is the same; you have a group of better-informed individuals
who are better suited to making decisions. Better to have them take the
lead than to use a democracy and allow every one to vote with equal
weight.

Vision
======
With a big project comes a long-term vision. The leader has a vision, and
tries to get other contributors to buy in to his vision.

The vision is very important. It determines how the system develops over
time. Is the focus on cross-platform? Research? Or targeted at people
wanting to just do practical calculations? Easy to start using? Or very powerful but with a
steep learning curve? Easy to maintain code or very efficient code? Where
do we put abstraction layers that allow customization of the system for
different applications? Focus on symbolics, numerics, or some subset of
mathematics to become very good at a very specific type of calculation? Or
be general purpose? There are a lot of design decisions that need to
be made. Different ssytems (and possibly even different branches of the
same system) can be built based on different visions.

It is essential that every one working on a branch has the same vision.

Different branches are maybe not a bad idea, just like having different
systems is not a bad idea per se. The different systems have different
properties, and are useful in different situations.

\start
Date: 18 Jul 2007 13:40:49 +0200
From: Martin Rubey
To: Ayal Pinkus
Subject: re: votes

Dear Ayal,

Ayal Ayal Pinkus writes:

> A democracy is not always the best approach. 

I only claim that it would be the best for axiom, because of many differing,
and very strong opinions, and because it is at the moment, and probably even in
future, just not necessary to have only one version of axiom.  Axiom is modular
enough to have ten versions living next to each other.

> Linux is complex enough that you don't want a beginner messing up the code.

I don't mind if somebody messes up code in some branch.  But democracy (in the
version I proposed) will ensure that code is not messed up in trunk.  Not
having democracy will not save you from having messed up code.

> You need the lead maintainer and his trusted lieutenants to verify that
> patches adhere to the long-term vision of the system.

If you read my proposal carefully, you will have noticed that I would in fact
like to have different visions being pursued, in different branches, of course.

> The people committed to maintaining the system (for the next 30 years no
> less!) *have* to understand all the parts of the system, and agree with
> how it is set up.

Axiom is very fortunate: the algebra is (nearly) completely decoupled from the
interpreter and the compiler.  And all of this has very little to do with the
build system.  The situation is very very different from Maxima, for example.

> The trusted lieutenants are not voted in through a democracy, but assigned
> the role by the lead maintainer, the leader, the visionary, the owner of the
> branch, who calls the shots in the end.

That's roughly the way it is at the moment, and that's why I decided to quit.
If the democratic model or a variation of it is adopted, I'll come back and
contribute.

> A democracy will not automatically lead to better decisions per se in *every*
> situation.  More specifically, when you have a situation where a certain
> group is better informed than another group, you need to have the
> better-informed group make the decisions.

The voting system I proposed relies on cooperation just as every other system
does.  Usually people do not vote on issues they do not understand, if they are
really interested in the system moving forward.  But really, most of the time
I'd guess that problematic issues are not well understood by anybody.  In this
case, democracy can help.

> I am not suggesting that developing a CAS is similar to warfare, but one
> aspect of it is the same; you have a group of better-informed individuals who
> are better suited to making decisions.

I'd say until recently there was exactly one person in the axiom project, that
would understand most of axiom.  Now, since he has left, there remains none.  I
guess, I understand a big part of the algebra.  But I do not have a clue about
the build system.

> Better to have them take the lead than to use a democracy and allow every one
> to vote with equal weight.

No, history (in the real world) demonstrated that sooner or later this style
will be problematic for many people.

> It is essential that every one working on a branch has the same vision.

In this case, axiom can stop development immediately.

\start
Date: 18 Jul 2007 09:51:50 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: votes

Martin Rubey writes:

| Dear Ayal,
| 
| Ayal Ayal Pinkus writes:
| 
| > A democracy is not always the best approach. 


To some extent, I agree with Ayal -- judging from my own experience
and involvement in some large scale open source projects (eg. GCC).
Though I can also cite the standardization of ISO C++ (done by
volunteers who pay to work on the project) as also a counter example
to some extent.

But, I do agree with many of the fundamental points he made.  Except
having only one visionaire.  I believe having a ``college'' is better.
This is from my experience on GCC -- which had had a One Single
Visionnaire till a decade ago.   GCC is doing much much better now
than before.  It is not run by popular votes, but it is not run either
by dictatorship.  Interested people, working system engineers, those
directly affected by GCC, collaborate to come to a decision.  A
release manager coordinates all of that.  There is a steering
committee to prevent the project to be taken over by one individual or
coorporate.  But the steering committee has no say on the technical
decisions -- I believe that is a good thing, but also acknowledge
other forms.  

With Axiom, I'm seeing a repetition of the GCC history.  To prevent
further implosion I would suggest a college of `trusted' maintainers
with strong interest in Axiom, and a steering committee that takes
care of the `political issues'.

My take on this is that if Axciom is supposed to be a research plaform,
then the interested *working* scientists should participate in the
college -- not necessarily a purely democratic participation.
Because, they are affected by Axiom and Axiom affects them.  If you
don't have to base your daily research work on Axiom, then it does not
matter much whether it is operational only in 30 years on in 3000
years.

If Axiom is supposed to be just a hobby, then it makes sense that it
is just one man's toy.  But then, that should be said clearly so as
not to waste the working scientists resource.

\start
Date: Wed, 18 Jul 2007 10:52:46 -0500
From: Tim Daly
To: list
Subject: Axiom trademark

Groklaw has just put up a page related to trademarks,
both common law and registered:
http://www.groklaw.net/article.php?story070717095916179

\start
Date: 18 Jul 2007 11:55:24 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: re: debugging

Greetings!  

OK the issue is that you are setting the compiler::fixed-args property
-- a legacy function signature facility which may have even been
implemented to support axiom for all that I know.  The short fix is to
stop setting this property and let GCL figure out the signature on its
own.

In more detail, this flag was intended to allow the user to assert a
signature of the form '((t t t) t).  A better way follows acl2,
(declaim (ftype (function (t t t) t) foo)), which is supported by the
ansi standard and is compatible with the new automatic function
signature discovery mechanism.  But either signature would be wrong
here as the functions in question return double float.  These cannot
be supported via the fastlink mechanism as the return type does not
portably fit in one machine word.  GCL compiles such (at safety <=2)
as a local C function returning double, and a global wrapper boxing
the double into a lisp object.  GCL is incorrectly relying on
'fixed-args to determine that a wrapper is not necessary.

If 'fixed-args is to be kept, I need to make it compatible with the
automatic function signature discovery, but the simplest for me would
be to ignore the property, depending on axiom's needs.  It seems
redundant with declaim anyway.  Thoughts welcome.

Take care,

Waldek Hebisch writes:

> Camm Maguire wrote:
> > Greetings, and thanks!  The problem is that the global entries to the
> > functions returning double float etc. are not being writtin into
> > DFLOAT.c.  I'm trying to debug by reproducing the compile-file step on
> > DFLOAT.lsp.  This fails at the lisp prompt:
> > 
> > (compile-file "DFLOAT.NRLIB/DFLOAT.lsp")
> > 
> > ; (DEFUN |DFLOAT;manexp| ...) is being compiled.
> > ;;; The tag #:G2017215 is undefined.
> > ; (DEFUN |DFLOAT;rationalApproximation;$2NniF;84| ...) is being compiled.
> > ;;; The tag #:G2017237 is undefined.
> > ;;; The tag G190 is undefined.
> > ; (DEFUN |DFLOAT;**;$F$;85| ...) is being compiled.
> > ;;; The tag #:G2017246 is undefined.
> > ;;; The tag #:G2017246 is undefined.
> > No FASL generated.
> > 
> > Error: 
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Signalled by BREAK.
> > Condition in BREAK [or a callee]: INTERNAL-SIMPLE-PROGRAM-ERROR: Compilation of "DFLOAT.NRLIB/DFLOAT.lsp" failed.
> > 
> > Broken at BREAK.  Type :H for Help.
> >  1 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
> >  2 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
> >  3 (Abort) Return to debug level 2.
> >  4 (Continue) Return from break.
> >  5 Return to top level.
> > COMPILER>>
> >
> > Then I try )co "DFLOAT.spad" from the axiom prompt:
> > 
> > )co "DFLOAT.spad"
> >    Your command is ambiguous. The following are abbreviated by co :
> >       compiler 
> >       copyright 
> > (1) -> )quit
> >    Please enter y or yes if you really want to leave the interactive 
> >       environment and return to the operating system:
> > y
> >    You have chosen to remain in the AXIOM interactive environment.
> > (1) -> 
> > (1) -> 
> > Program exited normally.
> > 
> > So I try a fresh interpsys, set the stage 1 bootstrap mode flag, And
> > find a very long chain of compiles which must proceed before I can
> > compile DFLOAT.  
> > 
> > I'm sure I'm just making some simple mistake, but how can one rebuild
> > just DFLOAT from any given stage in the build?  This will enable me to
> > fix this.
> >
> 
> All Axiom generated Lisp file use special macros, present in interpsys.
> Theoretically all macros are also present in depsys image, but I did
> not check if depsys works for Lisp compilation of algebra files.
> Error messages from Lisp compilation probably can be explained by lack
> of macros.  But behavoir of ')co' (and also ')quit') command looks
> strange -- I prefer to always use full version ')compile', but for
> me ')co' starts compilation.  Also the
> 
> "You have chosen to remain in the AXIOM interactive environment."
> 
> message looks like a bug.
> 
> Spad compilation is slightly more tricky: given spad file may require
> that several other files are compiled earlier.  When Spad compiler
> operates in default mode there are cyclic dependencies.  Basically the
> whole bootstrap procedure is to fight with those cyclic dependencies.
> Stage 1 of bootstrap must go in a rather rigid order.  After stage 1 of
> bootstrap it should be possible to compile all Spad files using special
> |$bootstrapDomains| flag.  Once Stage 2 is finished it should be
> possible to compile all normal mode.  
> 
> If you want to compile a single file after stage 1 finished do the following.
> 
> 1) start interpsys, you need to correctly set up AXIOM and DAASE variables,
>    for me the it is below:
> 
> ( export AXIOM=/h/axp62/ax-build2/target/x86_64-unknown-linux; export DAASE=/h/axp62/wh-sandbox/src/share; /h/axp62/ax-build2/build/x86_64-unknown-linux/bin/interpsys )
> 
> 2) for stage 2 compilation set the |$bootstrapDomains| flag:
> 
> )lisp (setf |$bootstrapDomains| t)
> 
> Value = T
> 
> 3) issue compilation command:
> 
> (2) -> )compile "DFLOAT.spad"
> 
> 
> If you want you can also do Lisp compilation:
> 
> (1) -> )lisp (compile-file "DFLOAT.NRLIB/DFLOAT.lsp")
> 
> Value = #P"/h/axp62/ax-build2/src/algebra/DFLOAT.NRLIB/DFLOAT.o"
> (1) ->
> 
> Trying the above I noticed that doing by hand stage 2 compilation of
> "DFLOAT.spad" I can also do stage 3 compilation of "DFLOAT.spad".
> So the problem seem to appear only if I do all compilations in a
> single image...
> 
> Normally Lisp files from stage 2 compilation are deleted before
> starting stage 3 compilation.  I changed the Makefile to capture
> the result from stage 2 compilation.  Comparing with the Lisp file
> obtained separately I see some differences, but none which can explain
> different behavior of object code.
> 
\start
Date: 18 Jul 2007 12:26:05 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: re: Pamphlets and LaTex

Cliff,

In some ways the discussion has strayed from the original question "is
latex the best vehicle for describing pamphlets?".  Thanks OK though.


Cliff Yapp writes:
[...]
> > Look at the algebra, for example.  Look at the interrelationships.  Do
> > you want to write your algebra for Boolean in the _same_ pamphlet for
> > the rest of the system which depends on it?  Do ( untested :)
> > 
> >      cd ./src/algebra && cat *.pamphlet > algebra.pamphlet
> > 
> > I expect that is the situation we would have.
> 
> No.  What I would do is have Boolean defined where it logically makes sense,
> and then have Axiom itself determine inter-relatedness if I were interested
> in it.  I might also include a bibtex reference to the pamphlet containing
> Boolean if it were of immediate interest to the concept I happened to be
> working on at the time.  Chunk level references shouldn't be necessary.

OK.  The inter-file \chunk{foo} reference was a bad example of
something a weave tool could understand but latex could not, for most
practical purposes.  Im reaching for simple examples here.


[...]
> I would find either:
> 
>            <<add>>=
>                (defun add (x y) (+ x y))
>            @
> 
>            <<subtract>>=
>                (defun subtract (x y) (- x y))
>            @
> 
> or
> 
>            <<add and substract>>=
>                (defun add (x y) (+ x y))
>                (defun subtract (x y) (- x y))
>            @
> 
> preferable in such a case, personally - the legality of other options
> just invites code that is more difficult to parse.  Just MHO of course.
>  As the tool complexity required to handle the alternatives increases,
> and/or the speed of processing decreases.  Is it worth the extra complexity?

I dont think there is anything difficult or complex about it, this is
pretty simple syntax.

[...]
> You are proposing to include all forms of documentation associated with
> a particular "chunk" of code in a single pamphlet, and depending on the
> type of chunk do different processing steps to obtain different output
> documents.  This is a departure from the model I was using, which was
> one document for research paper, another for API only (no embedded code
> chunks, just a general reference to the research paper containing the code.)

I dont think anything I have been saying says "put all your
documentation here".  Im not really advocating any kind of structure
at all.  Im just looking at the problem space and seeing something
which is not LaTeX.

However, we need tools which would support your particular needs as an
author and programmer.

> Is there a particular reason why we can't simply do something like:
<snip>

Something along those lines is possible, absolutely.

[...]
> > No, you are not missing anything.  Hence the idea of a documentation
> > `chunk'.  You will want to specify the API somewhere.  It could appear
> > in a research paper as an appendix or nowhere at all.  The very fact
> > that it is an option suggests to me that LaTeX is not the proper
> > primitive to encapsulate all that data.
> 
> Assuming you want all information pertaining to a particular code chunk
> in the same pamphlet and in the same location.

I am not sure why it needs to be in the same pamphlet?

> > For example, assume we can assign a type to a chunk, as I mentioned
> > above.  Then if the chunk type is Spad, feed it to the parser and ask
> > not for the AST, but for a list of export/documentation pairs,
> > extracted from the traditional +++ notation used in spad.  The +++
> > construct can be viewed as a special case of a "documentation chunk".
> 
> An interesting possibility.  My only request in that respect would be to
> select and stick with a single consistent method for such documentation
> per-language.

Lets use +++ comments for spad, docstrings for lisp.  I am not aware
of a convention for boot, probably just preceding a function with --
comments would be enough for now. 

\start
Date: 18 Jul 2007 11:51:52 -0500
From: Gabriel Dos Reis
To: Camm Maguire
Subject: re: debugging

Camm Maguire writes:

[...]

| If 'fixed-args is to be kept, I need to make it compatible with the
| automatic function signature discovery, but the simplest for me would
| be to ignore the property, depending on axiom's needs.  It seems
| redundant with declaim anyway.  Thoughts welcome.

Axiom should be fixed not to use 'fixed-args.

\start
Date: Wed, 18 Jul 2007 12:09:52 -0700 (PDT)
From: Cliff Yapp
To: Stephen Wilson
Subject: re: Pamphlets and LaTex

--- Stephen Wilson wrote:

> Cliff,
> 
> In some ways the discussion has strayed from the original question
> "is latex the best vehicle for describing pamphlets?".  Thanks OK
> though.

Well, that discussion is tied up with what we want pamphlets to do ;-).

> OK.  The inter-file \chunk{foo} reference was a bad example of
> something a weave tool could understand but latex could not, for most
> practical purposes.  Im reaching for simple examples here.
 
Sure, no problem.  I think it might be that only in the complex cases
does LaTeX becomes unsuitable - not completely sure though.

> > I would find either:
> > 
> >            <<add>>=
> >                (defun add (x y) (+ x y))
> >            @
> > 
> >            <<subtract>>=
> >                (defun subtract (x y) (- x y))
> >            @
> > 
> > or
> > 
> >            <<add and substract>>=
> >                (defun add (x y) (+ x y))
> >                (defun subtract (x y) (- x y))
> >            @
> > 
> > preferable in such a case, personally - the legality of other
> > options just invites code that is more difficult to parse.  Just
> > MHO of course.  As the tool complexity required to handle the
> > alternatives increases, and/or the speed of processing decreases. 
> > Is it worth the extra complexity?
> 
> I dont think there is anything difficult or complex about it, this is
> pretty simple syntax.

OK, what about the readibility issue?  Does anyone else agree that a
strict syntax makes for easier reading and editing or is that just me?

> I dont think anything I have been saying says "put all your
> documentation here".  Im not really advocating any kind of structure
> at all.  Im just looking at the problem space and seeing something
> which is not LaTeX.

OK.
 
> However, we need tools which would support your particular needs as
> an author and programmer.

It's fairly hard to define those tools without understanding the needs,
which is why I've been trying to wrap my brain around the cases you are
proposing.

> > Is there a particular reason why we can't simply do something like:
> <snip>
> 
> Something along those lines is possible, absolutely.

If that is acceptable, it is almost certainly possible to have the
finite state based cl-web support it.  Unless you prefer to remove the
finite state based code regardless, I can take a stab at adding this
functionality and doing some basic demos.

> > Assuming you want all information pertaining to a particular code
> > chunk in the same pamphlet and in the same location.
> 
> I am not sure why it needs to be in the same pamphlet?

For simplicity.  When editing the code chunk, it is much simpler to
have all documentation (API, research, etc.) pertaining to that chunk
to be immediately available for any updates.

> Lets use +++ comments for spad, docstrings for lisp.  I am not aware
> of a convention for boot, probably just preceding a function with --
> comments would be enough for now. 

Sounds good.

\start
Date: 18 Jul 2007 20:38:11 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: re: Pamphlets and LaTex

Cliff Yapp writes:
> > In some ways the discussion has strayed from the original question
> > "is latex the best vehicle for describing pamphlets?".  Thanks OK
> > though.
> 
> Well, that discussion is tied up with what we want pamphlets to do ;-).

Not really.  Even if all we want is functionality equivalent to what
noweb provides, my objections to using LaTex are still relevant.  It
just so happens that when considering new functionality, the
difficulties become even more involved.

[...]
> > However, we need tools which would support your particular needs as
> > an author and programmer.
> 
> It's fairly hard to define those tools without understanding the needs,
> which is why I've been trying to wrap my brain around the cases you are
> proposing.

>From the start I suggested we use a simple noweb-like syntax and go
from there, as I feel it is sufficient to build further functionality
on top of in the future.

> > > Is there a particular reason why we can't simply do something like:
> > <snip>
> > 
> > Something along those lines is possible, absolutely.
> 
> If that is acceptable, it is almost certainly possible to have the
> finite state based cl-web support it.  Unless you prefer to remove the
> finite state based code regardless, I can take a stab at adding this
> functionality and doing some basic demos.

I have absolutely no issue with you working on cl-web.  I have issues
with the code.  If the end result is that we have 350 lines of code
which is opaquely indexing raw arrays, and which still needs to be
macro expanded into a state machine (as is the case currently with
cl-web), I will need to object.  As you know, I am working on my own
implementation which handles a more general chunk structure then
cl-web and it does its work in 100 clean lines without copious use of
macros.  Of course, my objection may not count for much in the end.


So basically, if it is something you want to do, go for it :) If
someone tells me they think some work of mine is flawed in some way
that would not necessarily stop me from plugging away at it!

\start
Date: Thu, 19 Jul 2007 03:49:25 +0200 (CEST)
From: Waldek Hebisch
To: Camm Maguire
Subject: re: debugging

> Greetings!  
> 
> OK the issue is that you are setting the compiler::fixed-args property
> -- a legacy function signature facility which may have even been
> implemented to support axiom for all that I know.  The short fix is to
> stop setting this property and let GCL figure out the signature on its
> own.
>

Thanks, I have disabled setting fixed-args property.  This allowed
to go trough algebra at safety 1.  To dump databases I needed to
upgrade gcl to current cvs.  I see rather bad test results.  It is
possible that some problems are due to upgraging gcl during the
build, so I started a fresh one.
 
> In more detail, this flag was intended to allow the user to assert a
> signature of the form '((t t t) t).  A better way follows acl2,
> (declaim (ftype (function (t t t) t) foo)), which is supported by the
> ansi standard and is compatible with the new automatic function
> signature discovery mechanism.  But either signature would be wrong
> here as the functions in question return double float.  These cannot
> be supported via the fastlink mechanism as the return type does not
> portably fit in one machine word.  GCL compiles such (at safety <=2)
> as a local C function returning double, and a global wrapper boxing
> the double into a lisp object.  GCL is incorrectly relying on
> 'fixed-args to determine that a wrapper is not necessary.
> 
> If 'fixed-args is to be kept, I need to make it compatible with the
> automatic function signature discovery, but the simplest for me would
> be to ignore the property, depending on axiom's needs.  It seems
> redundant with declaim anyway.  Thoughts welcome.
>

I would like the 'fixed-args property to go away.  However, we
need to some work to make Axiom faster and to know which
techniques are effective.

\start
Date: Wed, 18 Jul 2007 19:02:30 -0700 (PDT)
From: Cliff Yapp
To: Stephen Wilson
Subject: re: Pamphlets and LaTex

--- Stephen Wilson wrote:

> Cliff Yapp writes:
> > Well, that discussion is tied up with what we want pamphlets to do
> > ;-).
> 
> Not really.  Even if all we want is functionality equivalent to what
> noweb provides, my objections to using LaTex are still relevant.  It
> just so happens that when considering new functionality, the
> difficulties become even more involved.

I think I'm understanding enough to agree that the weave step should
stay with us.

> From the start I suggested we use a simple noweb-like syntax and go
> from there, as I feel it is sufficient to build further functionality
> on top of in the future.

I would tend to agree.
 
> > If that is acceptable, it is almost certainly possible to have the
> > finite state based cl-web support it.  Unless you prefer to remove
> > the finite state based code regardless, I can take a stab at adding
> > this functionality and doing some basic demos.
> 
> I have absolutely no issue with you working on cl-web.  I have issues
> with the code.  If the end result is that we have 350 lines of code
> which is opaquely indexing raw arrays, and which still needs to be
> macro expanded into a state machine (as is the case currently with
> cl-web), I will need to object.

Fair enough.  I have a feeling I know the answer, but just to be sure -
is there anything I can do on the documentation side that will make it
less opaque?

> As you know, I am working on my own
> implementation which handles a more general chunk structure then
> cl-web and it does its work in 100 clean lines without copious use of
> macros.  Of course, my objection may not count for much in the end.

That sounds preferable to me in concept as well.  I originally didn't
start with the state machine - that was driven by performance concerns
only.

Gaby, you originally replied that you thought the speed was important:
http://lists.nongnu.org/archive/html/axiom-developer/2007-02/msg00154.html
I would appreciate it if you could weigh in on this discussion, when
you get a chance. 
 
> So basically, if it is something you want to do, go for it :) If
> someone tells me they think some work of mine is flawed in some way
> that would not necessarily stop me from plugging away at it!

It's more a question of "what do I do to best forward the goal of no
one having to come back and do this again later?"  cl-web was
apparently a failure in that respect - my current goal is to understand
what needs to be done to ensure it doesn't happen again.

\start
Date: 18 Jul 2007 22:51:04 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: re: Pamphlets and LaTex

Cliff, *,

Just for the record, I delved into the pamphlet-as-latex thing head
first and implemented my own noweb-like tool because I wanted to
enrich my understanding of the issues.  The timing was motivated by
the steadfast insistence by Martin and Ralf that they did not want to
see the latex change migrate into trunk.  I do not want to see either
of them leave, as I greatly value their insights and work.  However,
that is not enough (for me) to say that the latex change should not
occur.

I eventually came to what I hope is technical, objective, position as
to why pamphlets-as-latex is not the correct approach.  At the same
time I am trying to advocate a perspective about what pamphlets _can_
become which is consistent (I hope) with Tim's vision.

I sincerely hope that others will chime in and back the approach I am
advocating, or perhaps something simillar.  I have yet to see what is
lost by adopting it.

\start
Date: Wed, 18 Jul 2007 20:35:04 -0700 (PDT)
From: Cliff Yapp
To: Stephen Wilson
Subject: re: Pamphlets and LaTex

--- Stephen Wilson wrote:

> Cliff, *,
> 
> Just for the record, I delved into the pamphlet-as-latex thing head
> first and implemented my own noweb-like tool because I wanted to
> enrich my understanding of the issues.

That's always an excellent reason :-).

> The timing was motivated by
> the steadfast insistence by Martin and Ralf that they did not want to
> see the latex change migrate into trunk.  I do not want to see either
> of them leave, as I greatly value their insights and work.  However,
> that is not enough (for me) to say that the latex change should not
> occur.

Correct.  If possible, objective evaluation criteria should be found.

> I eventually came to what I hope is technical, objective, position as
> to why pamphlets-as-latex is not the correct approach.  At the same
> time I am trying to advocate a perspective about what pamphlets _can_
> become which is consistent (I hope) with Tim's vision.

I hope I have understood your arguments, and if I have I agree - the
weave step and typing of chunks is sufficiently advantageous that it is
worth maintaining the separation.

> I sincerely hope that others will chime in and back the approach I am
> advocating, or perhaps something simillar.  I have yet to see what is
> lost by adopting it.

I second that hope - so far it's just been a couple of players.  How
about it, y'all?

(Steve, I do plan to go over your code in more detail, once I get time
- work has been very time consuming the last few days and that has
slowed me down :-(. )

\start
Date: 18 Jul 2007 23:43:19 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: re: Pamphlets and LaTex

Cliff Yapp writes:
> (Steve, I do plan to go over your code in more detail, once I get time
> - work has been very time consuming the last few days and that has
> slowed me down :-(. )

Not to worry, the code has changed quite a bit since I sent you that
last copy.  When you have the time, just ask and I will send you the
latest.  That way you will get any bug fixes, new features, etc, which
get implemented between now and then.

\start
Date: 19 Jul 2007 00:01:25 -0400
From: Stephen Wilson
To: Martin Rubey
Subject: re: votes

Dear Martin,

I have not responded to your proposal yet because it has taken me some
time to consider.  But I think now I have settled on my position.

I do not believe that a vote is necessary, in any strong sense of the
term.  I would much rather, as William Sit so eloquently wrote on the
Wiki page, work towards an environment of "creative cooperations and
mutual trust".   It is only then that we can openly discuss,
criticize, and debate with some real prospect for agreement in the
end.  Votes alone cannot do that.

Martin Rubey writes:
> > The trusted lieutenants are not voted in through a democracy, but assigned
> > the role by the lead maintainer, the leader, the visionary, the owner of the
> > branch, who calls the shots in the end.
> 
> That's roughly the way it is at the moment, and that's why I decided to quit.
> If the democratic model or a variation of it is adopted, I'll come back and
> contribute.

The above comment struck me as being very much against the very
principles you are advocating.  You wrote in your original development
plan:

  Before you approve or disapprove, please try to envision how you
  will feel if your favourite patch does not make it into trunk,
  because there is a vote against it, and how you will feel if some
  large change takes place in trunk you are not happy with.
  Furthermore, will you be able to vote, independently and without
  being afraid of other peoples reactions?


I ask that you consider the notion that mutual respect and cooperation
can serve as a basis for the Axiom community.  The only trick is that
it takes everyone involved to make an effort in that direction.

\start
Date: Thu, 19 Jul 2007 01:57:36 -0500
From: Tim Daly
To: Martin Rubey
Subject: Democracy!

Martin,

I've given the matter much thought and I've decided to agree with you.

Axiom is now a democracy. You, as the leader of the movement and the
person who proposed the structure, are now the person who is in charge.

Silver is now yours to maintain.

I will work exclusively in a branch and, like everyone else, I will
submit diff-Naur patches to the list. These patches will be voted on
like everyone else's.

The last time I stepped away from the lead developer role Axiom
development stopped. No one changed anything. No one decided to
lead. This time I feel that you have a responsibilty to carry thru
with your vision and make sure that silver is properly maintained.  
I only ask that you maintain and expand silver. 

Congratulations, Mr. President. The future of Axiom is now in your hands.

\start
Date: Thu, 19 Jul 2007 10:01:40 +0200 (CEST)
From: Ayal Pinkus
To: Martin Rubey
Subject: re: votes

Hi Martin,

>
> If you read my proposal carefully, you will have noticed that I would in fact
> like to have different visions being pursued, in different branches, of course.
>

You might be right there. Although technically I would call it a
fork... Semantics. But that might indeed be the best approach. I am of the
belief that different systems are not bad per se. They are aimed at doing
different things.



>
> Axiom is very fortunate: the algebra is (nearly) completely decoupled from the
> interpreter and the compiler.  And all of this has very little to do with the
> build system.  The situation is very very different from Maxima, for example.
>


You isolated one property of Maxima, one for which Axiom is perhaps a
better system. But there are many properties to Maxima, and some probably
better in Maxima than in Axiom. I believe it is good to have different
systems with different properties. Design decisions are most of the time
trade-offs, hence the use for different systems (different trade-offs).
Systems like Maxima and Axiom are so different from each other that it
would probably be difficult to even share code between the two systems.
They are both useful in different domains.



> That's roughly the way it is at the moment, and that's why I decided to
quit.
> If the democratic model or a variation of it is adopted, I'll come back and
> contribute.
>

But you could just fork off in to an independent project couldn't you?


> The voting system I proposed relies on cooperation just as every other system
> does.
>

Name one successful system where there are no laws laid down a priori and
no police or equivalent to uphold those laws, and every decision is
arrived at through voting.



>
> No, history (in the real world) demonstrated that sooner or later this style
> will be problematic for many people.
>

I hope you are wrong. I believe that most family households are not a
democracy. The parents lay down the law, and the children do not get to
vote. I am hoping most of these families are happy ones. Until the
children grow up, the parents know more about life, and thus they make
the rules.



> > It is essential that every one working on a branch has the same vision.
>
> In this case, axiom can stop development immediately.
>

Not necessarily. Just create a fork of the project, and pursue the
different vision in that fork.

\start
Date: 19 Jul 2007 04:03:04 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: Pamphlets and LaTex

Cliff Yapp writes:

| Gaby, you originally replied that you thought the speed was important:
| http://lists.nongnu.org/archive/html/axiom-developer/2007-02/msg00154.html
| I would appreciate it if you could weigh in on this discussion, when
| you get a chance. 

I have been trying desperately to stay quiet in this discussion. :-)

>From my perspective, a replacement of noweb with a noticeable increase
of build time is non tolerable.  I value developer time as much as 
I value user time.  Longer build time means few build cycles.

I'll seen the slipery slope in GCC come the point where even people
who previously supported increase time will now ferously fight any
measurable increase, be it 0.5%.

So my conclusion is:

  (1) ideally, we should not increase build time.  And if we must, then
      there must be clearly identified benefits that we believe
      are good for the long term.

  (2) we should not gratuiteously break development environments.

[...]

| > So basically, if it is something you want to do, go for it :) If
| > someone tells me they think some work of mine is flawed in some way
| > that would not necessarily stop me from plugging away at it!
| 
| It's more a question of "what do I do to best forward the goal of no
| one having to come back and do this again later?"  cl-web was
| apparently a failure in that respect - my current goal is to understand
| what needs to be done to ensure it doesn't happen again.

We are dealing with computers and software, not abstract theorems :-)

\start
Date: 19 Jul 2007 04:35:20 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Democracy!

Tim Daly writes:

| Martin,
| 
| I've given the matter much thought and I've decided to agree with you.
| 
| Axiom is now a democracy. You, as the leader of the movement and the
| person who proposed the structure, are now the person who is in charge.
| 
| Silver is now yours to maintain.

So, is it correct that your answer to "get more inclusive" is 
"I'm stepping away"?

\start
Date: Thu, 19 Jul 2007 04:56:51 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Democracy!

Gaby,

> So, is it correct that your answer to "get more inclusive" is
> "I'm stepping away"?

Perhaps I wasn't clear.
I'm stepping away from the lead developer role (ala last November).
I'm not stepping away from the project.

I plan to spend my time making changes I believe are in the long term
interests of the project. Per Martin's vision (as I understand it) I
should be making these changes in my own branch. When I have something
to contribute I post a diff-Naur patch and the patch gets voted on. If
the majority vote yes the measure passes and the patch is accepted.

I'm not sure how Martin plans to garner 49 votes for anything but 
that's his problem to solve. I say 49 votes because there are 97
people registered on the mailing list. Every "democratic" process
I'm aware of requires at least a simple majority to "pass". If an
insufficient number of people vote, for whatever reason, the measure 
is dropped.

I'm also waiting for Martin to create a branch, merge his algebra,
and post a patch so we can vote on it.

\start
Date: Thu, 19 Jul 2007 05:20:20 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: re: Pamphlets and LaTex

--- Gabriel Dos Reis wrote:

> Cliff Yapp writes:
> 
> | Gaby, you originally replied that you thought the speed was
> important:
> |
>
http://lists.nongnu.org/archive/html/axiom-developer/2007-02/msg00154.html
> | I would appreciate it if you could weigh in on this discussion,
> | when you get a chance. 
> 
> I have been trying desperately to stay quiet in this discussion. :-)

Auugh ;-).  Don't do that - I'm not the strongest advocate for speed
and speed was the reason for doing cl-web the way we did it.

> From my perspective, a replacement of noweb with a noticeable
> increase of build time is non tolerable.  I value developer time as
> much as  I value user time.  Longer build time means few build
cycles.
> 
> I'll seen the slippery slope in GCC come the point where even people
> who previously supported increase time will now ferociously fight any
> measurable increase, be it 0.5%.

I take it the concern is a lot of small slowdowns can mean a noticeably
large slowdown when added up?

> So my conclusion is:
> 
>   (1) ideally, we should not increase build time.  And if we must,
>       then there must be clearly identified benefits that we believe
>       are good for the long term.

Would increased power for chunk syntax be (in your opinion) sufficient
justification for a slower build?  To me the question is not an obvious
one, and I was hoping some more people would weigh in on this point.

I think I can offer some flexibility with the inclusion of an options
box in the chunk syntax (no idea how noweb would react to that,
unfortunately...) that lets a developer designate a chunk as lisp,
SPAD, api, what have you.  Theoretically, a list of options with
information about the chunk would allow various functions to deal with
different types of chunks differently.  It would not allow an unlimited
range of syntax constructs, but I personally think a simple and
consistent style is its own reward.  A lot of the grief in web
development has come about because browsers attempted to work with
invalid syntax - it gave us joys like IE only websites.  I am very
dubious that additional syntax alternatives are worth the hassles they
can cause.

Although I personally prefer chunks that are visually well defined, as
I am thinking about it it may actually be possible (with some work) to
have a new chunk definition double as the end of the previous chunk -
do people actually want this?  It would also complicate any syntax
highlighting routines in an editor...  Is typing the extra @ really
that much of an inconvenience?
 
>   (2) we should not gratuitously break development environments.

You mean things like Emacs modes?

> | > So basically, if it is something you want to do, go for it :) If
> | > someone tells me they think some work of mine is flawed in some
> | > way that would not necessarily stop me from plugging away at it!
> | 
> | It's more a question of "what do I do to best forward the goal of
> | no one having to come back and do this again later?"  cl-web was
> | apparently a failure in that respect - my current goal is to
> | understand what needs to be done to ensure it doesn't happen again.
> 
> We are dealing with computers and software, not abstract theorems :-)

Exactly - I want to get to the part where we ARE dealing with abstract
theorems, and in the computer too ;-).  Until we get this set up
properly, we can't.

I will attempt to go over Steve's code this weekend and see what he is
doing.

An appeal to any really skilled Lisp coders out there (oh Tim...) - can
you examine cl-web and give me some direction on how it might be
re-written to be more easily understood and maybe somewhat more
flexible without losing speed?  Does gclweb provide the same speed? 
Kai had some code that implemented a finite state machine generator,
perhaps I can revisit that and use it to make specifying the state
machine more easily understandable...

Perhaps it is not possible to both achieve the speed and keep the code
easily understandable/flexible, but I would like to arrive at a
solution in Lisp that everyone can support.

\start
Date: Thu, 19 Jul 2007 07:42:39 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: Pamphlets and LaTex

On Thu, 19 Jul 2007, C Y wrote:

| > From my perspective, a replacement of noweb with a noticeable
| > increase of build time is non tolerable.  I value developer time as
| > much as  I value user time.  Longer build time means few build
| cycles.
| > 
| > I'll seen the slippery slope in GCC come the point where even people
| > who previously supported increase time will now ferociously fight any
| > measurable increase, be it 0.5%.
| 
| I take it the concern is a lot of small slowdowns can mean a noticeably
| large slowdown when added up?

Oh yes.  If you google for "GCC" and "compile-time performance", you
should have longish threads.  I know of at least one coorporate who
takes that issue very seriously (long before it became an issue for
the whole community) and was willing to pay contractors to improve the 
compile-time performance.

| > So my conclusion is:
| > 
| >   (1) ideally, we should not increase build time.  And if we must,
| >       then there must be clearly identified benefits that we believe
| >       are good for the long term.
| 
| Would increased power for chunk syntax be (in your opinion) sufficient
| justification for a slower build?  To me the question is not an obvious
| one, and I was hoping some more people would weigh in on this point.

Indeed, it is not obvious.  Last time we talked about it, the increase
was oder of magnitude.  Do you have new data?

Do you have a summary of what is gained, what is lost?
I've heard people upset because their development environements are
broken.

[...]

| >   (2) we should not gratuitously break development environments.
| 
| You mean things like Emacs modes?

Yes -- I think that is part of people's concern...

[...]

| > | It's more a question of "what do I do to best forward the goal of
| > | no one having to come back and do this again later?"  cl-web was
| > | apparently a failure in that respect - my current goal is to
| > | understand what needs to be done to ensure it doesn't happen again.
| > 
| > We are dealing with computers and software, not abstract theorems :-)
| 
| Exactly - I want to get to the part where we ARE dealing with abstract
| theorems, and in the computer too ;-).  Until we get this set up
| properly, we can't.

My point is that the fundamental technology that drives the computers
is moving fast, and you're aiming at a moving target.  That is unlike the
fundmental technology behind abstract algebra.

\start
Date: Thu, 19 Jul 2007 23:33:47 +1000
From: Alasdair McAndrew
To: list
Subject: Open source development - a useful resource

I have been watching the various kerfuffles for a while, staying
mostly quiet myself, seeing as I know nothing about open-source
development.  But I have been doing some research, and have come
across this useful resource:

"Producing Open Source Software" by Karl Fogel, at
http://producingoss.com/html-chunk/

It seems that chapter 4, "Social and Political Infrastructure", is
germane to much of the current discussion.

\start
Date: Thu, 19 Jul 2007 06:58:11 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: re: Pamphlets and LaTex

--- Gabriel Dos Reis wrote:

> Oh yes.  If you google for "GCC" and "compile-time performance", you
> should have longish threads.  I know of at least one coorporate who
> takes that issue very seriously (long before it became an issue for
> the whole community) and was willing to pay contractors to improve
> the compile-time performance.

OK, that's good to bear in mind.

> | Would increased power for chunk syntax be (in your opinion)
> | sufficient justification for a slower build?  To me the question
> | is not an obvious one, and I was hoping some more people would
> | weigh in on this point.
> 
> Indeed, it is not obvious.  Last time we talked about it, the
> increase was oder of magnitude.  Do you have new data?

You mean my original code vs. the finite state machine?  The original
code was almost certainly neither fast or flexible, so it's out.  Of
more interest is Steve's new work.  I don't know how it does on speed
trials.  Steve, have you had a chance to run any benchmarks?

> Do you have a summary of what is gained, what is lost?
> I've heard people upset because their development environements are
> broken.

That's only a consequence of changing from <<>>= to \begin{chunk}... I
don't have any particular opinion about that personally, but I am
beginning to share Steve's concern that we shouldn't be trying to
replace the weave step.  We can still weave \begin{chunk}... just as
well as <<>>= - it's all just strings, in the end - but if we aren't
getting rid of weave I prefer the <<>>= syntax - less typing ;-).  It
also has the benefit of Emacs modes which are already working.

Of more concern is the rather interesting possibility of chunks that
are intended to appear in neither a woven document (in the current
sense) or a tangled document.  The possibility of such environments, or
other (more elaborate) behavior would make LaTeX processing
increasingly complex and in some cases would necessitate a weave step
anyway (short of implementing some things in TeX that it wasn't really
designed for, as far as I can tell...)  The deeper concern is that
making an assumption of no weaving step constrains what can be done
with chunks, and I am thinking there is some merit to that concern.

So here are the pros and cons as I currently know them, without doing a
detailed study and benchmarking of Steve's new code:

Finite State solution:
+ Very fast
- Inherently complex
- Not flexible in what chunk syntax it allows
+ Can be extended to support <<chunkname>>[option1,option2]=

Other solutions:
+ Simpler to code and understand
- Probably slower
+ Flexible with respect to syntax
+ Can be extended to support arbitrary chunk structures.

Whether syntax flexibility is a plus or a minus depends on your
priorities - personally I favor enforcing one (fairly strict) structure
with the options extension, rather than allowing a new chunk start to
also serve as a chunk terminator and other noweb abilities.  It makes
processing easier for the finite state machine, but I would prefer that
anyway - for me, a uniform, easy to parse chunk style is also easier to
read.
> 
> | >   (2) we should not gratuitously break development environments.
> | 
> | You mean things like Emacs modes?
> 
> Yes -- I think that is part of people's concern...

Unless I'm missing something, the use of \begin{chunk}{ instead of <<
and other such substitutions is the only hangup for that type of issue.
  Hopefully, judicious string substitution in the .el files defining
the modes would be all that is needed.  However, losing the weave step
as a basic assumption, as outlined by Steve, have potential long term
implications.

(I would be curious how AucTeX handles the verbatim environment -
presumably its handling of that would relate to its formatting of chunk
environments of this type.  mmm-mode I'm less sure about, presumably it
would simply need to know about the new strings...)
 
> | Exactly - I want to get to the part where we ARE dealing with
> | abstract theorems, and in the computer too ;-).  Until we get this
> | set up properly, we can't.
> 
> My point is that the fundamental technology that drives the computers
> is moving fast, and you're aiming at a moving target.  That is unlike
> the fundmental technology behind abstract algebra.

A Lisp environment isn't a moving target, most of the time - at least
the ANSI Lisp specification hasn't moved in many years.  That's the
whole point of high level languages and specifications in the first
place - to abstract the logic above the computer technology of the day
and make something well defined to target.

There are of course situations where you can't do that (GCC being an
obvious example, and the Lisp itself being another) but I don't think
this part of Axiom should need to be sensitive to the platform it is
running on - any ANSI Lisp environment should be sufficient.  There is
functionality we will need for other things that is NOT covered by the
spec (sockets, graphics) but I don't think the weave and tangle steps
need it.  (Other functionality will of course, but that comes later.) 

My take on this is to create tools now that cover all the needs we can
forsee, and are easily extended if we meet needs that we can't see.  My
hope is that <<chunkname>>[options]= would be general enough to cover
what is needed.  If I am alone in my preference for strict syntax, that
is probably not true and a finite state machine trying to be that
flexible may prove too convoluted to be maintainable or extendable.

There is of course nothing that says we can't have two implementations
of this functionality - one simple and flexible and one tuned and
complex.  Chapters one and two in volume 4 ;-).  Indeed, a good
explanation of a simpler tool might actually be useful background for
the state machine solution.  Maybe Axiom's tangle/weave system could
even respect the whole "safety" system for lisp compiling and use the
slower solution when the safey settings are more conservative.

\start
Date: Thu, 19 Jul 2007 10:25:35 -0400
From: Alfredo Portes
To: Alasdair McAndrew
Subject: Re: Open source development - a useful resource

Hi Alasdair,

> It seems that chapter 4, "Social and Political Infrastructure", is
> germane to much of the current discussion.

Nice finding. The chapter explains exactly the current situation.

\start
Date: 19 Jul 2007 12:43:49 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: re: Pamphlets and LaTex
Cc: Gabriel Dos Reis

Cliff Yapp writes:
> You mean my original code vs. the finite state machine?  The original
> code was almost certainly neither fast or flexible, so it's out.  Of
> more interest is Steve's new work.  I don't know how it does on speed
> trials.  Steve, have you had a chance to run any benchmarks?

Only a simple file with repetitive chunk structure, ~20000 lines long
with approx 800 chunks.  The chunk structure is flat, rather than
deeply nested and hierarchical but that should not matter (until I
implement a walker for the chunk graph to check for circularity's).

So my non-optimized code weaves it in 1.3 seconds and tangles it .6
seconds. noweb takes ~5 seconds for both operations.  I didnt check
cl-web yet, because I cant use an unmodified version with gcl. I did
look at its speed on other examples I am sure it works faster than my
code.  On the smaller examples the speed difference was within a tenth
of a second, neither two appeared slower on average sized files.

For the 20000 line example, LaTeX and GCL each take over one minute to
generate the dvi, or object file.

So really, for normal sized files we are talking only tenths of
seconds, and for huge files we are talking only a second maximum gain
in speed.  In this context, I would rather trade 100 lines of slightly
slower clean code for a faster 400 line tagbody of gotos any day.

\start
Date: Fri, 20 Jul 2007 05:03:26 +0200 (CEST)
From: Waldek Hebisch
To: Stephen Wilson
Subject: Re: Bug in GeneralizedMultivariateFactorize?

Stephen Wilson wrote:
> 
> *,
> 
> I was hoping for some help with GeneralizedMultivariateFactorize
> (GENMFACT) in allfact.spad.pamphlet.
> 
> The issue is with the following code, in particular with the call to
> squareFree at the end:
> 
>    T == add
>     factor(p:P) : Factored P ==
>       R has FiniteFieldCategory => factor(p)$MultFiniteFactorize(OV,E,R,P)
>       R is Polynomial(S) and S has EuclideanDomain =>
>          factor(p)$MPolyCatPolyFactorizer(E,OV,S,P)
>       R is Fraction(S) and S has CharacteristicZero and 
>         S has EuclideanDomain =>
>             factor(p)$MRationalFactorize(E,OV,S,P)
>       R is Fraction Polynomial S =>
>          factor(p)$MPolyCatRationalFunctionFactorizer(E,OV,S,P)
>       R has CharacteristicZero and R has EuclideanDomain =>
>                factor(p)$MultivariateFactorize(OV,E,R,P)
>       squareFree p
> 
> 
> Here, P satisfies a PolynomialCategory over an IntegralDomain.  But
> such a P does not export squareFree unless the coefficient ring is a
> GcdDomain.  This is a bug in GENMFACT, I believe.
> 
> I do not have the experience necessary with the algebra code yet to be
> terribly efficient in determining what the proper fix here is.
> Perhaps it is as simple as requiring GcdDomain.
> 
> Could anyone provide some insight here?
> 

This looks like a frequent bug in Axiom, namely giving too general
signature.  From correctness point of view the last call to squareFree
is debatable: we promised to give full factorization, but we are
giving only the square free one.

So IMHO the correct thing to do would be to require that R is UFD.
Since factorization algorithm for polynomials over UFD may be
impractical, it is reasnable to signal error if we miss aproproate
algoritm.

Alternative approach is to work on "best effort" basis and just
return the input unfactored if we have no idea how to factor it.
However, I would not call such funtions factor, but rather
maybeFactor.

Looking at usage I see that in SYSSOLP GeneralizedMultivariateFactorize
is used for R which is only IntegralDomain -- I am not sure if
SYSSOLP can give sensible results for general IntegralDomain.

In GROEBSOL GeneralizedMultivariateFactorize is used for GcdDomain.
My impression is that GROEBSOL works on "best effort" basis, so
using squareFree may be reasonable here.

\start
Date: Fri, 20 Jul 2007 05:09:23 -0400
From: William Sit
To: Waldek Hebisch
Subject: Re: Bug in GeneralizedMultivariateFactorize?

The domain Factored R does not promise full factorization. Indeed, it only
promise to keep the elements of R in factored form, and a factor has a flag,
including "nil", "sqfr", "irred" or "prime". So returning a square free form is
not a bug.

The MultivariateSquareFree package has a squareFree operation when the
coefficient domain is a EuclideanDomain (and the PolynomialGcdPackage provides
gcd operations via Hensel lifting). However, I am not sure if there is a
squareFree operation when the coefficient ring is just an integral domain. There
is some indication from the +++ comments that the author (Gianni) believed a
squareFree factorization is possible for multivariate polynomial rings over
certain integral domains (but the algorithm then used requires a Euclidean
division algorithm) and hence the more relaxed requirement on the coefficient
domain in GENMFACT.

Disclaimer: I am not an expert on factorization.

William

Waldek Hebisch wrote:

> Stephen Wilson wrote:
> >
> > *,
> >
> > I was hoping for some help with GeneralizedMultivariateFactorize
> > (GENMFACT) in allfact.spad.pamphlet.
> >
> > The issue is with the following code, in particular with the call to
> > squareFree at the end:
> >
> >    T == add
> >     factor(p:P) : Factored P ==
> >       R has FiniteFieldCategory => factor(p)$MultFiniteFactorize(OV,E,R,P)
> >       R is Polynomial(S) and S has EuclideanDomain =>
> >          factor(p)$MPolyCatPolyFactorizer(E,OV,S,P)
> >       R is Fraction(S) and S has CharacteristicZero and
> >         S has EuclideanDomain =>
> >             factor(p)$MRationalFactorize(E,OV,S,P)
> >       R is Fraction Polynomial S =>
> >          factor(p)$MPolyCatRationalFunctionFactorizer(E,OV,S,P)
> >       R has CharacteristicZero and R has EuclideanDomain =>
> >                factor(p)$MultivariateFactorize(OV,E,R,P)
> >       squareFree p
> >
> >
> > Here, P satisfies a PolynomialCategory over an IntegralDomain.  But
> > such a P does not export squareFree unless the coefficient ring is a
> > GcdDomain.  This is a bug in GENMFACT, I believe.
> >
> > I do not have the experience necessary with the algebra code yet to be
> > terribly efficient in determining what the proper fix here is.
> > Perhaps it is as simple as requiring GcdDomain.
> >
> > Could anyone provide some insight here?
> >
>
> This looks like a frequent bug in Axiom, namely giving too general
> signature.  From correctness point of view the last call to squareFree
> is debatable: we promised to give full factorization, but we are
> giving only the square free one.
>
> So IMHO the correct thing to do would be to require that R is UFD.
> Since factorization algorithm for polynomials over UFD may be
> impractical, it is reasnable to signal error if we miss aproproate
> algoritm.
>
> Alternative approach is to work on "best effort" basis and just
> return the input unfactored if we have no idea how to factor it.
> However, I would not call such funtions factor, but rather
> maybeFactor.
>
> Looking at usage I see that in SYSSOLP GeneralizedMultivariateFactorize
> is used for R which is only IntegralDomain -- I am not sure if
> SYSSOLP can give sensible results for general IntegralDomain.
>
> In GROEBSOL GeneralizedMultivariateFactorize is used for GcdDomain.
> My impression is that GROEBSOL works on "best effort" basis, so
> using squareFree may be reasonable here.

\start
Date: Fri, 20 Jul 2007 13:08:48 +0200 (CEST)
From: Waldek Hebisch
To: William Sit
Subject: Re: Bug in GeneralizedMultivariateFactorize?

William Sit wrote:
> The domain Factored R does not promise full factorization. Indeed, it only
> promise to keep the elements of R in factored form, and a factor has a flag,
> including "nil", "sqfr", "irred" or "prime". So returning a square free form is
> not a bug.
> 

Well, if you look just at types factor can return anything.  However,
we have:

    factor      :      P  ->  Factored P
      ++ factor(p) factors the multivariate polynomial p over its coefficient
      ++ domain

The ++ comment does not mention possibility of unfactored output. Other
factor functions give completly factored output, so giving unfactored
output is inconsistent with other functions.  Given that there are
functions like subtractIfCan it is natural that function which
factorizes on "best effort" basis should have different name.

> The MultivariateSquareFree package has a squareFree operation when the
> coefficient domain is a EuclideanDomain (and the PolynomialGcdPackage provides
> gcd operations via Hensel lifting). However, I am not sure if there is a
> squareFree operation when the coefficient ring is just an integral domain. There
> is some indication from the +++ comments that the author (Gianni) believed a
> squareFree factorization is possible for multivariate polynomial rings over
> certain integral domains (but the algorithm then used requires a Euclidean
> division algorithm) and hence the more relaxed requirement on the coefficient
> domain in GENMFACT.
> 

Mathematically, to have well-defined (unique) factorizations we need
something like Krull ring.  But Krull ring such that gcd exists for
all pairs of elements is a unique factorisation domain.  I suspect
that similar things holds for square free decomposition.

Practically, when working with polynomils we may want to ignore
problems due to coefficient ring, that is consider degree 0 factors
as trivial.  But it is still not clear if we can do square free
decomposition (without for example extending coefficient ring to a
field).   However, assuming that we can compute such a decomposition
it would be a different operation than the normal square free
decomposition, so I feel that it deserves different name.

Similarly, it may happen that some elements of a ring which is
not a unique factorisation domain happen to have unique factorisation.
Again, a operation which factors elements which are factorizable
and returns other unfactored is IMHO a different operation than
Axiom factor function.

\start
Date: 20 Jul 2007 07:44:58 -0400
From: Stephen Wilson
To: Waldek Hebisch
Subject: Re: Bug in GeneralizedMultivariateFactorize?

Waldek Hebisch writes:
> Practically, when working with polynomils we may want to ignore
> problems due to coefficient ring, that is consider degree 0 factors
> as trivial.  But it is still not clear if we can do square free
> decomposition (without for example extending coefficient ring to a
> field).   However, assuming that we can compute such a decomposition
> it would be a different operation than the normal square free
> decomposition, so I feel that it deserves different name.


Please forgive that this question may be elementary, uninformed, etc
(I am no mathematician).

Is it common enough to encounter integral domains which are not UFD's
yet admit a computable extension to a field?

If so, then can we not use both squarefree factorization and
Berlekamps algorithm to obtain a complete factorization, apply Hensel
lifting, and do (in the most general case) an exponential algorithm to
recombine the factors?

If this is nonsense, just say "thats nonsense".  Im not asking you
to spend your time explaining why my question is uninformed.

\start
Date: Fri, 20 Jul 2007 14:22:45 +0200 (CEST)
From: Waldek Hebisch
To: Stephen Wilson
Subject: Re: Bug in GeneralizedMultivariateFactorize?

Stephen Wilson wrote:
> Is it common enough to encounter integral domains which are not UFD's
> yet admit a computable extension to a field?
>

Well, naive users probably use only things like Integer,
Expression Integer and polynomials over them -- given that they
will probably never hit an integral domain which is not an UFD.

But very simple number theory gives you an integral domain
which is not UFD, namely extend integers adding sqrt(-5).
The resulting ring is not UFD, while the field of fractions
is quite nice.  In general, algebraic extensions of integers
rarely are UFD.

Another example is ring of real trigonometic polynomials, namely
finite sums of the form:

sum a_k*sin(k*x) + sum b_k*cos(k*x)

where a_k and b_k are real (note that if you take _complex_
coefficients you get UFD).

Such ring appear naturally if you try to do computations in
smallest possible ring (and for reasons of efficiency we
want to compute in small rings).


> If so, then can we not use both squarefree factorization and
> Berlekamps algorithm to obtain a complete factorization, apply Hensel
> lifting, and do (in the most general case) an exponential algorithm to
> recombine the factors?
> 

This does not work for rings: modular methods essentially work
on monic polynomials, so you have problems with constant factors
(this problem vanishes if you pass to the field).  Also, at least
theoretically when you try to recombine factors you can get
more factors when you work over field of quotients and there
is no longer clear that factors will combine in the ring in a
unique way.

\start
Date: Fri, 20 Jul 2007 12:21:40 -0400
From: William Sit
To: Waldek Hebisch
Subject: Re: Bug in GeneralizedMultivariateFactorize?

Waldek Hebisch wrote:

> Well, if you look just at types factor can return anything.  However,
> we have:
>
>     factor      :      P  ->  Factored P
>       ++ factor(p) factors the multivariate polynomial p over its coefficient
>       ++ domain

> The ++ comment does not mention possibility of unfactored output. Other factor
> functions give completly factored output, so giving unfactored output is
> inconsistent with other functions.

It did not say "completely factors into irreducibles" but it does not preclude it
either (but that is quibbling :-).

> Given that there are functions like subtractIfCan it is natural that function which
> factorizes on "best effort" basis should have different name.

Following that logic, we should also have integrateIfCan, solveIfCan,  and lots of
other IfCan's so that there would be no need for errors messages (like addIfCan on
vectors instead of signalling error when the summands have different dimensions).
There has to be some freedom in the way errors or incomplete solutions are handled.
Given a choice, I would prefer to signal an error at run time instead of using IfCan's
and asks the compiler to verify the right branch. IfCan requires Union("failed", ...)
as its target domain, leading to unnecessary overhead. Union("failed", ...) would be
useful if it is possible to handle the "failed" case, but then there would be no need
for error signalling anyway.

> Mathematically, to have well-defined (unique) factorizations we need
> something like Krull ring.  But Krull ring such that gcd exists for
> all pairs of elements is a unique factorisation domain.  I suspect
> that similar things holds for square free decomposition.
>
> Practically, when working with polynomils we may want to ignore
> problems due to coefficient ring, that is consider degree 0 factors
> as trivial.  But it is still not clear if we can do square free
> decomposition (without for example extending coefficient ring to a
> field).   However, assuming that we can compute such a decomposition
> it would be a different operation than the normal square free
> decomposition, so I feel that it deserves different name.

In that case, the domanis Factored R should also be restricted to hold only completely
factored forms. You will then need new names for all the intermediately factored
forms.

> Similarly, it may happen that some elements of a ring which is
> not a unique factorisation domain happen to have unique factorisation.
> Again, a operation which factors elements which are factorizable
> and returns other unfactored is IMHO a different operation than
> Axiom factor function.

In the case a domain does not have UFD, if we use factorIfCan, we would be hard
pressed to come up with a general algorithm that can detect which elements can be
factored uniquely. The complexity is much higher than subtractIfCan. Is this even
decidable? What domain would have such an algorithm?

\start
Date: Fri, 20 Jul 2007 22:39:04 +0200 (CEST)
From: Franz Lehner
To: list
Subject: MonoidWithZero

Hello,

here is an algebra question for a change.
I need a version of MonoidRing for MonoidWithZero.
That is, the monoid has a "zero" element which also becomes the zero 
element of its monoid ring and thus needs special treatment.
For this I need (so I think) both a Category MonoidWithZero, which is 
easy, and a special version of MonoidRing which knows how to treat the zero 
element. I would like to reuse as much as possible from MonoidRing,
however I realized that MonoidRingCategory is only locally defined in 
mring.spad:

MonoidRing(R: Ring, M: Monoid): MRcategory == MRdefinition where
     Term ==> Record(coef: R, monom: M)

     MRcategory ==> Join(Ring, RetractableTo M, RetractableTo R) with
     ...

Is there a smart way to reuse this without completely rewriting it?

\start
Date: Fri, 20 Jul 2007 19:56:49 -0500
From: Tim Daly
To: Scott Morrison
Subject: Democracy!

Scott!!!

Actually I have no opinion about how the votes should be counted, what
the quorum rules are, nor who should be allowed to vote, nor anything
else related to "the process". I plan to code and contribute by
posting patches. It's fine if they get voted down.

You designed and authored fair portions of the code.  God knows, if you
have an opinion on a technical issue it would certainly carry more
weight with me than just about anyone elses. (Especially if you were
to agree with me :-) ).

\start
Date: Fri, 20 Jul 2007 21:11:01 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Pamphlet format discussion

Stephen,

Would a correct summary of your concern be: 
Axiom pamphlet format should not be restricted to latex syntax?

\start
Date: Thu, 12 Jul 2007 03:25:57 -0700 (PDT)
From: Yalcin Oksuz
To: list
Subject: can't compile user-defined functions on axiom 

Hello

I am trying to use axiom in my academic study, but I
can't get it run properly. The problem is when I try
to define a function it gives error, for example

(2) -> f(n|n<=0)==-n
                                                      
            Type: Void
(3) -> f(3)
   Compiling function f with type PositiveInteger ->
Integer
sh: gcc: command not found

I searched on the net and learn that it could be the
gcc version installed on my computer. I have installed
Debian 4.0 etch  on my computer with gcc 4.0 version.
I am using linux system for only axiom, or to draw
plots in axiom which is not available in windows. If
you could recommend another distrubition I can gladly
try that. I have a newer mainboard with jmicron
pata-controller, which is not supported by kernels
older than 2.6.18. I will appreciate any help, thanks
in advance.  


\start
Date: 21 Jul 2007 00:05:47 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Pamphlet format discussion

Tim,

Tim Daly writes:
> Stephen,
> 
> Would a correct summary of your concern be: 
> Axiom pamphlet format should not be restricted to latex syntax?

No, I dont think so.  The syntax does not bother me in any way.

I cannot see how we can get past the the need for a weave stage in
general, especially when we consider wide range of possibilities open
to us in the future.  This is my main concern.

Also, I cannot see a distinct advantage to using latex directly, even
given the modest features we have available in our tools today.  After
all, most of a pamphlet is pure latex.

I am also concerned about attracting new developers to this method as
well.  Its difficult to get them to buy into literate programming to
begin with.  I believe that even people who do practice the methodology
would be forlorn to break with the familiar concept of `weaving' a
document.  Normally I would not consider this an issue, but I dont see
why we should spend time preaching to the converted when, at least to
me, there is no clear gain in the end.


To have a good tangle/weave tool, implemented in Lisp, which is
tailored to axioms current needs and extensible for future
requirements, appears to me as being the best way forward.  We do not
loose anything, AFAICT, but there is, potentially, a lot to gain.

\start
Date: Sat, 21 Jul 2007 12:26:11 +0700 (NOVST)
From: Andrey G. Grozin
To: Stephen Wilson
Subject: re: Pamphlet format discussion

On Sat, 21 Jul 2007, Stephen Wilson wrote:
> Tim Daly writes:
>> Would a correct summary of your concern be:
>> Axiom pamphlet format should not be restricted to latex syntax?
>
> No, I dont think so.  The syntax does not bother me in any way.
>
> I cannot see how we can get past the the need for a weave stage in
> general, especially when we consider wide range of possibilities open
> to us in the future.  This is my main concern.
I think it is best not to introduce an additional syntax, when the 
familiar LaTeX syntax is good for describing any structured documents (in 
this sense, I think that xml is a re-invention of the LaTeX wheel). An 
additional advantage is that in the simplest case (which means 100% of 
cases now, but may decrease to 99% in the future) we can directly run 
LaTeX on pamphlet files, thus saving build time. I don't see why 
references to chunks from other files can be a problem - just 
\usepackage{hyperref} and get nice hyperlinks in dvi or pdf. It should be 
also quite easy (in principle) to generate, say, hyperdoc pages from LaTeX 
pamphlets - we can invent LaTeX structures for hyperref-specific purposes, 
such as uses/used-by lists or running axiom commands from hyperdoc. Of 
course, this requires some programming, but quite trivial - LaTeX syntax 
is very simple and regular (unless we play dirty low-level TeX games with 
re-defining character classes, etc.; such tricks should be certainly 
banned in pamphlet files). If some more complicated processing of 
pamphlets is needed, such as extracting some special kind of chunks from 
many pamphlets (for some other kind of documentation in The Crystall :-), 
it can be done by a program. In this sense, weaving will be available when 
we need it (of course, it should be programmed, but this is certainly not 
difficult). But in the majority of cases, weaving will by just the 
identity transformation. I think this is a Good Thing - saving build time 
and the necessity to learn one more syntax.

I'll have a look how \begin{verbatim} ... \end{verbatim} is handled in 
auctex. I am sure this can be generalized in such a way that chunks 
written in some programming language will be syntax-highlighted by an 
appropriate mode. Ideally, we should have the possibliity to have chunks 
written in several languages in the same pamphlet, and to work with them 
comfortably from emacs. Currently, this is not possible; so, I don't think 
that the current setup is purfect and should not be improved.

\start
Date: 21 Jul 2007 01:33:54 -0400
From: Stephen Wilson
To: Andrey G. Grozin
Subject: re: Pamphlet format discussion

Andrey G. Grozin writes:
[...]
> I'll have a look how \begin{verbatim} ... \end{verbatim} is handled in
> auctex. I am sure this can be generalized in such a way that chunks
> written in some programming language will be syntax-highlighted by an
> appropriate mode. 

Take a look at the listings package. It does a fairly nice job of
formatting a large number of languages.  It is extensible too. One
draw back is that there are a few active characters, so it is not a
true verbatim environment, and complicates the typing of code.

> Ideally, we should have the possibliity to have chunks written in
> several languages in the same pamphlet, and to work with them
> comfortably from emacs. Currently, this is not possible; so, I don't
> think that the current setup is purfect and should not be improved.

I am not sure what you mean here.  Noweb and similar tools are
language independent.  By specifying the root chunk to extract at the
tangle stage, you can extract source code in various languages from
the same pamphlet.

\start
Date: Sat, 21 Jul 2007 00:38:24 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Pamphlet format discussion

Steve,

Another try: Would a correct summary of your concern be:

We need to provide a weave function in order to enable possible future
pamphlet format extensions.

\start
Date: 21 Jul 2007 01:46:32 -0400
From: Stephen Wilson
To: Andrey G. Grozin
Subject: re: Pamphlet format discussion
Cc: list

Andrey G. Grozin writes:
[...]
> An additional advantage is that in the simplest case (which
> means 100% of cases now, but may decrease to 99% in the future) we can
> directly run LaTeX on pamphlet files, thus saving build time.

You might save one or two seconds on a file 20000 lines long.  Latex
will take over a minute to process the beast.  What you gain is hardly
even noticeable.

> I don't see why references to chunks from other files can be a
> problem - just \usepackage{hyperref} and get nice hyperlinks in dvi
> or pdf. It should be also quite easy (in principle) to generate,
> say, hyperdoc pages from LaTeX pamphlets - we can invent LaTeX
> structures for hyperref-specific purposes, such as uses/used-by
> lists or running axiom commands from hyperdoc. Of course, this
> requires some programming, but quite trivial - LaTeX syntax is very
> simple and regular (unless we play dirty low-level TeX games with
> re-defining character classes, etc.; such tricks should be certainly
> banned in pamphlet files). 

Latex is far from trivial, IMHO.  Perhaps that is my lack of
experience speaking, but I can think of many, many languages I would
rather _program_ in then LaTeX.

> If some more complicated processing of pamphlets is needed, such as
> extracting some special kind of chunks from many pamphlets (for some
> other kind of documentation in The Crystall :-), it can be done by a
> program. In this sense, weaving will be available when we need it
> (of course, it should be programmed, but this is certainly not
> difficult). 

Weaving costs nothing.  It does not result in a more restrictive
environment.  All the power of latex is at your disposal.  Writing in
pure latex gains nothing.  

> But in the majority of cases, weaving will by just the
> identity transformation. I think this is a Good Thing - saving build
> time and the necessity to learn one more syntax.

Every literate programmer knows the basic syntax already.  Noweb, for
example, introduces two new constructs.  This is minor, totally
trivial.  Your not learning a new programming language.  One can
memorize and be completely fluent writing a pamphlet in about ten
minutes.

\start
Date: Sat, 21 Jul 2007 01:51:40 -0400
From: Bill Page
To: Alfredo Portes
Subject: Re: Open source development - a useful resource

On 7/19/07, Alasdair McAndrew wrote:
> I have been watching the various kerfuffles for a while, staying
> mostly quiet myself, seeing as I know nothing about open-source
> development.  But I have been doing some research, and have come
> across this useful resource:
>
> "Producing Open Source Software" by Karl Fogel, at
> http://producingoss.com/html-chunk/
>
> It seems that chapter 4, "Social and Political Infrastructure", is
> germane to much of the current discussion.
>

On 7/19/07, Alfredo Portes wrote:
> Nice finding. The chapter explains exactly the current situation.
>

I agree that this book by Karl Fogel is well worth reading and that it
describes the current situation very well. It seems to me that if we
accept the view of Fogel then the Axiom project is evolving exactly as
it should given the personalities involved. This also fits the model
that Gaby has mentioned several times about the history of the gcc
project. So I do not think there is any particular reason to be
worried about the future of Axiom as an open source project as such.

Fogel's analysis suggests that efforts to move Axiom to a  more
"democratic" style of governance is probably premature. At this stage
is seems more productive to live with one (or more) forks of the
original project.

\start
Date: 21 Jul 2007 02:04:44 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Pamphlet format discussion

Tim Daly writes:

> Steve,
> 
> Another try: Would a correct summary of your concern be:
> 
> We need to provide a weave function in order to enable possible future
> pamphlet format extensions.

Close :)  I would say that we need a weave function in order to enable
possible extensions of functionality, and for integration with Axiom as
a whole.

\start
Date: Sat, 21 Jul 2007 02:10:09 -0400
From: Bill Page
To: Stephen Wilson
Subject: re: Pamphlet format discussion

On 21 Jul 2007 01:46:32 -0400, Stephen Wilson wrote:
> Andrey G. Grozin writes:
> [...]
>
> > But in the majority of cases, weaving will by just the
> > identity transformation. I think this is a Good Thing - saving build
> > time and the necessity to learn one more syntax.
>
> Every literate programmer knows the basic syntax already.  Noweb, for
> example, introduces two new constructs.  This is minor, totally
> trivial.  Your not learning a new programming language.  One can
> memorize and be completely fluent writing a pamphlet in about ten
> minutes.
>

I agree with Steve, noweb seems entirely adequate for the purpose for
which it is used in Axiom. I do not see any point in the change in
syntax proposed by Tim and supported by Andrey. Further I do not see a
tool like noweb - no matter how the syntax might be expressed or
extended - as a possible way forward to a significantly improved
literate programming methodology. Except for the (to me irrational)
desire to embed noweb in a lisp-only incarnation of Axiom, I do not
see any reason to waste time on this issue. Noweb is entirely adequate
as it stands and represents that ideal situation of depending on other
open source projects for basic tools.

\start
Date: Sat, 21 Jul 2007 02:20:42 -0400
From: William Sit
To: Stephen Wilson
Subject: Crystal, Pamphlets and LaTex

Epilog: I must be writing this after smoking ... . I have
put this away in my draft folder for a few days because I
know little about databases.  Encouraged by Stephen's
prompt, I decide finally to submit it for whatever it is not
worth. I suppose I could have rephrased things in question
form, given that I do not know the internals of how Axiom's
databases are created and used (which might for all I know
have been already in some form of structure that is
supportive of the Crystal vision). So if this makes any
sense, we can continue to discuss it (but don't expect me to
do any implementation). Otherwise, it's ok to tell me that's
nonsense -- I learnt that from Stephen :-). If my uncooked
ideas help raise questions on what infrastructure Crystal
would need, that is good enough for the effort.

(no, I don't smoke, but I am following Stephen's pipe dream
perhaps)


Stephen wrote:

> How do you define the database? How is it going to be
> constructed,
> defined? You need to write it down somewhere, and in the
> case of
> axiom, it will be written down in a pamphlet. May as well
> let the
> pamphlets communicate the structure.

I will argue that according to my understanding of the
Crystal vision, pamphlets are a very poor way to support the
vision.

If I understand Tim's vision correctly, the Crystal concept
is nothing new. In fact, we are experiencing it almost every
time we open a new web page (read the news,  shop on the
internet, do a google search, etc.)  If I go to any news
site, I can see the world view, the US view, or any other
geographical region in the world; I can also see the
business view, the technology view, the health view, and so
on. With each click, we are provided with a new facet,
tailored to provide not only the information asked, but also
additional and peripheral info (like ads, etc.) The web page
does not preexist in a single (html) file. Rather this
single html file that is displayed is created on the fly. It
is not self contained (because it loads other files), but it
is the "master" composer for a particular facet.

For the Crystal project, a pamphlet file should be equated
to such a modern web page (and even exceed it in
imagination) that masters a facet, because, as the ultimate
document seen by the user, that facet document should be
literate and Tim has argued that pamphlet files are for
literate programming. However, they should never be
pre-composed, but should be generated on the fly from a
database, where the individual items may have different
formats (pictures, gif, movies, etc. in the case of html
file, and lisp code, boot code, spad code, documentation,
graphs, research articles, etc., some perhaps as fragments
of a pamphlet file, in the case of a facet). A facet can
lead to other facets or subfacets. On display, all subfacets
should be live and clickable.

If I want to work with elliptic curves, I want examples, I
want links to its definition, its theory, its code, I want
to see a graph, I want to see how it is used in
cryptography, I want to see how it is an algebraic group, or
an abelian variety. I want to be able to compute addition on
its points. Each of these can be displayed in a subfacet
document. How can a single elliptic.spad.pamphlet be able to
satisfy these diverse demands? Its graph probably would be
better handled by a general program that plots any graph, or
picked from a library of stocked examples. Its algebraic and
algebraic-geometric structure should be taken from some
articles about abelian variety in general. Its use in
cryptography would be better supplied from a subdatabase on
cryptography. The information should be very modular to
allow efficient storage and multiple use, and be able to be
mixed at will.

If I want to build a business like Amazon.com, I don't
create all the documents about an item in an item.pamphlet
file where we include all information on the item (best
price, manufacturers, specs, consumer reviews, related
items, companies selling them, local shops, shipping
information, etc.). I would use a database (for example, a
live relational one), from which I can piece these info
together and present them in one single web page. I would
also collect user information and tailor the ads to his
recent interests. The Crystal project should be no
different! Each facet should be tailored to the user's
interest.

A relational database is efficient on multidimensional
searches and storage (each piece of information is stored
once). The database stores what might be called atomic
information, little pieces of indivisible information.
Exactly what is indivisible depends on the applications the
relational database is to support. Data may be categorized
(into domain types) by attributes, organized and stored into
hierarchical files structures. Relations among them are
captured in tables or schema.  Management programs allow
input of the data and relations (a multi-window environment
fancier than what Stephen hypothesized). A query language
allows searches that provides customized views of the
relevant information (which may be called facets).

For the Axiom project, what are the atomic objects? On the
algebra level, and even at the boot and lisp level, they are
functions (and associated documentation, which will be
discussed later). Yes, just functions: these include
operating system utilities, category constructors, domain
constructors, packages, and exported functions. So in the
Crystal database, the organization should be around
functions. With each function, we need to define what are
its attributes, what info should go with it, what
mathematical concepts go with it, what c.sc. concepts go
with it, what theorems go with it, what algorithms go with
it, what are the relevant references (perhaps sorted with a
weighing system), what other functions it depends on, what
are its usage (all the things you can ask at hyperdoc), what
is an example for its call? what other functions use this?
(these include domains, and packages that include it as
export). All these make up the content of a literate
document for the function.

Notations used in defining a function should be
"relocatable" that is, they are dummies, so that when
different functions got pieced into a coherent facet
document, the dummy names do not conflict with each other.
An analogy is the link and load stages of object codes into
an executable. Another is the references using \label, \ref,
and \cite in LaTeX which are "relocatable" (we can easily
physically relocate the referenced items without affecting
the references). We would do this on a document level where
"memory location" or "offsets" are now identifiers and
mathematical notations. This may not be too important for
code, as the boundaries of code are usually clear. However,
for documentation and the notations used in documentation,
there is potential for conflicts because the boundaries are
no longer clear.

Similarly, the (literate) documentation parts that explain
the code in a function should be as specific to the function
as possible, but liberally using cross-referencing
techniques (which are not yet designed at this time) and
document "glue" (again not yet designed) to be combined with
other documentation parts of other functions. By being
specific, such literate documentation can remain small and
easier to write. Some "glue" may have to be supplied
interactively by a knowledgeable human at first, but these
"glue" documents will be stored and reused. LaTeX is, in
some ways, a good example of a document system that allows
pieceing together other "bits" like table of content, index,
bibliograhy, graphs and figures, tables, etc. In the case of
LaTeX, the "glue" is minimal and is more or less technical
rather than literate.

A flat model, such as a linear pamphlet file will not be
suitable, because the interrelationships among functions
(especially across pamphlet files) are not explicitly
stored. For now,  a linear flat structure may satisfy our
current needs (yes, we can create new latex commands and
latex packages to handle all the embedded constructs,
including new code chunks, running some code outside of the
LaTeX environment and inserting the console transcript back
into the document). We did this already all the time, say
when embedding a eps figure, or making a url in a pdf file
live, or creating a TOC or creating an index. But all this
is linear processing (even if we need multipasses). What we
need is searching, selection, and most importantly for
literate programming, documentation "glue", to present a
facet, not as a discrete set of related objects, but as a
literary piece. Even without concern about literate
programming, just getting the data would be difficult and
inefficient if the info is encaged in pamphlets (or linear
flat) files with no inter-referencing structure to connect
them (current labelled LaTeX references and bib-items are
local, unlike url items; even html files do better in this
respect). Such pamphlet files would only be good for what
each pamphlet file already contains. It would be difficult
to use them to support the Crystal vision.

Even with a relational database infrastructure, it would
only support one aspect of the facet process, namely,
fetching the data to be incorporated into the facet page.
Still, a relational database supports this fetching or
searching much better than flat files. A flat file needs to
be parsed to obtain the individual atomic information.
There should be a compile (or select), a link and a load and
a run phase on the current type of pamphlets. Repeat (second
pass) if further resolution is needed. End result is
fragment of a latex file with the documentation, code, test
run and results, ready to be used in a facet pamphlet.
Question: what information does our current compile stage
collect and is the way it is stored supportive of the
Crystal vision?

The difficulty in the facet process is not the mechanical
processes, but the non-mechanical process of supplying the
glue that make the resulting output a "literate" piece of
prose. With pamphlets, it is always written with one
purpose: documentation, but the glue is very particular to
the structure of THAT document. When the pieces need to be
taken out of context and combined with other similar pieces
from another pamphlet, and then combined to form a facet
document, there is no glue and or only out of context,
irrelevant glue residues.
A relational database would avoid the need for parsers of
embedded chunks from a flat linear pamphlet.

So perhaps my conclusion may be summarized as that pamphlet
files are not a good input device, but can be a good output
device. This bring us back to the fancy GUI. I think it
should be like any developer's interface for languages.
Those of you who deal with developing code day-in day-out
can imagine a better interface. In my inexperienced opinion,
it should consist of multiwindows (of course they don't have
to be opened simultaneously):

     assembly language window
     lisp code window
     boot window
     spad code window
     interpreter (console) window
     aldor window
     graphics window
     latex window (editor for documentation or theory)
     keyword and facet window (or relations window)
     help window

each window with its content wrapped in a minipamphlet
fragment for formatting, as well as a plain file without
wrappers.

Even though we do not yet have this GUI for input, we can
discuss the file structure, search strategies, and
experiment with a small part of Axiom where we build the
supportive database by a combination of automated tools and
manual inputs (such as documentation). The Crystal project,
if it is ever to be realized, must start with a small
prototype, and we must have a design for the infrastructure.

\start
Date: Sat, 21 Jul 2007 01:28:43 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Pamphlet format discussion

So the statement of your concern is:

We need a weave function in order to enable possible extensions of
functionality, and for integration with Axiom as a whole.

\start
Date: Sat, 21 Jul 2007 01:31:39 -0500
From: Tim Daly
To: Andrey G. Grozin
Subject: Pamphlet format discussion

Is a fair statement of your position:

Latex is sufficient to handle all current requirements, 
thus removing the need for noweb and its syntax.

\start
Date: Sat, 21 Jul 2007 02:32:31 -0400
From: Bill Page
To: Yalcin Oksuz
Subject: Re: can't compile user-defined functions on axiom

On 7/12/07, yalcin oksuz wrote:
>
> I am trying to use axiom in my academic study, but I
> can't get it run properly. The problem is when I try
> to define a function it gives error, for example
>
> (2) -> f(n|n<=0)==-n
>
>             Type: Void
> (3) -> f(3)
>    Compiling function f with type PositiveInteger ->
> Integer
> sh: gcc: command not found
>
> I searched on the net and learn that it could be the
> gcc version installed on my computer. I have installed
> Debian 4.0 etch  on my computer with gcc 4.0 version.

This error message from Axiom is very unusual *if* you really do have
gcc installed. This is the behaviour one might expect if gcc is not
installed properly or if for some reason gcc is not in the PATH used
in your session.

Before starting Axiom what reply do you get if you type the command:

  $ gcc --version

Can you compile simple test programs written in C?

> I am using linux system for only axiom, or to draw
> plots in axiom which is not available in windows.

I suppose from this comment that you are not very familiar with using linux?

> If
> you could recommend another distrubition I can gladly
> try that. I have a newer mainboard with jmicron
> pata-controller, which is not supported by kernels
> older than 2.6.18. I will appreciate any help, thanks
> in advance.
>

Axiom should work fine on this distribution. How did you install
Axiom? What version?

When using Debian the best advice would be to install Axiom using the

  $ apt-get install axiom*

command (or gui equivalent).

\start
Date: Sat, 21 Jul 2007 01:33:40 -0500
From: Tim Daly
To: Bill Page
Subject: Pamphlet format discussion

Is a fair statement of your position:

The status quo use of noweb is entirely adequate.

\start
Date: Sat, 21 Jul 2007 02:43:27 -0400
From: Bill Page
To: Tim Daly
Subject: Re: Pamphlet format discussion
Cc: Bill Page

On 7/21/07, Tim Daly wrote:
>
> Is a fair statement of your position:
>
> The status quo use of noweb is entirely adequate.
>

Yes. I think it is entirely adequate for the use of literate
programming as it exists now in Axiom. No significant improvement can
be made by incremental changes to this approach. Eventually an
entirely new approach will be needed (c.f. the recent post by William
Sit about databases and Crystal) but this should not be a focus of any
effort in the Axiom project at this time.

\start
Date: 21 Jul 2007 02:46:30 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Pamphlet format discussion

Tim Daly writes:

> Steve,
> 
> So the statement of your concern is:
> 
> We need a weave function in order to enable possible extensions of
> functionality, and for integration with Axiom as a whole.

Yes.  What do you think? 

\start
Date: Sat, 21 Jul 2007 02:55:16 -0400
From: Bill Page
To: Franz Lehner
Subject: Re: MonoidWithZero

On 7/20/07, Franz Lehner wrote:
>
> here is an algebra question for a change.
> I need a version of MonoidRing for MonoidWithZero.
> That is, the monoid has a "zero" element which also becomes the zero
> element of its monoid ring and thus needs special treatment.
> For this I need (so I think) both a Category MonoidWithZero, which is
> easy, and a special version of MonoidRing which knows how to treat the zero
> element. I would like to reuse as much as possible from MonoidRing,
> however I realized that MonoidRingCategory is only locally defined in
> mring.spad:
>
> MonoidRing(R: Ring, M: Monoid): MRcategory == MRdefinition where
>      Term ==> Record(coef: R, monom: M)
>
>      MRcategory ==> Join(Ring, RetractableTo M, RetractableTo R) with
>      ...
>
> Is there a smart way to reuse this without completely rewriting it?
>

I think the short answer is "no". But if you do re-write it, I can see
no reason why this should not be written as a normal category
definition and used in MonoidRing instead of the local macro
definition.

On the other hand perhaps the category "AbelianMonoidRing" in
'src/algebra/polycat.spad.pamphlet' is what you need?

\start
Date: Sat, 21 Jul 2007 01:55:59 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Pamphlet format discussion

I agree that we need a weave function in order to enable possible
extensions of functionality, and for integration with Axiom as a whole.

We differ in the implementation question of that weave function.

\start
Date: Sat, 21 Jul 2007 02:02:57 -0500
From: Tim Daly
To: Bill Page
Subject: Pamphlet format discussion

I agree that the status quo use of noweb is entirely adequate.

We differ in the future planned use. I believe that noweb functionality 
(tangle/weave) needs to be integrated into Axiom so that the pamphlet
file format becomes entirely native, enabling long term goals.

\start
Date: Sat, 21 Jul 2007 03:07:24 -0400
From: Bill Page
To: Tim Daly
Subject: Re: Pamphlet format discussion
Cc: Bill Page

On 7/21/07, Tim Daly wrote:
>
> I agree that the status quo use of noweb is entirely adequate.
>
> We differ in the future planned use. I believe that noweb functionality
> (tangle/weave) needs to be integrated into Axiom so that the pamphlet
> file format becomes entirely native, enabling long term goals.
>

Integrating noweb into Axiom to support the current pamphlet file
format seems entirely reasonable to me. I think calling noweb as a
system supplied utility is the best approach.

\start
Date: Sat, 21 Jul 2007 03:26:46 -0400
From: Bill Page
To: Martin Rubey
Subject: re: keyword arguments,

On 14 Jul 2007 08:41:02 +0200, Martin Rubey wrote:
> Stephen Wilson writes:
>
> > Perhaps the best solution in this case is as Bill Page suggested,
> > implementing keyword arguments in Axiom, allowing us to write [a:1] or
> > [b:1] thus enabling unambiguous specification of the branch.
>
> Please (!) do it the aldor way, i.e., use == instead of :.  There is no reason
> here to diverge from aldor syntax.
> ...

Actually I agree with Martin. *If* we need this, it should be done the
way it is done in Aldor. But note: This is *not* the way I think Union
should be implemented. Union should be the categorical dual of Record,
neither of which need to resort to lower level constructs like
keywords.

\start
Date: Sat, 21 Jul 2007 02:30:19 -0500
From: Tim Daly
To: Bill Page
Subject: Pamphlet format discussion

Tim writes:
>> I agree that the status quo use of noweb is entirely adequate.

>> We differ in the future planned use. I believe that noweb functionality 
>> (tangle/weave) needs to be integrated into Axiom so that the pamphlet
>> file format becomes entirely native, enabling long term goals.

Bill writes:
> Integrating noweb into Axiom to support the current pamphlet file
> format seems entirely reasonble to me. I think calling noweb as a
> system supplied utility is the best approach.

In the current system the result would be the same from the user
perspective.  In future planned use this would not be the case.  Can
you state in one or two sentences either your advocacy of noweb or
your objection to native?

\start
Date: Sat, 21 Jul 2007 03:37:33 -0400
From: Bill Page
To: Tim Daly
Subject: Re: Pamphlet format discussion
Cc: Bill Page

On 7/21/07, Tim Daly wrote:
> Bill writes:
> > Integrating noweb into Axiom to support the current pamphlet file
> > format seems entirely reasonble to me. I think calling noweb as a
> > system supplied utility is the best approach.
>
> In the current system the result would be the same from the user
> perspective.  In future planned use this would not be the case.  Can
> you state in one or two sentences either your advocacy of noweb or
> your objection to native?
>

noweb exists, works as required and is maintained by someone else.
Rewriting basic tools is a waste of current and future resources. I
don't know what "future planned use" involves but in my opinion more
radical changes in literate programming philosophy are required then
can be accomplished by changes of this kind.

\start
Date: Sat, 21 Jul 2007 03:25:42 -0500
From: Tim Daly
To: Bill Page
Subject: Pamphlet format discussion

Bill writes:
>>> Integrating noweb into Axiom to support the current pamphlet file
>>> format seems entirely reasonable to me. I think calling noweb as a
>>> system supplied utility is the best approach

Tim writes:
>> In the current system the result would be the same from the user
>> perspective. In future planned use this would not be the case. Can
>> you state in one or two sentences either your advocacy of noweb or
>> your objection to native

Bill writes:
> noweb exists, works as required and is maintained by someone else.
> Rewriting basic tools is a waste of current and future resources. I
> don't know what "future planned use" involves but in my opinion more
> radical changes in literate programming philosophy are required than
> can be accomplished by changes of this kind.




So, two points then.

1) "Rewriting basic tools is a waste of current and future resources."

The code already exists in the current silver to tangle pamphlet files
using either noweb or latex format. The weave function already exists
in a local version, enabling context-specific processing of pamphlets
at runtime rather than as now, only at build time. For example, we could
dynamically fetch partial content from a pamphlet in response to a 
)help command.

There are no "current and future" resources. This is a volunteer effort
and we only get to decide our own resource usage. Objecting to the use
other people make of their time isn't a topic of debate.





2) "I don't know what "future planned use" involves but in my opinion 
   more radical changes in literate programming philosophy are required 
   than can be accomplished by changes of this kind."

At the present time there is no user-visible difference between noweb
and cl-web (or, for non-ansi, gclweb). Thus they are functionally
equivalent.

Since you don't have future plans and don't know of any future plans
it seems that you must be objecting to my future plans.  For instance,
there have been discussions of my future plans for crystal on this
list in the past. Clearly noweb is not adequate for those "future
plans".




Rather than say "no" to system change it seems more useful to propose
an alternative. Anyone can say "no" but that just slows progress. 

What plans do you have that are impacted by the change?
How can we compromise on the plans you have versus the plans I have?

It also seems that your objections are at the level of construction
(don't put that brick there) rather than architecture (we need 4 bell 
towers, not 3).

Architectural decisions are reasonably subject to objection and vote.
Construction decisions follow from necessity and aren't appropriate 
for voting.

\start
Date: 21 Jul 2007 03:30:52 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Pamphlet format discussion
Cc: Bill Page

Bill Page writes:

| On 7/21/07, Tim Daly wrote:
| > Bill writes:
| > > Integrating noweb into Axiom to support the current pamphlet file
| > > format seems entirely reasonble to me. I think calling noweb as a
| > > system supplied utility is the best approach.
| >
| > In the current system the result would be the same from the user
| > perspective.  In future planned use this would not be the case.  Can
| > you state in one or two sentences either your advocacy of noweb or
| > your objection to native?
| >
| 
| noweb exists, works as required and is maintained by someone else.
| Rewriting basic tools is a waste of current and future resources.

I must confess I completely agree with this statement.

\start
Date: 21 Jul 2007 03:36:46 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Recent changes to silver

  A fresh update of my local tree reveals that you downcased every
file.  I don't remember a consensus among the "active" committers
or developers that this indeed was what we wanted.

  I don't propose to revert your changes, but it is my understanding
that the "canonical" spelling of "change log file", is "ChangeLog".
Furthermore, I don't see the necessity for downcasing README or FAQ.

  I would suggest that files like ChangeLog, Makefile, README
retain those spellings.

\start
Date: 21 Jul 2007 03:42:15 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Pamphlet format discussion
Cc: Bill Page

Tim Daly writes:

| Bill writes:
| >>> Integrating noweb into Axiom to support the current pamphlet file
| >>> format seems entirely reasonable to me. I think calling noweb as a
| >>> system supplied utility is the best approach
| 
| Tim writes:
| >> In the current system the result would be the same from the user
| >> perspective. In future planned use this would not be the case. Can
| >> you state in one or two sentences either your advocacy of noweb or
| >> your objection to native
| 
| Bill writes:
| > noweb exists, works as required and is maintained by someone else.
| > Rewriting basic tools is a waste of current and future resources. I
| > don't know what "future planned use" involves but in my opinion more
| > radical changes in literate programming philosophy are required than
| > can be accomplished by changes of this kind.
| 
| 
| 
| 
| So, two points then.
| 
| 1) "Rewriting basic tools is a waste of current and future resources."
| 
| The code already exists in the current silver to tangle pamphlet files
| using either noweb or latex format. The weave function already exists
| in a local version, enabling context-specific processing of pamphlets
| at runtime rather than as now, only at build time. For example, we could
| dynamically fetch partial content from a pamphlet in response to a 
| )help command.
| 
| There are no "current and future" resources. This is a volunteer effort
| and we only get to decide our own resource usage. Objecting to the use
| other people make of their time isn't a topic of debate.

The objection, as I understand it, is not to your spending your time
playing with your toy.   The objection as, I understand it, is against
having the common toy (Axiom) move to duplicating functionalities
(already provided by external tools) and having to maintain the source
code.  It is a waste of resource.

\start
Date: 21 Jul 2007 03:46:16 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Pamphlet format discussion
Cc: Bill Page

Tim Daly writes:

[...]

| Architectural decisions are reasonably subject to objection and vote.
| Construction decisions follow from necessity and aren't appropriate 
| for voting.

Since the construction is that of a common toy, it makes sense that active
maintainers have a say on where a brik should go.  This is part of the
review process.

\start
Date: 21 Jul 2007 03:29:01 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Pamphlet format discussion
Cc: Benjamin Kosnik

Bill Page writes:

[...]

| Integrating noweb into Axiom to support the current pamphlet file
| format seems entirely reasonable to me. I think calling noweb as a
| system supplied utility is the best approach.

Please don't go out of your way to "copy" noweb into Axiom.  Make it
a dependency.

At IBM Toronto, where we just had an ISO C++ meeting, I spoke again
with Benjamin Kosnik (from Red Hat, in CC:) about what would remain to be
done to get Axiom packaged and distributed in Fedora Core (for
example).  I explained what has been done in terms moving to standard
build system.  I pointed out that at this moment we still critically
depend on GCL and noweb.  He quickly made a search and informed me
that FC distributes GCL-2.6.7-something (but I guess the next FC may
distribute GCL-2.6.8 if it is finalized by then), but they do not
have noweb at the moment.  He looked at the noweb page and suggested
that a first step would be to list the noweb RPM as a dependency in yum
package and see how it works.  Benjamin is very willing to provide
advice on how to make forward progress with these issues.
I have not spoken with the SuSE people recently about the progress we
have made with Axiom.build-improvements, but I would be surprised if
they didn't say roughly the same thing.

We should try hard to avoid complicating system packager's life.

\start
Date: Sat, 21 Jul 2007 18:31:50 +0700 (NOVST)
From: Andrey G. Grozin
To: Stephen Wilson
Subject: re: Pamphlet format discussion

On Sat, 21 Jul 2007, Stephen Wilson wrote:
>> Ideally, we should have the possibliity to have chunks written in
>> several languages in the same pamphlet, and to work with them
>> comfortably from emacs. Currently, this is not possible; so, I don't
>> think that the current setup is purfect and should not be improved.
>
> I am not sure what you mean here.  Noweb and similar tools are
> language independent.  By specifying the root chunk to extract at the
> tangle stage, you can extract source code in various languages from
> the same pamphlet.
I mean emacs mode only. Ideally, I'd like LaTeX in a pamphlet to be 
syntax-highlighted as LaTeX, spad code - as spad code (or as aldor, for 
which an emacs mode is available), Makefile parts - as Makefiles, lisp 
code - as lisp, etc. Even better if key bindings will be those of the lisp 
mode when the cursor is inside a lisp chunk, those of auctex when the 
cursor is in LaTeX, etc. All in a single pamphlet. Currently, this cannot 
be done :-(

\start
Date: Sat, 21 Jul 2007 07:07:27 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Pamphlet files and Axiom

As near as I can tell, the question about tools used is not really the
important one for Axiom at this time.  Choosing tools to use is easily
handled at build time.  Of more importance is the details of how to
specify a chunk.

Axiom+Noweb currently uses the syntax 

<<chunkname>>=

@

This has the merit of being quickly typed, and simple to see and
understand.  Noweb also seems to permit variations on this theme.

When noweb performs its weave step, it substitutes the delimiters in
the chunk structure with more elaborate LaTeX commands.

Axiom's current default weave usage does not make use of the full power
of noweb's weave logic.  Ralf's ALLPROSE (demonstrated in his
experiments on cl-web a while back) makes much fuller use of this logic
and at this time constitutes the most advanced weave output yet
demonstrated for an Axiom pamphlet file.

Tim's new proposal, as I understand it (please correct me if I'm wrong)
is to use 

\begin{chunk}{chunkname}

\end{chunk}

or something close to that instead of noweb's syntax.  Then, instead of
using weave to translate the delimiters into LaTeX, he will provide in
a LaTeX sty file the necessary logic - I assume similar backend logic
to that triggered by the noweb auto-generated commands themselves?

This means that instead of going from
 "<<" -> *noweb autogenerated* -> *internal TeX logic*
the process is
 "\begin{chunk}{" -> *internal TeX logic*.

This would in fact fully support the weave functionality being used in
the Axiom Silver tree and other branches as it currently stands, unless
there are new features being used I am not aware of.

However, if we go straight from "\begin{chunk}{" -> *internal TeX
logic* there is no opportunity to operate on the chunk structure
outside of the TeX environment itself.  Currently, we are not doing
anything that couldn't be done by LaTeX/TeX itself, if I understand
TeX's abilities correctly.  The concern is, if we we eliminate the
possibility of doing something before reaching TeX, we constrain
ourselves for minimal benefit.

The syntax questions are actually minor - \begin{chunk}{ vs. << is just
a matter of preference for string identification, except that the
former makes the direct to TeX parsing process easier.  The major issue
is the consequences that follow from assuming no weave step.  A first
example would be the source code introspection demonstrated by Ralf's
demo with cl-web - I doubt that functionality can be produced
reasonably inside LaTeX and for that job even noweb's abilities fall
short of what would be required for a really proper job of
introspection - i.e. cooperation with the compiler itself.  It is not a
feature we currently use (nor, admittedly, is it one the lisp tools
support as yet) but certainly it looks to be a very useful feature we
would want to consider using and one that cannot be reasonably
duplicated inside LaTeX.  There are undoubtedly other scenarios we
haven't gotten to yet.

My preference would be to use the following convention, retaining the
weave step:

<<chunkname>>[options]=

@

options would not have to be present, but would be checked for.  I
think this syntax would give us full control as far as non-standard
tangle/weave behaviors are concerned - a chunk could be designated as
being lisp, boot, spad, api, or anything else we wanted it to be.  I
don't know about noweb, but inside Lisp awareness of these options
shouldn't be hard to achieve.  We could do things like extract all lisp
chunks from a pamphlet or build an api document from the api chunks.

>From my standpoint, the only processing logic we should put in LaTeX is
the logic that pertains to actually typesetting the document.  A weave
step, potentially, can do a lot more than just typesetting the
document.  Currently, only noweb's weave functionality practically
demonstrates this ability but that doesn't have to remain true
indefinitely.

In any case, what the tools are capable of is less critical to me than
agreement on a syntax we can use to create the pamphlets in the first
place.  Which tool to use can be specified with a configure flag at
build time, so long as all the tools know what it is they are supposed
to be processing.  If we incorporate Ralf's example of an advanced
weave process as the default, we can most likely spruce up the weave
output of pamphlets immediately.  (Assuming noweb's introspection
routines can understand SPAD...)  If someone wants to work just in
Lisp, they can specify the lisp web and live with the (currently) more
limited output.  Given a consistent syntax, that is a developer's
choice at compile time.

So let's put the tool discussion aside for the moment, and think JUST
syntax and weave step.

I think Steve is right, and we don't want to ditch the weave step. 
Earlier I thought this might be a good idea but upon reflection I agree
with him.  What I wasn't aware of before is that a weave step is
potentially more than just translation for typesetting.  And if we
don't abandon the weave step, the << >> syntax serves just as well.

\start
Date: Sat, 21 Jul 2007 21:59:35 +0700 (NOVST)
From: Andrey G. Grozin
To: Cliff Yapp
Subject: Re: Pamphlet files and Axiom

Hello *,

Each layer of syntax brings in extra complications. For example, with the 
standard noweb syntax one cannot use << and >> unescaped. When there are 
many layers and many things to be escaped by different characters, things 
become unreadable. For example, if I want to find all lines with \\ in my 
LaTeX file, I have to say

grep \\\\\\\\ foo.tex

because of regex escapes and shell escapes (yes, I know how to write it a 
little shorter, but I just wanted to show an example with multi-layes 
escapes due to the regex syntax and the shell syntax). Similar things 
happen in C strings with regexes, etc. The fewer layers, escapes and 
syntaxes, the better.

noweb is (as far as I know) not flexible enough to do axiom-specific 
things (like introspection). Such things should be done by axiom 
components, like compiler. And it is equally easy to teach it to 
understand \begin{chunk}{foo} ... \end{chunk} as the noweb syntax. One 
layer less, no need to escape << and >>.

\start
Date: 21 Jul 2007 11:10:27 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: Re: Pamphlet files and Axiom

Hi Cliff,

I think you are making some very important points.

Cliff Yapp writes:
[...]
> My preference would be to use the following convention, retaining the
> weave step:
> 
> <<chunkname>>[options]=
> 
> @

I myself think that noweb made a mistake in choosing the <<chunkname>>
syntax.  It stands out well but it introduces another character
sequence `<<' which needs to be escaped.  I really prefer the syntax
used in CWEB, so we could write:

    @<chunkname@>[options]=

Or some such.  @ signs are a very rare candidate for collision in both
written text and program code.  Plus, we can boil down the rules for
when such characters are `active'.  For example, the rules could be:

     - @< is active everywhere, in code and text.

     - A single @ is active when it appears in the first column
       position.

The reason `@<' is active everywhere is that you can reference a code
chunk in program code and text in a uniform way, by simply typing
@<chunkname@>.

I have been using these rules with very good success in the initial
pamphletization of my noweb-like tool.  Considering the code and
documentation is full of @ signs, its is only in a handfull of cases I
have need to escape.


> options would not have to be present, but would be checked for.  I
> think this syntax would give us full control as far as non-standard
> tangle/weave behaviors are concerned - a chunk could be designated as
> being lisp, boot, spad, api, or anything else we wanted it to be.  I
> don't know about noweb, but inside Lisp awareness of these options
> shouldn't be hard to achieve.  We could do things like extract all lisp
> chunks from a pamphlet or build an api document from the api chunks.

Absolutely.  We could also reserve one or two more `magic' sequences,
like @[, and @(.  In fact, the occurence of such `at sign + delimiter
collision' is so rare that we might even be able to reserve a full set
of escapes based on the common opening delimiters without it impacting
on the user, thus allowing a fairly rich name space with which to work.

[...]
> So let's put the tool discussion aside for the moment, and think JUST
> syntax and weave step.
> 
> I think Steve is right, and we don't want to ditch the weave step. 
> Earlier I thought this might be a good idea but upon reflection I agree
> with him.  What I wasn't aware of before is that a weave step is
> potentially more than just translation for typesetting.  And if we
> don't abandon the weave step, the << >> syntax serves just as well.

Practically speaking, the weave step can also help immensely when
typesetting the document too.

For example, I am using the `fancyvrb' package as the verbatim
environment in which code chunks are output.  That package allows you
to escape to latex from within the environment.  I use that to embed
hyperlinks to code chunk references (cl-web does this too, I think,
but uses the listings package, right?).

In this environment, to escape to latex, one needs to define three
character escapes.  For example, you could use !, [, and ].  Which
means that the latex command \texttt{foo} could be embedded directly
into your verbatim environment by writing !texttt[foo].  

You know this, I am sure, but I do have a point, and here it is :)

I am using the standard three characters \, {, and } currently as
escapes, which means that anywhere these characters occur in your
program weave needs to replace them with something else.  I do this my
simply defining a few macros which expand into the respective
charcodes.

Thus, the Lisp string:
   "\\usepackage{fancyvrb}"

gets translated into the latex

   "\axBS{}\axBS{}usepackage\axLB{}fancyvrb\axRB{}"

Which I am very happy I did not need to type directly.

A weave tool can also support several kinds of verbatim environments,
without the author of a pamphlet worrying that there programs might
contain active characters which will collide.

\start
Date: 21 Jul 2007 11:16:56 -0400
From: Stephen Wilson
To: Andrey G. Grozin
Subject: Re: Pamphlet files and Axiom

Andrey G. Grozin writes:
> And it is equally easy to teach it to
> understand \begin{chunk}{foo} ... \end{chunk} as the noweb syntax. One
> layer less, no need to escape << and >>.

What are the active escape characters in your model?  The `\'? The 7 
character sequence "\begin{".  How do you embed a hyper link to
another chunk of code in your program listing?  Do you use an escape?

Your not going to get around escapes, unless you want to typeset in
strict verbatim environments.

\start
Date: 21 Jul 2007 11:26:42 -0400
From: Stephen Wilson
To: Stephen Wilson
Subject: Re: Pamphlet files and Axiom

Stephen Wilson writes:

> Andrey G. Grozin writes:
> > And it is equally easy to teach it to
> > understand \begin{chunk}{foo} ... \end{chunk} as the noweb syntax. One
> > layer less, no need to escape << and >>.
> 
> What are the active escape characters in your model?  The `\'? The 7 
> character sequence "\begin{".  How do you embed a hyper link to ...
                      ^^^^^^^
I meant to type:  The 11 character sequence "\end{chunk}".

\start
Date: Sat, 21 Jul 2007 10:30:32 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Pamphlet format discussion

The current silver axiom.sty definition of the axiom environment
definition uses the alltt verbatim environment which is shipped
with standard latex. This could trivially be changed to use the
fancyvrb environment.

See the silver file src/doc/axiom.sty.pamphlet, lines 16-63
In particular, see line 53 for the use of alltt. Changing this
to fancyvrb would mean that 

\begin{chunk}{chunkname}

would use the fancyvrb environment.

\start
Date: Sat, 21 Jul 2007 10:34:57 -0500
From: Tim Daly
To: Cliff Yapp, Andrey G. Grozin
Subject: Pamphlet format discussion

Cliff, Andrey

It would be trivial to add another argument to the chunk to
allow your optional language argument.

See the silver file src/doc/axiom.sty.pamphlet, lines 16-63
In particular, see line 50.

To add the optional argument line 50, which now reads:

   \newenvironment{chunk}[1]{

would be changed to read:

   \newenvironment{chunk}[1][1]{


After that change you could write:


\begin{chunk}{chunkname}
\begin{chunk}{chunkname}{spad}
\begin{chunk}{chunkname}{makefile}
\begin{chunk}{chunkname}{lisp}

\start
Date: Sat, 21 Jul 2007 10:38:29 -0500
From: Tim Daly
To: Cliff Yapp,	Andrey G. Grozin, Stephen Wilson
Subject: Pamphlet format discussion

Cliff, Andrey, Steve,

I hope to demonstrate the ability to extract a small, well defined
portion of a pamphlet file in response to an axiom help command
using the lisp-level weave. Thus I'd like to be able to say

  )help DHMATRIX )examples

which involves extracting just the portion of the dhmatrix.spad.pamphlet
file that shows examples for each command. This could also be more
specific to apply to a single command, such as

  )help DHMATRIX )examples rotate

This requires a combination of tangle and weave.

\start
Date: Sat, 21 Jul 2007 11:40:31 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Pamphlet format discussion
Cc: Benjamin Kosnik

On 21 Jul 2007 03:29:01 -0500, Gabriel Dos Reis wrote:
> "Bill Page" writes:
>
> [...]
>
> | Integrating noweb into Axiom to support the current pamphlet file
> | format seems entirely reasonable to me. I think calling noweb as a
> | system supplied utility is the best approach.
>
> Please don't go out of your way to "copy" noweb into Axiom.  Make it
> a dependency.

Yes I agree. noweb should *only* be a dependency *not* copied into the
Axiom source. It is a tool to be used just like gcl uses gcc - not
more.

>
> At IBM Toronto, where we just had an ISO C++ meeting, I spoke again
> with Benjamin Kosnik (from Red Hat, in CC:) about what would remain to be
> done to get Axiom packaged and distributed in Fedora Core (for
> example).  I explained what has been done in terms moving to standard
> build system.  I pointed out that at this moment we still critically
> depend on GCL and noweb.  He quickly made a search and informed me
> that FC distributes GCL-2.6.7-something (but I guess the next FC may
> distribute GCL-2.6.8 if it is finalized by then), but they do not
> have noweb at the moment.

That is excellent. Thank you for bringing this up with him.

Perhaps you will recall that Camm Maguire actually distributes the
current gcl-2.6.8pre as a "fix" release to gcl-2.6.7 on Debian.
Perhaps a similar approach should be taken with Red Hat?

> He looked at the noweb page and suggested
> that a first step would be to list the noweb RPM as a dependency in yum
> package and see how it works.

Could you explain what you mean by this? What yum package? Do you mean
that we shoulld encourage the noweb developer (Norman Ramsey) to
submit such a package?

>  Benjamin is very willing to provide
> advice on how to make forward progress with these issues.
> I have not spoken with the SuSE people recently about the progress we
> have made with Axiom.build-improvements, but I would be surprised if
> they didn't say roughly the same thing.
>
> We should try hard to avoid complicating system packager's life.
>

Indeed! We want to make it as easy as possible to re-distribute Axiom.

\start
Date: 21 Jul 2007 11:42:54 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Pamphlet format discussion

Tim Daly writes:

> Stephen,
> 
> The current silver axiom.sty definition of the axiom environment
> definition uses the alltt verbatim environment which is shipped
> with standard latex. This could trivially be changed to use the
> fancyvrb environment.
> 
> See the silver file src/doc/axiom.sty.pamphlet, lines 16-63
> In particular, see line 53 for the use of alltt. Changing this
> to fancyvrb would mean that 
> 
> \begin{chunk}{chunkname}
> 
> would use the fancyvrb environment.

I looked at the code there as I used to do most of my typesetting work
in plain TeX and am not up to speed on LaTeX yet, so I needed a bit of
inspiration on how to get my local experiment working :)

Out of curiosity, what are the plans for the \begin{chunk} environment
w.r.t active escape characters?  It would be possible to reduce them
to an out-fix delimiter pair.  For example, if the @ sign were used you
could write @\LaTeX\@ in the running code, and then maybe @\atsign@
for a literal `@' character.

Also, is it possible to change (now or in the future) the verbatim
environment used by the \begin{chunk} construct in the sty file
without need to audit all your code for active characters?

\start
Date: Sat, 21 Jul 2007 08:55:59 -0700 (PDT)
From: Cliff Yapp
To: Stephen Wilson
Subject: Re: Pamphlet files and Axiom

--- Stephen Wilson wrote:

> Hi Cliff,
> 
> I think you are making some very important points.

Thanks.  I'm trying my best to keep the "big picture" in mind here,
despite my burning desire to move on to things other than pamphlet
format ;-).

> Cliff Yapp writes:
> [...]
> > My preference would be to use the following convention, retaining
> > the weave step:
> > 
> > <<chunkname>>[options]=
> > 
> > @
> 
> I myself think that noweb made a mistake in choosing the
> <<chunkname>> syntax.  It stands out well but it introduces
> another character sequence `<<' which needs to be escaped.

I think an important question to ask here is which is more critical -
the delimiters standing out to the human eye or minimizing the
character sequences that need to be escaped?

My thought (and this is JUST my thought) is that most of the time spent
with pamphlets will be human beings editing them.  In that context, the
most important thing is for the human being to be able to easily read
and edit the pamphlet.  If we must escape the << sequence it is a pain,
but how often does << appear in Lisp or Spad code?  Or, put another
way, is the number of cases where << must be escaped sufficiently high
that the inconvenience of doing it offsets the reading advantage of the
<< >> form? 

I don't know how you're doing your code, but cl-web will pass by <<
except in two cases - one is where << is part of a << >>= structure and
the other is inside a chunk when it is part of a << >> structure.  I
actually didn't need to escape (even when cl-web was tangling and
weaving itself!) except for the case of defining the escape delimiters
for the listings package in code, and for that I cheated and used
(char-code) to specify what characters to put rather than including the
literal character.

> I really prefer the syntax used in CWEB, so we could write:
> 
>     @<chunkname@>[options]=
> 
> Or some such.  @ signs are a very rare candidate for collision in
> both written text and program code.  Plus, we can boil down the rules
> for when such characters are `active'.  For example, the rules could
> be:
> 
>      - @< is active everywhere, in code and text.
> 
>      - A single @ is active when it appears in the first column
>        position.

Hmm.  I'll need to think about this, and more specifically what it
means to be "active".
 
> The reason `@<' is active everywhere is that you can reference a code
> chunk in program code and text in a uniform way, by simply typing
> @<chunkname@>.

Oh, OK.  I've been using the chunk structures only for identifying the
chunks - for any kind of reference work I would have the weave step
generate a LaTeX label and reference that using normal procedures in
LaTeX.  How were you planning to use this feature?

> I have been using these rules with very good success in the initial
> pamphletization of my noweb-like tool.  Considering the code and
> documentation is full of @ signs, its is only in a handfull of cases
> I have need to escape.
 
That will be very interesting to see!  I sidestepped the escape problem
the one time it came up, so it's not really a problem cl-web addresses
at all.  The idea was to use the rigid structure of the chunk
definition to make sure escape wouldn't be necessary.
 
> Absolutely.  We could also reserve one or two more `magic' sequences,
> like @[, and @(.  In fact, the occurence of such `at sign + delimiter
> collision' is so rare that we might even be able to reserve a full
> set of escapes based on the common opening delimiters without it
> impacting on the user, thus allowing a fairly rich name space with
> which to work.

Again, the problem there is the visual difference between 

@[chunkname@] and @(chunkname@) 

is rather slight, as compared to

<<chunkname>>[lisp] and <<chunkname>>[spad]

To my eye at least the latter makes for much easier reading.  Whether
this is important enough to warrant consideration should probably be a
matter for discussion - in my opinion the readability of code intended
for humans to read and edit is very important.

> Practically speaking, the weave step can also help immensely when
> typesetting the document too.
> 
> For example, I am using the `fancyvrb' package as the verbatim
> environment in which code chunks are output.  That package allows you
> to escape to latex from within the environment.  I use that to embed
> hyperlinks to code chunk references (cl-web does this too, I think,
> but uses the listings package, right?).

Yes.  In the case of cl-web the hyperlinks are automatically generated
as part of the weave process itself - the code author should never need
to directly escape to LaTeX.
 
> Thus, the Lisp string:
>    "\\usepackage{fancyvrb}"
> 
> gets translated into the latex
> 
>    "\axBS{}\axBS{}usepackage\axLB{}fancyvrb\axRB{}"
> 
> Which I am very happy I did not need to type directly.

Yes.  cl-web also makes use of the automatic substitution of the weave
step.  If I follow you, the point you are making is that the weave step
outside of LaTeX makes for much simpler creation hyperlinking within
the code chunks.  I whole-heartedly agree with that.  To be fair,
whether it is possible to do that with a LaTeX style file as well is
something I am not sure about.  I had assumed when Tim said he was
working on the LaTeX only solution he would include abilities such as
this in the style file.

> A weave tool can also support several kinds of verbatim environments,
> without the author of a pamphlet worrying that there programs might
> contain active characters which will collide.

Um.  Can you give an example of what you mean here?

\start
Date: Sat, 21 Jul 2007 09:09:14 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Andrey G. Grozin,	Stephen Wilson
Subject: Re: Pamphlet format discussion

--- Tim Daly wrote:

> Cliff, Andrey, Steve,
> 
> I hope to demonstrate the ability to extract a small, well defined
> portion of a pamphlet file in response to an axiom help command
> using the lisp-level weave. Thus I'd like to be able to say
> 
>   )help DHMATRIX )examples
> 
> which involves extracting just the portion of the
> dhmatrix.spad.pamphlet
> file that shows examples for each command. 

That's a good example.  How would you plan to identify the part of the
pamphlet file that contains the example?  Something like:

\begin{chunk}{chunk1}{spad}
code
\end{chunk}

\begin{chunk}{chunk1}{example}
example
\end{chunk}

is one option, but then the tangle operation needs to know not to
extract the example into the source file.  Or maybe just having a
unique chunk name for the example:

\begin{chunk}{chunk1}
code
\end{chunk}

\begin{chunk}{chunk1-example}
example
\end{chunk}

and having the help command know the chunk names of the examples in
dhmatrix? 

> This could also be more
> specific to apply to a single command, such as
> 
>   )help DHMATRIX )examples rotate
> 
> This requires a combination of tangle and weave.

Correct.  How did you plan to be able to have Axiom know which example
in the pamphlet pertains to the rotate command?  Presumably the
pamphlet structure itself would need to suggest this - what mechanism
did you have in mind?

\start
Date: Sat, 21 Jul 2007 12:19:48 -0400
From: Bill Page
To: Tim Daly
Subject: Re: Pamphlet format discussion

On 7/21/07, Tim Daly wrote:
> ...
> So, two points then.
>
> 1) "Rewriting basic tools is a waste of current and future resources."
>
>...
> There are no "current and future" resources. This is a volunteer effort
> and we only get to decide our own resource usage. Objecting to the use
> other people make of their time isn't a topic of debate.
>

I do not object to how you spend you time. My only objection is the
the direction in which you lead the Axiom project. In my opinion this
direction of development results in significant wasted effort.

>
> 2) "I don't know what "future planned use" involves but in my opinion
>    more radical changes in literate programming philosophy are required
>    than can be accomplished by changes of this kind."
>
> At the present time there is no user-visible difference between noweb
> and cl-web (or, for non-ansi, gclweb). Thus they are functionally
> equivalent.
>
> Since you don't have future plans and don't know of any future plans
> it seems that you must be objecting to my future plans.  For instance,
> there have been discussions of my future plans for crystal on this
> list in the past. Clearly noweb is not adequate for those "future
> plans".

If by "plans" you are referring to your email of a few years ago
regarding your vision of a "crystal" as a navigation mechanism in
Axiom, then as I said I think your current approach of extending noweb
and incorporating noweb-like access in Axiom is entirely inadequate. I
much more radical approach to literate programming and to the Axiom
user interface in general is required.

>
> Rather than say "no" to system change it seems more useful to propose
> an alternative. Anyone can say "no" but that just slows progress.
>

It is only my opinion, but "progress" in the wrong direction seems
worse than no progress. In fact I have proposed some alternatives
including Leo and the kind of Axiom-related features that I have
implemented in MathAction. I think either (or both) of these
approaches is much more interesting that playing with noweb syntax.

> What plans do you have that are impacted by the change?
> How can we compromise on the plans you have versus the plans I have?
>

I do not think your plans will have much impact on my own use of Axiom.

> It also seems that your objections are at the level of construction
> (don't put that brick there) rather than architecture (we need 4 bell
> towers, not 3).
>
> Architectural decisions are reasonably subject to objection and vote.
> Construction decisions follow from necessity and aren't appropriate
> for voting.
>

I don't understand what you are trying to say here.

>From my point of view what I have been talking about is at the level
of the Axiom system architecture.

\start
Date: Sat, 21 Jul 2007 12:23:40 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Pamphlet format discussion

> ...
> Tim Daly wrote:
> | There are no "current and future" resources. This is a volunteer effort
> | and we only get to decide our own resource usage. Objecting to the use
> | other people make of their time isn't a topic of debate.
>
On 21 Jul 2007 03:42:15 -0500, Gabriel Dos Reis wrote:
> The objection, as I understand it, is not to your spending your time
> playing with your toy.   The objection as, I understand it, is against
> having the common toy (Axiom) move to duplicating functionalities
> (already provided by external tools) and having to maintain the source
> code.  It is a waste of resource.
>

Yes, that is exactly my point.

\start
Date: 21 Jul 2007 12:39:00 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: Re: Pamphlet files and Axiom

Cliff Yapp writes:
> My thought (and this is JUST my thought) is that most of the time spent
> with pamphlets will be human beings editing them.  In that context, the
> most important thing is for the human being to be able to easily read
> and edit the pamphlet.  If we must escape the << sequence it is a pain,
> but how often does << appear in Lisp or Spad code? 

It appears quite often in Aldor, where it is an operator.  There is no
reason to expect that it will not become one in Spad too.  It is also
very common in C and C++, for example, among other languages.  I like
nowebs `language neutral' approach, but I think `<<' was a mistake for
such a general purpose tool.

> Or, put another way, is the number of cases where << must be escaped
> sufficiently high that the inconvenience of doing it offsets the
> reading advantage of the << >> form?

I find, personally, @<chunk@> fairly pleasent.  Emacs can be taught to
highlight such sequences, giving them a more pronounced, or a softer
appearance, according to ones taste.

I think that the rarity of collision using the `@' based form as
opposed to `<<' is quite an important property.

> I don't know how you're doing your code, but cl-web will pass by <<
> except in two cases - one is where << is part of a << >>= structure and
> the other is inside a chunk when it is part of a << >> structure.  I
> actually didn't need to escape (even when cl-web was tangling and
> weaving itself!) except for the case of defining the escape delimiters
> for the listings package in code, and for that I cheated and used
> (char-code) to specify what characters to put rather than including the
> literal character.

In my version, the detailed (preliminary) rules are:
   
   1) An at sign in the first column is `active'.  This is to allow for
      future extensions.  If the resulting line does not parse
      according to the following rules, it is an error.

   2) An at sign in the first column followed by a space, newline, or
      EOF, introduce a document chunk.

   3) An `@<' sequence anywhere introduces either a code chunk
      definition or a code chunk reference.  A chunk definition starts
      on the first coloumn and has the full form @<chunkname@>=, a
      chunk reference is just @<chunkname@>.

So, if you need an at sign in the first column position, type `@@', if
you need the sequence `@<', type `@@<'.

I am also considering reserving at-sign/delimiter sequences in general
for future use by the tool, in the same spirit as rule 1.

[...]
> Oh, OK.  I've been using the chunk structures only for identifying the
> chunks - for any kind of reference work I would have the weave step
> generate a LaTeX label and reference that using normal procedures in
> LaTeX.  How were you planning to use this feature?

I just expand chunk references into an appropriate hyperlink using the
hyperref package.  You have clickable links in both code and
documentation chunks.

Currently, they expand into the chunk name in both text and code as
"<chunkname>", but it would be nice in the doc chunks to specify some
arbitrary latex string into which they expand serving as the clickable
region.  I might experiment with @<chunkname@>[lable=\someTeX{}] or
somesuch.

> > I have been using these rules with very good success in the initial
> > pamphletization of my noweb-like tool.  Considering the code and
> > documentation is full of @ signs, its is only in a handfull of cases
> > I have need to escape.
>  
> That will be very interesting to see!  I sidestepped the escape problem
> the one time it came up, so it's not really a problem cl-web addresses
> at all.  The idea was to use the rigid structure of the chunk
> definition to make sure escape wouldn't be necessary.

The code I am working on fully supports the ability to have active
escape characters in the latex environment which is used to typeset
your code, without one needing to even think about it.

> > Absolutely.  We could also reserve one or two more `magic' sequences,
> > like @[, and @(.  In fact, the occurence of such `at sign + delimiter
> > collision' is so rare that we might even be able to reserve a full
> > set of escapes based on the common opening delimiters without it
> > impacting on the user, thus allowing a fairly rich name space with
> > which to work.
> 
> Again, the problem there is the visual difference between 
> 
> @[chunkname@] and @(chunkname@) 
> 
> is rather slight, as compared to
> 
> <<chunkname>>[lisp] and <<chunkname>>[spad]
> 
> To my eye at least the latter makes for much easier reading.  Whether
> this is important enough to warrant consideration should probably be a
> matter for discussion - in my opinion the readability of code intended
> for humans to read and edit is very important.

I personally dont find them too hard to distinguish, but I would like
a good pamphlet.el mode to highlight them differently. 

The idea is to allow different concepts to be associated with the
sequences.  For example, @[some text@] when appearing in a code chunk
could escape into raw LaTeX.

We could overload a single escape sequence to accomplish that, but
then readability I think is hindered more.  For example

    <<chunkname>>[lang=lisp]   vs  <<chunkname>>[latex=true]

Where the interpretation of "chunkname" is different in the two
contexts.

[...]
> > A weave tool can also support several kinds of verbatim environments,
> > without the author of a pamphlet worrying that there programs might
> > contain active characters which will collide.
> 
> Um.  Can you give an example of what you mean here?


Sure.  Take the listings package vs. fancyvrb.  They have different
policies about how to escape into raw latex.  In the listings package
an active character is used to delimit the expression you want LaTeX
to see. So you can say the `!' character escapes, and write
`!\LaTeX\!'.  Compare to the three characters needed with fancyvrb.

This means that only one character needs to be expanded specially --
all `!' characters when they appear in code chunks.

I experimented with both packages while writing the code, and I could
tell the tool how to transform the running text as appropriate by
changing a few definitions here and there.  It is quite possible to
design a general mechanism which would allow the user to configure the
system concisely to use various environments and escape policies (this
would go under the section titled `Advanced Usage' in the pamphlet).

\start
Date: Sat, 21 Jul 2007 09:41:52 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Gabriel Dos Reis
Subject: Re: Pamphlet format discussion

--- Bill Page wrote:

> On 21 Jul 2007 03:42:15 -0500, Gabriel Dos Reis wrote:
> > The objection as, I understand it, is against having the common toy
> > (Axiom) move to duplicating functionalities (already provided by
> > external tools) and having to maintain the source code.  It is a
> > waste of resource.
> >
> 
> Yes, that is exactly my point.

Once the autoconf work becomes mainstream, this won't matter.  The
build logic can presumably be set up such that if noweb is specified as
the literate programming tool, the other tools never need to be touched
by the build.  In that scenario, as long as the behavior and structure
the point AFTER which the literate tool of choice is loaded are
consistent, maintaining other tools need concern only those who want to
use them.  Bill, you and Gaby shouldn't ever have to worry about it -
no one would ask you to work on them.  At most, we might ask that they
be listed as a configure option with enough logic to trigger them.  I'm
hopeful that an entry of that sort would border on trivial.

Ideally, once these things are done they will require very little work
as long as a working Lisp environment is present, but again it would
matter ONLY to the people wanting to use it.  The only point at which
it becomes a real issue is if the pamphlets go in a direction that
noweb can't follow, and I don't see that happening for a good long
while.

\start
Date: 21 Jul 2007 12:54:29 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: Re: Pamphlet format discussion
Cc: Gabriel Dos Reis

Cliff Yapp writes:
> Ideally, once these things are done they will require very little work
> as long as a working Lisp environment is present, but again it would
> matter ONLY to the people wanting to use it.  The only point at which
> it becomes a real issue is if the pamphlets go in a direction that
> noweb can't follow, and I don't see that happening for a good long
> while.

It only took a couple of hours to write a fully functional noweb
replacement.  New features can be added actively.  The time frame
of noweb being sufficient is very, very short.

A lisp based tool integrated with axiom turns the dependency
discussion into no discussion at all.

\start
Date: Sat, 21 Jul 2007 11:54:57 -0500
From: Tim Daly
To: list
Subject: diff-Naur 20070721.01.tpd.patch

Attached is a changeset to update the list of contributors
to the Axiom project. This list is available in Axiom with
the )credits command.

You can apply this patch to your tree by 
  cd your-axiom-root
  patch -p1 <20070721.01.tpd.patch

Note that, by default, patch tries to skip any leading garbage,
apply the diff, and then skip any trailing garbage. Thus you can
save this whole email as a file, run the above patch command, and
patch will "do the right thing".

Tim

diff --git a/changelog b/changelog
index 3ac5da7..0c9e91d 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,5 @@
+20070721 tpd src/interp/setq.lisp update contributor name list
+20070721 tpd readme update contributor name list
 20070716 tpd src/doc/axiom.bib move developernotes to bookvol4
 20070716 tpd src/doc/Makefile move developernotes to bookvol4
 20070716 tpd src/input/Makefile add chtheorem.regress
diff --git a/readme b/readme
index 2ce2d10..112fa70 100644
--- a/readme
+++ b/readme
@@ -166,24 +166,27 @@ which contains this list. Typing
 )credits 
 at the axiom command prompt will prettyprint the list.
 
-"An alphabetical listing of contributors to AXIOM (to October, 2006):"
+"An alphabetical listing of contributors to AXIOM (to July, 2007):"
 "Cyril Alberga          Roy Adler              Christian Aistleitner"
 "Richard Anderson       George Andrews         S.J. Atkins"
 "Henry Baker            Stephen Balzac         Yurij Baransky"
 "David R. Barton        Gerald Baumgartner     Gilbert Baumslag"
-"Fred Blair             Vladimir Bondarenko    Mark Botch"
+"Jay Belanger           David Bindel           Fred Blair"
+"Vladimir Bondarenko    Mark Botch"
 "Alexandre Bouyer       Peter A. Broadbery     Martin Brock"
 "Manuel Bronstein       Florian Bundschuh      Luanne Burns"
 "William Burge"
 "Quentin Carpent        Robert Caviness        Bruce Char"
-"Cheekai Chin           David V. Chudnovsky    Gregory V. Chudnovsky"
-"Josh Cohen             Christophe Conil       Don Coppersmith"
-"George Corliss         Robert Corless         Gary Cornell"
-"Meino Cramer           Claire Di Crescenzo"
+"Ondrej Certik          Cheekai Chin           David V. Chudnovsky"
+"Gregory V. Chudnovsky  Josh Cohen             Christophe Conil"
+"Don Coppersmith        George Corliss         Robert Corless"
+"Gary Cornell           Meino Cramer           Claire Di Crescenzo"
+"David Cyganski"
 "Timothy Daly Sr.       Timothy Daly Jr.       James H. Davenport"
-"Jean Della Dora        Gabriel Dos Reis       Michael Dewar"
-"Claire DiCrescendo     Sam Dooley             Lionel Ducos"
-"Martin Dunstan         Brian Dupee            Dominique Duval"
+"Didier Deshommes       Michael Dewar"
+"Jean Della Dora        Gabriel Dos Reis       Claire DiCrescendo"
+"Sam Dooley             Lionel Ducos           Martin Dunstan"
+"Brian Dupee            Dominique Duval"
 "Robert Edwards         Heow Eide-Goodman      Lars Erickson"
 "Richard Fateman        Bertfried Fauser       Stuart Feldman"
 "Brian Ford             Albrecht Fortenbacher  George Frances"
@@ -191,33 +194,36 @@ at the axiom command prompt will prettyprint the list.
 "Marc Gaetano           Rudiger Gebauer        Kathy Gerber"
 "Patricia Gianni        Holger Gollan          Teresa Gomez-Diaz"
 "Laureano Gonzalez-Vega Stephen Gortler        Johannes Grabmeier"
-"Matt Grayson           James Griesmer         Vladimir Grinberg"
-"Oswald Gschnitzer      Jocelyn Guidry"
-"Steve Hague            Satoshi Hamaguchi      Richard Harke"
-"Vilya Harvey           Martin Hassner         Arthur S. Hathaway"
-"Waldek Hebisch         Ralf Hemmecke          Henderson"
-"Antoine Hersen"
+"Matt Grayson           Klaus Ebbe Grue        James Griesmer"
+"Vladimir Grinberg      Oswald Gschnitzer      Jocelyn Guidry"
+"Steve Hague            Satoshi Hamaguchi      Mike Hansen"
+"Richard Harke          Vilya Harvey           Martin Hassner"
+"Arthur S. Hathaway     Waldek Hebisch         Ralf Hemmecke"
+"Henderson              Antoine Hersen         Gernot Hueber"
 "Pietro Iglio"
 "Richard Jenks"
 "Kai Kaminski           Grant Keady            Tony Kennedy"
 "Paul Kosinski          Klaus Kusche           Bernhard Kutzler"
-"Larry Lambe            Frederic Lehobey       Michel Levaud"
-"Howard Levy            Rudiger Loos           Michael Lucks"
-"Richard Luczak"
-"Camm Maguire           Francois Maltey        Bob McElrath"
-"Michael McGettrick     Ian Meikle             David Mentre"
-"Victor S. Miller       Gerard Milmeister      Mohammed Mobarak"
-"H. Michael Moeller     Michael Monagan        Marc Moreno-Maza"
-"Scott Morrison         Joel Moses             Mark Murray"
+"Larry Lambe            Franz Lehner           Frederic Lehobey"
+"Michel Levaud          Howard Levy            Rudiger Loos"
+"Michael Lucks          Richard Luczak"
+"Camm Maguire           Francois Maltey        Alasdair McAndrew"
+"Bob McElrath           Michael McGettrick     Ian Meikle"
+"David Mentre           Victor S. Miller       Gerard Milmeister"
+"Mohammed Mobarak       H. Michael Moeller     Michael Monagan"
+"Marc Moreno-Maza       Scott Morrison         Joel Moses"
+"Mark Murray"
 "William Naylor         C. Andrew Neff         John Nelder"
 "Godfrey Nolan          Arthur Norman          Jinzhong Niu"
-"Michael O'Connor       Kostas Oikonomou       Humberto Ortiz-Zuazaga"
+"Michael O'Connor       Summat Oemrawsingh     Kostas Oikonomou"
+"Humberto Ortiz-Zuazaga"  
 "Julian A. Padget       Bill Page              Susan Pelzel"
-"Michel Petitot         Didier Pinchon         Jose Alfredo Portes"
+"Michel Petitot         Didier Pinchon         Ayal Pinkus"
+"Jose Alfredo Portes"
 "Claude Quitte"
 "Norman Ramsey          Michael Richardson     Renaud Rioboo"
 "Jean Rivlin            Nicolas Robidoux       Simon Robinson"
-"Michael Rothstein      Martin Rubey"
+"Raymond Rogers         Michael Rothstein      Martin Rubey"
 "Philip Santas          Alfred Scheerhorn      William Schelter"
 "Gerhard Schneider      Martin Schoenert       Marshall Schor"
 "Frithjof Schulze       Fritz Schwarz          Nick Simicich"
@@ -234,8 +240,8 @@ at the axiom command prompt will prettyprint the list.
 "Stephen Wilson         Shmuel Winograd        Robert Wisbauer"
 "Sandra Wityak          Waldemar Wiwianka      Knut Wolf"
 "Clifford Yapp          David Yun"
-"Richard Zippel         Evelyn Zoernack        Bruno Zuercher"
-"Dan Zwillinger"
+"Vadim Zhytnikov        Richard Zippel         Evelyn Zoernack"
+"Bruno Zuercher         Dan Zwillinger"
 
 Pervasive Literate Programming
 
diff --git a/src/interp/setq.lisp.pamphlet b/src/interp/setq.lisp.pamphlet
index a4fc0ed..6f23778 100644
--- a/src/interp/setq.lisp.pamphlet
+++ b/src/interp/setq.lisp.pamphlet
@@ -722,24 +722,27 @@
 (setq |$profileCompiler| nil)
 
 (setq credits '(
-"An alphabetical listing of contributors to AXIOM (to October, 2006):"
+"An alphabetical listing of contributors to AXIOM (to July, 2007):"
 "Cyril Alberga          Roy Adler              Christian Aistleitner"
 "Richard Anderson       George Andrews         S.J. Atkins"
 "Henry Baker            Stephen Balzac         Yurij Baransky"
 "David R. Barton        Gerald Baumgartner     Gilbert Baumslag"
-"Fred Blair             Vladimir Bondarenko    Mark Botch"
+"Jay Belanger           David Bindel           Fred Blair"
+"Vladimir Bondarenko    Mark Botch"
 "Alexandre Bouyer       Peter A. Broadbery     Martin Brock"
 "Manuel Bronstein       Florian Bundschuh      Luanne Burns"
 "William Burge"
 "Quentin Carpent        Robert Caviness        Bruce Char"
-"Cheekai Chin           David V. Chudnovsky    Gregory V. Chudnovsky"
-"Josh Cohen             Christophe Conil       Don Coppersmith"
-"George Corliss         Robert Corless         Gary Cornell"
-"Meino Cramer           Claire Di Crescenzo"
+"Ondrej Certik          Cheekai Chin           David V. Chudnovsky"
+"Gregory V. Chudnovsky  Josh Cohen             Christophe Conil"
+"Don Coppersmith        George Corliss         Robert Corless"
+"Gary Cornell           Meino Cramer           Claire Di Crescenzo"
+"David Cyganski"
 "Timothy Daly Sr.       Timothy Daly Jr.       James H. Davenport"
-"Jean Della Dora        Gabriel Dos Reis       Michael Dewar"
-"Claire DiCrescendo     Sam Dooley             Lionel Ducos"
-"Martin Dunstan         Brian Dupee            Dominique Duval"
+"Didier Deshommes       Michael Dewar"
+"Jean Della Dora        Gabriel Dos Reis       Claire DiCrescendo"
+"Sam Dooley             Lionel Ducos           Martin Dunstan"
+"Brian Dupee            Dominique Duval"
 "Robert Edwards         Heow Eide-Goodman      Lars Erickson"
 "Richard Fateman        Bertfried Fauser       Stuart Feldman"
 "Brian Ford             Albrecht Fortenbacher  George Frances"
@@ -747,33 +750,36 @@
 "Marc Gaetano           Rudiger Gebauer        Kathy Gerber"
 "Patricia Gianni        Holger Gollan          Teresa Gomez-Diaz"
 "Laureano Gonzalez-Vega Stephen Gortler        Johannes Grabmeier"
-"Matt Grayson           James Griesmer         Vladimir Grinberg"
-"Oswald Gschnitzer      Jocelyn Guidry"
-"Steve Hague            Satoshi Hamaguchi      Richard Harke"
-"Vilya Harvey           Martin Hassner         Arthur S. Hathaway"
-"Waldek Hebisch         Ralf Hemmecke          Henderson"
-"Antoine Hersen"
+"Matt Grayson           Klaus Ebbe Grue        James Griesmer"
+"Vladimir Grinberg      Oswald Gschnitzer      Jocelyn Guidry"
+"Steve Hague            Satoshi Hamaguchi      Mike Hansen"
+"Richard Harke          Vilya Harvey           Martin Hassner"
+"Arthur S. Hathaway     Waldek Hebisch         Ralf Hemmecke"
+"Henderson              Antoine Hersen         Gernot Hueber"
 "Pietro Iglio"
 "Richard Jenks"
 "Kai Kaminski           Grant Keady            Tony Kennedy"
 "Paul Kosinski          Klaus Kusche           Bernhard Kutzler"
-"Larry Lambe            Frederic Lehobey       Michel Levaud"
-"Howard Levy            Rudiger Loos           Michael Lucks"
-"Richard Luczak"
-"Camm Maguire           Francois Maltey        Bob McElrath"
-"Michael McGettrick     Ian Meikle             David Mentre"
-"Victor S. Miller       Gerard Milmeister      Mohammed Mobarak"
-"H. Michael Moeller     Michael Monagan        Marc Moreno-Maza"
-"Scott Morrison         Joel Moses             Mark Murray"
+"Larry Lambe            Franz Lehner           Frederic Lehobey"
+"Michel Levaud          Howard Levy            Rudiger Loos"
+"Michael Lucks          Richard Luczak"
+"Camm Maguire           Francois Maltey        Alasdair McAndrew"
+"Bob McElrath           Michael McGettrick     Ian Meikle"
+"David Mentre           Victor S. Miller       Gerard Milmeister"
+"Mohammed Mobarak       H. Michael Moeller     Michael Monagan"
+"Marc Moreno-Maza       Scott Morrison         Joel Moses"
+"Mark Murray"
 "William Naylor         C. Andrew Neff         John Nelder"
 "Godfrey Nolan          Arthur Norman          Jinzhong Niu"
-"Michael O'Connor       Kostas Oikonomou       Humberto Ortiz-Zuazaga"
+"Michael O'Connor       Summat Oemrawsingh     Kostas Oikonomou"
+"Humberto Ortiz-Zuazaga"  
 "Julian A. Padget       Bill Page              Susan Pelzel"
-"Michel Petitot         Didier Pinchon         Jose Alfredo Portes"
+"Michel Petitot         Didier Pinchon         Ayal Pinkus"
+"Jose Alfredo Portes"
 "Claude Quitte"
 "Norman Ramsey          Michael Richardson     Renaud Rioboo"
 "Jean Rivlin            Nicolas Robidoux       Simon Robinson"
-"Michael Rothstein      Martin Rubey"
+"Raymond Rogers         Michael Rothstein      Martin Rubey"
 "Philip Santas          Alfred Scheerhorn      William Schelter"
 "Gerhard Schneider      Martin Schoenert       Marshall Schor"
 "Frithjof Schulze       Fritz Schwarz          Nick Simicich"
@@ -790,8 +796,8 @@
 "Stephen Wilson         Shmuel Winograd        Robert Wisbauer"
 "Sandra Wityak          Waldemar Wiwianka      Knut Wolf"
 "Clifford Yapp          David Yun"
-"Richard Zippel         Evelyn Zoernack        Bruno Zuercher"
-"Dan Zwillinger"
+"Vadim Zhytnikov        Richard Zippel         Evelyn Zoernack"
+"Bruno Zuercher         Dan Zwillinger"
 ))
 
 @

\start
Date: Sat, 21 Jul 2007 12:57:12 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Pamphlet format discussion
Cc: Gabriel Dos Reis

On 7/21/07, Cliff Yapp wrote:
> ...
> Once the autoconf work becomes mainstream, this won't matter.  The
> build logic can presumably be set up such that if noweb is specified as
> the literate programming tool, the other tools never need to be touched
> by the build.  In that scenario, as long as the behavior and structure
> the point AFTER which the literate tool of choice is loaded are
> consistent, maintaining other tools need concern only those who want to
> use them.  Bill, you and Gaby shouldn't ever have to worry about it -
> no one would ask you to work on them.  At most, we might ask that they
> be listed as a configure option with enough logic to trigger them.  I'm
> hopeful that an entry of that sort would border on trivial.
>

Certainly I don't want to spend my time working on this, but I was
thinking more of people like Norman Ramsey and other people who
already use noweb. Why not embrace the concept of co-operating with
other open source projects instead of re-inventing the wheel? Perhaps
people would be more interested in working on the Axiom project if we
use their work rather than redoing it.

> Ideally, once these things are done they will require very little work
> as long as a working Lisp environment is present, but again it would
> matter ONLY to the people wanting to use it.  The only point at which
> it becomes a real issue is if the pamphlets go in a direction that
> noweb can't follow, and I don't see that happening for a good long
> while.
>

That does not seem consistent with what Tim Daly is writing.

\start
Date: Sat, 21 Jul 2007 10:12:51 -0700 (PDT)
From: Cliff Yapp
To: Stephen Wilson
Subject: Re: Pamphlet files and Axiom

--- Stephen Wilson wrote:

> It appears quite often in Aldor, where it is an operator.  There is
> no reason to expect that it will not become one in Spad too.

But do the sequences << followed by >> occur on the same line in source
code often?  That is the only possibility that would require an escape.

> It is also very common in C and C++, for example, among other
> languages.  I like nowebs `language neutral' approach, but I think
> `<<' was a mistake for such a general purpose tool.

Possibly.  Has Norman Ramsey documented the reason for that particular
choice anywhere?

> > Or, put another way, is the number of cases where << must be
> > escaped sufficiently high that the inconvenience of doing it
> > offsets the reading advantage of the << >> form?
> 
> I find, personally, @<chunk@> fairly pleasent.  Emacs can be taught
> to highlight such sequences, giving them a more pronounced, or a
> softer appearance, according to ones taste.

Hmm.  Matters of personal preference are where this gets tricky, as I
have the opposite reaction to that syntax :-/.  I don't suppose there
is research anywhere on readability of different syntax constructs to
the human eye?

> I think that the rarity of collision using the `@' based form as
> opposed to `<<' is quite an important property.

Out of curosity, can you think of an example use of << in Spad or Aldor
that would cause cl-web in its current form to make a mistake? 

> > I don't know how you're doing your code, but cl-web will pass by <<
> > except in two cases - one is where << is part of a << >>= structure
> > and the other is inside a chunk when it is part of a << >>
> > structure.  I actually didn't need to escape (even when cl-web was
> > tangling and weaving itself!) except for the case of defining the
> > escape delimiters for the listings package in code, and for that I
> > cheated and used (char-code) to specify what characters to put
> > rather than including the literal character.
> 
> In my version, the detailed (preliminary) rules are:
>    
>    1) An at sign in the first column is `active'.  This is to allow
>       for future extensions.  If the resulting line does not parse
>       according to the following rules, it is an error.

OK.

>    2) An at sign in the first column followed by a space, newline, or
>       EOF, introduce a document chunk.

Does this mean the document must begin with an @ symbol?

>    3) An `@<' sequence anywhere introduces either a code chunk
>       definition or a code chunk reference.  A chunk definition
>       starts on the first coloumn and has the full form
>       @<chunkname@>=, a chunk reference is just @<chunkname@>.
> 
> So, if you need an at sign in the first column position, type `@@',
> if you need the sequence `@<', type `@@<'.

OK.  Does this mean you are working only off of these rules and not
altering your parsing rules inside a chunk body?

> I am also considering reserving at-sign/delimiter sequences in
> general for future use by the tool, in the same spirit as rule 1.
> 
> [...]
> > Oh, OK.  I've been using the chunk structures only for identifying
> > the chunks - for any kind of reference work I would have the weave
> > step generate a LaTeX label and reference that using normal
> > procedures in LaTeX.  How were you planning to use this feature?
> 
> I just expand chunk references into an appropriate hyperlink using
> the hyperref package.  You have clickable links in both code and
> documentation chunks.

OK.  I think I understand what you are doing.  You are deliberately
making chunk references the same in both document and code, and only
treating them differently based on environment in the tangle step?

> Currently, they expand into the chunk name in both text and code as
> "<chunkname>", but it would be nice in the doc chunks to specify some
> arbitrary latex string into which they expand serving as the
> clickable region.  I might experiment with
>  @<chunkname@>[lable=\someTeX{}] or somesuch.

OK.  My design approach would have been to keep references in
documentation chunks in LaTeX and source code, but I'll wait and see
what your approach is.

> The code I am working on fully supports the ability to have active
> escape characters in the latex environment which is used to typeset
> your code, without one needing to even think about it.

Again out of curiosity, can you propose a scenario in the cl-web
context that would require any character escaping?
 
> I personally dont find them too hard to distinguish, but I would like
> a good pamphlet.el mode to highlight them differently. 

Can we get some more opinions on this point?
 
> The idea is to allow different concepts to be associated with the
> sequences.  For example, @[some text@] when appearing in a code chunk
> could escape into raw LaTeX.

Oh, I understand the idea.  It's not a bad one, it's just rather
different from how I had envisioned working.  What is a use case where
you would want to escape into raw LaTeX inside a code chunk?  (As
opposed to the weave step doing it to create references?)

> We could overload a single escape sequence to accomplish that, but
> then readability I think is hindered more.  For example
> 
>     <<chunkname>>[lang=lisp]   vs  <<chunkname>>[latex=true]
> 
> Where the interpretation of "chunkname" is different in the two
> contexts.

Ah, but the idea in that case would be that the source code and latex
were different sides of the "chunkname" crystal.  In other words, the
intent is that the latex and the lisp code in those cases both be
associated with the chunk chunkname.  Or, put another way, a query for
latex associated with the lisp code in chunkname should lead directly
and inevitably to the latex associated with chunkname.

Also, in those cases the syntax itself conveys in english what type of
content is supposed to be in these chunks.  I find that to be an
advantage, particularly in the case where an occasional Axiom author
who is primarily a mathematician is looking to edit a pamphlet file. 
@( and @{ convey no inherent information about what they define, but
<<chunkname>>[lisp] does.

> Sure.  Take the listings package vs. fancyvrb.  They have different
> policies about how to escape into raw latex.  In the listings package
> an active character is used to delimit the expression you want LaTeX
> to see. So you can say the `!' character escapes, and write
> `!\LaTeX\!'.  Compare to the three characters needed with fancyvrb.
> 
> This means that only one character needs to be expanded specially --
> all `!' characters when they appear in code chunks.

Oh, got it.  Not verbatim environments so much, but different options
for src environments.  My approach to the escape issue was to just pick
a longer sequence of characters that was so astronomically unlikely to
appear anywhere that collisions with source code weren't a factor. 
Since the weave step generates them anyway, it doesn't really make too
much difference.  Does fancyvrb insisted on the same three escape
characters and/or only let you use three?
 
> I experimented with both packages while writing the code, and I could
> tell the tool how to transform the running text as appropriate by
> changing a few definitions here and there.  It is quite possible to
> design a general mechanism which would allow the user to configure
> the system concisely to use various environments and escape policies
> (this would go under the section titled `Advanced Usage' in the
> pamphlet).

I never considered wanting to let different LaTeX environments act as
the "container" for the source code, although I guess that's possible. 
 I guess I always thought it would just make more sense to identify the
best features in the various options and incorporate them into a
unified environment, rather than complicate the tools.  The
proliferation of multiple incompatible LaTeX packages for the same jobs
has been somewhat unfortunate - I keep hoping there will be a trend
towards consolidation at some stage.

\start
Date: Sat, 21 Jul 2007 10:26:25 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Pamphlet format discussion
Cc: Gabriel Dos Reis

--- Bill Page wrote:

> Certainly I don't want to spend my time working on this, but I was
> thinking more of people like Norman Ramsey and other people who
> already use noweb. Why not embrace the concept of co-operating with
> other open source projects instead of re-inventing the wheel?

For myself, it's because I am sufficiently motivated to want to be able
to work only within the Lisp environment that re-implementing the
functionality inside Lisp is worth the effort.  That is highly unlikely
to appeal to authors of other tools.

> Perhaps people would be more interested in working on the Axiom
> project if we use their work rather than redoing it.

We are using their work - we're using noweb now, and it DOES work. 
Redoing it doesn't need to interfere with moving forward on other
aspects of the problem.  How has work on Lisp tools hindered any other
efforts?

> > Ideally, once these things are done they will require very little
> > work as long as a working Lisp environment is present, but again
> > it would matter ONLY to the people wanting to use it.  The only
> > point at which it becomes a real issue is if the pamphlets go in
> > a direction that noweb can't follow, and I don't see that
> > happening for a good long while.
> 
> That does not seem consistent with what Tim Daly is writing.

Surely noweb is capable of weaving and tangling using different strings
for delimiters?  Other than the delimiter change, these changes don't
have to be an "all or nothing" proposition - just because running LaTeX
on a raw pamphlet will produce a dvi file doesn't mean that the build
logic CAN still run weave if it wishes to, as long as the pamphlet
structure is well defined.

Of course, those are just my thoughts and I'm not an expert on noweb. 
Nor do I know all the details of what Tim would like to do, so I can't
say with certainty what the impact would be.

\start
Date: Sat, 21 Jul 2007 12:44:23 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Pamphlet format discussion

Steve writes:
> The idea is to allow different concepts to be associated with the
> sequences. For example, @[some test@] when appearing in a code chunk
> could escape into raw latex.

Each of these special syntax options means a learning curve for the
new user. These special syntax modes are only applicable in the
axiom project. We could achieve the same goals using standard latex
syntax.

The same effect could be achieved by making

  \begin{chunk}{C}

automatically escape << sequences,

  \begin{chunk}{latex}

automatically escape \

  \begin{chunk}{spad}

automatically escape [[
etc.

Making this work would take some time but would not be difficult.

Latex also involves a fairly steep learning curve but latex is widely
used in mathematics, mostly due to its typesetting abilities. However,
almost every conference I've been associated with expects (and
sometimes requires) latex. Thus there is a benefit beyond axiom for
learning latex, making the learning effort worthwhile.

Latex already is the standard for axiom documentation so people would
have to have at least a minimal understanding of latex. 

Note that I'm not advocating dropping weave, simply pointing out that
most of what we currently wish to do can easily be achieved using
standard latex and the already-necessary axiom.sty file.

\start
Date: Sat, 21 Jul 2007 10:45:08 -0700 (PDT)
From: Cliff Yapp
To: Cliff Yapp, Stephen Wilson
Subject: Re: Pamphlet files and Axiom

--- Cliff Yapp wrote:
> OK.  My design approach would have been to keep references in
> documentation chunks in LaTeX and source code, but I'll wait and see
> what your approach is.

sorry - meant to say "My design approach would have been to keep
references in documentation different from references in source code,
using only the standard LaTeX reference tools in hyperref to reference chunks."

\start
Date: Sat, 21 Jul 2007 12:48:08 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Pamphlet format discussion

I should also note that the idea of using tangle/weave processing on
standard latex documents using lisp is not new, and not my idea.

Some of the input files in the IBM/NAG versions of Axiom were generated
by scanning the Jenks book and generating the hyperdoc pages. That is
why the Jenks book sources include \spadcommand{}.

This work was originally done by Bob Sutor.
He also authored the NAG TeXExplorer user interface.

I'm trying to recover these ideas and extend them.

\start
Date: 21 Jul 2007 13:57:03 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: Re: Pamphlet files and Axiom

Cliff Yapp writes:

> --- Stephen Wilson wrote:
> 
> > It appears quite often in Aldor, where it is an operator.  There is
> > no reason to expect that it will not become one in Spad too.
> 
> But do the sequences << followed by >> occur on the same line in source
> code often?  That is the only possibility that would require an escape.

Yes.  Particularly in C and C++ where these sequences are used for
logical shifts.

I considered the `full form' parsing rule, requiring that both paired
delimiters are required to activate the sequence.  But I rejected it
because it was not very consistent.  I prefer simple rules which would
treat both this line containing the << and >> pair as being active,
as opposed to this line with just one <<.

Its easier the type without needing to think about what is active and
what is not.

[...]
> > I think that the rarity of collision using the `@' based form as
> > opposed to `<<' is quite an important property.
> 
> Out of curosity, can you think of an example use of << in Spad or Aldor
> that would cause cl-web in its current form to make a mistake? 

I havent tried to break cl-web in this case.  If you want me to I can
give it a go :)

> Does this mean the document must begin with an @ symbol?

No.  In my code the `mode' is a documentation chunk at the start.
However, if you do not start your document with an @ sign, then the
first chunk is interpreted as a prelude, which is to contain latex
commands to appear before \begin{document} is (automatically)
inserted.

> > So, if you need an at sign in the first column position, type `@@',
> > if you need the sequence `@<', type `@@<'.
> 
> OK.  Does this mean you are working only off of these rules and not
> altering your parsing rules inside a chunk body?

Im not sure I understand your question.  Could you elaborate?

[...]
> OK.  I think I understand what you are doing.  You are deliberately
> making chunk references the same in both document and code, and only
> treating them differently based on environment in the tangle step?

Correct.


> > Currently, they expand into the chunk name in both text and code as
> > "<chunkname>", but it would be nice in the doc chunks to specify some
> > arbitrary latex string into which they expand serving as the
> > clickable region.  I might experiment with
> >  @<chunkname@>[lable=\someTeX{}] or somesuch.
> 
> OK.  My design approach would have been to keep references in
> documentation chunks in LaTeX and source code, but I'll wait and see
> what your approach is.

I considered that but the weave stage generates the label references
automatically for you, so unless you have a sixth sense about such
things, you cannot predict what the tag might be.

Note that one of the main reasons of automatically defining the labels
is to enable chunk names to contain LaTeX, which cannot be used as the
label used to target the hyperlinks.   I like being able to say:

   @<The \texttt{WEAVE} command@>= ....

> > The code I am working on fully supports the ability to have active
> > escape characters in the latex environment which is used to typeset
> > your code, without one needing to even think about it.
> 
> Again out of curiosity, can you propose a scenario in the cl-web
> context that would require any character escaping?

Sure, give the following code a try:

  <<chunk>>=
    (defun hello-world () (format t "Hello World!")
  @

You wont get the `!' typeset, as its active.  Try replacing the string
with "!\LaTeX!" and see what happens.

[...]
> > The idea is to allow different concepts to be associated with the
> > sequences.  For example, @[some text@] when appearing in a code chunk
> > could escape into raw LaTeX.
> 
> Oh, I understand the idea.  It's not a bad one, it's just rather
> different from how I had envisioned working.  What is a use case where
> you would want to escape into raw LaTeX inside a code chunk?  (As
> opposed to the weave step doing it to create references?)

Hey, you already have that feature in cl-web :)

Seriously though, I would use the feature to typeset comments without
needing to teach the tool what characters introduce comments and have
it do the escape to latex for me.


> > We could overload a single escape sequence to accomplish that, but
> > then readability I think is hindered more.  For example
> > 
> >     <<chunkname>>[lang=lisp]   vs  <<chunkname>>[latex=true]
> > 
> > Where the interpretation of "chunkname" is different in the two
> > contexts.
> 
> Ah, but the idea in that case would be that the source code and latex
> were different sides of the "chunkname" crystal.  In other words, the
> intent is that the latex and the lisp code in those cases both be
> associated with the chunk chunkname.  Or, put another way, a query for
> latex associated with the lisp code in chunkname should lead directly
> and inevitably to the latex associated with chunkname.

I dont follow.  I meant that <<chunkname>>[latex=true] would be an
escape to latex.  Note the ambiguity.  I used the string "chunkname"
to indicate that in the two contexts it has a different
interpretation, not quite what you would expect.

> Also, in those cases the syntax itself conveys in english what type of
> content is supposed to be in these chunks.  I find that to be an
> advantage, particularly in the case where an occasional Axiom author
> who is primarily a mathematician is looking to edit a pamphlet file. 
> @( and @{ convey no inherent information about what they define, but
> <<chunkname>>[lisp] does.

Well, I have played with @( to be an mechanism to escape into lisp.
So if I write:

             "@((format t "HI!~%")@) 

Then when tangle or weave is called, and the form exists in a chunk
they process, the programs will print "HI!".

But thats just a fun thing.  It would take a lot of thought as to how
one can make it useful (but there are certainly a lot of
possibilities there).


> > Sure.  Take the listings package vs. fancyvrb.  They have different
> > policies about how to escape into raw latex.  In the listings package
> > an active character is used to delimit the expression you want LaTeX
> > to see. So you can say the `!' character escapes, and write
> > `!\LaTeX\!'.  Compare to the three characters needed with fancyvrb.
> > 
> > This means that only one character needs to be expanded specially --
> > all `!' characters when they appear in code chunks.
> 
> Oh, got it.  Not verbatim environments so much, but different options
> for src environments.  My approach to the escape issue was to just pick
> a longer sequence of characters that was so astronomically unlikely to
> appear anywhere that collisions with source code weren't a factor. 
> Since the weave step generates them anyway, it doesn't really make too
> much difference.  Does fancyvrb insisted on the same three escape
> characters and/or only let you use three?

Im not sure.  I know you can pick any three characters, but I have not
read about an option to define an outfix style delimitation.

[...]
> I never considered wanting to let different LaTeX environments act as
> the "container" for the source code, although I guess that's possible. 
>  I guess I always thought it would just make more sense to identify the
> best features in the various options and incorporate them into a
> unified environment, rather than complicate the tools.  The
> proliferation of multiple incompatible LaTeX packages for the same jobs
> has been somewhat unfortunate - I keep hoping there will be a trend
> towards consolidation at some stage.

I always prefer `sensible defaults' with the power to override,
customize, and extend.  If the tool does not allow me to do that (like
noweb), I tend to seek out better ones or write them myself.

\start
Date: 21 Jul 2007 14:07:59 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Pamphlet format discussion

Tim Daly writes:
> The same effect could be achieved by making
> 
>   \begin{chunk}{C}
> 
> automatically escape << sequences,
> 
>   \begin{chunk}{latex}
> 
> automatically escape \
> 
>   \begin{chunk}{spad}
> 
> automatically escape [[
> etc.
> 
> Making this work would take some time but would not be difficult.

I dont understand.  What are the active characters in a begin{chunk}
environment?  Why do you need to escape `[[', for example?


> Latex also involves a fairly steep learning curve but latex is widely
> used in mathematics, mostly due to its typesetting abilities. However,
> almost every conference I've been associated with expects (and
> sometimes requires) latex. Thus there is a benefit beyond axiom for
> learning latex, making the learning effort worthwhile.

Most literate documents are mainly latex.  The learning curve is still
there if you want to climb it.

We can always weave our pamphlets for submission to conference
proceedings.


> Latex already is the standard for axiom documentation so people would
> have to have at least a minimal understanding of latex. 

I agree.

> Note that I'm not advocating dropping weave, simply pointing out that
> most of what we currently wish to do can easily be achieved using
> standard latex and the already-necessary axiom.sty file.

I agree that latex can handle the job of typesetting documents.

As you know, I have my reasons to think that something which must be
woven into latex is not itself latex.

Latex is fully capable of tangling the chunks too.  But I would
argue against doing that for similar reasons.

\start
Date: Sat, 21 Jul 2007 13:35:11 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Pamphlet format discussion

> I don't understand. What are the active characters in a begin{chunk}
> environment. Why do you need to escape `[[', for example?

Normally you would not. I'm suggesting that it is entirely possible
to side-step the escape question for any given set of characters for
any given language in a trivial way. TeX is designed to do that.

\start
Date: Sat, 21 Jul 2007 13:35:30 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Pamphlet format discussion

The current silver version in axiom.sty uses the latex alltt environment.
<http://www.tug.org/texlive/Contents/live/texmf-dist/doc/latex/base/alltt.pdf>
This environment is shipped with standard latex. As I mentioned before we 
could easily choose to use fancyvrb rather that alltt.

The alltt environment is a verbatim-like environment except that the
`\', `{', and `}' have their usual meanings. Thus, other commands and
environments can appear within an alltt environment.

Other systems, like Scientific WorkPlace, use it:
<http://www.mackichan.com/index.html?techtalk/458.htm~mainFrame>

\start
Date: Sat, 21 Jul 2007 13:36:02 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Pamphlet format discussion

Note that section 12.3 of the AUCTeX manual explains how to insert
the chunk environment into AUCTeX. Thus emacs users should be able
to customize chunk environments trivially. In chunk.el you add

(TeX-add-style-hook
 "chunk"
 (lambda ()
  (LaTeX-add-environments
   '("chunk" "chunkname"))))

\start
Date: Sat, 21 Jul 2007 11:52:55 -0700 (PDT)
From: Cliff Yapp
To: Stephen Wilson
Subject: Re: Pamphlet files and Axiom

--- Stephen Wilson wrote:
> > But do the sequences << followed by >> occur on the same line in
> > source code often?  That is the only possibility that would require
> > an escape.
> 
> Yes.  Particularly in C and C++ where these sequences are used for
> logical shifts.

And you think such events would be sufficiently common to merit going
away from them as tags for references?

> I considered the `full form' parsing rule, requiring that both paired
> delimiters are required to activate the sequence.  But I rejected it
> because it was not very consistent.  I prefer simple rules which
> would treat both this line containing the << and >> pair as being
> active, as opposed to this line with just one <<.

Hmm.  I'll have to try out your solution and see how it works.

> > Out of curosity, can you think of an example use of << in Spad or
> > Aldor that would cause cl-web in its current form to make a
mistake? 
> 
> I havent tried to break cl-web in this case.  If you want me to I can
> give it a go :)

Don't worry about it if it would distract you from your tool.  I just
want us to decide on how to write pamphlets so we can start writing
said pamphlets.
 
> > Does this mean the document must begin with an @ symbol?
> 
> No.  In my code the `mode' is a documentation chunk at the start.
> However, if you do not start your document with an @ sign, then the
> first chunk is interpreted as a prelude, which is to contain latex
> commands to appear before \begin{document} is (automatically)
> inserted.

Hmm. OK.

> > OK.  Does this mean you are working only off of these rules and not
> > altering your parsing rules inside a chunk body?
> 
> Im not sure I understand your question.  Could you elaborate?

In cl-web, the only time the << >> combination has significance to the
scanner is inside a code chunk.  In documentation, it has no unusual
significant at all.

> > OK.  I think I understand what you are doing.  You are deliberately
> > making chunk references the same in both document and code, and
> > only treating them differently based on environment in the tangle
> > step?
> 
> Correct.

I'm curious when you plan to refer to code chunks in documentation. 
Thus far most of the references I've made are from chunk to chunk. 

> I considered that but the weave stage generates the label references
> automatically for you, so unless you have a sixth sense about such
> things, you cannot predict what the tag might be.

I just used the chunk name as the label name in LaTeX, so a
\ref{chunkname} would work every time.
 
> Note that one of the main reasons of automatically defining the
> labels is to enable chunk names to contain LaTeX, which cannot
> be used as the label used to target the hyperlinks.   I like being
> able to say:
> 
>    @<The \texttt{WEAVE} command@>= ....

Erm.  That didn't occur to me.  I always viewed simple non-LaTeX chunk
names as sufficient.
 
> > Again out of curiosity, can you propose a scenario in the cl-web
> > context that would require any character escaping?
> 
> Sure, give the following code a try:
> 
>   <<chunk>>=
>     (defun hello-world () (format t "Hello World!")
>   @
> 
> You wont get the `!' typeset, as its active.  Try replacing the
> string with "!\LaTeX!" and see what happens.

In cl-web, they both come out literally as they went in.  Isn't that
desired behavior?

\index{chunk}
\begin{lstlisting}[caption={chunk}, label=chunk, escapeinside={(s*t@ }{
@e*t)}]
    (defun hello-world () (format t ""!\LaTeX!"")
\end{lstlisting}


\index{chunk}
\begin{lstlisting}[caption={chunk}, label=chunk, escapeinside={(s*t@ }{
@e*t)}]
    (defun hello-world () (format t "Hello World!")
\end{lstlisting}

> Hey, you already have that feature in cl-web :)

Only as an automatic part of the weave process itself.  
 
> Seriously though, I would use the feature to typeset comments without
> needing to teach the tool what characters introduce comments and have
> it do the escape to latex for me.

So you want LaTeX typset comments inside the source code chunks? 
 
> I dont follow.  I meant that <<chunkname>>[latex=true] would be an
> escape to latex.

Oh, we're on different pages.  I ment
<<chunkname>>[lisp]=
lisp code
@

<<chunkname>>[latex]
latex documentation
@

With the idea that Axiom could ask for the LaTeX documentation
associated with chunkname.

> Note the ambiguity.  I used the string "chunkname"
> to indicate that in the two contexts it has a different
> interpretation, not quite what you would expect.

I may be missing something.  From my standpoint, the user will never
expect to have anything inside a source chunk typeset except what the
weave command itself automatically generates by redoing weave
references.  The author escaping to LaTeX themselves is a non-issue -
it would never be done.

> Well, I have played with @( to be an mechanism to escape into lisp.
> So if I write:
> 
>              "@((format t "HI!~%")@) 
> 
> Then when tangle or weave is called, and the form exists in a chunk
> they process, the programs will print "HI!".

OK, I think you are using escapes differently from how I'm thinking
about them.  I'd better wait for your code - I seem to be stuck in a
more narrow view of how I want pamphlets to work.
 
\start
Date: 21 Jul 2007 15:02:48 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Pamphlet format discussion

Tim Daly writes:

> The alltt environment is a verbatim-like environment except that the
> `\', `{', and `}' have their usual meanings. Thus, other commands and
> environments can appear within an alltt environment.

Right, so if I want to write code which contains a `\', say, and have
latex typeset it properly, I need to write $\backslash$ in my code.
Similarly \{ and \} for { and }.

You will need to standardize on one set of escapes and one alone,
otherwise tangle will have a very tough job of converting the latex
back into the equivalent code. 

Having arbitrary latex appear in source code is tough to manage for a
tangle tool regardless, as it needs to decide what pieces to include
and what to ignore.

\start
Date: 21 Jul 2007 15:29:58 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: Re: Pamphlet files and Axiom

Cliff Yapp writes:

> --- Stephen Wilson wrote:
> > > But do the sequences << followed by >> occur on the same line in
> > > source code often?  That is the only possibility that would require
> > > an escape.
> > 
> > Yes.  Particularly in C and C++ where these sequences are used for
> > logical shifts.
> 
> And you think such events would be sufficiently common to merit going
> away from them as tags for references?

Absolutely.  If I design a piece of software I consider its
`philosophy', the why of its approach to the problem.

I want a tool which can be tailored to axioms needs.  But at the same
time, I do not want to say that you can only write spad, boot, and
lisp code with this tool.

C and C++ are sufficiently popular for them to be considered when
writing a program which manipulates source code.

[...]
> > I havent tried to break cl-web in this case.  If you want me to I can
> > give it a go :)
> 
> Don't worry about it if it would distract you from your tool.  I just
> want us to decide on how to write pamphlets so we can start writing
> said pamphlets.

Me too. Absolutely.

[...]
> > > OK.  Does this mean you are working only off of these rules and not
> > > altering your parsing rules inside a chunk body?
> > 
> > Im not sure I understand your question.  Could you elaborate?
> 
> In cl-web, the only time the << >> combination has significance to the
> scanner is inside a code chunk.  In documentation, it has no unusual
> significant at all.

OK.  My tool gives significance to @< currently in documentation,
which introduces a chunk reference.


> > > OK.  I think I understand what you are doing.  You are deliberately
> > > making chunk references the same in both document and code, and
> > > only treating them differently based on environment in the tangle
> > > step?
> > 
> > Correct.
> 
> I'm curious when you plan to refer to code chunks in documentation. 
> Thus far most of the references I've made are from chunk to chunk. 

Really?  I always cite other code when describing a function which
supports or uses it.

[...]
> > Note that one of the main reasons of automatically defining the
> > labels is to enable chunk names to contain LaTeX, which cannot
> > be used as the label used to target the hyperlinks.   I like being
> > able to say:
> > 
> >    @<The \texttt{WEAVE} command@>= ....
> 
> Erm.  That didn't occur to me.  I always viewed simple non-LaTeX chunk
> names as sufficient.

For me it is not sufficient.


> > > Again out of curiosity, can you propose a scenario in the cl-web
> > > context that would require any character escaping?
> > 
> > Sure, give the following code a try:
> > 
> >   <<chunk>>=
> >     (defun hello-world () (format t "Hello World!")
> >   @
> > 
> > You wont get the `!' typeset, as its active.  Try replacing the
> > string with "!\LaTeX!" and see what happens.
> 
> In cl-web, they both come out literally as they went in.  Isn't that
> desired behavior?

latex the file and look at the dvi.

[...]
> > Seriously though, I would use the feature to typeset comments without
> > needing to teach the tool what characters introduce comments and have
> > it do the escape to latex for me.
> 
> So you want LaTeX typset comments inside the source code chunks? 

Sure, why not?  Sometimes the explanation of an algorithm falls
naturally in that context.  We could number each line in a source code
context automatically, but I dont like that approach exclusively.  Its
a pain to always say "at line 34 we ....".  Its also a drag to have to
ensure that line 34 isnt typeset as line 33 or somesuch.  Little
creeping errors like that bug me, and I can avoid them completely by
placing simple explanations in comments (and I would like to have
TeXs math available to make the comments even more concise).

[...]
> I may be missing something.  From my standpoint, the user will never
> expect to have anything inside a source chunk typeset except what the
> weave command itself automatically generates by redoing weave
> references.  The author escaping to LaTeX themselves is a non-issue -
> it would never be done.

I will do it.  Just because you wont doesnt mean its not possible or
desirable.  We need tools which are accommodating to needs different
to our own.

\start
Date: Sat, 21 Jul 2007 13:07:41 -0700 (PDT)
From: Cliff Yapp
To: Stephen Wilson
Subject: Re: Pamphlet files and Axiom

--- Stephen Wilson wrote:

> Cliff Yapp writes:
> > And you think such events would be sufficiently common to merit
> > going away from them as tags for references?
> 
> Absolutely.  If I design a piece of software I consider its
> `philosophy', the why of its approach to the problem.

OK.  I was thinking solely about the Axiom codebase, but that is
probably too narrow a scope.

> I want a tool which can be tailored to axioms needs.  But at the same
> time, I do not want to say that you can only write spad, boot, and
> lisp code with this tool.

Fair enough.

> C and C++ are sufficiently popular for them to be considered when
> writing a program which manipulates source code.

Especially since we are likely to be using libraries written in those
languages for some time...

> OK.  My tool gives significance to @< currently in documentation,
> which introduces a chunk reference.

OK.

> > I'm curious when you plan to refer to code chunks in documentation.
> > Thus far most of the references I've made are from chunk to chunk. 
> 
> Really?  I always cite other code when describing a function which
> supports or uses it.

Hmm.  OK.  I look forward to seeing your new example - it should be
quite educational!
 
> > >    @<The \texttt{WEAVE} command@>= ....
> > 
> > Erm.  That didn't occur to me.  I always viewed simple non-LaTeX
> > chunk names as sufficient.
> 
> For me it is not sufficient.

I guess I can see that.  In a collection chunk, would you then do:

@<collectingterms@>=
   @<The \texttt{TANGLE} command@>
   @<The \texttt{WEAVE} command@>
etc...
@

That would be very interesting.
 
> > In cl-web, they both come out literally as they went in.  Isn't
> > that desired behavior?
> 
> latex the file and look at the dvi.

I did.  Maybe I have something set up oddly here.  Oh, well - no
matter.
 

> > So you want LaTeX typset comments inside the source code chunks? 
> 
> Sure, why not?  Sometimes the explanation of an algorithm falls
> naturally in that context.  We could number each line in a source
> code context automatically, but I dont like that approach
> exclusively. 

So, we could (for example) have the latex mode use the tangle line
information to append each line with its line number per the tangled
file output?  That would be sweet...

> Its a pain to always say "at line 34 we ....".  Its also a drag to
> have to ensure that line 34 isnt typeset as line 33 or somesuch. 
> Little creeping errors like that bug me, and I can avoid them
> completely by placing simple explanations in comments (and I would
> like to have TeXs math available to make the comments even more
> concise).

How would such comments be tangled?
 

> I will do it.  Just because you wont doesnt mean its not possible or
> desirable.

Of course.  My concern was that the complexity of learning how to write
pamphlets will be increased by using a tool that is so general,
resulting in driving away authors.  However, that's probably wrong upon
reflection - it's not any harder than anything else needed for Axiom.

> We need tools which are accommodating to needs different
> to our own.

That actually brings up a point - how much of a uniform writing style
policy do we want to enforce in Axiom?

Cheers, and thanks for all your hard work on this!

\start
Date: 21 Jul 2007 16:34:43 -0400
From: Stephen Wilson
To: Cliff Yapp
Subject: Re: Pamphlet files and Axiom

Cliff Yapp writes:
[...]
> > > >    @<The \texttt{WEAVE} command@>= ....
> > > 
> > > Erm.  That didn't occur to me.  I always viewed simple non-LaTeX
> > > chunk names as sufficient.
> > 
> > For me it is not sufficient.
> 
> I guess I can see that.  In a collection chunk, would you then do:
> 
> @<collectingterms@>=
>    @<The \texttt{TANGLE} command@>
>    @<The \texttt{WEAVE} command@>
> etc...
> @
> 
> That would be very interesting.

Yep, that is currently possible.  I need to figure out the best way to
typeset them.  Currently the references pull in the font in effect in
the verbatim environment.  I need to define the fonts used explicitly
in the latex support header.

> > > In cl-web, they both come out literally as they went in.  Isn't
> > > that desired behavior?
> > 
> > latex the file and look at the dvi.
> 
> I did.  Maybe I have something set up oddly here.  Oh, well - no
> matter.

Ya, its a small change. I should have chosen a more obvious example.

The exclamation point on its own dissapears. So "Hello World!" gets
typeset as "Hello World".  If you have the `!' characters paired, you
get latex interpreting the contents actively.  So "!\LaTeX!" gets
typeset as the familiar glyph.  This could run havoc on code chunks
containing exclaimation points.

> 
> > > So you want LaTeX typset comments inside the source code chunks? 
> > 
> > Sure, why not?  Sometimes the explanation of an algorithm falls
> > naturally in that context.  We could number each line in a source
> > code context automatically, but I dont like that approach
> > exclusively. 
> 
> So, we could (for example) have the latex mode use the tangle line
> information to append each line with its line number per the tangled
> file output?  That would be sweet...

Humm, I never though of that!  I was just thinking about using the
automatic counters which packages like fancyvrb provide.  But humm,
line numbers corresponding to the tangled source sounds interesting.
Will have to think about that a bit more.  Thanks!


> > Its a pain to always say "at line 34 we ....".  Its also a drag to
> > have to ensure that line 34 isnt typeset as line 33 or somesuch. 
> > Little creeping errors like that bug me, and I can avoid them
> > completely by placing simple explanations in comments (and I would
> > like to have TeXs math available to make the comments even more
> > concise).
> 
> How would such comments be tangled?

You could just output them as you would any other textual item in the
listing -- character for character. They will be hidden by the comment
marker in the language you are programming in.


> > I will do it.  Just because you wont doesnt mean its not possible or
> > desirable.
> 
> Of course.  My concern was that the complexity of learning how to write
> pamphlets will be increased by using a tool that is so general,
> resulting in driving away authors.  However, that's probably wrong upon
> reflection - it's not any harder than anything else needed for Axiom.

Right.  But also note that noone needs to know about any other
features -- so long as the tool does not require them to be known in
order to be used.  I think what I have been working on is no more
complex than noweb in order to get the same effect as that tool.


> > We need tools which are accommodating to needs different
> > to our own.
> 
> That actually brings up a point - how much of a uniform writing style
> policy do we want to enforce in Axiom?

I am going to start writing right to left.  As long as the policy does
not enforce a rule which says I cant, Ill be OK with that. :)

\start
Date: Sat, 21 Jul 2007 15:38:37 -0500
From: Tim Daly
To: list
Subject: diff-Naur 20070721.02.tpd.patch

This patch, originally written by Waldek, declares variables to 
be special. This reduces the number of warnings.

You can apply this patch to your tree by
  cd your-axiom-root
  patch -p1 <20070721.02.tpd.patch

Note that if you have not applied patch 20070721.01.tpd.patch
you will get a .rej file due to `changelog'. This can be safely
ignored.

Tim

diff --git a/changelog b/changelog
index 0c9e91d..7091ec9 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,4 @@
+20070721 wxh src/interp/spad.lisp make evalSharpOne declare arg specials
 20070721 tpd src/interp/setq.lisp update contributor name list
 20070721 tpd readme update contributor name list
 20070716 tpd src/doc/axiom.bib move developernotes to bookvol4
diff --git a/src/interp/spad.lisp.pamphlet b/src/interp/spad.lisp.pamphlet
index c6e7542..c39b435 100644
--- a/src/interp/spad.lisp.pamphlet
+++ b/src/interp/spad.lisp.pamphlet
@@ -450,7 +450,14 @@
 	 (if |$InteractiveMode| (|spadThrow|))
 	 (S-PROCESS x))))
 
-(defun |evalSharpOne| (x \#1) (declare (special \#1)) (EVAL x))
+
+@
+The evalSharpOne function needs to declare the second argument
+special to reduce warning messages about variables being assumed
+special.
+<<*>>=
+(defun |evalSharpOne| (x |#1|) (declare (special |#1|))
+ (EVAL `(let() (declare (special |#1|)) ,x)))
 
 (defun new () (|New,ENTRY|))
 
\start
Date: Sun, 22 Jul 2007 12:41:31 +0200 (CEST)
From: Franz Lehner
To: Bill Page
Subject: Re: MonoidWithZero

>
> I think the short answer is "no". But if you do re-write it, I can see
> no reason why this should not be written as a normal category
> definition and used in MonoidRing instead of the local macro
> definition.
well I tried. Are there instructions for the clueless like me?
Simply modifying mring.spad.pamphlet apparently is not enough
(see attached diff).
The category definition is not exported into 
MRING.spad. Is there some index where it has to appear also in order
to be compiled?

> On the other hand perhaps the category "AbelianMonoidRing" in
> 'src/algebra/polycat.spad.pamphlet' is what you need?
no, my monoids are usually nonabelian, even the commutative ones,
because I prefer "*" notation.

regards,
Franz
--461446550-599641714-1185100891=:4551

LS0tIG1yaW5nLnNwYWQucGFtcGhsZXQub3JpZwkyMDA3LTA2LTAxIDA5OjI2
OjM2LjAwMDAwMDAwMCArMDIwMA0KKysrIG1yaW5nLnNwYWQucGFtcGhsZXQJ
MjAwNy0wNy0yMiAxMjoxNDoyNi4wMDAwMDAwMDAgKzAyMDANCkBAIC05LDEy
ICs5LDEyIEBADQogXGVqZWN0DQogXHRhYmxlb2Zjb250ZW50cw0KIFxlamVj
dA0KLVxzZWN0aW9ue2RvbWFpbiBNUklORyBNb25vaWRSaW5nfQ0KLTw8ZG9t
YWluIE1SSU5HIE1vbm9pZFJpbmc+Pj0NCi0pYWJicmV2IGRvbWFpbiBNUklO
RyBNb25vaWRSaW5nDQorXHNlY3Rpb257Y2F0ZWdvcnkgTVJDQVQgTW9ub2lk
UmluZ0NhdGVnb3J5fQ0KKzw8Y2F0ZWdvcnkgTVJDQVQgTW9ub2lkUmluZ0Nh
dGVnb3J5Pj49DQorKWFiYnJldiBjYXRlZ29yeSBNUkNBVCBNb25vaWRSaW5n
Q2F0ZWdvcnkNCiArKyBBdXRob3JzOiBTdGVwaGFuIE0uIFdhdHQ7IHJldmlz
ZWQgYnkgSm9oYW5uZXMgR3JhYm1laWVyDQogKysgRGF0ZSBDcmVhdGVkOiBK
YW51YXJ5IDE5ODYNCi0rKyBEYXRlIExhc3QgVXBkYXRlZDogMTQgRGVjZW1i
ZXIgMTk5NSwgTWlrZSBEZXdhcg0KKysrIERhdGUgTGFzdCBVcGRhdGVkOiAy
MiBKdWx5IDIwMDcsIEZyYW56IExlaG5lcg0KICsrIEJhc2ljIE9wZXJhdGlv
bnM6ICosICssIG1vbm9taWFscywgY29lZmZpY2llbnRzDQogKysgUmVsYXRl
ZCBDb25zdHJ1Y3RvcnM6IFBvbHlub21pYWwNCiArKyBBbHNvIFNlZToNCkBA
IC0yMywyNiArMjMsMTMgQEANCiArKyAgaW5kZXRlcm1pbmF0ZXMNCiArKyBS
ZWZlcmVuY2VzOg0KICsrIERlc2NyaXB0aW9uOg0KLSsrICBcc3BhZHR5cGV7
TW9ub2lkUmluZ30oUixNKSwgaW1wbGVtZW50cyB0aGUgYWxnZWJyYQ0KKysr
ICBcc3BhZHR5cGV7TW9ub2lkUmluZ0NhdGVnb3J5fShSLE0pIGRlZmluZXMg
dGhlIGFsZ2VicmENCiArKyAgb2YgYWxsIG1hcHMgZnJvbSB0aGUgbW9ub2lk
IE0gdG8gdGhlIGNvbW11dGF0aXZlIHJpbmcgUiB3aXRoDQogKysgIGZpbml0
ZSBzdXBwb3J0Lg0KLSsrICBNdWx0aXBsaWNhdGlvbiBvZiB0d28gbWFwcyBm
IGFuZCBnIGlzIGRlZmluZWQNCi0rKyAgdG8gbWFwIGFuIGVsZW1lbnQgYyBv
ZiBNIHRvIHRoZSAoY29udm9sdXRpb24pIHN1bSBvdmVyIHtcZW0gZihhKWco
Yil9DQotKysgIHN1Y2ggdGhhdCB7XGVtIGFiID0gY30uIFRodXMgTSBjYW4g
YmUgaWRlbnRpZmllZCB3aXRoIGEgY2Fub25pY2FsDQotKysgIGJhc2lzIGFu
ZCB0aGUgbWFwcyBjYW4gYWxzbyBiZSBjb25zaWRlcmVkIGFzIGZvcm1hbCBs
aW5lYXIgY29tYmluYXRpb25zDQotKysgIG9mIHRoZSBlbGVtZW50cyBpbiBN
LiBTY2FsYXIgbXVsdGlwbGVzIG9mIGEgYmFzaXMgZWxlbWVudCBhcmUgY2Fs
bGVkDQotKysgIG1vbm9taWFscy4gQSBwcm9taW5lbnQgZXhhbXBsZSBpcyB0
aGUgY2xhc3Mgb2YgcG9seW5vbWlhbHMNCi0rKyAgd2hlcmUgdGhlIG1vbm9p
ZCBpcyBhIGRpcmVjdCBwcm9kdWN0IG9mIHRoZSBuYXR1cmFsIG51bWJlcnMN
Ci0rKyAgd2l0aCBwb2ludHdpc2UgYWRkaXRpb24uIFdoZW4gTSBpcw0KLSsr
ICBcc3BhZHR5cGV7RnJlZU1vbm9pZCBTeW1ib2x9LCBvbmUgZ2V0cyBwb2x5
bm9taWFscw0KLSsrICBpbiBpbmZpbml0ZWx5IG1hbnkgbm9uLWNvbW11dGlu
ZyB2YXJpYWJsZXMuIEFub3RoZXIgYXBwbGljYXRpb24NCi0rKyAgYXJlYSBp
cyByZXByZXNlbnRhdGlvbiB0aGVvcnkgb2YgZmluaXRlIGdyb3VwcyBHLCB3
aGVyZSBtb2R1bGVzDQotKysgIG92ZXIgXHNwYWR0eXBle01vbm9pZFJpbmd9
KFIsRykgYXJlIHN0dWRpZWQuDQotDQotTW9ub2lkUmluZyhSOiBSaW5nLCBN
OiBNb25vaWQpOiBNUmNhdGVnb3J5ID09IE1SZGVmaW5pdGlvbiB3aGVyZQ0K
K01vbm9pZFJpbmdDYXRlZ29yeShSOiBSaW5nLCBNOiBNb25vaWQpOkNhdGVn
b3J5ID09IE1SQ2RlZmluaXRpb24gd2hlcmUNCiAgICAgVGVybSA9PT4gUmVj
b3JkKGNvZWY6IFIsIG1vbm9tOiBNKQ0KIA0KLSAgICBNUmNhdGVnb3J5ID09
PiBKb2luKFJpbmcsIFJldHJhY3RhYmxlVG8gTSwgUmV0cmFjdGFibGVUbyBS
KSB3aXRoDQorICAgIE1SQ2RlZmluaXRpb24gPT0gSm9pbihSaW5nLCBSZXRy
YWN0YWJsZVRvIE0sIFJldHJhY3RhYmxlVG8gUikgd2l0aA0KICAgICAgICAg
bW9ub21pYWwgICAgICAgICA6IChSLCBNKSAtPiAlDQogICAgICAgICAgICsr
IG1vbm9taWFsKHIsbSkgY3JlYXRlcyBhIHNjYWxhciBtdWx0aXBsZSBvZiB0
aGUgYmFzaXMgZWxlbWVudCBtLg0KICAgICAgICAgY29lZmZpY2llbnQgOiAo
JSwgTSkgLT4gUg0KQEAgLTgyLDYgKzY5LDM4IEBADQogICAgICAgICAgICAg
KysgYW1vbmcgYWxsIHRob3NlIHdpdGggbm9uLXplcm8gY29lZmZpY2llbnRz
Lg0KICAgICAgICAgICByZWR1Y3R1bSAgICAgICAgICA6ICUgLT4gJQ0KICAg
ICAgICAgICAgICsrIHJlZHVjdHVtKGYpIGlzIGYgbWludXMgaXRzIGxlYWRp
bmcgbW9ub21pYWwuDQorQA0KK1xzZWN0aW9ue2RvbWFpbiBNUklORyBNb25v
aWRSaW5nfQ0KKzw8ZG9tYWluIE1SSU5HIE1vbm9pZFJpbmc+Pj0NCispYWJi
cmV2IGRvbWFpbiBNUklORyBNb25vaWRSaW5nDQorKysgQXV0aG9yczogU3Rl
cGhhbiBNLiBXYXR0OyByZXZpc2VkIGJ5IEpvaGFubmVzIEdyYWJtZWllcg0K
KysrIERhdGUgQ3JlYXRlZDogSmFudWFyeSAxOTg2DQorKysgRGF0ZSBMYXN0
IFVwZGF0ZWQ6IDE0IERlY2VtYmVyIDE5OTUsIE1pa2UgRGV3YXINCisrKyBC
YXNpYyBPcGVyYXRpb25zOiAqLCArLCBtb25vbWlhbHMsIGNvZWZmaWNpZW50
cw0KKysrIFJlbGF0ZWQgQ29uc3RydWN0b3JzOiBQb2x5bm9taWFsDQorKysg
QWxzbyBTZWU6DQorKysgQU1TIENsYXNzaWZpY2F0aW9uczoNCisrKyBLZXl3
b3JkczogbW9ub2lkIHJpbmcsIGdyb3VwIHJpbmcsIHBvbHlub21pYWxzIGlu
IG5vbi1jb21tdXRpbmcNCisrKyAgaW5kZXRlcm1pbmF0ZXMNCisrKyBSZWZl
cmVuY2VzOg0KKysrIERlc2NyaXB0aW9uOg0KKysrICBcc3BhZHR5cGV7TW9u
b2lkUmluZ30oUixNKSwgaW1wbGVtZW50cyB0aGUgYWxnZWJyYQ0KKysrICBv
ZiBhbGwgbWFwcyBmcm9tIHRoZSBtb25vaWQgTSB0byB0aGUgY29tbXV0YXRp
dmUgcmluZyBSIHdpdGgNCisrKyAgZmluaXRlIHN1cHBvcnQuDQorKysgIE11
bHRpcGxpY2F0aW9uIG9mIHR3byBtYXBzIGYgYW5kIGcgaXMgZGVmaW5lZA0K
KysrICB0byBtYXAgYW4gZWxlbWVudCBjIG9mIE0gdG8gdGhlIChjb252b2x1
dGlvbikgc3VtIG92ZXIge1xlbSBmKGEpZyhiKX0NCisrKyAgc3VjaCB0aGF0
IHtcZW0gYWIgPSBjfS4gVGh1cyBNIGNhbiBiZSBpZGVudGlmaWVkIHdpdGgg
YSBjYW5vbmljYWwNCisrKyAgYmFzaXMgYW5kIHRoZSBtYXBzIGNhbiBhbHNv
IGJlIGNvbnNpZGVyZWQgYXMgZm9ybWFsIGxpbmVhciBjb21iaW5hdGlvbnMN
CisrKyAgb2YgdGhlIGVsZW1lbnRzIGluIE0uIFNjYWxhciBtdWx0aXBsZXMg
b2YgYSBiYXNpcyBlbGVtZW50IGFyZSBjYWxsZWQNCisrKyAgbW9ub21pYWxz
LiBBIHByb21pbmVudCBleGFtcGxlIGlzIHRoZSBjbGFzcyBvZiBwb2x5bm9t
aWFscw0KKysrICB3aGVyZSB0aGUgbW9ub2lkIGlzIGEgZGlyZWN0IHByb2R1
Y3Qgb2YgdGhlIG5hdHVyYWwgbnVtYmVycw0KKysrICB3aXRoIHBvaW50d2lz
ZSBhZGRpdGlvbi4gV2hlbiBNIGlzDQorKysgIFxzcGFkdHlwZXtGcmVlTW9u
b2lkIFN5bWJvbH0sIG9uZSBnZXRzIHBvbHlub21pYWxzDQorKysgIGluIGlu
ZmluaXRlbHkgbWFueSBub24tY29tbXV0aW5nIHZhcmlhYmxlcy4gQW5vdGhl
ciBhcHBsaWNhdGlvbg0KKysrICBhcmVhIGlzIHJlcHJlc2VudGF0aW9uIHRo
ZW9yeSBvZiBmaW5pdGUgZ3JvdXBzIEcsIHdoZXJlIG1vZHVsZXMNCisrKyAg
b3ZlciBcc3BhZHR5cGV7TW9ub2lkUmluZ30oUixHKSBhcmUgc3R1ZGllZC4N
CitNb25vaWRSaW5nKFI6IFJpbmcsIE06IE1vbm9pZCk6IE1vbm9pZFJpbmdD
YXRlZ29yeShSLE0pID09IE1SZGVmaW5pdGlvbiB3aGVyZQ0KKyAgICBUZXJt
ID09PiBSZWNvcmQoY29lZjogUiwgbW9ub206IE0pDQogDQogICAgIE1SZGVm
aW5pdGlvbiA9PT4gYWRkDQogICAgICAgICBFeCA9PT4gT3V0cHV0Rm9ybQ0K
QEAgLTM5NSw2ICs0MTQsNyBAQA0KIDw8Kj4+PQ0KIDw8bGljZW5zZT4+DQog
DQorPDxjYXRlZ29yeSBNUkNBVCBNb25vaWRSaW5nQ2F0ZWdvcnk+Pg0KIDw8
ZG9tYWluIE1SSU5HIE1vbm9pZFJpbmc+Pg0KIDw8cGFja2FnZSBNUkYyIE1v
bm9pZFJpbmdGdW5jdGlvbnMyPj4NCiBADQo=

--461446550-599641714-1185100891=:4551--

\start
Date: Sun, 22 Jul 2007 07:53:08 -0500
From: Tim Daly
To: list
Subject: diff-Naur 20070722.01.tpd.patch

This patch cleans up the latex complaints in src/interp/Makefile.pamphlet
during builds.

You can apply this patch to your tree by
  cd your-axiom-root
  patch -p1 <20070722.01.tpd.patch

Note that if you have not applied previous you will get a .rej file
due to `changelog'. This can be safely ignored.

Tim

diff --git a/changelog b/changelog
index 7091ec9..962132e 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,4 @@
+20070722 tpd src/interp/Makefile cleanup latex warnings
 20070721 wxh src/interp/spad.lisp make evalSharpOne declare arg specials
 20070721 tpd src/interp/setq.lisp update contributor name list
 20070721 tpd readme update contributor name list
diff --git a/src/interp/Makefile.pamphlet b/src/interp/Makefile.pamphlet
index 49f9cc4..23ec4cc 100644
--- a/src/interp/Makefile.pamphlet
+++ b/src/interp/Makefile.pamphlet
@@ -545,7 +545,8 @@ in util.lisp that emulates the new boot parser command BOOTTOCL. since
 we eventually plan to move to the new boot parser this function (and
 the push) should disappear.
 
-The load of postpar and parse (without extensions) allows the [[.${LISP}]] 
+The load of postpar and parse (without extensions) allows the 
+\verb+.${LISP}+
 form to be loaded in a virgin system. However, if depsys is recreated then
 the compiled form will get loaded.
 
@@ -2390,9 +2391,9 @@ code. We need to keep the translated code around so we can bootstrap
 the system. In other words, we need this boot code translated so we
 can build the boot translator.
 
-{\bf NOTE: IF YOU CHANGE THE BOOT CODE IN C-UTIL.BOOT.PAMPHLET
-YOU MUST TRANSLATE THIS CODE TO LISP AND STORE THE RESULTING LISP
-CODE BACK INTO THE C-UTIL.BOOT.PAMPHLET FILE. THIS IS NOT AUTOMATED.}
+{\bf note: if you change the boot code in c-util.boot.pamphlet
+you must translate this code to lisp and store the resulting lisp
+code back into the c-util.boot.pamphlet file. this is not automated.}
 <<c-util.lisp (OUT from IN)>>=
 ${OUT}/c-util.${LISP}: ${IN}/c-util.boot.pamphlet
 	@ echo 146 making ${OUT}/c-util.${LISP} from ${IN}/c-util.boot.pamphlet
@@ -3290,9 +3291,9 @@ code. We need to keep the translated code around so we can bootstrap
 the system. In other words, we need this boot code translated so we
 can build the boot translator.
 
-{\bf NOTE: IF YOU CHANGE THE BOOT CODE IN CLAM.BOOT.PAMPHLET
-YOU MUST TRANSLATE THIS CODE TO LISP AND STORE THE RESULTING LISP
-CODE BACK INTO THE CLAM.BOOT.PAMPHLET FILE. THIS IS NOT AUTOMATED.}
+{\bf note: if you change the boot code in clam.boot.pamphlet
+you must translate this code to lisp and store the resulting lisp
+code back into the clam.boot.pamphlet file. this is not automated.}
 <<clam.lisp (OUT from IN)>>=
 ${OUT}/clam.${LISP}: ${IN}/clam.boot.pamphlet
 	@ echo 221 making ${OUT}/clam.${LISP} from ${IN}/clam.boot.pamphlet
@@ -3760,9 +3761,9 @@ code. We need to keep the translated code around so we can bootstrap
 the system. In other words, we need this boot code translated so we
 can build the boot translator.
 
-{\bf NOTE: IF YOU CHANGE THE BOOT CODE IN G-BOOT.BOOT.PAMPHLET
-YOU MUST TRANSLATE THIS CODE TO LISP AND STORE THE RESULTING LISP
-CODE BACK INTO THE G-BOOT.BOOT.PAMPHLET FILE. THIS IS NOT AUTOMATED.}
+{\bf note: if you change the boot code in g-boot.boot.pamphlet
+you must translate this code to lisp and store the resulting lisp
+code back into the g-boot.boot.pamphlet file. this is not automated.}
 <<g-boot.lisp (OUT from IN)>>=
 ${OUT}/g-boot.${LISP}: ${IN}/g-boot.boot.pamphlet
 	@ echo 256 making ${OUT}/g-boot.${LISP} from ${IN}/g-boot.boot.pamphlet
@@ -3991,9 +3992,9 @@ code. We need to keep the translated code around so we can bootstrap
 the system. In other words, we need this boot code translated so we
 can build the boot translator.
 
-{\bf NOTE: IF YOU CHANGE THE BOOT CODE IN G-UTIL.BOOT.PAMPHLET
-YOU MUST TRANSLATE THIS CODE TO LISP AND STORE THE RESULTING LISP
-CODE BACK INTO THE G-UTIL.BOOT.PAMPHLET FILE. THIS IS NOT AUTOMATED.}
+{\bf note: if you change the boot code in g-util.boot.pamphlet
+you must translate this code to lisp and store the resulting lisp
+code back into the g-util.boot.pamphlet file. this is not automated.}
 <<g-util.lisp (OUT from IN)>>=
 ${OUT}/g-util.${LISP}: ${IN}/g-util.boot.pamphlet
 	@ echo 272 making ${OUT}/g-util.${LISP} from ${IN}/g-util.boot.pamphlet
@@ -5436,12 +5437,10 @@ ${DOC}/package.boot.dvi: ${IN}/package.boot.pamphlet
 @
 
 \subsection{parse.boot}
-\begin{verbatim}
-NOTE: this is used to build a bootsys on a virgin copy of the system
-notice that the file placed in ${OUT} is a .lisp file
-this is to allow the depsys to be built even if the .${O} file does
+note: this is used to build a bootsys on a virgin copy of the system
+notice that the file placed in \verb+${OUT}+ is a .lisp file
+this is to allow the depsys to be built even if the \verb+.${O}+ file does
 not exist on the new system
-\end{verbatim}
 <<parse.o (AUTO from OUT)>>=
 ${AUTO}/parse.${O}: ${OUT}/parse.${O}
 	@ echo 374 making ${AUTO}/parse.${O} from ${OUT}/parse.${O}
@@ -5468,9 +5467,9 @@ code. We need to keep the translated code around so we can bootstrap
 the system. In other words, we need this boot code translated so we
 can build the boot translator.
 
-{\bf NOTE: IF YOU CHANGE THE BOOT CODE IN PARSE.BOOT.PAMPHLET
-YOU MUST TRANSLATE THIS CODE TO LISP AND STORE THE RESULTING LISP
-CODE BACK INTO THE PARSE.BOOT.PAMPHLET FILE. THIS IS NOT AUTOMATED.}
+{\bf note: if you change the boot code in parse.boot.pamphlet
+you must translate this code to lisp and store the resulting lisp
+code back into the parse.boot.pamphlet file. this is not automated.}
 <<parse.lisp (OUT from IN)>>=
 ${OUT}/parse.${LISP}: ${IN}/parse.boot.pamphlet
 	@ echo 376 making ${OUT}/parse.${LISP} from ${IN}/parse.boot.pamphlet
@@ -5551,12 +5550,10 @@ ${DOC}/pathname.boot.dvi: ${IN}/pathname.boot.pamphlet
 @
 
 \subsection{postpar.boot}
-\begin{verbatim}
-NOTE: this is used to build bootsys on a virgin copy of the system
-notice that the file placed in ${OUT} is a .lisp file
-this allows the depsys to be built even if the .${O} file does
+note: this is used to build bootsys on a virgin copy of the system
+notice that the file placed in \verb+${OUT}+ is a .lisp file
+this allows the depsys to be built even if the \verb+.${O}+ file does
 not exist on the new system
-\end{verbatim}
 <<postpar.o (AUTO from OUT)>>=
 ${AUTO}/postpar.${O}: ${OUT}/postpar.${O}
 	@ echo 382 making ${AUTO}/postpar.${O} from ${OUT}/postpar.${O}
@@ -5569,9 +5566,9 @@ code. We need to keep the translated code around so we can bootstrap
 the system. In other words, we need this boot code translated so we
 can build the boot translator.
 
-{\bf NOTE: IF YOU CHANGE THE BOOT CODE IN POSTPAR.BOOT.PAMPHLET
-YOU MUST TRANSLATE THIS CODE TO LISP AND STORE THE RESULTING LISP
-CODE BACK INTO THE POSTPAR.BOOT.PAMPHLET FILE. THIS IS NOT AUTOMATED.}
+{\bf note: if you change the boot code in postpar.boot.pamphlet
+you must translate this code to lisp and store the resulting lisp
+code back into the postpar.boot.pamphlet file. this is not automated.}
 <<postpar.lisp (OUT from IN)>>=
 ${OUT}/postpar.${LISP}: ${IN}/postpar.boot.pamphlet
 	@ echo 383 making ${OUT}/postpar.${LISP} \
@@ -5765,9 +5762,9 @@ code. We need to keep the translated code around so we can bootstrap
 the system. In other words, we need this boot code translated so we
 can build the boot translator.
 
-{\bf NOTE: IF YOU CHANGE THE BOOT CODE IN SETVARS.BOOT.PAMPHLET
-YOU MUST TRANSLATE THIS CODE TO LISP AND STORE THE RESULTING LISP
-CODE BACK INTO THE SETVARS.BOOT.PAMPHLET FILE. THIS IS NOT AUTOMATED.}
+{\bf note: if you change the boot code in setvars.boot.pamphlet
+you must translate this code to lisp and store the resulting lisp
+code back into the setvars.boot.pamphlet file. this is not automated.}
 <<setvars.lisp (OUT from IN)>>=
 ${OUT}/setvars.${LISP}: ${IN}/setvars.boot.pamphlet
 	@ echo 393 making ${OUT}/setvars.${LISP} \
@@ -5915,9 +5912,9 @@ code. We need to keep the translated code around so we can bootstrap
 the system. In other words, we need this boot code translated so we
 can build the boot translator.
 
-{\bf NOTE: IF YOU CHANGE THE BOOT CODE IN SLAM.BOOT.PAMPHLET
-YOU MUST TRANSLATE THIS CODE TO LISP AND STORE THE RESULTING LISP
-CODE BACK INTO THE SLAM.BOOT.PAMPHLET FILE. THIS IS NOT AUTOMATED.}
+{\bf note: if you change the boot code in slam.boot.pamphlet
+you must translate this code to lisp and store the resulting lisp
+code back into the slam.boot.pamphlet file. this is not automated.}
 <<slam.lisp (OUT from IN)>>=
 ${OUT}/slam.${LISP}: ${IN}/slam.boot.pamphlet
 	@ echo 403 making ${OUT}/slam.${LISP} from ${IN}/slam.boot.pamphlet
@@ -8546,7 +8543,7 @@ information is useful. There are 2 cases:
 (as of 2/92: browser old parser and old compiler)
 \item adding new files
 \begin{itemize}
-\item case 1:\\
+\item case 1:
 \begin{itemize}
 \item [(a)] you have to add the file to the list of files currently there
 (e.g. see BROBJS above)

\start
Date: Sun, 22 Jul 2007 12:38:16 -0400
From: Bill Page
To: Franz Lehner
Subject: Re: MonoidWithZero

On 7/22/07, Franz Lehner wrote:
> Bill Page wrote:
> > I think the short answer is "no". But if you do re-write it, I can see
> > no reason why this should not be written as a normal category
> > definition and used in MonoidRing instead of the local macro
> > definition.
>
> well I tried. Are there instructions for the clueless like me?
> Simply modifying mring.spad.pamphlet apparently is not enough
> (see attached diff).
> The category definition is not exported into
> MRING.spad. Is there some index where it has to appear also in order
> to be compiled?
>

What you wrote appears to be correct (I have not tried to compile it
yet). You have modified 'mring.spad.pamphlet' to define the new
category, so you need to ensure that when you re-build Axiom it finds
this new code. How this works depends on what version of the Axiom
sources you are using. All versions scan the algebra pamphlet files
looking for chunk names like:

  <<category MRCAT MonoidRingCategory>>=

and then extract these names to create rules used during 'make' but
when this happens is different between the different versions. For
example in build-improvements this is done during the ./configure
step.

So to keep it as simple as possible, I would recommend that after
making this change, you do a complete re-build of Axiom. When using
build improvements the simplest way to do this is to modify the local
working copy of the repository and then do a new out-of-source build.

Of course instead of modifying the original source, for testing at
least, you could just re-compile these modules using ')compile' in the
Axiom interpreter.

\start
Date: Sun, 22 Jul 2007 19:12:02 +0200 (CEST)
From: Franz Lehner
To: Bill Page
Subject: Re: MonoidWithZero

>
> What you wrote appears to be correct (I have not tried to compile it
> yet). You have modified 'mring.spad.pamphlet' to define the new
> category, so you need to ensure that when you re-build Axiom it finds
> this new code. How this works depends on what version of the Axiom
> sources you are using.
I still use wh-sandbox although this will be obsolete at some point as I 
understand.

> So to keep it as simple as possible, I would recommend that after
> making this change, you do a complete re-build of Axiom.
This is what I was trying to do.
MRING.spad is generated in the weave step but the MRCategory chunk does 
not make it there for some reason.
It appears however in 
src/algebra/extract-spad.mk
Grepping around I saw that e.g. AbelianMonoidRing
also appears in various other places of the source,

src/doc/bookvol1.pamphlet
src/doc/topics.data
src/doc/book.pamphlet
src/share/algebra/compress.daase
src/share/algebra/libaxiom.al
src/share/algebra/command.list
src/interp/daase.lisp.pamphlet

to name a few which may be relevant.
Do I have to insert the new category into these databases per hand to
make it visible?

I tried recompiling modules with )compile with other patches earlier but 
this somehow confuses the precedence in the interpreter.
For example, taking inverses in  Matrix Integer  called the inverse 
function from  FreeGroup Matrix Integer ...
Anyways I do want to have it in the library, because I compile my Aldor 
domains externally with a Makefile.

> When using
> build improvements the simplest way to do this is to modify the local
> working copy of the repository and then do a new out-of-source build.
that's what I did with the results noted above.

> Of course instead of modifying the original source, for testing at
> least, you could just re-compile these modules using ')compile' in the
> Axiom interpreter.
yes, manual notangle + )compile works.

\start
Date: Sun, 22 Jul 2007 14:18:27 -0400
From: Bill Page
To: Franz Lehner
Subject: Re: MonoidWithZero

On 7/22/07, Franz Lehner wrote:
> This is what I was trying to do.
> MRING.spad is generated in the weave step but the MRCategory chunk does
> not make it there for some reason.
> It appears however in
> src/algebra/extract-spad.mk
> Grepping around I saw that e.g. AbelianMonoidRing
> also appears in various other places of the source,
>
> src/doc/bookvol1.pamphlet
> src/doc/topics.data
> src/doc/book.pamphlet
> src/share/algebra/compress.daase
> src/share/algebra/libaxiom.al
> src/share/algebra/command.list
> src/interp/daase.lisp.pamphlet
>
> to name a few which may be relevant.
> Do I have to insert the new category into these databases per hand to
> make it visible?
>

No. The src/doc files are not involved. All of the database files are
re-generated dynamically during the build. I am not sure about
command.list but looking at the makefile in share suggests that it is
not necessary for what you want to do.

wh-sandbox uses a different bootstrap method than Axiom Silver and
build-improvements, so you might need to do things slightly
differently. But most important in any case is the contents of the
file:

  wh-sandbox/src/algebra/Makefile.pamphlet

grep for 'AMR' (the abbreviation for AbelianMonoidRing) in this file.
E.g. in SPADLIST, CATLIST, CATDOMS

I think that at least you will need to add your new 'MRCAT' to each of
these lists.

If you are still having trouble I will have time to try this myself
only much later today and I will try to give you more specific
suggestions then.

\start
Date: Sun, 22 Jul 2007 22:44:27 +0200 (CEST)
From: Franz Lehner
To: Bill Page
Subject: Re: MonoidWithZero

> wh-sandbox uses a different bootstrap method than Axiom Silver and
> build-improvements, so you might need to do things slightly
> differently. But most important in any case is the contents of the
> file:
>
> wh-sandbox/src/algebra/Makefile.pamphlet
>
> grep for 'AMR' (the abbreviation for AbelianMonoidRing) in this file.
> E.g. in SPADLIST, CATLIST, CATDOMS
>
> I think that at least you will need to add your new 'MRCAT' to each of
> these lists.
indeed adding MRCAT to SPADLIST and CATLIST makes MRCAT.spad and  MRCAT.o 
appear in the build directory.
Adding it to CATDOMS triggers an early error when compiling VECTOR.
However when it comes to compiling MRING, MRCAT is invisible as before:

    initializing NRLIB MRING for MonoidRing
    compiling into NRLIB MRING
    cannot produce category object:
(|MonoidRingCategory| R M)
    finalizing NRLIB MRING
    Internal Error
    Unexpected error in call to system function getSlotFromFunctor


> If you are still having trouble I will have time to try this myself
> only much later today and I will try to give you more specific
> suggestions then.
thanks so far, later today will be tomorrow for me ...

\start
Date: Mon, 23 Jul 2007 02:41:03 -0400
From: Bill Page
To: Franz Lehner
Subject: Re: MonoidWithZero

On 7/22/07, Franz Lehner wrote:
>
> > wh-sandbox uses a different bootstrap method than Axiom Silver and
> > build-improvements, so you might need to do things slightly
> > differently. But most important in any case is the contents of the
> > file:
> >
> > wh-sandbox/src/algebra/Makefile.pamphlet
> >
> > grep for 'AMR' (the abbreviation for AbelianMonoidRing) in this file.
> > E.g. in SPADLIST, CATLIST, CATDOMS
> >
> > I think that at least you will need to add your new 'MRCAT' to each of
> > these lists.
> indeed adding MRCAT to SPADLIST and CATLIST makes MRCAT.spad and  MRCAT.o
> appear in the build directory.
> Adding it to CATDOMS triggers an early error when compiling VECTOR.

You are right. I do not think it should be included in CATDOMS.

> However when it comes to compiling MRING, MRCAT is invisible as before:
>
>     initializing NRLIB MRING for MonoidRing
>     compiling into NRLIB MRING
>     cannot produce category object:
> (|MonoidRingCategory| R M)
>     finalizing NRLIB MRING
>     Internal Error
>     Unexpected error in call to system function getSlotFromFunctor
>
>
> > If you are still having trouble I will have time to try this myself
> > only much later today and I will try to give you more specific
> > suggestions then.
> thanks so far, later today will be tomorrow for me ...
>

After applying your patch and adding MRCAT to SPADLIST and CATLIST, so
far all I can do is confirm the error message that you show above. I
do not understand the cause but I suspect a bootstrap-related error. I
think we need the opinion of the expert here: Waldek, do you
understand the meaning and cause of the message "cannot produce
category object"? Is this a bootstrap problem or perhaps a problem in
the SPAD compiler?

\start
Date: Mon, 23 Jul 2007 08:52:55 +0200 (CEST)
From: Franz Lehner
To: Bill Page
Subject: Re: MonoidWithZero

> After applying your patch and adding MRCAT to SPADLIST and CATLIST, so
> far all I can do is confirm the error message that you show above. I
> do not understand the cause but I suspect a bootstrap-related error. I
> think we need the opinion of the expert here: Waldek, do you
> understand the meaning and cause of the message "cannot produce
> category object"? Is this a bootstrap problem or perhaps a problem in
> the SPAD compiler?
When compiling it says
    Using local database
/home/lehner/usr/local/src/axiom/wh-sandbox/src/share/algebra/DAASE
where DAASE runs over

compress.daase
interp.daase
operation.daase
category.daase
browse.daase

These appear to be static but not intended to be read by humans. Does
anyone know how to update these databases?

\start
Date: Mon, 23 Jul 2007 03:02:42 -0400
From: Bill Page
To: Franz Lehner
Subject: Re: MonoidWithZero

On 7/23/07, Franz Lehner wrote:
>
> > After applying your patch and adding MRCAT to SPADLIST and CATLIST, so
> > far all I can do is confirm the error message that you show above. I
> > do not understand the cause but I suspect a bootstrap-related error. I
> > think we need the opinion of the expert here: Waldek, do you
> > understand the meaning and cause of the message "cannot produce
> > category object"? Is this a bootstrap problem or perhaps a problem in
> > the SPAD compiler?
> When compiling it says
>     Using local database
> /home/lehner/usr/local/src/axiom/wh-sandbox/src/share/algebra/DAASE
> where DAASE runs over
>
> compress.daase
> interp.daase
> operation.daase
> category.daase
> browse.daase
>
> These appear to be static but not intended to be read by humans. Does
> anyone know how to update these databases?
>

The databases are being rebuilt as part of the bootstrap process and
at some point the new database files need to be used for the compile.
I think you are right to suspect this as a possible cause of the
problem. As I recall Waldek only partially completed the process of
completely rebuilding the databases files in wh-sandbox. In fact in
some recent commits to the FriCAS project he states that the build
process in FriCAS now builds the algebra without using any pre-defined
databases and in the documentation he explains exactly this kind of
problem.

I will try your patches on FriCAS and let you know how it turns out.

\start
Date: 23 Jul 2007 02:55:53 -0500
From: Gabriel Dos Reis
To: list
Subject: Axiom meeting

All Axiomatizers --

  For those of you who will be attending ISSAC '07, I propose we 
have a meeting around the topic: Axiom, present and future! 

See all y'all.

\start
Date: Mon, 23 Jul 2007 11:29:08 +0200 (CEST)
From: Franz Lehner
To: Bill Page
Subject: Re: MonoidWithZero

> I will try your patches on FriCAS and let you know how it turns out.
The same problem persists in FriCAS:
)compile "MRING.spad"

    Compiling AXIOM source code from file

/local/data/lehner/usr/local/src/axiom/ax-build/src/algebra/MRING.spad
       using old system compiler.
    MRING abbreviates domain MonoidRing
    processing macro definition Term ==> Record(coef: R,monom: M)
    >> System error:
    The function |MonoidRingCategory| is undefined.

(1) -> Phase 3
mv: Aufruf von stat fuer browse.daase nicht moelich: Datei oder Verzeichnis nicht gefunden
...


Databases apparently are built and MRCAT is compiled befor MRING,
still it does not work.
What is missing?

\start
Date: Mon, 23 Jul 2007 11:53:50 +0200 (CEST)
From: Franz Lehner
To: Bill Page
Subject: Re: MonoidWithZero

> Databases apparently are built
> ...and MRCAT is compiled befor MRING,
that's actually not true. MRCAT.spad is generated, but now we have to make 
sure it is compiled before MRING (?).

\start
Date: Mon, 23 Jul 2007 15:03:34 +0200 (CEST)
From: Franz Lehner
To: Bill Page
Subject: Re: MonoidWithZero

> that's actually not true. MRCAT.spad is generated, but now we have to make 
> sure it is compiled before MRING (?).
apparently appending a line in
fricas/src/algebra/boo-cat.input
does the trick. At least both MRCAT.NRLIB and MRING.NRLIB did compile and 
it didn't stop yet.

\start
Date: Mon, 23 Jul 2007 10:42:02 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Axiom meeting

On 23 Jul 2007 02:55:53 -0500, Gabriel Dos Reis wrote:
>
> All Axiomatizers --
>
>   For those of you who will be attending ISSAC '07, I propose we
> have a meeting around the topic: Axiom, present and future!
>
> See all y'all.
>

I will be arriving in Waterloo late afternoon on Sunday, July 29. I am
staying in the university residence. I expect we can meet during the
6:30 PM Welcome Reception.

I am very much in favor of scheduling a meeting about Axiom during the
conference. I would like to make it as open as possible. Perhaps we
can ask the conference organizers to post a notice (even though it is
not part of the "official" program)?

http://www.cs.uwaterloo.ca/conferences/issac2007/program-schedule.shtml

What time would you propose?

\start
Date: Mon, 23 Jul 2007 17:15:01 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Pamphlet files and Axiom

>>>>    @<The \texttt{WEAVE} command@>= ....
>>> Erm.  That didn't occur to me.  I always viewed simple non-LaTeX
>>> chunk names as sufficient.
>> For me it is not sufficient.
> 
> I guess I can see that.  In a collection chunk, would you then do:
> 
> @<collectingterms@>=
>    @<The \texttt{TANGLE} command@>
>    @<The \texttt{WEAVE} command@>
> etc...
> @
> 
> That would be very interesting.

And boring (because it doesn't use the full power of LaTeX). Rather look 
at 
http://www.risc.uni-linz.ac.at/people/hemmecke/AldorCombinat/combinatsu25.html#noweb.NWf7R7q-2dx9rs-4

It's the same example that Martin recently copied to the list.

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

<<implementation: Compose>>=
structures(s: SetSpecies L): Generator % == generate {
     for pi in structures(s)$Partition(L) repeat {
         <<Yield elements of $F[\pi]\times\prod_{p\in\pi} {G[p]}$>>
     }
}
@

<<Yield elements of $F[\pi]\times\prod_{p\in\pi} {G[p]}$>>=
import from MachineInteger, Partition L;
arrlist: Array List L := pi::Array List L;
for f in structures(pi::SetSpecies(SetSpecies L))$F(SetSpecies L) repeat {
     for p in structures(0, arrlist) repeat yield per [pi, f, p];
}
@

Consider chunk names as section titles!

Also look at the bottom of 
http://wiki.axiom-developer.org/SandboxPamphletStyle

\start
Date: Mon, 23 Jul 2007 17:21:35 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Pamphlet files and Axiom

> Axiom's current default weave usage does not make use of the full power
> of noweb's weave logic.  Ralf's ALLPROSE (demonstrated in his
> experiments on cl-web a while back) makes much fuller use of this logic
> and at this time constitutes the most advanced weave output yet
> demonstrated for an Axiom pamphlet file.

http://lists.nongnu.org/archive/html/axiom-developer/2007-05/msg00034.html
http://portal.axiom-developer.org/Members/hemmecke

To achieve that without a weave step is probably very hard.

One should also be aware that the current Axiom-pamphlets are not really 
nicely hyperlinked and indexed. If that will be added then running TeX 
just once is not enough for the build. I hope that is also considered 
when noweb is blamed for being slow in contrast to the time that latex 
needs. (Anyway, Stephen has already given some timings that look 
drastically different from what Tim experiences.)

\start
Date: 23 Jul 2007 11:23:00 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Axiom meeting
Cc: Gabriel Dos Reis

Greetings!  Alas, I cannot make this meeting, but would dearly
appreciate another gathering like the one we had in NYC.  Don't know
if this is feasible or not.

Take care,

Bill Page writes:

> On 23 Jul 2007 02:55:53 -0500, Gabriel Dos Reis wrote:
> >
> > All Axiomatizers --
> >
> >   For those of you who will be attending ISSAC '07, I propose we
> > have a meeting around the topic: Axiom, present and future!
> >
> > See all y'all.
> >
> 
> I will be arriving in Waterloo late afternoon on Sunday, July 29. I am
> staying in the university residence. I expect we can meet during the
> 6:30 PM Welcome Reception.
> 
> I am very much in favor of scheduling a meeting about Axiom during the
> conference. I would like to make it as open as possible. Perhaps we
> can ask the conference organizers to post a notice (even though it is
> not part of the "official" program)?
> 
> http://www.cs.uwaterloo.ca/conferences/issac2007/program-schedule.shtml
> 
> What time would you propose?

\start
Date: Mon, 23 Jul 2007 11:25:13 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Pamphlet files and Axiom

Ralf writes:
> One should also be aware that the current Axiom-pamphlets are not really
> nicely hyperlinked and indexed. If that will be added then running TeX
> just once is not enough for a build.

TeX is run twice on every file, once for the first pass and once to
resolve the index/citations/etc.

\start
Date: Mon, 23 Jul 2007 13:02:18 -0400
From: Bill Page
To: Franz Lehner
Subject: Re: MonoidWithZero

On 7/23/07, Franz Lehner wrote:
>
> > that's actually not true. MRCAT.spad is generated, but now we have to make
> > sure it is compiled before MRING (?).
> apparently appending a line in
> fricas/src/algebra/boo-cat.input
> does the trick. At least both MRCAT.NRLIB and MRING.NRLIB did compile and
> it didn't stop yet.
>

Yes, apparently that is exactly what was needed. Good work! I can
confirm that this compiles with FriCAS revision 25 under MSYS/MinGW on
my Windows XP system.

You might also want to add MRCAT to exposed.lisp.pamphlet. The
following is a summary of the patches on my system. Would you be
willing to submit these patches to Waldek for inclusion in FriCAS?

-------------
Administrator@ASUS ~/fricas/src/algebra
$ svn diff exposed.lsp.pamphlet
Index: exposed.lsp.pamphlet
===================================================================
--- exposed.lsp.pamphlet        (revision 25)
+++ exposed.lsp.pamphlet        (working copy)
@@ -625,6 +625,7 @@
   (|Monad| . MONAD)
   (|MonadWithUnit| . MONADWU)
   (|Monoid| . MONOID)
+  (|MonoidRingCategory| . MRCAT)
   (|MonogenicAlgebra| . MONOGEN)
   (|MonogenicLinearOperator| . MLO)
   (|MultiDictionary| . MDAGG)

Administrator@ASUS ~/fricas/src/algebra
$ svn diff boo-cat.input
Index: boo-cat.input
===================================================================
--- boo-cat.input       (revision 25)
+++ boo-cat.input       (working copy)
@@ -75,6 +75,7 @@
 )compile "LSAGG.spad"
 )compile "TBAGG.spad"
 )compile "ALAGG.spad"
+)compile "MRCAT.spad"
 )compile "AMR.spad"
 )compile "ARR2CAT.spad"
 )compile "BRAGG.spad"

Administrator@ASUS ~/fricas/src/algebra
$ svn diff Makefile.pamphlet
Index: Makefile.pamphlet
===================================================================
--- Makefile.pamphlet   (revision 25)
+++ Makefile.pamphlet   (working copy)
@@ -271,7 +271,7 @@
      MKUCFUNC MLIFT MLO MMAP MODFIELD MODMONOM \
      MODMON MODOP MODRING MODULE MOEBIUS MONAD \
      MONADWU MONOGEN MONOID MONOTOOL MPC2 MPC3 \
-     MPCPF MPOLY MPRFF MRATFAC MRF2 MRING \
+     MPCPF MPOLY MPRFF MRATFAC MRCAT MRF2 MRING \
      MSETAGG MSET MSYSCMD MTHING MTSCAT MULTFACT \
      MULTSQFR NAALG NARNG \
      NASRING NCEP NCNTFRAC NCODIV NFINTBAS \
@@ -366,7 +366,7 @@
         FDIVCAT FFCAT FILECAT MONAD NARNG NAALG FINAALG LIECAT FLALG \
         FORTCAT FMC FMCAT FMFUN FMTC FNCAT FORTFN REAL RNS FPS FRNAALG \
         SETAGG FSAGG FVC FVFUN GRMOD GRALG IDPC OINTDOM INS INTCAT LALG \
-        LFCAT OREPCAT LODOCAT LZSTAGG MATCAT MDAGG MLO MONADWU MSETAGG \
+        LFCAT OREPCAT LODOCAT LZSTAGG MATCAT MDAGG MLO MONADWU MRCAT MSETAGG \
         PSCAT MTSCAT NASRING PSETCAT TSETCAT RSETCAT NTSCAT OC \
         PRQAGG OMSAGG ORDFIN ORDMON PADICCT PERMCAT \
         PPCURVE PSCURVE VECTCAT PTCAT QFCAT QUATCAT RCFIELD RMATCAT \

Administrator@ASUS ~/fricas/src/algebra
$ svn diff boo-cat.input
Index: boo-cat.input
===================================================================
--- boo-cat.input       (revision 25)
+++ boo-cat.input       (working copy)
@@ -75,6 +75,7 @@
 )compile "LSAGG.spad"
 )compile "TBAGG.spad"
 )compile "ALAGG.spad"
+)compile "MRCAT.spad"
 )compile "AMR.spad"
 )compile "ARR2CAT.spad"
 )compile "BRAGG.spad"

Administrator@ASUS ~/fricas/src/algebra
$ svn status
?      mring.spad.pamphlet.diff
M      boo-cat.input
M      Makefile.pamphlet
M      exposed.lsp.pamphlet
M      Makefile.in
M      mring.spad.pamphlet

Administrator@ASUS ~/fricas/src/algebra
$ svn diff Makefile.pamphlet
Index: Makefile.pamphlet
===================================================================
--- Makefile.pamphlet   (revision 25)
+++ Makefile.pamphlet   (working copy)
@@ -271,7 +271,7 @@
      MKUCFUNC MLIFT MLO MMAP MODFIELD MODMONOM \
      MODMON MODOP MODRING MODULE MOEBIUS MONAD \
      MONADWU MONOGEN MONOID MONOTOOL MPC2 MPC3 \
-     MPCPF MPOLY MPRFF MRATFAC MRF2 MRING \
+     MPCPF MPOLY MPRFF MRATFAC MRCAT MRF2 MRING \
      MSETAGG MSET MSYSCMD MTHING MTSCAT MULTFACT \
      MULTSQFR NAALG NARNG \
      NASRING NCEP NCNTFRAC NCODIV NFINTBAS \
@@ -366,7 +366,7 @@
         FDIVCAT FFCAT FILECAT MONAD NARNG NAALG FINAALG LIECAT FLALG \
         FORTCAT FMC FMCAT FMFUN FMTC FNCAT FORTFN REAL RNS FPS FRNAALG \
         SETAGG FSAGG FVC FVFUN GRMOD GRALG IDPC OINTDOM INS INTCAT LALG \
-        LFCAT OREPCAT LODOCAT LZSTAGG MATCAT MDAGG MLO MONADWU MSETAGG \
+        LFCAT OREPCAT LODOCAT LZSTAGG MATCAT MDAGG MLO MONADWU MRCAT MSETAGG \
         PSCAT MTSCAT NASRING PSETCAT TSETCAT RSETCAT NTSCAT OC \
         PRQAGG OMSAGG ORDFIN ORDMON PADICCT PERMCAT \
         PPCURVE PSCURVE VECTCAT PTCAT QFCAT QUATCAT RCFIELD RMATCAT \

Administrator@ASUS ~/fricas/src/algebra
$ svn diff mring.spad.pamphlet
Index: mring.spad.pamphlet
===================================================================
--- mring.spad.pamphlet (revision 25)
+++ mring.spad.pamphlet (working copy)
@@ -9,12 +9,12 @@
 \eject
 \tableofcontents
 \eject
-\section{domain MRING MonoidRing}
-<<domain MRING MonoidRing>>=
-)abbrev domain MRING MonoidRing
+\section{category MRCAT MonoidRingCategory}
+<<category MRCAT MonoidRingCategory>>=
+)abbrev category MRCAT MonoidRingCategory
 ++ Authors: Stephan M. Watt; revised by Johannes Grabmeier
 ++ Date Created: January 1986
-++ Date Last Updated: 14 December 1995, Mike Dewar
+++ Date Last Updated: 22 July 2007, Franz Lehner
 ++ Basic Operations: *, +, monomials, coefficients
 ++ Related Constructors: Polynomial
 ++ Also See:
@@ -23,26 +23,13 @@
 ++  indeterminates
 ++ References:
 ++ Description:
-++  \spadtype{MonoidRing}(R,M), implements the algebra
+++  \spadtype{MonoidRingCategory}(R,M) defines the algebra
 ++  of all maps from the monoid M to the commutative ring R with
 ++  finite support.
-++  Multiplication of two maps f and g is defined
-++  to map an element c of M to the (convolution) sum over {\em f(a)g(b)}
-++  such that {\em ab = c}. Thus M can be identified with a canonical
-++  basis and the maps can also be considered as formal linear combinations
-++  of the elements in M. Scalar multiples of a basis element are called
-++  monomials. A prominent example is the class of polynomials
-++  where the monoid is a direct product of the natural numbers
-++  with pointwise addition. When M is
-++  \spadtype{FreeMonoid Symbol}, one gets polynomials
-++  in infinitely many non-commuting variables. Another application
-++  area is representation theory of finite groups G, where modules
-++  over \spadtype{MonoidRing}(R,G) are studied.
-
-MonoidRing(R: Ring, M: Monoid): MRcategory == MRdefinition where
+MonoidRingCategory(R: Ring, M: Monoid):Category == MRCdefinition where
     Term ==> Record(coef: R, monom: M)

-    MRcategory ==> Join(Ring, RetractableTo M, RetractableTo R) with
+    MRCdefinition == Join(Ring, RetractableTo M, RetractableTo R) with
         monomial         : (R, M) -> %
           ++ monomial(r,m) creates a scalar multiple of the basis element m.
         coefficient : (%, M) -> R
@@ -82,6 +69,38 @@
             ++ among all those with non-zero coefficients.
           reductum          : % -> %
             ++ reductum(f) is f minus its leading monomial.
+@
+\section{domain MRING MonoidRing}
+<<domain MRING MonoidRing>>=
+)abbrev domain MRING MonoidRing
+++ Authors: Stephan M. Watt; revised by Johannes Grabmeier
+++ Date Created: January 1986
+++ Date Last Updated: 14 December 1995, Mike Dewar
+++ Basic Operations: *, +, monomials, coefficients
+++ Related Constructors: Polynomial
+++ Also See:
+++ AMS Classifications:
+++ Keywords: monoid ring, group ring, polynomials in non-commuting
+++  indeterminates
+++ References:
+++ Description:
+++  \spadtype{MonoidRing}(R,M), implements the algebra
+++  of all maps from the monoid M to the commutative ring R with
+++  finite support.
+++  Multiplication of two maps f and g is defined
+++  to map an element c of M to the (convolution) sum over {\em f(a)g(b)}
+++  such that {\em ab = c}. Thus M can be identified with a canonical
+++  basis and the maps can also be considered as formal linear combinations
+++  of the elements in M. Scalar multiples of a basis element are called
+++  monomials. A prominent example is the class of polynomials
+++  where the monoid is a direct product of the natural numbers
+++  with pointwise addition. When M is
+++  \spadtype{FreeMonoid Symbol}, one gets polynomials
+++  in infinitely many non-commuting variables. Another application
+++  area is representation theory of finite groups G, where modules
+++  over \spadtype{MonoidRing}(R,G) are studied.
+MonoidRing(R: Ring, M: Monoid): MonoidRingCategory(R,M) == MRdefinition where
+    Term ==> Record(coef: R, monom: M)

     MRdefinition ==> add
         Ex ==> OutputForm
@@ -395,6 +414,7 @@
 <<*>>=
 <<license>>

+<<category MRCAT MonoidRingCategory>>
 <<domain MRING MonoidRing>>
 <<package MRF2 MonoidRingFunctions2>>
 @

\start
Date: Mon, 23 Jul 2007 13:26:53 -0500
From: Tim Daly
To: Bill Page
Subject: MonoidWithZero

Could you please post a corresponding change for Axiom against
the SVN trunk?

\start
Date: Mon, 23 Jul 2007 14:34:42 -0400
From: Bill Page
To: Tim Daly
Subject: Re: MonoidWithZero

On 7/23/07, Tim Daly wrote:
> Bill,
>
> Could you please post a corresponding change for Axiom against
> the SVN trunk?
>

I am sorry Tim, but I do not think this change can be made to work
without almost all of the completely new bootstrap system designed by
Waldek that is now part of FriCAS. It does not even work with the
wh-sandbox branch. The problem is that the change requires a deep
change to the databases files and cannot be compiled with the existing
database files that are used in previous versions. The reason is that
it can be made to work in FriCAS is that FriCAS no longer requires any
pre-existing database files and builds them all as the bootstrap
process proceeds.

The only possibility I can think of that might work be to update the
src/share database files in trunk with those generated by FriCAS. But
all this database stuff is rather a mystery to me so I could well be
wrong...

\start
Date: Mon, 23 Jul 2007 17:23:32 -0500
From: Tim Daly
To: list
Subject: Windows sockets

There is some information on this site regarding the issue of porting
socket-based programs to windows:

http://tangentsoft.net/wskfaq/articles/bsd-compatibility.html

\start
Date: Mon, 23 Jul 2007 18:55:10 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom meeting

On Mon, 23 Jul 2007, Bill Page wrote:

| On 23 Jul 2007 02:55:53 -0500, Gabriel Dos Reis wrote:
| >
| > All Axiomatizers --
| >
| >   For those of you who will be attending ISSAC '07, I propose we
| > have a meeting around the topic: Axiom, present and future!
| >
| > See all y'all.
| >
| 
| I will be arriving in Waterloo late afternoon on Sunday, July 29. I am
| staying in the university residence. I expect we can meet during the
| 6:30 PM Welcome Reception.

I'll be there -- I'll be coming from London (after attending SNC/PASCO)
with wife&kid.

| I am very much in favor of scheduling a meeting about Axiom during the
| conference. I would like to make it as open as possible. Perhaps we
| can ask the conference organizers to post a notice (even though it is
| not part of the "official" program)?

That would be great!

| http://www.cs.uwaterloo.ca/conferences/issac2007/program-schedule.shtml
| 
| What time would you propose?

7:30pm?

\start
Date: Tue, 24 Jul 2007 16:28:27 +0200 (CEST)
From: Franz Lehner
To: Tim Daly
Subject: Re: MonoidWithZero

> Could you please post a corresponding change for Axiom against
> the SVN trunk?
since I spent some time on this, how does one add new algebra to the 
library? How does one update the databases?
The page
http://wiki.axiom-developer.org/AxiomAlgebra
explains it but I did not understand.

\start
Date: Tue, 24 Jul 2007 10:44:17 -0500
From: Tim Daly
To: Franz Lehner
Subject: MonoidWithZero

> since I spent some time on this, how does one add new algebra to the
> library? How does one update the databases?
> The page
> http://wiki.axiom-developer.org/AxiomAlgebra
> explains it but I did not understand.

I'm working on the details of adding new algebra at the moment
as I'm adding Martin's algebra. When that completes I'll document
the process.

\start
Date: Tue, 24 Jul 2007 10:49:47 -0500
From: Tim Daly
To: Franz Lehner
Subject: MonoidWithZero

> since I spent some time on this, how does one add new algebra to the
> library? How does one update the databases?
> The page
> http://wiki.axiom-developer.org/AxiomAlgebra
> explains it but I did not understand.

Are your algebra changes documented and posted somewhere I can reach?

\start
Date: Tue, 24 Jul 2007 20:25:36 +0200 (CEST)
From: Franz Lehner
To: Tim Daly
Subject: Re: MonoidWithZero

> Are your algebra changes documented and posted somewhere I can reach?
It was just the patch I sent earlier, the complete version appearing in 
Bill's preceding message (just leave out the boo-cat.input part).
There is not much to document, it just makes a locally hidden category 
visible. Otherwise I don't have much to contribute yet.

\start
Date: Tue, 24 Jul 2007 16:52:20 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Axiom meeting

Dear Axiom Users and Developers,

Based on Gaby's suggestion I wrote to the ISSAC 2007 conference
organizers asking to schedule a meeting about Axiom during the
conference next week, to which they agreed. It is tentatively
scheduled for Monday (July 30) 7:30 PM to 9:30 PM with conference room
still to be determined.

I would greatly appreciate it if you could let me know if you are
interested and able to attend.

---------- Forwarded message ----------
From: George Labahn
Date: Jul 24, 2007 3:00 PM
Subject: Re: Axiom meeting during ISSAC 2007
To: Bill Page

Dear Bill,

There is no problem finding you a room and even putting you opposite
the Maple tutorial meeting. Please just tell me if it will happen.

George L

On Mon, 23 Jul 2007, Bill Page wrote:

> Dear Program Committee;
>
> Gabriel Dos Reis and I and probably several more Axiom developers and
> users will be attending ISSAC 2007. Although we have not previously
> asked for such an arrangement, we were wondering if on short notice it
> might be possible to schedule and announce in the ISSAC 2007 program a
> short meeting for interested participants on the topic:
>
>  Axiom, present and future!
>
> Recently there has been some discord between members of the Axiom open
> source project concerning project goals, organization, and tools,
> resulting in a project fork. This has left both developers and users
> somewhat uncertain about the future of the Axiom open source project.
> An open meeting during ISSAC 2007 would be a timely opportunity to
> "clear the air" and help set new directions and priorities.
>
> -----
>
> In order to have as little impact as possible on the published
> schedule, perhaps the meeting could be organized for Monday (July 30)
> evening overlapping the Maple Tutorial, 7:30 PM to 9:30 PM. Depending
> on the number of participants we would hope that the meeting would be
> mostly a self-organized workshop except perhaps for a designated
> chairperson. I expect that a small room accommodating at most 20 - 30
> people would be adequate.
>
> Please let us know if this arrangement will be possible or if you
> could suggest something similar but more suitable. I understand that
> this might be difficult on such short notice so if this doesn't work
> out, then of course there will also be informal opportunities for us
> to meet during the conference.

\start
Date: Tue, 24 Jul 2007 14:02:57 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Axiom meeting

Bill, I won't be at ISSAC unfortunately - would it be possible to
arrange a video or even an audio recording of the meeting?

I wish I could be there - I think this is a VERY good idea.

\start
Date: Tue, 24 Jul 2007 17:10:26 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Axiom meeting

On 7/24/07, C Y wrote:
> Bill, I won't be at ISSAC unfortunately - would it be possible to
> arrange a video or even an audio recording of the meeting?
>
> I wish I could be there - I think this is a VERY good idea.
>

I will try to arrange audio recording if participants agree. Video
would be very difficult unless pre-arranged by conference organizers
(unlikely).

\start
Date: Tue, 24 Jul 2007 16:11:03 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Axiom meeting

--- Bill Page wrote:

> On 7/24/07, C Y wrote:
> > Bill, I won't be at ISSAC unfortunately - would it be possible to
> > arrange a video or even an audio recording of the meeting?
> >
> > I wish I could be there - I think this is a VERY good idea.
> >
> 
> I will try to arrange audio recording if participants agree. Video
> would be very difficult unless pre-arranged by conference organizers
> (unlikely).

Thanks!  Have fun everybody.

\start
Date: Wed, 25 Jul 2007 22:46:28 -0500
From: Tim Daly
To: Bill Page
Subject: Fricas

Bill,

I see that you've decided to update the pages
<http://wiki.axiomm-developer.org/AxiomCommunity>
to include the fricas project. We discussed this issue previously
on the mailing list.

I suggest that you read the section:
<http://producingoss.com/html-chunk/forks.html>
from which I quote:
   "If those initiating the fork feel that they are sprouting a
    new branch off the main project, the perception question is
    resolved immediately and easily. Everyone, both developers
    and users, will treat the fork as a new project, with a new
    name (perhaps based on the old name, but easily distinguishable
    from it), a separate website, and a separate philosophy or goal."

I strongly object to the dilution of the Axiom name and resources
implied by your action. A fork implies the decision NOT to share
resources. Please do NOT promote Fricas as Axiom in any forum.
They are two entirely separate projects.

We clearly disagree on this point.

Until we have a mechanism for voting in place, and a vote is taken
that results in community discussion and agreement that Fricas should
be promoted as you have done, I ask you to remove your edits.

\start
Date: Thu, 26 Jul 2007 11:44:11 +0700 (NOVST)
From: Andrey G. Grozin
To: Tim Daly
Subject: Re: Fricas

On Wed, 25 Jul 2007, Tim Daly wrote:
> Bill,
> 
> I see that you've decided to update the pages
> <http://wiki.axiomm-developer.org/AxiomCommunity>
> to include the fricas project. We discussed this issue previously
> on the mailing list.

I am sorry to ask: what is the purpose of the web site? To be useful? Or 
something entirely different, which I don't understand?

To be useful, each project web site includes links to related projects. 
FriCAS is, certainly, a related project, although a separate one.

\start
Date: Thu, 26 Jul 2007 00:21:49 -0500
From: Tim Daly
To: Andrey G. Grozin
Subject: Fricas

I suggest you visit
the CMUCL common lisp project, <http://www.cons.org/cmucl> and
the SBCL common lisp project, <http://www.sbcl.org/index.html>.

These are two separate projects, with completely separate goals
and resources. SBCL is a fork from CMUCL, started in 1999.
SBCL acknowledges this at <http://www.sbcl.org/history.html>.
There is no confusion in the common lisp community between these
two projects. In fact, they are sensitive to the confusion issue
on the history page and clearly state the differences.

The only cross-linking I can find on these sites is as follows:
CMUCL has a URL in the FAQ <http://www.cons.org/cmucl/FAQ.html>
SBCL has a URL in the history <http://www.sbcl.org/history.html>.
Other than that I do not see any connection. Please find other
examples.




Bill isn't just providing a link. He's providing project-specific
information. In particular, the page 
<http://wiki.axiom-developer.org/FriCAS>
explains the goals of the FriCAS project. It seems off-topic to me.

And the page
<http://wiki.axiom-developer.org/AxiomCommunity>
specifically links the FriCAS mailing lists as co-equal to the
Axiom mailing lists. This promotes confusion.

My problem with Bill's actions is that he does things like post FriCAS
patches on the axiom mailing list. This is entirely off-topic. You
never see patches to SBCL on the CMUCL mailing list, nor patches to
CMUCL on the SBCL mailing list. Both would be "off-topic". 

Bill's action clearly goes against fork behavior of at least one other
project. It goes against the idea of a fork as separate.  It also goes
against my objections without any attempt to reach agreement. 

An off-site wiki link to FriCAS would be appropriate as would a FAQ entry.
Anything beyond that promotes confusion.

There is no suggestion that anyone has to choose which project to work on.
But it is important to keep the projects clearly distinguished so there
is no confusion. There are over 100 computer algebra systems in the world.
None of them are confused with Axiom and FriCAS should not be an exception.

\start
Date: Thu, 26 Jul 2007 01:22:11 -0400
From: Bill Page
To: Tim Daly
Subject: Re: Fricas

Tim,

I am truly shocked and saddened by your demand to remove my updates
concerning the FriCAS project from the axiom-developer server. !!!
:-((  ?

But you are paying the bills for the entire axiom-developer.org server
so I have complied with your request. To me this clearly demonstrates
that an open source project (like Axiom used to be) should *never*
allow themselves to get into a situation where significant project
resources are controlled by only one individual. Never - even if you
once strongly believed in that person's good intentions.

So now what are you intentions? Are you really trying to alienate
everyone involved in the project?  I asked you a few weeks ago: "Do
you have any idea how much damage you are causing?". I guess that
question still stands. I really thought you had recovered from the
state that lead to the current acrimonious situation and so we could
just move on. Sigh. But now you have even *me* feeling like some of
our other colleagues who have already announced their resignation from
the project. I feel like I have been trying hard to do some damage
control and keep the Axiom project together but you have just stabbed
me in the back!

I believe that describing FricCAS the way I just attempted to do - in
the same way that we have previously described and supported Reduce,
Maxima, SymPy and Sage is not the same thing as promoting it -
certainly not any more than promoting progress in computer algebra
systems in general. I just cannot understand what you are thinking...

Under these circumstances I do not think I can continue to help
maintain the Axiom website on the axiom-developer server any more, at
least not until some very basic problems are resolved here. This makes
me very sad not only because I have put a lot of effort into it over
the last 4 years but also because I think it is still a very important
way of promoting Axiom and I still want Axiom to look good even if I
can not agree with you about how this should be done. Fortunately
there are still some other Axiom developers who have not yet resigned
and who have manager-level access to this web site so I am fairly sure
you can get by with their help.

I am not optimistic that any kind of "vote" out of this sitation is
possible. As the book quote points out, democracy is only likely to
happen in a mature well-populated project that has already sorted out
most of these differences. Right now we are lucky if we can even find
5 out out of the nearly 100 subscribers in the axiom-devel mailing
list who are willing to make a public statement about any of issues
that have been considered for vote-taking here recently. I get the
feeling either everyone is watching and waiting to see what happens
next, or else (maybe) very few people really care that much and they
really aren't watching at all.

So here we are. This is certainly not the kind of situation I thought
we would be in next time we met in person . (I presume you are still
planning to attend the ISSAC conference?) I thought I would be buying
you a beer - or maybe even a 4-course gourmet meal to celebrate  - not
arguing and biting nails. It's Damn disappointing :-( but by the way,
my invitation to dinner next week still stands.

Bill Page.


On 7/25/07, Tim Daly wrote:
> Bill,
>
> I see that you've decided to update the pages
> <http://wiki.axiomm-developer.org/AxiomCommunity>
> to include the fricas project. We discussed this issue previously
> on the mailing list.
>
> I suggest that you read the section:
> <http://producingoss.com/html-chunk/forks.html>
> from which I quote:
>    "If those initiating the fork feel that they are sprouting a
>     new branch off the main project, the perception question is
>     resolved immediately and easily. Everyone, both developers
>     and users, will treat the fork as a new project, with a new
>     name (perhaps based on the old name, but easily distinguishable
>     from it), a separate website, and a separate philosophy or goal."
>
> I strongly object to the dilution of the Axiom name and resources
> implied by your action. A fork implies the decision NOT to share
> resources. Please do NOT promote Fricas as Axiom in any forum.
> They are two entirely separate projects.
>
> We clearly disagree on this point.
>
> Until we have a mechanism for voting in place, and a vote is taken
> that results in community discussion and agreement that Fricas should
> be promoted as you have done, I ask you to remove your edits.

\start
Date: 26 Jul 2007 01:27:04 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Fricas

Bill,

I need to strongly second Tim's concern.  It is one thing for Axiom
developers and FriCAS developers to exchange ideas and patches on the
axiom-developer mailing list.  It is another issue all together to use
this forum, or to use Axioms website, to promote FriCAS as an
alternative to the system so many of us invest our time and resources
in. 

If FriCAS is to be successful, it needs to make it on its own, and not
leverage the resources which Axiom has earned and, therefore,
deserves.

\start
Date: Thu, 26 Jul 2007 01:05:49 -0500
From: Tim Daly
To: Bill Page
Subject: Fricas

Bill,

> But you are paying the bills for the entire axiom-developer.org server
> so I have complied with your request. To me this clearly demonstrates
> that an open source project (like Axiom used to be) should *never*
> allow themselves to get into a situation where significant project
> resources are controlled by only one individual. Never - even if you
> once strongly believed in that person's good intentions.

I don't believe *I* mentioned anything about the axiom-developer server.
I don't believe *I* "forced" you to remove your changes BECAUSE *I*
"control" the server. You have root access on the server and you have
never needed to ask my permission. If you removed your changes for
the stated reasons you have misconstrued my statements.

It is not clear how you can be shocked about the request to remove updates.
We specifically had this discussion on the mailing list.
<http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00121.html>
<http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00123.html>
<http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00146.html>




My objections are stated in terms of the resources of the Axiom project,
  * the goals of the Axiom project
  * the Axiom trademark
  * the history of the project
  * the goodwill associate with the Axiom name
  * the savannah project site
  * the sourceforge project site
  * the Axiom mailing lists
  * the publications such as the Axiom books, thesis work, etc
  * the work associated with the source code and documentation
  * the public presentation of "Axiom"
  * and, yes, the wiki server

If someone writes algebra that only works in FriCAS and not in Axiom
but says that it is "Axiom algebra", could someone be confused?

If a paper appears at ISSAC next year stating it was done on Axiom
but was done on FriCAS and won't work on Axiom what can we say?
Could someone be confused?

If a CD appears in public with the label "Axiom" but contains the
code from the FriCAS project and the person finds bugs should he
post them to the Axiom mailing list? Could someone be confused?

If the code from FriCAS appears in public with the label Axiom
but contains only source code and no pamphlet files, could a
person be confused if they think the Axiom goal of literate
programming is gone?

If someone demonstrates FriCAS and it has abilities that don't
work in Axiom could someone be confused?


FriCAS is capable of developing its own resources. 
That's what a fork is. 

\start
Date: Thu, 26 Jul 2007 11:26:49 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Fricas

I clearly understand any position. Axiom is not FriCAS and FriCAS should 
not sell under the name of Axiom. That's clear, but not the point.

Much better for Axiom would be if we get Waldek back into the boat. 
Isn't that simple? Cooperation, not separation.

Let's not fight against each other!

\start
Date: Thu, 26 Jul 2007 07:41:04 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Fricas

> Much better for Axiom would be if we get Waldek back into the boat.
> Isn't that simple? Cooperation, not separation.

There has been no discussion against Waldek participating in Axiom.
I, for one, would welcome his participation at any time. I participate
in a couple computer algebra systems and a few other projects. At no
time is this a personal issue.  At no time have I ever claimed that
Waldek is not welcome.

That said, it IS a project issue. Deciding to fork a project risks
"bringing confusion to the marketplace". The separation of projects
needs to be clear and absolute so people clearly know what they mean
when they say "Axiom" and "FriCAS". Witness CMUCL vs SBCL. Forking a
project is clearly an act of separation, not cooperation. 

I know it appears that I'm being divisive, deliberately creating
dissention and discord. However, except for replying to personal
attacks I've limited my discussion to the question of what it means to
participate in a project. 

I am trying to make the point that Axiom is a well-defined thing. 
Prior to Bill's wiki there was an Axiom website I maintained. See:
<http://axiom.axiom-developer.org/axiom-website/faq.html>
It had a list of goals, some of which have been abandoned, some of
which failed, some of which are still relevant. See:
<http://axiom.axiom-developer.org/axiom-website/currentstate.html>
It has not been updated since Oct, 2004 which is when the wiki started.







There are certain standards about how one contributes to an open
source project. Certain behaviors, such as promoting a branch above
the main distribution or the development trunk are NOT cooperative
behaviors. Creating public branches without posting trunk diffs is not
cooperative behavior.  Posting patches to another project are
off-topic for a mailing list. Ad-hominem attacks (attacking the
speaker rather than the point) are off-topic.  Delaying and derailing
the promotion of the development version to the distribution version
is non-cooperative behavior.

I get the impression that most people have never participated in an
open source project before. The behaviors I've seen and complained
about are obviously not aimed at participation or cooperation.  These
things feel so painfully obvious to me. I would never consider doing
some of the behaviors I've watched here, on a project like Fedora,
SBCL, binutils, or other projects I follow. 

Cooperation, not separation, applies to everyone on the project.

\start
Date: Thu, 26 Jul 2007 06:00:26 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: re: Fricas

--- Bill Page wrote:

> Right now we are lucky if we can even find
> 5 out out of the nearly 100 subscribers in the axiom-devel mailing
> list who are willing to make a public statement about any of issues
> that have been considered for vote-taking here recently.

I think people are wary of poking their heads into this kind of
argument.  I know in my case, as I am not nearly as significant a
contributor as people on BOTH sides of this argument, I was reluctant
to make any comments which would further inflame anyone.

> I get the
> feeling either everyone is watching and waiting to see what happens
> next, or else (maybe) very few people really care that much and they
> really aren't watching at all.

I have made some comments in the past.  I guess I can be a little more
definite in what my take on things is:

a)  First, a bias statement - I work on Axiom only for a hobby and do
not depend on it being in a functioning state for any professional or
academic need.  Of necessity, this makes my outlook different than that
of many people here.

b)  I am almost certainly one of the youngest, least experienced
members of the Axiom community - I do not have any formal training in
CAS and only minimal training in programming.  Thus, my opinions skirt
dangerously close to being uninformed, another reason I don't want them
to inflame things.

c)  That said, my interest and hope for Axiom is that it proposes a new
way of designing and developing a CAS - one that is intended to scale
and be comprehensible in the long term.  We discussed that earlier
(7/11/07), and both you and I concluded my goals are "disconnected from
reality," but that does not alter them - they'll stay disconnected
unless someone tries to make them into a reality.  Whether they are
representative of one "side" or the other in this debate I don't really
know - probably I am closer to Tim's goals.

d)  One area where I do have somewhat different opinions is the
changing of the current code base, which except in the strictly
technical sense is almost completely non-literate.  To me it makes
little difference whether we decode and correctness check IBM/NAG's
non-literate code or Waldek's non-literate code - in fact the latter
would probably be easier.  I see little point AT THIS STAGE in keeping
the Axiom codebase slowly changing, because I don't see any special
merit the current codebase has with respect to being mathematically
reliable.  Can it generate a proof trail of a calculation that can be
verified by COQ/ACL2/Metamath/HOL/whatever?  If not, why do we trust
the current code more than Waldek's code?  If we don't, Waldek's code
works better with modern tools and for that reason alone would be
easier to unravel.

e)  That said, there is are arguments for merging in only well
documented, compartmentalized changes.  The most compelling one
socially is that if literate files are not mandatory it will be VERY
tempting for people to ignore the requirement.  FriCAS I see as having
a legitimate purpose - it is trying a different development style than
Axiom.  It may succeed (for some definitions of success) better than
Axiom, and that's great.  But Axiom AS THE PROJECT WAS DEFINED (or at
least how I understood it to be defined) is about more than just a
working CAS.  That's why Steve and I are spending time creating the
tools we want to handle literate files - because those are foundational
tools to the direction Axiom wants to head and we need to resolve them
BEFORE other work begins.  I would much prefer to be working on Units
and Dimensions but to make that possible the foundation must be solid. 
That means the literate tools must be solid, SPAD must be solid, and
the interp environment must be solid.  Solid, by the Axiom project's
definition, means well documented literate pamphlets.  So, that's where
we must begin.  After that will probably come a systematic evaluation
of the pieces of Axiom comprising interp, and hopefully Steve's work on
a new SPAD.   Then we consider the foundations of the algebra, and I
will push at that time for a re-grounding in Category Theory.  Probably
the question of proof systems would need to be addressed by then as
well.  This of course means the final system would be YEARS away from
even basic functionality.  Per my stated bias this is OK with me, but I
understand not with others.

f)  I had hoped FriCAS would be a project for those who need a running
system now, and Axiom could continue with it's "do it Right" approach. 
In the end the two systems might wind up looking quite different, but I
think each would be useful in its own way.  To risk an analogy, it
might be that FriCAS would be the Concise  Oxford Dictionary of CAS -
high quality and widely used - and Axiom would be the full Oxford
Unabridged Dictionary - attempts to be the last word but is not widely
used outside of academic environments.

g) In the end, I think much of this comes down to project goals and how
they are set.  My understanding was that Tim from the outset had very
specific directions and goals he wanted to pursue, and he created the
Axiom project in order to pursue those specific goals.  The central
question to me seems to be whether these goals can be altered by the
Axiom community or they remain a fixed property of the project itself,
with other goals to be pursued in other projects.  That was my
understanding of the reason Tim is asking what he is asking - FriCAS
has DIFFERENT goals than Axiom and he wants to make sure Axiom as a
project is and remains defined by its foundational goals.


Whether the Axiom Project's defining goals are or should be subject to
community alteration seems to me to be the root question here.


Tim, perhaps you could upload a page to the wiki defining in a concise
manner the original foundational project goals, so we have a place to
refer to for this discussion?

Cheers,
CY

P.S.  This is a philosophical discussion that does not and is not
intended to address issues like who commits what and with or without
review.  That would be a separate and far more personal discussion, and
I'm deliberately attempting to avoid it - the more fundamental
questions I think are the critical points to resolve.

\start
Date: Thu, 26 Jul 2007 15:01:57 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Fricas

>> Much better for Axiom would be if we get Waldek back into the boat.
>> Isn't that simple? Cooperation, not separation.

> Cooperation, not separation, applies to everyone on the project.

Did I say something else?

Tim, my last mail text was delibarately not addressed to you but to the 
community. I am sorry that I forgot to remove your email-address from 
the reply. I hope it did not cause too much confusion.

\start
Date: Thu, 26 Jul 2007 09:20:58 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Fricas

Cliff,

> Tim, perhaps you could upload a page to the wiki defining in a concise
> manner the original foundational project goals, so we have a place to
> refer to for this discussion?

<http://axiom.axiom-developer.org/axiom-website/currentstate.html>
contains the project goals as of Oct, 2004 representing years of work.
They were update regularly to reflect changes and progress. The goals 
changed over time as it became obvious that some could not work 
(e.g. funding). 

* As you can see, hyperdoc, sman, etc. did not work at that time.
* You can see that I succeeded in converting BLAS Fortran to Aldor.
* You can see the work started to convert BLAS to pamphlet form (still
  ongoing in a local branch). 
* You can see that I was rewriting Magnus to be literate and merge with 
  Axiom. This code exists and was contributed to the Magnus source tree. 
* You can see that building Axiom on CMUCL was in plan but not started.
* You can see that there is an approved project to Journal papers which
  would be drag-and-drop <http://www.gnu.org/axiom/Journal> and that I
  worked with Carlo Traverso at the University of Pisa and the ACM on it.
* You can see the crystal idea.
* You can see the proviso research.
* You can see Indefinites, which got NSF grant funding.
* You can see the Doyen effort, spun off as a separate project now
  <http://sourceforge.net/projects/doyencd>
* You can see the discussions with Boyer&Moore and Chandy&Misra on
  the subject of proving Axiom correct.
* You can see the discussion with Artimov on using HOL Theorem provers.
* You can see the goal of training axiom internal developers and setting
  up a CVS on tenkan.org.
* You can see work to support French computer algebra (OSCAS)
* You can see the effort to set up savannah as a public website.
* You can see the Rosetta effort, which collected about 100 computer
  algebra systems and distributed them on the Rosetta CD set.
* You can see the axiom-website and its death (tombstoning) for the wiki.
* You can see my efforts to generate funding.
* You can see the instructions for anyone to modify Axiom
  <http://arch.axiom-developer.org/index.html>
* You can see instructions on how to submit patches
  <http://axiom.axiom-developer.org/axiom-website/faq.html>


What you don't see is that a lot of these items were generated by 
discussions with people in the community at the time.

Mike Dewar was vital in releasing Axiom.
Arthur Norman released and helped with CCL.
Tim Daly, Jr. set up the Tenkan site.
Camm Maguire was instrumental in re-use of GCL.
Barry Trager contributed his PhD thesis.
Manuel Bronstein contributed his thesis and supported Axiom at ISSAC.
Tom Lord helped with Arch and gave a lecture in my course at CCNY.
Bill Page suggested and implemented a wiki.
Carlo Traverso worked with me on LiveJournal/LiterateJournal.
David Mentre suggested noweb.
Federic Lehobey suggested OSCAS.
William Sit participated in NSF grant funding.
Joris Van der Hoeven suggested TeXmacs and the savannah website.
Gilbert Baumslag supported the literate Magnus and Axiom work.
Emil Volcheck was supportive of ACM related activities.
William Walster worked with me on interval analysis.
etc.

All of this work existed about 3 years ago.
When the wiki was started this list was no longer maintained.

To suggest that this is "Tim's project" and that I set all the goals
is to rewrite history in a very negative way. It minimizes the efforts
and contributions of a large number of people, all named (or intended
to be named) in the list of Axiom credits.

\start
Date: Thu, 26 Jul 2007 07:26:37 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Fricas

--- Tim Daly wrote:

> To suggest that this is "Tim's project" and that I set all the goals
> is to rewrite history in a very negative way. It minimizes the
> efforts and contributions of a large number of people, all named (or
> intended to be named) in the list of Axiom credits.

My apologies - that wasn't what I ment to imply.  My main goal was to
put forth the question:

"Are the some goals of the Axiom project considered as defining, and
without which the project would cease to be Axiom?"

I.e. goals such that a development direction not pursuing them would by
definition be a project other than Axiom?

\start
Date: Thu, 26 Jul 2007 12:49:06 -0400
From: Bill Page
To: Tim Daly
Subject: Re: Fricas

On 7/26/07, Tim Daly wrote:
>
> > But you are paying the bills for the entire axiom-developer.org server
> > so I have complied with your request. To me this clearly demonstrates
> > that an open source project (like Axiom used to be) should *never*
> > allow themselves to get into a situation where significant project
> > resources are controlled by only one individual. Never - even if you
> > once strongly believed in that person's good intentions.
>
> I don't believe *I* mentioned anything about the axiom-developer server.

??? The Axiom Wiki runs on the axiom-developer server.

> I don't believe *I* "forced" you to remove your changes BECAUSE *I*
> "control" the server. You have root access on the server and you have
> never needed to ask my permission. If you removed your changes for
> the stated reasons you have misconstrued my statements.
>

Tim,

On Jul 25, 2007 11:46 PM you wrote:

> I see that you've decided to update the pages
> <http://wiki.axiomm-developer.org/AxiomCommunity>
> to include the fricas project. We discussed this issue previously
> on the mailing list.
> ...
> I strongly object to the dilution of the Axiom name and resources
> implied by your action. A fork implies the decision NOT to share
> resources. Please do NOT promote Fricas as Axiom in any forum.
> They are two entirely separate projects.
>
> We clearly disagree on this point.
>
> Until we have a mechanism for voting in place, and a vote is taken
> that results in community discussion and agreement that Fricas
> should be promoted as you have done,
> I ask you to remove your edits.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Tim
--------

You did not force me, you asked me. I complied. But it made me very
angry. The Axiom Wiki is a public wikiwiki website. That means
*anybody* in the world can edit and change pages any time they want.
Instead you asked *me* to remove *my* changes. That is what really
made me mad. If you objected to what I wrote, why didn't *you* change
it?

The fact that that you personally pay for the axiom-developer.org
server (about $250 per month, now I think!) where the Axiom Wiki runs
makes me feel that I am compelled to do what you ask even if I
disagree.

> It is not clear how you can be shocked about the request to remove updates.
> We specifically had this discussion on the mailing list.
> <http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00121.html>
> <http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00123.html>
> <http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00146.html>
>

Editorial policy on a public wiki is a tricky business (as I am sure
most people well understand from the fantastic success and serious
tribulations of the wikipedia project). I am shocked that you want to
exercise editorial control over the Axiom Wiki site but are not
prepared to  use it yourself.

>
> My objections are stated in terms of the resources of the Axiom project,
>   * the goals of the Axiom project
>   * the Axiom trademark
>   * the history of the project
>   * the goodwill associate with the Axiom name
>   * the savannah project site
>   * the sourceforge project site
>   * the Axiom mailing lists
>   * the publications such as the Axiom books, thesis work, etc
>   * the work associated with the source code and documentation
>   * the public presentation of "Axiom"
>   * and, yes, the wiki server
>

Do you mean your "objections" to my edits? I do not understand how my
edits affect the resources of the Axiom project. From my point of view
FriCAS itself is a resource from the point of view the Axiom project.
If for whatever reason we can't work together with Waldek in the Axiom
project then at least Axiom still has access to his skills and the
work of some other people through FriCAS. It is not the ideal
situation but it is not a net loss. (I think at least Clifford Yapp
agrees with me on this.) Devoting a little of the Axiom project's
resources to track what is happening in FriCAS just seems very
sensible to me.

Your mention of trademark, history and goodwill just seems silly to
me. Trademark is a non-issue. This is not a commercial enterprise and
no one to my knowledge (except perhaps NAG 10 years ago) has attempted
to register such a mark. History is what we make of it. Most important
is that the contributions of other people continue to be recognized.
And although it is wearing a little thin, goodwill still exists here,
I think.

Because of *your* insistence FriCAS has it's own SourceForge project
site (instead of continuing as the wh-sandbox branch in the Axiom
project). FriCAS also has it's own email list hosted by Google. I
thought Axiom users might want to have this information available to
them along side the lists of Axiom and Aldor email lists on the
AxiomCommunity page. But you asked me to remove these edits.

I plan to give a public presentation (Software exhibit) on Axiom at
the upcoming ISSAC 2007 conference. (See attached abstract.) And I
have also arranged with the conference organizers to have a meeting
specifically about Axiom on Monday evening 7:30 PM. Are you going to
say if I happen to mention FriCAS once or twice that I am somehow
mis-using Axiom "resources, history, goodwill", etc. ?

> If someone writes algebra that only works in FriCAS and not in Axiom
> but says that it is "Axiom algebra", could someone be confused?
>

No. This can be easily explained to any beginning user of Axiom and
FriCAS - especially if no one closes their eyes about what is
happening in the FriCAS project. Are you confused about algebra that
only works in Aldor but not Aldor in Axiom? Right now FriCAS is
identical to Axiom in the algebra code that it runs. But FriCAS has
solved some problems with the algebra bootstrap that have not been
solved yet in Axiom. So the potential certainly exists for new algebra
code to be written that can not (yet) be compiled in Axiom. (We have
been discussing that in another thread on MonoidRing.) As far as I
know it is the intention of everyone involved that Axiom will
eventually be able to compile this code.

> If a paper appears at ISSAC next year stating it was done on Axiom
> but was done on FriCAS and won't work on Axiom what can we say?
> Could someone be confused?
>

I don't think so. All it takes is one sentence of explanation.

> If a CD appears in public with the label "Axiom" but contains the
> code from the FriCAS project and the person finds bugs should he
> post them to the Axiom mailing list? Could someone be confused?
>

Well, I think *most* people would like to continue to use the name
Axiom generically to refer to computer algebra systems that have
evolved from the IBM ScratchPad project. I don't think there is much
room for confusion here - certainly not more than already exists. It
would be very easy to include both FriCAS and Aldor as categories in
the IssueTracker system on the Axiom Wiki.

> If the code from FriCAS appears in public with the label Axiom
> but contains only source code and no pamphlet files, could a
> person be confused if they think the Axiom goal of literate
> programming is gone?
>

No. The respective goals have been clearly stated by both you and
Waldek. If a disk is mislabelled as Axiom when it is really
FriCAS-specific then that is just a clerical error.

> If someone demonstrates FriCAS and it has abilities that don't
> work in Axiom could someone be confused?
>

That is easily explained and one very good reason why I think FriCAS
should continued to be discussed in the Axiom email lists and on the
Axiom wiki. To do otherwise is just to invite the type of confusion to
which you refer.

>
> FriCAS is capable of developing its own resources.
> That's what a fork is.
>

A fork is a failure to communicate (which also happens to be the cause
of most wars :-(

\start
Date: Thu, 26 Jul 2007 12:54:39 -0400
From: Bill Page
To: Tim Daly
Subject: Re: Fricas

------=_Part_150548_24245255.1185468879658

On 7/26/07, I wrote:
> ...
> I plan to give a public presentation (Software exhibit) on Axiom at
> the upcoming ISSAC 2007 conference. (See attached abstract.) And I
> have also arranged with the conference organizers to have a meeting
> specifically about Axiom on Monday evening 7:30 PM. Are you going to
> say if I happen to mention FriCAS once or twice that I am somehow
> mis-using Axiom "resources, history, goodwill", etc. ?
> ...

Here's the attached PDF file containing the abstract that was accepted
by the ISSAC organizers.

The Axiom meeting announcement is here:

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

Regards,
Bill Page.

------=_Part_150548_24245255.1185468879658

JVBERi0xLjQKJcfsj6IKOSAwIG9iago8PC9MZW5ndGggMTAgMCBSL0ZpbHRlciAvRmxhdGVEZWNv
ZGU+PgpzdHJlYW0KeJztXElzHceRnjPCP+KFT+9N8DVrX+Yyoy1s2pYti4zRTEg6cBNIcwFNEqIY
8+f9ZS1dWd3VAAE93SYYQTS6u6qysnL5cmn8cycmuRP0r/x8/Ors7rdS7s7fnaXbO7n783z14uyf
Z7L8Isrru88f0Ai1k2bSxqndg5/OZHlfWjuZnXNuUmb34NXZ9/vPDkc9OSu03P9PujTRuP29g5i8
VTKY/d9wKYII2uj913jD6UkJt/8/XHosoGR5Q7pg1f4NbtspCKH2Tw96Elhq/5peDZM3an//cFQg
SjqzvzioSXiDxS7bzbeHo5is0yr4/ePDUU7Ba2cxFdY1U8QbXxzkJHUwsUygvNu/AgHOCxMjrV/n
YtO+x6vWGGkLURiNlXSwk9a6sMAEt39JT6WSZn8+T55G+P2jFZHSYsRDPJU+RPnjgz+dSeWmYHZH
GXYPnoC3bLcfaYzUyuuwfwdyjfLS2BVhrmzGBR89TYmDNLuInStn6CCPcfIyRrU7ajNZG8tK32F0
tETuczo5o3AUL9OViV6WS7r5vN18eDjipKLE4q/AAaWmiA3dB39NsMLsJ9zUbrJC7r85yEBCoMqg
gOM5b8Of0kkppYIuJLtdAMlOh0SynoKOxBclMFTITPJnNN465cP+l8MRAhm8sKDPTEYHRfKB0ym0
GawO6fnycMSmozYGSyqw02AbPx8wLTbk2L2Xq1lILkFjsJa99hbMwPaEMIXusLNT9N4mul1MdO90
4Xii+j9JVqxUxtdLZ10erUS3a+mhati0AckYP28a00UPnj4Co52UUUMewD5HAyEPdpJGEWkOdGeG
iwmHL6WDRuCUHahp7035PJyPI9aDbw56f1N+K+cnL8L+WeK30DaCDHrqvSJqVQTfbCCdIKa6qBhT
2xX0Xnn8guFtGboJvbNW75+06fMgDxOTjxMbuu44aagIpC9gkLAxCuW6xSHQ4JsHr7ChiDlBOkQx
aszd0VOJeIwT8SYIWhp7hOrCzsmyYpwZ4MsdOd8hTRF60p5sIdkSheNi0sWWOy+DhwQ8LA/Tfo12
ke38I60B3cXEjc5uQHqtDU2swC48+EyycUzCcJRyEjo2A0VrK6XLpK5oBUypM6rM77QjJsIYSwWR
eXxQYbJa6iofNPxNu2yDnpDZhng6DYcC8ierwIx7SQesCXJ/h7yFm6LQjCHvyV3A7li3/3DQsEo6
6Hmn7+ghzMivlZ61MZiJJdUk2fEqJq5DGRzeZGR/jnmUsnATX+cNKHD5stHzuknnispsdzArNmFC
5asGs5/xVzFtJJPKJ2gsYqLVZk0naIWPfNK1fidvjLllnG/9lAREWY8DqubiW7IROIco2Rz56CWO
dmUaLCcqEW1ikMmwHsvMRymmqITOC/wJFk4q7+tROcjz6yZFL7KNCkYWtcVi++8rJTTtVw/O/n5G
oEbsvv1DuXh7vg2IOss4A6JArmVnIZyiICJZ5ZctcgPcNV4G1sSrbpkfZ65OZCfdBC15QDwJpA69
MMBoQw1k1TK6y7h9cSDdVtKp/T8wAV04phPNXJAlDApy51f+00HULlbWpD3r9CRbdYkBUE8RMSS/
6Dt5fEurgUhI+UMywbCnLlTd633G0FRiWwpYxIqkRclpOMlkFrewa632qtwSRJmFibTQ2zU9zYWx
5cibeQ8IZ7mJSbeA2h6WGcHFoco1h7JcplOHpDaAKOlY60beZKUzmN7JqnXNfNdpmC4fyYPrIHTR
KgIYQFNJrWaE8VOSgBBD4RTZYWbR4S0N4gLQvPFmekw7Oo13Hvo5QEcdsbiQ/G5b5QM9h4mN3E8O
LWkHS3SEmcF2+jWFI0jPtOBiHtNBB6Zbl41+xv7BiQytax3anDN4Sog/9As22recQN1lGealj+Fq
Mtou3xXxihSRFOmaCiWQ7Psj2MNEdrBK8fucxCyR3sQskHmxHmJ8c4DNU40fBRcYGacm5nQzi5EL
gdl7smwUl9ihPrDLFeXE1qZ2LwbmgIgQgPvBXuGEY6QQupMoggYBKIwNGhqykZV4Txt3k2cMXmCF
K6Q1L22s39h4I/LRdaK8Kbc0pGgS4ltubOkcEJ+SSTQiTtY7pvgDm3c+0/20SCKUcw5GXs8Ii8Gm
VwdFvLF+HFiQbRIQLe4DigUr4pdW6M1hVh2HyNyM0SzDsA2HXDtqpHHPV+xgZwumGo2oysStkyeF
CO4EdqrnWLLmlsngiOCNsGktLp0o18e0N4VlYjuZMWWj+Ksz65iHQKEeCd4G/raUVYHIkG1TlGng
L76uhobozRgXkfZsD0fKHhcRX/mJwMUAYFSEUPdxhwPSY5m9x7lbsnZUOsD12xMFYbQJ5nerkBFy
IpCGAOUE4BGhjoh+HJYpK1IEPDSBA7c4iNtpQSIYmMhgZ0xyCAuCTACCG6Qxms+8Q1xwwJJ2Q/to
SZ3UtJ7sGgxXyoRaUqZBkb/CjeSTNvu/Fhk0UwhVBjv7N8xkDE38FTmAIoppkd4XF95Jw0FbzUgM
4WIXlQ/EmBtK8hsI9IjJfwAbQbrTvaStbEPKFiu8uv9h35j313bEnx0QAsjoDZvyh0NOTMJJ9VCv
TPUVvQk3G3rIuTzOh8yxzq89qbMECPkgFrvI8b6wW1CO7ffFACsPzXRd1MpFFgR4yrs+92EMpdrJ
Cyc6tFk5jEqas9oEvS1USRQRQqhZFPNMCNQyGV0YspCuPK53tQ22fWyK2W4yAVoh20wdmXCngciq
BJCgcgmACw24duxsVgK60L4nTdiGhukDrQmPp25iWCDiOAVd8AcZzJWYF7cNJzQFK7dNg9HAUnBk
txYnoFoEwcugx2JWa3g2sjPkzXjVhQrisghSevxgqczAY2z2MzlFSTRQmYDjniRcwVCyowjXMiWU
H/YS1Dzd+cgYLXPMhNTmrJ3iAkZqatTkelc3ClnHoWSL6nMeLheJPrlcoQ1ggBzp7VBimvNj6609
UYvX3x8AtyJ4v3bEw2nv5KSpQmx1wywlRM4FyZ1mtVRX5lLre0OPejlUycdzvBpbOoT4AZcbtGFH
1oxTM1grpJEDmXV2ZurtWFkuuUk49rxqysLBuPCMKx1rgPEJnlehltFrTdRD62lP3KmRxQ5q8p3Z
uBgp+qbFxgQIyyAby+A9JX0/KXgHDGT2J8Xm2GnkcDElh83p8+uMfkZfyvRrfx26Tz4/4LCUGh4r
2+kCXpBx0I6zfx1A0eWj2T51KCt7SVEF8jqpL7MVJyk2PWQDW5cNTDFT1wIB8hFRE4jj8O2Xlh0f
eyhKn9kTQP7K1dNn3gmhWrUz4GPJiBcfc8K0uyJjypf4kVgjEqrqHSZiPwfTfgKHCd1XsNG9w6QR
1XUqHKPQdDyfAGMKXZR1gfiT4o3PtLNU62Qhe/MjTQVLJtwC+pfYKDn1l0SjmaRxi1inUrFaL5ur
RYo6Yn8k/b0avBmKfC4mUH8ELybAmcKPmLgdRtcXmL0qlQPneHKT2YUrS8aUlLpZ1rfEEMnjOcVz
F9pgdS1vAx7GiHGIM5kVa1m3ZzRVBOjw2+Azs46zgFE3DFW6jNY6mVN6MUzkB3M59sjz84s5KrYy
VkNLzLM2CeDI8y+JS3XupQdMkjx6c46QacHe92/J5pXAdJjS4KHxRhWkntVvYFwlOfEdZWpNMX36
9NZVJQzPF7lRUdOSVIX974bi3WUaU/9GdJ8AnxX8vb0OirxuJcxPh6e8N4QWMRtFz8EOhun22hrD
C5oOVsvcplMnBwJ9zFGLmDeMgOwSYJUeki58c4KKMssMwLDLR80aIxZXtsgk3ZlbaHg69PlcEmJ2
Z9Wlo8KWtewqbEmG+mLbhhOb541XpPROV5GnSqiz281WdIz6lgWwAYTpK/kxpECSFbrb6W/kJLLo
2NRhmA/NbVacaom75TuvUZqPRAj1MrZE8XAXK5/D+/9KbGdzBpRL6NB8D8F4TU0Gz54zl3768Ij3
JKR8gVf7cba6JDoftixHRXKdDCY8ZeUQZi6q8ZRLNOrKslwwm2U5wiwiDJHPhvOvDBuayy5GnxPY
fzl78O88Nn+2tBO5PgViKGcRxqBmOIgJb59/pdLzqp9gVTVvB3zZndI6o1Kpi+noFFy0C4Mq6huu
QYvQI0uPstiiPXWtkLI9HYoaJ4tej9jFnpM8ydSUyre53bJWbHkVia7MrRVCX8T8Y6tRrYuc68pZ
iKLcanwriJgLqgowYLPTFRCSIi9G61XLTV6sL/Bt1p7yGVDtiTIXYU5yKBHKLsmIDvPizDoxznb5
jlqM68xkygQtudr3INT+XXCV56faLgiIeDOFlKhpDV7G4xx1M0ltwFqCHzWaR0CDsjm1EW1RSitO
aNvvEvSSN0rHVoz0Hc0pYd14P8cLPrgi1pZWbTSzLS2BXT7FJIyaFLNlL6tMnx7gU+uKdjtKb7mC
vc3JAT41CwHg80UawL9T2KVWNdVSd0kAF275i2SyqcOuZE4Fz7EXvXJYfeGrWw6sOeBiHDzXmpaE
XeHF3s6zm9XnQRZuEZufIjc/N/iOs8G5QRgrfELFgIBOzt2u7fKwYeOqpiEScGb3P7XZ7fuqCSeT
cAr/Ff431DibZM+eXMDpDIAR+SI8gmVKmz+okgCmNn1QdVTwwZI+w8lft8xN00BCWqeGWTlpRE5k
TwmtORHLPVl6YyelnTTsJoR7cp66bcunT8YF9vgdHboormi5I7hH5aPfHQmzzCo0tzKn70QsNbKb
WzVe36FKIIQGSlIaw4NiQK3MGWGYaxGXJR8XhSboOnWQ378Om1ys1aaQ4XDJ+tOn2QrfbxNNhWK4
3R9+KDOtfXxTdRrel24p/SQUfehmqBC/mccw9DWd26jKtMk3EM5au37H50kF4gDA/cW8+rDDZVzU
6PKYuZQBEZ57/JfLp9QaV25PFszznX1s2GhoWlrGoANBv2+qe6SkvK9J4RlFsbB/nIMbGvcWzw0j
qQLfSHv++wBM43XciDvXGOa8YlfHG1L6JmUKcqLb/2+aG/o1ktkX9B5sed/jsv6sqLabqflOKno5
+r6wa2pjQp5LZSr3zNAqEoTV5ErDriXPQnOG8tCvX1p/4RTmO8X0zj/ZsLnAkQ5X0vHjTPvGIzWy
Q9fWUSkPEI1P5WsqVBq7VZrt0Hb6okjfUuvTp4Yy3FzdrgysgJ1N6BJ7y/6r3Ci7AJuLrFKN991I
I1uzzUgj123kTCOZuxbJmearbWeqwvAbF0f5xh0hdBGyM31GH7WamCwRrqyINl+le2/me/8x37vb
X6Wn7+Z7D+ernwf3XvdXVmnJnjZapsGIi3lEu3c+eO+ynyWNuJjvvR2MvbvYL414y9YlM4iAfv+P
+d7T+erxPOJ9fk+6yNhxt2dCevGX+d7zeepG4Kt6dcpvm6gbyqR6Ll5gtYaFvv85mbAgnF/nmciW
jyt8d3K4StrLDEZXeOvTpouWTQ2LpGVkXYENLjDDMluLv6QPtZVVy268K5v9B8lZQuYygjOe+izK
2oN2yEHq7iG3SMuKUvllI/WS5/p9zQxKZsiuafJep4Kk2wxOUqZou64oKAyGkcqFvRSpriEHwymt
ujB/5ypcl6Whb5YAp/jpdPAyD677v1wLRX20TBJrqpP1NcDmjRjSeFKzR65P48wvLD+nsovPrpap
9E8qKVP3Ci5/nfdvjl0vvH9rTqh3GlJgE1TQINdzGyIyTgbRzf0N3DnQ1DGv2sejtQe3Ce9ndYfu
VjCqvL+AKDzbYEYma/Tx0ghyNtQxTDK9HFw1/LGh7QMks4pAclIwpRJkDLdJZXxCUkxDRyxsxXcH
j2Vsl9G+Niu2MC8EnH875KGoqnJK5PGBOdN69WJwb7rGEXcoo3fESZkot61J8tcQ4Od5wnbv5WDC
N/3YBcyY2IiECrRWI7TyG8ACrFb/1oy9WseGXyAM0+NdYiJpiVQsr9FsaN9wUhJlQxjeTNKwUtF1
F9XZ58WZjrIcZ67A0SZGnyMzt/2baYSkT5rU/2vEr9CIsnca/OUAtX8cEDhHHyttwjHuLP09ifQ7
zj/sZA4O8TN6ykU+fnX2+b2zu/e+3r1/e/n07O53O3l294/03+fffIEf977c/dvZV/d2XEU3FbP7
ezazbGhN30lKTQWYLBvlT9lQX3e7HKUZgZNk6vvo/ijOo1HLxsjpTfPT4d8LGbnW/8odmeSAGNhq
mcsPc0ag6ToLiUudTW//pY3qlkb+K99zOrKgYdizfb7Q4L+f/QtAUssEZW5kc3RyZWFtCmVuZG9i
agoxMCAwIG9iago0NjQ3CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAw
IDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE
RiAvSW1hZ2VCIC9UZXh0XQovRXh0R1N0YXRlIDMyIDAgUgovRm9udCAzMyAwIFIKPj4KL0Fubm90
c1syMiAwIFIKMjMgMCBSCjI0IDAgUgoyNSAwIFIKMjYgMCBSCjI3IDAgUgozMCAwIFIKMzEgMCBS
XS9Db250ZW50cyA5IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMg
Wwo0IDAgUgpdIC9Db3VudCAxCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Db3VudCAyIC9GaXJzdCA3
IDAgUiAvTGFzdCA4IDAgUiA+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdl
cyAzIDAgUgovT3V0bGluZXMgNiAwIFIKL0Rlc3RzIDUgMCBSCi9PcGVuQWN0aW9uIFs0IDAgUiAv
Rml0SF0KL1BhZ2VNb2RlL1VzZU91dGxpbmVzCi9NZXRhZGF0YSA0MyAwIFIKPj4KZW5kb2JqCjcg
MCBvYmoKPDwgL1RpdGxlKEFYSU9NIC0tIE9wZW4gU291cmNlIENvbXB1dGVyIEFsZ2VicmEgU3lz
dGVtKQovRGVzdC9jaGFwdGVyLjEKL1BhcmVudCA2IDAgUgovTmV4dCA4IDAgUgo+PgplbmRvYmoK
MTEgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUKL09QTSAxPj5lbmRvYmoKMjIgMCBvYmoKPDwvVHlw
ZS9Bbm5vdAovQyBbMCAxIDBdCi9IL0kKL0JvcmRlciBbMCAwIDBdCi9SZWN0IFsxODcuMDQ0IDUy
OS4wNDQgMTkzLjcxNiA1MzYuNzk2XQovRGVzdC9jaXRlLkpTMQovU3VidHlwZS9MaW5rPj5lbmRv
YmoKMjMgMCBvYmoKPDwvVHlwZS9Bbm5vdAovQyBbMCAxIDBdCi9IL0kKL0JvcmRlciBbMCAwIDBd
Ci9SZWN0IFsyNTMuNTI0IDQzMC40MDQgMjYwLjE5NiA0MzguMTU2XQovRGVzdC9jaXRlLlREMQov
U3VidHlwZS9MaW5rPj5lbmRvYmoKMjQgMCBvYmoKPDwvVHlwZS9Bbm5vdAovQyBbMCAxIDBdCi9I
L0kKL0JvcmRlciBbMCAwIDBdCi9SZWN0IFsyMTguMjQ0IDQwOC40NDQgMjI1LjAzNiA0MTYuMzE2
XQovRGVzdC9jaXRlLkRLMQovU3VidHlwZS9MaW5rPj5lbmRvYmoKMjUgMCBvYmoKPDwvVHlwZS9B
bm5vdAovQyBbMCAxIDBdCi9IL0kKL0JvcmRlciBbMCAwIDBdCi9SZWN0IFs0MDQuMzY0IDM2NC42
NDQgNDExLjAzNiAzNzIuMzk2XQovRGVzdC9jaXRlLldTUDEKL1N1YnR5cGUvTGluaz4+ZW5kb2Jq
CjI2IDAgb2JqCjw8L1R5cGUvQW5ub3QKL0MgWzAgMSAwXQovSC9JCi9Cb3JkZXIgWzAgMCAwXQov
UmVjdCBbMzU0LjIwNCAzNTMuNzI0IDM2MC44NzYgMzYxLjQ3Nl0KL0Rlc3QvY2l0ZS5BUDEKL1N1
YnR5cGUvTGluaz4+ZW5kb2JqCjI3IDAgb2JqCjw8L1R5cGUvQW5ub3QKL0gvSQovQm9yZGVyIFsw
IDAgMF0KL0MgWzAgMSAxXQovUmVjdCBbMTY2LjE2NCAyNjIuMDQ0IDM2MS4xMTYgMjcyLjMxNl0K
L0E8PC9VUkkoaHR0cDovL3NhdmFubmFoLm5vbmdudS5vcmcvcHJvamVjdHMvYXhpb20pCi9TL1VS
ST4+Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagozMCAwIG9iago8PC9UeXBlL0Fubm90Ci9IL0kKL0Jv
cmRlciBbMCAwIDBdCi9DIFswIDEgMV0KL1JlY3QgWzE2Ni4xNjQgMjE4LjI0NCAzMTQuNTU2IDIy
OC4zOTZdCi9BPDwvVVJJKGh0dHA6Ly93aWtpLmF4aW9tLWRldmVsb3Blci5vcmcpCi9TL1VSST4+
Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagozMSAwIG9iago8PC9UeXBlL0Fubm90Ci9IL0kKL0JvcmRl
ciBbMCAwIDBdCi9DIFswIDEgMV0KL1JlY3QgWzE2Ni4xNjQgMTk2LjI4NCAzNDIuNzU2IDIwNi41
NTZdCi9BPDwvVVJJKGh0dHA6Ly93aWtpLmF4aW9tLWRldmVsb3Blci5vcmcvRG95ZW4pCi9TL1VS
ST4+Ci9TdWJ0eXBlL0xpbms+PmVuZG9iagozMiAwIG9iago8PC9SMTEKMTEgMCBSPj4KZW5kb2Jq
CjMzIDAgb2JqCjw8L1IyOAoyOCAwIFIvUjIwCjIwIDAgUi9SMTgKMTggMCBSL1IxNgoxNiAwIFIv
UjE0CjE0IDAgUi9SMTIKMTIgMCBSPj4KZW5kb2JqCjI4IDAgb2JqCjw8L0Jhc2VGb250L1lTSExL
VCtDTVRUOS9Gb250RGVzY3JpcHRvciAyOSAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgNDUvTGFz
dENoYXIgMTIxL1dpZHRoc1sgNTI1IDUyNSA1MjUKMCAwIDAgMCAwIDAgMCAwIDAgMCA1MjUgMCAw
IDAgMCAwCjAgMCAwIDAgNTI1IDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwCjAgNTI1IDAgNTI1IDUyNSA1MjUgMCA1MjUgNTI1IDUyNSA1MjUgNTI1
IDUyNSA1MjUgNTI1IDUyNQo1MjUgMCA1MjUgNTI1IDUyNSA1MjUgNTI1IDUyNSA1MjUgNTI1XQov
RW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMjAgMCBvYmoK
PDwvQmFzZUZvbnQvSUVTU1NPK0NNQlg5L0ZvbnREZXNjcmlwdG9yIDIxIDAgUi9UeXBlL0ZvbnQK
L0ZpcnN0Q2hhciA0Ni9MYXN0Q2hhciAxMTYvV2lkdGhzWyAzMjkgMAowIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwCjAgODkzIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgNTc1IDY1NyA1MjYgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAKMCAwIDQ4OCA0NjcgNDYwXQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5cGUv
VHlwZTE+PgplbmRvYmoKMTggMCBvYmoKPDwvQmFzZUZvbnQvRUFOUFhGK0NNTUk2L0ZvbnREZXNj
cmlwdG9yIDE5IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciA2My9MYXN0Q2hhciA2My9XaWR0aHNb
IDYzOV0KL0VuY29kaW5nIDQwIDAgUi9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjQwIDAgb2JqCjw8
L1R5cGUvRW5jb2RpbmcvQmFzZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJlbmNlc1sK
NjMvc3Rhcl0+PgplbmRvYmoKMTYgMCBvYmoKPDwvQmFzZUZvbnQvSkpRR1hSK0NNUjkvRm9udERl
c2NyaXB0b3IgMTcgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDEyL0xhc3RDaGFyIDEyMy9XaWR0
aHNbIDU3MSAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCA1MTQgMCAw
IDAgMCAwIDQwMCA0MDAgMCAwIDI4NSAzNDMgMjg1IDAKNTE0IDUxNCA1MTQgNTE0IDUxNCA1MTQg
MCA1MTQgNTE0IDUxNCAwIDAgMCAwIDAgMAo3OTkgNzcxIDcyOCA3NDIgNzg1IDY5OSAwIDgwNiAw
IDM3MSA1MjggNzk5IDY0MiA5NDIgNzcxIDc5OQo2OTkgMCA3NTYgNTcxIDc0MiAwIDc3MSAxMDU2
IDAgNzcxIDAgMjg1IDUxNCAyODUgMCAwCjAgNTE0IDU3MSA0NTcgNTcxIDQ1NyAzMTQgNTE0IDU3
MSAyODUgMzE0IDU0MiAyODUgODU2IDU3MSA1MTQKNTcxIDAgNDAyIDQwNSA0MDAgNTcxIDU0MiA3
NDIgNTQyIDU0MiAwIDUxNF0KL0VuY29kaW5nIDQxIDAgUi9TdWJ0eXBlL1R5cGUxPj4KZW5kb2Jq
CjQxIDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvQmFzZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9E
aWZmZXJlbmNlc1sKMTIvZmkKMzQvcXVvdGVkYmxyaWdodAo5Mi9xdW90ZWRibGxlZnQKMTIzL2Vu
ZGFzaF0+PgplbmRvYmoKMTQgMCBvYmoKPDwvQmFzZUZvbnQvR1NDSlBJK0NNUjEwL0ZvbnREZXNj
cmlwdG9yIDE1IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciA0Ni9MYXN0Q2hhciAxMDkvV2lkdGhz
WyAyNzggMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAKNjgxIDAgMCA1NTYgMCAwIDAgMTAyOCAwIDAgMCAwIDAgMCAwIDAKMCA1
MDAgMCAwIDAgNDQ0IDAgNTAwIDAgMjc4IDAgMCAyNzggODMzXQovRW5jb2RpbmcvV2luQW5zaUVu
Y29kaW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTIgMCBvYmoKPDwvQmFzZUZvbnQvVkJXU1BS
K0NNQlgxMi9Gb250RGVzY3JpcHRvciAxMyAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgNjUvTGFz
dENoYXIgMTIzL1dpZHRoc1sgODUwIDAgODEzIDAgMCAwIDAgMCA0MTkgMCAwIDAgMTA2NyAwIDg0
NQowIDAgODM5IDYyNSAwIDAgMCAwIDg1MCAwIDAgMCAwIDAgMCAwCjAgNTQ3IDYyNSA1MDAgMCA1
MTMgMzQ0IDU2MyAwIDAgMCAwIDMxMyA5MzggNjI1IDU2Mwo2MjUgMCA0NTkgNDQ0IDQzOCA2MjUg
MCAwIDAgNTk0IDAgNTYzXQovRW5jb2RpbmcgNDIgMCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoK
NDIgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Rp
ZmZlcmVuY2VzWwoxMjMvZW5kYXNoXT4+CmVuZG9iagoyOSAwIG9iago8PC9UeXBlL0ZvbnREZXNj
cmlwdG9yL0ZvbnROYW1lL1lTSExLVCtDTVRUOS9Gb250QkJveFstNiAtMjI4IDUyNCA2OTRdL0Zs
YWdzIDUKL0FzY2VudCA2OTQKL0NhcEhlaWdodCA2OTQKL0Rlc2NlbnQgLTIyOAovSXRhbGljQW5n
bGUgMAovU3RlbVYgNzgKL0F2Z1dpZHRoIDUyNQovTWF4V2lkdGggNTI1Ci9NaXNzaW5nV2lkdGgg
NTI1Ci9DaGFyU2V0KC9EL2EvYy9jb2xvbi9kL2UvZy9oL2h5cGhlbi9pL2ovay9sL20vbi9vL3Av
cGVyaW9kL3Ivcy9zbGFzaC90L3Uvdi93L3gveSkvRm9udEZpbGUzIDM0IDAgUj4+CmVuZG9iagoz
NCAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL1N1YnR5cGUvVHlwZTFDL0xlbmd0aCAyMzMx
Pj5zdHJlYW0KeJytVnlwU+UWv7dJbi5tgbpcnojeWwUcZHtFVBbfIC2LCpQCWmQp0BoSkrYkbRa6
JC2lrdT2pCulpeneQlJTlkKhwrBZkVZpHoISWdRxQHHhKc+Ho+c6H2/m3bSlico/zryZ/JFv8n3n
/H6/8zvnhKbkQRRN08y86Ndem+X79pQ4hhYfCxIfl71J0sWm3xYpIFQGofK3Hwsd/yDmPoCLR+LU
MEpG0wsXr5lnSMkw6jZpzeET5j0dPm3WrBnhkZvVRp0qQR8enWDWqjcnmKVDcvirBpVObc6YGh6Z
nBy+wvfCFL5CbVIbt6g39qeeZ9icYjGrjeHRho1qo56iqDEZepVhY4p6vnGTSWvWWRK3JKUlJ6Rv
njJ19t8pag0VQ82nllELqOXUQmo89Sr1MvUa9QoVSy2iVlKLqdepJdQqKpqKolZTS6kR1EhqDBVG
PSaRpeSUm36UttBHg8YG7Qy6LYuUNcjXy+8otIoehmfymV+UK5RXWB3bPuzJYc7gecHa4MLgM8FE
bB4hNpM0j7jbQ3d5ZeJcMYirAxeUFe8orqmAZrbdAJk8YZhMAyRll2c5CoSyQifUQrY6bal1leG5
HN32NLaIyW9LO5160dyb7zD1OWA3lBfvKquoAgfbngIZvvdWPSSlV+dWviW9b4N6wMfJz4/YC0u3
QhEUmf9h01tU+hxjYUXDI4X7jTszgDVkpKeo3PGnL3Z/eL1NkFCCB3s89PdeXCbhjMKj3O01R2fF
rctMVPOuoro3+BeZLAljohMcwjuke4P/hM8zNS5o35sCNmEDRjI/Xt5/4kSNaRlPTEnKLAlXost3
a2LALUbKt92D5z30x15M/k4mapDmmmyVluwssOTy+bbMhAXAPr/wwo1T7l/x4bqaIigVGgvtRfbc
Ep1zWy2wzsZG56fjIY5ELiVjppMRP07AkTjWfdshDIV+z4sNEhUdJnMYNuU2URDFlAkkjITdmohy
lN/6AcN4oiIRXFTMpZtf93144eK56GemxURFDYbo82CQh97nRbtPEPGf3N68St3vZZjMWBpULSuB
JbJJk8gDZOTNiUgd7ao7cEBIhswj/OVAzpE4iotdP3vuwmUf3fjac/5S78nXY3mfPYwenHxPfCkX
aomRC1A0jnFvPpTxDrAo++EWPoghz/1E5HEJmXqtcCC7TP87RHcbAwsTLGZwPT0nPrjQ89Kzzyx6
OWr+xs9P8wPkuD4c7qHfvYo7L8vE2bica2yGg8gu+hfhyIjJ40kICft5Aj6Mjx692eorTFa2VBjB
tGIx5MBymLEv7RZr7+Mavjh36H24CIfXVcxl+z0kWjz0Z17c6ZX1iMjZBqDUCk13LVuYoROqGPzb
V/gEPovPPocTyWiByO92caLlGyUyp8mjREbY5SQ0fNCW3R4aJ0q6mHEJ99P560jxJRpX/i5gW5rq
XA1bj85cscQUu1ZwK/sLROT+RJ+R7hcC0tYzNW2SrAZJViLzeZCk9+HsD0714co+2uNzfvuHMtx0
jsuDbMgrsUIB5Ph6ahfsglKoLqt02ty5bmC/9176qj3XlblHaK52FNfYy1Ob8mokOA31rU6Le6V5
w5t6jWCo11VpgZ0SGTVdsyup3iTkWrelQiokNBmKC19KeGsR2Njpv8TgQ/jgr71f4ViyBPT8GlRy
q+K7uru7uk6d6oqPjY2PXyXYyXzuJtIwU7Ug/qmnow53dbQfPlXqN/onHtzpkYmR4hOcA5xJ5u1b
89/i1Q1rIFMy5jxbhGFlp6k6T9i3xbX9jnVPwbVsWM0m67WTlqqaetL4/MaCKgOwGjCnCRFKG6S0
O2oqXDv4k9qz0CiZbnbrt4dOJLtNDkG121g2xZFQ/koVdLB72l3ffFOis9j5YoMTdgDbAS0NQ3PE
1zn3HSW4WPmnNrpr+b9Mkx7PnUYaJ3n7vWKRBi1O918i0z9nGqBF46PJvzBTaU2BxCRfvi+JjRn7
ifbj6xd6vftTIceaVphUxBeuVVl0wEZCd+uQCa/9h8ZcKbRHPMu5zC0Gg9lsMLSYXa6WFhdPYsgo
v91RQbrJiABS3X7nPYlXmH4J7qEeEkocfZ8Ro2FmzNmqmwNtbh6b/6wdKWWmnE+9sr+z7O0uvnRz
ozT62ct/0GZg/0jwj3+HEVIi5X0JxPsIpEhx9/gIjLo7gQErqFM3per0YIYseBNsdmtxkR12FB1K
rNwKrMVoTZrzb+jE8Qcx+CNBjFIO0WrCOx66VUwZWHhtjGMAj1UgwcxQDfcw44hnHHoUewLaMtjf
rm0MBpEb1ZoWaILRDdLSqz7A3qsFKqWZQPXK8AhWcBiCcsV+xuGUgqT6kkT4g+xlyGQyVoG3B8C9
4k9//K5lrf+EEX4Qaz9lrlySSjhBkWSSXNIGNQKG+sMnM0MUa8UcmRgnUXS1wt72fp8N98c8yawj
RxRFTIHTeibvbdu7BbUa2AQFNuvyHE12XIFR2uur8YjiZAD94Ux/CVrBJZwl1yvUzVILju6Ckp11
vS2f2xvtNaydKTHURZdb6mJKsg9L1W6GioP+0YsWyaCn7+0q8jwTWFELGRVwvhEg2KjBFprm+VZa
Cl5fFHEOHuCuxlwl4euegrn65ozWWnf5cd5VUg+VwF47lrhUIC8Ukkfi4Gn2xQvRP1RfhkPdfKuu
G/YCOyiH1bYFKtKFyAuc5KAtqrRNmeulkcoue2Nv54mf9mGYPWDAH0EjhzSOU3QG4Aq5J8du4eWp
C79TtA7JHOJn0slItRonbaxpChVjTR3sawwZiGMGvXAN2S8Iq0g1/eE3Xw4VM4ThVC8yvo9M3IDv
cc2A8me2rYXVb/CFpenHYiUKiXn61IK2NJD+PiUO5G+G/QLpVmotg5FvDgS2gFbA+covDx/rbNyV
Fc2TTGWufrBlP/5LVyRw2PQpfUaMkIkzsImrOggdBzWwVSDnmRw1aNQdUN2vIj5E41p8SIbXznEd
yc4kTUpyksad0t7hdLfzAxdwgf+SKPvzLfK+/H4vZzb9Zm6kz4qTZeL630K5HbVghwq2Jd2RYcpN
37adJ1f/G5Vnlf5n5o82N9jqWyvrq8r4ETlVIlaRV3cwJL1c6Qn2hvDB8gxD6DBPaKg3dDhF/Q8V
TfTxCmVuZHN0cmVhbQplbmRvYmoKMjEgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250
TmFtZS9JRVNTU08rQ01CWDkvRm9udEJCb3hbMCAtNiA4NDkgNzAwXS9GbGFncyA0Ci9Bc2NlbnQg
NzAwCi9DYXBIZWlnaHQgNzAwCi9EZXNjZW50IC02Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMjcK
L01pc3NpbmdXaWR0aCAzOTQKL0NoYXJTZXQoL0EvYS9iL2MvcGVyaW9kL3Ivcy90KS9Gb250Rmls
ZTMgMzUgMCBSPj4KZW5kb2JqCjM1IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovU3VidHlw
ZS9UeXBlMUMvTGVuZ3RoIDEwMzM+PnN0cmVhbQp4nD1Se1BUVRg/lwt77+q6orQKafeuiEYaFFOh
KDMOropJFIIFQaA8VgQWdt3ltTxyCXntx0NeAoZtDIjJLsTTQdlB8jHkTPWHwjT80VjjOKFZk3/U
d/E4Q5emac4/3zfnfN/vdRji6UEYhlHoovcnhK1UAdImRtrsIb3CQtXSo6UYL1CxoPIce966HiPX
YehafN2bsAxzKCpRZzRZzVmZp/K1gbrXtCFhYbu0Ebl6c1Z6ap42OjX/lD43NV9uDNo4Y3qWPt8a
rI0wGLSxKxMWbazeojcX6jP+BdYZc00F+XqzNtqYoTfnEUL4iHSzJT81LZgQf3KAxJFj5EOyn+jI
WqKUGROOlJEnzGHmgcd2j0usDxu6zNhNRL3Mlj0k4MatbinKwUifLr2jsfWXgVU+ZWAz0eYXv/ue
LQW7ubakrtheAnxhouJWQ2f9DIyCE+7W8m7OBFlgPH8TfX3ximKWbvUKSlQMNf4J4zABP8OI/GQH
R59JBg0qqcuLnlGolz3W/EaqrkrKq8wo+uFB3MBKNuQ1n8uQRWC3VgpFSSnGGOCpP2DA5Gw9euPG
lm/s1fa6Wrtd/MxWUwrlfNqAZXBg8MvJx1QLGfTYIaqmDF3/aBvuGXY3X5oQbg913IBGXr3MLG5e
kfj0NoMMskjQh0UT5mlgrh/5p402W3UJlPLHh4ouO509E9PxrpiDJxKOFgh2ZBR0b6VXIjfbChki
vROZyM03NsMU9MEdmJGFhXLy9nszpGpM8vmaGZ3Hs/OstEUK11yE80UVpZUVViGnK6MpG3gDfQuo
rz9uLBiqEn8q/94GsbwuCAoSjnT+midUd9sbC4E/DVUWcQtnBZujpQG6eoT+7uuGGXCA3xV8G3D7
dJ7TekFMGck5F96Z1PpeO0zys4vQg55NMaYGob68C9qB76s/1yvKtL4Lki3G527c52D+QiWunmbR
Ioka3OmmOzEuQWEP+iRgWy2f/oD2cVTxR9ndhalbc8JMwsfcgUyr+SjM9gpyUvt2y+owcRBfHWPm
cAPuRiUrFeO05qHuBxocS1+qeyNlsHBgcKB3/KuS7tpGob2ht2kY+PvjmeFiDkf30PATlA3EdcX3
f7zhut4vnoakvwW34osu6OsthQoxql5m3ctT5U2NP+WhJiHVNem6uIDxbSvwzfoVc1Vj+MF/6XWj
n5ze0hENjfw/mRdPprl+Z2t7xwVnjttwD3h889ljfBk37VikgXs/yiovFpvjNH3OKee38p03UNW7
qRBfmClmx71fUwTRkD5S6Fz5KIdHCWAI8wuGsFizoLl20pWWnH0yLXk4e/yaa3hcUJ/pWNrfQVva
8LhDQZNbOPcqVK4WVnnucqiUY20qFSovq9bUq9SE/ANCLeHoCmVuZHN0cmVhbQplbmRvYmoKMTkg
MCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9FQU5QWEYrQ01NSTYvRm9udEJC
b3hbMCAwIDU3MSA0OTJdL0ZsYWdzIDQKL0FzY2VudCA0OTIKL0NhcEhlaWdodCA0OTIKL0Rlc2Nl
bnQgMAovSXRhbGljQW5nbGUgMAovU3RlbVYgODUKL01pc3NpbmdXaWR0aCAzMzMKL0NoYXJTZXQo
L3N0YXIpL0ZvbnRGaWxlMyAzNiAwIFI+PgplbmRvYmoKMzYgMCBvYmoKPDwvRmlsdGVyL0ZsYXRl
RGVjb2RlCi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGggMzYyPj5zdHJlYW0KeJxjZGBhYmBkZGRz9vX1
NAOxVH5IM/6QYfohy9zd/eP8jwbWbh7mbh6Wld+vCn03F/xuwv/dUICBhZHRzTsqzjm/oLIoMz2j
REHDWVPB0NLSXMExN7UoMzkxT8E3sSQjNTexBMjJUQjOT85MLanUU3DMyVEIAukoVghKLU4tKktN
AdvsnJ9bUFqSWqTgm5+SWpRXXJJYxMDAwGjPwNjFwMTIyD7zP6NvKAPff6a6xwxTF/zwnc947kcP
8/cT3zVFe3snTurr7u8+5jWlcX7p/NIFZRPa+9ondnNMnjRp8sSUC3WL5Qt2dvdWrv1uc0ti5qQJ
E7oncUzomFrXrFbeXi3nUlfy3adzZuf0um7J2u7O6q7Gkt8+Er8jNrDWdTS2tUxsndYm/93OujKz
u7MwVrIyJ8O3u5WjeVLL5P7+nmlT5fjKFvy0X/B76dRp09h+J0xlX8f1gFuOi8V8Pg/nun4eHgYG
AILJirQKZW5kc3RyZWFtCmVuZG9iagoxNyAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv
bnROYW1lL0pKUUdYUitDTVI5L0ZvbnRCQm94Wy0zOSAtMjUwIDEwMzYgNzUwXS9GbGFncyA0Ci9B
c2NlbnQgNzUwCi9DYXBIZWlnaHQgNzUwCi9EZXNjZW50IC0yNTAKL0l0YWxpY0FuZ2xlIDAKL1N0
ZW1WIDE1NQovTWlzc2luZ1dpZHRoIDM0MgovQ2hhclNldCgvQS9CL0MvRC9FL0cvSS9KL0svTC9N
L04vTy9QL1IvUy9UL1YvVy9ZL2EvYXQvYi9icmFja2V0bGVmdC9icmFja2V0cmlnaHQvYy9jb21t
YS9kL2UvZWlnaHQvZW5kYXNoL2YvZmkvZml2ZS9mb3VyL2cvaC9oeXBoZW4vaS9qL2svbC9tL24v
bmluZS9vL29uZS9wL3BhcmVubGVmdC9wYXJlbnJpZ2h0L3BlcmlvZC9xdW90ZWRibGxlZnQvcXVv
dGVkYmxyaWdodC9yL3Mvc2V2ZW4vdC90aHJlZS90d28vdS92L3cveC95L3plcm8pL0ZvbnRGaWxl
MyAzNyAwIFI+PgplbmRvYmoKMzcgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9TdWJ0eXBl
L1R5cGUxQy9MZW5ndGggNjU3Mz4+c3RyZWFtCnicrVgHVFTX1r7DyNwbRY3lKhhzh1iwK2qMYkMk
ir13pIk0GRh6kTb0mdkz9I70YYBBigqIgFhCrIkmlhejvkRNjESjL8Y8zyWH995/LqjJe8u8tf5/
/Wtcg7DuPWXv7/v2t7eIGmBEiUQiY9v1W6yE/1jw74n4sUb8++L9OOW30p44YzARg8mA+rHm24ej
X4Yh+VA0/V1KLBKtXLPbVu4XHuDl4RlkPtl2ivlsK6v55jY+bgFeri6+5utdgjzdfFyCyC8y861y
Vy+3oPCZ5jYymfkW4Y1A8y1ugW4BIW77hZ1t5T5+wUFuAebr5fvdAnwpirJZZxPu67p+uXz/7g22
fm4bP3bftCLAI9Bzi12Q19bgA9tWh3ivCZW57Fgb5rNv5+Qp02dEWM20nD1n79wPl80bZ28y32EB
Rc2gxlF7qI3Ux9RMajy1iVpBLaRmUROozdRKypKaSNlRsykLaiu1itpGrabmUpOp7dQa6kNqB7WW
mkdNpXZS66hp1C5qPbWcmk9Np3ZTGyhbagH1DjWQGkwNoeTUGGooNYwaTo2gvKiRFEt9QI2iQqnF
lA9lSi2lzKjlJLgUTdlT90RBImS0w+iF2Ed8fcD2AfeMHYy/kGyVtNAmdAj9DbOOOfXOB+/8PLBw
0LhBP5hEmJwZbDr44pApQ1RD+KFrhna8u/Pd9mEhw5qGWw8/OsJ15NSR3azLqHGjYkbdHW02evbo
1aOvj35pGmJ61myBWeeYzWOq3zs4duzYsrFn33d5/9z7jzj5v0Q7cqgh/zKKW0mBoUdkECHzh2L+
Mcph5RKFRRQeju2A+VCyV5VRJ+Wr6MbU3B+4WoPEU2kJruAA68ExhZGV07e0CndpbxntrlIs5YJk
fLVkyL/ERofJmsjewNuViPgZPWvZpDxlZgREgCoxMQJ79/5gGnMgyHOpmpHRR1L00Aj1UKb+RMUY
6C2agwYohixtmjatDbGmKFdyBk9LjdUoIcnMZyv4czK6NeUUnIBWSIFvlIzhIL0eFFmxVQyu4w+x
aCC+Y4wV5BBGnC+FXXT8LYOo5J6Yt0bfsjmVRU2XtWQXb6UMokEOMo1cS85wQgUekAyK5NjkeAsc
Z4oHoILEfEgDrVllHZRyBnqPKlTtAkrYAvvJrelWKFbl+qE5vbSpwi8xOj4seIev3RoIgIN5Sm2m
pioT6pjKsMKggPAIP8dm91OftXx6toIjZ1qISWD4UToRGnATud8U8wdQBgvfQLW8PqjKLW83zATn
lVFyRv2TBE9UGMvoq1kJe6S4hHZQwGpy9TZtsaYd2iFPfVqI1moFnJCiNfTf/3Lq0rm8PRs5HPEn
T+4ih1MbmCH/El24QCmqUMMP1VWiuvvIqVvMU/z7bEhyaBT4Mv4loZWVpYcMF1ccmYtHTjPHwzD7
YgoaiKS1aHBWrgKUClAdTOSCVm713wXMWqtTaDKyvNN2Pu+MKqBRSlJfh17DaaKBb7grRtAzhY0v
UWv9gMGLZeWSfsAk0X5gP5Gc86w2X9NBzlmgPiOccyK066V8La3RIPU/qLTo1LhcMMuBtKzULJTS
Y2KqURv3XnkNNsn5lCtQAOlwEy4RJATRS1U5jVK+jG7U5tziyg14sSQEEiAhHAf1XjYl4f/qJwGX
n+lQIznf+G/RtSfiph5r9i0wniBB7/34fffDD29gca70WcmXl+Am8920u9iUwxvwVRYl03XajDYO
jZI8bVqycemqlTOkmMIP2T6+oAq0mUbM0Skblm60nkDCYiR6QKLOT9WJqu+jhvtiPgx5sWj0+Bd4
KB5hYY5H4mEvJqOhaMTPP6OhHA7Fu9jd4KILOurfrD5NwN4IXbqmms6TBQ3QBU3eJV7lLppd4ALu
sDnASe7gEOoCTD+8FDp+kg65NwvJ1V0To6vC/V7ByItOSnc8vYQkYqj5FMziYX+zQINutLaUFknX
0mhajrGBtovL6JDyL2ib3msshIMyMkTm6BDmCs7gWuHf7N+iOge10JZ+uvJYWW2T4TQ0w7EQvVtu
BKghjHnN/L70P34g7qH5O2xJraHhtoak1lPpC17gCcGarQLpGoojgmKUSfExUmyNy/Am1JqYrUyD
NLOKRo2BUG6fcgPZ1YGQbgGh3CH6POTHF8mRH35iine8QUBbykkQYE6++xBgrcxpkKKd9L8dxdzA
LzOIkaJnLhufq4SwPiRWSdpBl6ABprfhv2Ixj+aX9L7MjCFHA7NCyCyW8m20HtqfkzNuV0Wq7WEP
RPdf6TnY+0l7rcnmRj+spIINPTMMoq7nfJJe3LOsZxF7CLJiEpTKuERu1zJvw5ZPLMAM78AL8Dzs
iPehhXgO2oYW/oLeR+9kQ1ZUNCTEqaXxeDo2sZkAzEd49Wl0GNWiNae/efbrMvxRhVQbrUnKA6YQ
0kql/cnHOwxouo6fUCV6eROV3RejHDyf7RcJK7rSv+7A58CgQcjoCRqNhk/5Gx64fXfwPjfpJRpP
FsTmWnqis7TX860SspTXs3Wfni1pBubr87PJVhK7uQsd3SrrA6XRJaCFYkFbLk4TtMWzAi3tA7ry
qpifgMLZsjQo/WXrY4Jykxnj8bt49K+T0BA0pONleUZSelysMiFZLfWaOEcVCfawTx9Ud6BDfR6a
GU0Fm4VmPiysgrNw3kWDRwoAkzpTwTU9s6uEwAY9F/eEo0cscsaz0Ed4I/nMwvOxE3ZCliSaG8jH
Es1BThx+jL9lLbD0O5SDlGj87Z9+QuMXYyXOwdK5FoJqDZO8xsq4B/z4Z+Jjb1cFRoJs0DgieZvQ
FixFs/HHUjzmH+b9pOcb+iXhpeQnOL9L73F8c4EtTIZ9MG7bip12tiHrBIqKFr4jVABjA9KSImB8
rft7MVrHT2ARY8CDkLHkh47WluxsVXI2F5scEQMBjH9xuE5fVFx5xO3wtiVWmyZxmF4su42/ep2k
09o8TSccgwr1JYLZUHq5MkfQYaN2Z0HqGqrQJeFSD9H552IUia6waJEEmT9/8OTZhAdYKsX4jSK/
uaWkNeUTIjkn4BNo/V1VlaiQRWX9N3wiQVaAjRwdyRde+Ptu5w3ocJ3gI5BTlbhndp+VCMCz/G2x
NaGceb+XQMXd9NNc2TxpFSqSS+bFyKZwM1G8pF9Nx0iQJVRtL8TmTJVEjoKNe6+/OWDxmzTckwzh
LYQoNoteXnv5nRitJCBrykGTkIRT0yo1CVwg41d6sLy0vKCm1qfGcaOLy/ogTv1Cgse9paj+WQiJ
ZuN9erTu0h09StCLqj9BkbfqPhGjYciO1UUYIk8A8/j61dsd8rrofOmxhjbIhSRlfBKEM4qMsPL8
wuzS4iiDq6+jwsOT8yvbn080erqt3eJdNR6FkVKVSu5J1M2r0EMfvivC1R32Mh8/24JGoqG/nr7V
FHbcvYLbWr8ZpkMoeEO81jc9TE+UtzCtICuPeZ7MzoGnZXpt3aEKaUGJvqAKmIcwNSgIps6WnsBL
2Vo0VL1wy1LHGVNs2s4WZn9+n1xHlO0mFAfLMlFdJ4ruFKOf+IV9kpSkgphoTqWKi0tMkpXJ0r1I
rkwPLN/lne9fHiytkx1J6IzrjD2kLDuYHa8LAzdmrgVETfS/dyaGU2ar02OAiYL4cCkeSR+EuNx0
jaa4iEtNz8lLS2ved0KpI4oztOX6ldZQfXC51OuwR4ZNvn/a8jzoYmrLm39AVMaCAC2niYFEImX5
kFEs/YNNEurYnzmlVbDHU7aVUaMnkn716stqb+H/n1Uy+jWcCi4juO7UoU7DcCINqOP5U/3oEdH8
HqI6j/Vfn4OvmWd48F1MaHn9LUz6z+rUxySUQo9oQyaS61Drlppc4w6R8DG5jVO7W5v7ecgB5tuC
BxXpkEsqQFy8Wpq0ThYoIxhQlMQfiiuLu5rYGn8x7goW1zNYVMBiBmVLoFKbVZyapa2FUmDuoxGA
p8xzWofHCspmQe5gQNEGfkJfLbJ7SGoR2sMeS027QgrYGuLndsB+mAeepMjW0t0pMe7SdTQegqdD
tBXe1IEa/1hyuD+WHBRN/7eK5ozm4w/Rrh+vN3RUSQ/5NXhmA5MDWYUCFFMbBTc0woAWlIj+fhON
qRKjVYIITjTgiWidXKKe7zlhqpIJeICraTzgbtDpK/WXr3Fd8u20jczDYxV8V0TMtOj9qD4pbUYm
iBK0VIw28r1sTWCFjywowNe3PMBQU1FRw+FJeD2xQJezEgnpS18nvVVbqjkOhcTAdJDU0GuS045K
eTHdDz5Sui1JhbmM7l4mVq3Hii2BzJgEtTomgYsOz847sPNgyc6TMwhP3plvOXFJm31akrTVqSgJ
DZLfDctSHfbSqOvcYRNjt2eZ5VJMrLNVPKcmPjW6jyqhUrydDoX43AyNJjeDyyuKjT586uLG27Ed
hCpD7v7tZVfI8cAaqfNZx5w1BXNLTReV+F+G48yVM5e/ReypaRb5XEqYJim3jy2vCz8h9qg3VEHX
eds3nm8FPWf3WtsFSS1nOPQtjacJTLkFyjlSPJWGNeBywrM6tCnhGJyCjvLq84xmgQRNfmMEEaL7
S1ZfI9Uf6P3d3STSvq8i7RMY6ONTEVjTH2nLvkh/1UdEKe2bPMlO6Q+5gVxtNlRBOmmJSvx8w0P9
dn4q77p96bNHHB/9yiuRPOJGEbotoJOE+x+0JBQHG1dJ8pFVSTWaSjrCashWFSVrYklJJATzgshx
3H6ZpCEFGUEL+ZAfDSSP++lxUFAntABQqckqSc3W6qEIyAIlvvnYitQUcp0A/IeGFx3kf2YbtLl3
OJ1Bsk9pRyynM9jBPsIGHX1HG+Mh0NlDFbOIC5BJmlKu9m12FZrIXgH0IlVug7S/01SU8mMMIn45
+p4t7azPrRcMr4/SEVS/d5nVqkOR4A+xalWyYjxOM8USVKlMV6VDhlllAxQTNjqrgtROxCH7gofQ
ZbaRaxe4IwuMTNMjMpVZkAWZ2oxDTP+OJGSSGuQvlEAxakaV7NN7J45eTekz2irSGPiAv2a7sG+B
OjeBtN5hEdFx8fgDPMiU96ffqpjHtTpNMzSBTt36RjF/pi+fOexc61TrZFYYnBkDUUysMkbWx58K
zVGSlVqoFvhzAAI1Hu3C0d4dSQXruhDFhxlE7UiEZj0Qo8/QZHbWzh07Xe2LjwRwR5PL9WBgaoIr
vGWBIZ7Lv9zw6N73p57kc5pMOA6VDD+NbiqACyQgq5UxsB1cYW6fPNXRjwV56kdMf8B7hqEHbNmF
ptRSIeCu5OIHwA2iwFWIX4s634+Uz1hVojJhFk4xtUB6Il4pkGJWadBWkuUdlPtIYGQk3t7C87VQ
os6JylLkuZKmQ5WkALUVDjadjvISC4jBTTXTH+3LkgPJkivZh3QzwlukbqhyvRCL/26aFpMSW0Aa
0tSc1Ozn6LDpL/hwamyqogDMCiAlOzWbeS1aPaLmfsFa17OG/dPqdQLa4JC6400uXrWROhSiq/6x
Xie60Y0W3bxeJeanoVKW9IV1jk3uh+0LdgMzf4XLWlnpwUp9cUlli1OaWqqvbM+qBqazy22u9ABp
W5YlrfK29QzeCa6M1U9+V745crYqn0tzqfZoAUZ3qeCO9BP5NloBuz08oL2Qs2lnpy7zcdrrVHfy
864v0Yx0rr+9Ci7t+YDkgOX/ypaebspvgzddnjOEavYI4OtQlwUR0McT0Mfirb3hpngvn0LEKx00
ZjWdUE3i6ajcRYyQC0RqPhbeuAE5yfmeKKm3xzQ9MiWhkGh0Snpafp/3X/DHUZUl/xGLNiKbS+cu
ag5pzAy0r3I3xApNscZRWKhKXRBNer14YskS8H18wRR98XowIHFUbiV7OsDWt0+x3m6BkTVN2hZj
tBEXZyqyIkFh5rsfwgXikDLfCpXEQnYKXFgHUVneJ36nqTE58KcomE3IAg35aL9+nJlpqKuruCBg
1lfpR5DkRnrtPswWqPLiCWYj4hRJiWsXmy55lpCl0hKFgNyc3HLheTeVv1qQlVeTqC9Aqzqx6RfM
mgb771gdHLB74xZVCAhqk6LvY2etulYAUECK8hBkE/DnFxRVGCprdDW3LUyLg8lCiaCIjQ4URnHN
hNItBOldcFS4hiuRkOAqIe67wv8wtfIQ/ol7lIIdewBVBxpDKlxzHcAW9rjId8Scc22YD4tgz84Q
B0b99H81xELU1yfPny3av+LPrdn/4tHfXdwfhyIvryEdaYtX/gftuqvoxgsGp5PyM2D2uj8eNvln
bGK319MvUJqygSVSrMkprDvRUXiEFIBjgZUulc7aTcSW7U3c4e8a7L1PtgMcwa0isDGqlORY6IYH
mE9+xZDfFvFfswWtet05IYMypTcIhk6u2SzA9JK63AeCIEmVrErAlr0epngBH6NOVWYQxTF0gb6P
IbvJ4tsgAdYLOe+EYlXOwazoklWgBrWSFBT8Qe9iUzyfjyT6piX69vb3uqAE8tyQS2+vaVpUWmIu
ZJJ6kl6MlvDppmhpb0r6QW1CPpjlQlo/3wSbhrWlv20pEf18SYx+xHEspClTEjMwiwbuR6sA2QKa
VUOa4Q/QmNRUbQqkMRlJqQkxs22xaDtnPy1wAuBBYJuFJWfxwHN4aPdy4loy0lIzpP+2OIohq3ei
VBb+GoOMdiLxJjR05g3SV8Sq4pVJWmVGgvTTncgIjwV8BPB4f2yPJ+L3VMrkZEhilNr47NyH15Ho
DNf+pOIXQCavVBZvL0XLBGO4RidGawpZothW1rbJSZAMaiYpPSEj5+4tNPAL/8b9nmF+fn7FfvW6
ggKN4Ct35FBo/UVRDtKL0RG0nr2I9evpfvFFGToR8NliPpvAX9ebHfDq78FVjY++1fEf6ERfdCOf
H8T8UHSCxUosdt4StCv1sD+XKslUHc2EY0xleIlcHhbus/q080PEko8pkqMKbPL5bExPnIlH4xGP
piHjG8dOtxRxmP2YjYA94H0x7Ah09HcSpUdqOo/mNRAPol+ZGpvvnroBnJnlB8bPeO2IyZW/Q5QY
7TrDVgfqiEEL8H1j0F4dVtczXCc6dh/l3xfzPugGC1eU9z3/4vSjdcVm2AjWgU7TvFcmLQRrWKOd
2rK47aOvI07AZ3CzqvlRzZX0v8AdBsvwl6wP2OaHIePYc3CfSMZVuJ17tuT7y0V1cAQuhRbPzNkG
S2AdrIf5sZtCsMQmNqBvREn2J1rSaDhO8h56S4y6ekawOrU2gFu/dhahBYFpMVyAM5VMbz7troyZ
yXkLLu97Ykua4GGfx/OmZypzXzfocAc9f/HcIOp8gbwfifl9aAUrl6ii4zdFRyTGrSRKyuCVktKS
zy/l5qAFaNyF0/CcQfT0O3goppdYWu5uScoqqylsqAkpkyUpQZ3MVVy7XHsGmOf101dOXLrAfqcU
r8V7FAoilEFm/AhJ/678WEQhG3KD2WjI12iIGNXyW1h9mN4zOjo5TkF6abVaDYwK0rM+r7nQ3irV
alMEcqQlZiTEfrQMm6ytdGmuL9brObR31P/ltdegu02OMa4SDfzbRZ2ohXgt2XMxSkbfsQ+OrJiO
R9p57AqbmnbTUdqQVKWDOuZwQKlvgE+ky5zulYhBw7ofPn+w8ua0Uq67/vgN+IK59dH58eOXbLI+
UBZWXV1aWl0fWODFVTZfKCF9yTeFq/f6JNoHuElljp4qX1WASgXxEKeOV4OCic6EQ9zr1KIxBt6F
ROYCadmH93Ckc8oIi1Gro+I4/Fmvu7EMVc4jeVUs44JlkkspX0IGpMH1vvF9ML1MGLzcf26YSNvw
ErZXgoHun/gRz2Os48cI36KuKiS6iQpuIhFxPj/zDqwONHLOS+LXsqtpNUk3NW06HoaHPZmOqC9b
W8uLpPlbLiiqgOnOR6JfUBi2Rhy27psUzsF78QZkjpeh/Y/ROyVtyEiamZqmhUwmJx4iuDhJJMl6
VMI8t1nBQq+3GY9Cc5At2oDGo0nIGlmgxZjB4ROjF27wTTx8WGrT0jcxjwrxsncI8wDGduN9khLR
+fvX69vDd9ZLc8NeDcn7c4dET4k0odHf5JaIXhhQLOlF3uMvsjVxhiSDMDO5/n1eVmJqEgl0Upx0
b5hDvAtxVY6ZDsWxaSqyEBMDsQeluI0OB0V+ZkpqVjpX09xecQqYl4BneshgvdxR6ufiErYfNsGq
xsCbGkhXZQBTUp3XYAgu8guRx7hafjULidHgX56id9Hgec+wyH5PhIfnK2bx77/Sz9E6ZEsk1JK/
x172b3Z5rZZ5ealZOZxWq9FogNFCYtxqnw32jlKVSqkksiwIbPa9vyATAeL/l9deiXhKy28WLSJk
0iJGBTiFbZn8m8WzFjzun5H0mzGRsQEN+7FGJ9T2A8RS3+dXshFqgUkqNUkfSdwQZCR58WN9V/mR
xEAdtz85UQYxjE/FwXJ9aXFV17bWRZOwyXZzDhv/22D1bQ4cfYXm0W3p0fukuOy/Pccbva4LpfzF
OyTBaE23mI/mX7JZOaRAlzJYK8HDQZmnLGbkkgPYjbS6qeWZn+TlZqTfhnySfndJsO8OmxA5HoXt
YvB82MIowPFEGxzP4zpoQJPKEHP6OvPvQRpMgrSgJ47F45yf/dNisjMaJ3kNtp6hOtG1dlTVLkbX
0T/ZkxU3TsJd5scZZ2ePs1o2yy3fo8KXOxSWnvyp+1yXTRvAivng11VEW5inf0XUTzbtAYWcItO3
KCaDwZMesT7FQXpoZD778ujnty5uX7Fio4NrELd0E9vsfyj2ikt55Elv2MAsXmS/+MPlF7+5fvL8
lw3ckOCyHusyrD+EfHMkeF8ubRh4cxA3cMD8EpN3dOkmJjcLTQZT1P8AaAG2ewplbmRzdHJlYW0K
ZW5kb2JqCjE1IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvR1NDSlBJK0NN
UjEwL0ZvbnRCQm94WzAgLTIwNiAxMDA5IDcwNV0vRmxhZ3MgNAovQXNjZW50IDcwNQovQ2FwSGVp
Z2h0IDcwNQovRGVzY2VudCAtMjA2Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxNTEKL01pc3NpbmdX
aWR0aCAzMzMKL0NoYXJTZXQoL1AvUy9XL2EvZS9nL2kvbC9tL3BlcmlvZCkvRm9udEZpbGUzIDM4
IDAgUj4+CmVuZG9iagozOCAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL1N1YnR5cGUvVHlw
ZTFDL0xlbmd0aCAxNDQyPj5zdHJlYW0KeJylkmlQU1cUx98jkPdUxEr6BnB5L8w4irZjXQewUxUo
1A0tICqIYIAYliRAErTiQpQEk5wkLEpABbIQCAQMiNK6IGLV6khpsWOpTl0Ga6d+cGlVeoOPGRq0
+q2fOufOnXvPnHPuPb//wTFvLwzHcW5UbPzCBeOn2e7puHuGl3smB9j01+qRRB/w5YCvt2sGl/ZH
G6aiZVPQ/A8wDo7HrE2OysvfLcsWZSn4IVFz+QvDw0P5ERKhLDtDIOXHChRZQolA4bmI+Ql5GdlC
xe75/AixmB8/niHnxwvlQtlOYeabp6PyJPmFCqGMH5uXKZRJMQybKPxSlJ0gFkg2z8ewGGwhtgpb
gy3BYrFIbD0Whk3BJnl+jhFYDnYb7/EK8rrJmcJxeEt8QnxWj+GxiZjfGN5dgCntSGJBkVbccR8d
7Oe4p6E9lNUIlmeJT9ipLPnJLM8+7dU8RCC/M4hTX1ViKD2oVZdomaxZC+EAJEFGi6JDch76oZ3U
W6gKNPeB/QSQL6rY6ZmM35hXsxEDJzrZiG44cUQPoQsvOGgXGqDQZ1zki7C7z5+G/MbOZNhhcQP3
tkEpYkYbCJFWuZyWi7ku489w0mOD4NKQTjmxXGtqZzSolkI2os1QeY5+xEWLITg5BViMXcz4uTVs
ug3FX31gQ2Dzd1zcNYgiB10XA3h/IxlaSS2B57YmfesxO3O42uY4BeRDmKPI1+XulTElxYq8DCBD
DlOdeac19UA+Hhi43bGnQ2Zj2k+0l9eBAcrBqFMeKlVCMVlUU3y8qr7SVlvcmrkrTZ0uoAVtAmMh
kPNjYpanWYX2ncz+vbtzIIvkjYC4RujctaEodztkkFHPNiI/NPFlzx3Xvp4tDnqTIw7Wgwy2g0qf
W7bTCa1QBrZaM4l47Bg1O6an9+zJjm+MzHfcIeQNSxM/T5rrYYpT1zxM3T5daPKw/+BwdH8A7zGK
dq+nWL7SR0x8f0SdzLBWIlUJq2gx0aq/ZGgAF7i0J3Skk1h9qLyT4f1Z5j5JtcoseeLC/IJ8a4HT
Ybe00h65PjJihc6RBQ7/y40FfejHvk2NAbxb6C93IMV+6Iw9lnkJrgbdvHT9DvrUyoalVtB6NahN
QNZAeT2DthG1UKlU6XTFKjorXtKcfnoRBLGc0MXBYb2Rd/IZ06Ge4ptFJO9xk6pF5dhhKajKgRzy
86SoUOmK8u5NdNwlTZ+uXVdVAhog94NqN8OmEEWgMlXqDaZKGvRGY1uvM7tP9AhINOHXp8jr+ep7
oeb3SEbwLhxx+jkoemQNxc4ah3HzsCqZGa19B6NN32uwgx26tR3jMFYp4cz42CitRU6Ua2n6/bzV
v+v21j9Q6MAtewBvjxIN/UKVZTQJzgFpuX70LnNZlkDEydTKnENnymmUQkAXdIo6MjuTjm8FMjwm
ZbXEXNToqDM3Vpe2bdMzTa5uUyuQ3VcyFzE7CN4F5RZNtGadZGW2bDOkkcueyG70nz11rp5WoTBq
DvFxVHZqcrrrwrdd91F4hUcNTkTiW6ELrf7I68a6ASQcXwE8F/JCTyjW8q4tl77H0ASNcPGtxm/a
QuuIlz9d7rthSoyn2X3/O3KzZ0x1LSRKIGAInOL2fbU55jgIhbQNRcJ9DyNMqRAJKdvzYkne4CuC
DX7P3m/Mm3MNK7SMBDvxutdyzutg9z2q7srXVZ3gqSrRinUSkMJaQ4GeFBM/6Mw58BWoNSVaNTtv
ND2QXeLeryvTVkB5UMtVaKSdhEjzBQg9tt2QPp5xBSxQLbJGB7LMaAS71K3UGXWVYPyP6EEoK63e
gVJGRwKNB40HauAoGCrLalC4uzwQLRuteOsMeusl/x2rYXxomIM29lLN8gapVC6XShvkzc0NDc20
X6F1ZIWVbapFUhOXTa8mnBMHJtETvUPNvhOsR3x9B8y+kzHsH6ga6FUKZW5kc3RyZWFtCmVuZG9i
agoxMyAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1ZCV1NQUitDTUJYMTIv
Rm9udEJCb3hbMCAtMjAxIDEwMjUgNzAwXS9GbGFncyA0Ci9Bc2NlbnQgNzAwCi9DYXBIZWlnaHQg
NzAwCi9EZXNjZW50IC0yMDEKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDE1MwovTWlzc2luZ1dpZHRo
IDM3NQovQ2hhclNldCgvQS9DL0kvTS9PL1IvUy9YL2EvYi9jL2UvZW5kYXNoL2YvZy9sL20vbi9v
L3Avci9zL3QvdS95KS9Gb250RmlsZTMgMzkgMCBSPj4KZW5kb2JqCjM5IDAgb2JqCjw8L0ZpbHRl
ci9GbGF0ZURlY29kZQovU3VidHlwZS9UeXBlMUMvTGVuZ3RoIDI3MzM+PnN0cmVhbQp4nI1WC1BT
Zxa+l0DuBZFa3SjUegNW1NZHQZmqba1FKiqKgmjBIhoQBBQIBogi8hQwyUlQkIfyDE95RBGRYKWL
KFXXR7XWx3R3pXbdumy7tLayeC79mXH/YN123J3ZnTOZSSbn/v893/ed7xyWsbZiWJblvHyXBrnP
s3ydLk5mxVetxCkSICE/Fw372YC9BOyt21+1jx+PaS/jqpfQbRwjYVnv1cFeyvhkVXRkVKLzTK/X
nd0XLVrg7BkboYreGhrn7BuaGBURG5pIf8Q4Byi3RkckJs919oyJcV5neSLBeV1EQoRKHRH+7G4v
ZWx8UmKEytlXGR6himMYxskzOW5rkK/SKz5i7TZVZMK6xICklTGhsWEpDDOV+YhZy3zALGLmMn7M
NMaf8WbcmOVMALOCWc/MZzYwHsyHzBuML7OUWcN4MUrmFVooY82ksxJ2O3vDSiXhJOGSfusg616b
+TYFNt9LO7lgjvCefL/tYts023Y7d7vPxrw1Zo04xuGpxF/LgBndzKJPFStuHl4ky67QHkwAFWhz
s5OJfuSJY3YKaJUalWY/JAGfrJDWGy5BIzTAbajR8mYuCSJAWZxXCAbDgR6c6IhG6RXiZjNHIW0x
DEAbtMBPUEcTZ3PkgZgiQ56csiGpUoenVv49DNlkEq+Z2WpkJeI+8SVZ/pEDh64CPTVaux/CIB60
sM7AKzj9GUjTaHJ0GjmxJQfJ77DJ5rxZmqBdDkqIAz/YSZOucug74pqbnhqXm+6k3rzDexnsh3TI
yDfom0qgjTclGGNjEtTRmzpDL/Wdu9NZJTgM24BZtDOxKEEWN1te4ihelH0X9gmx8vKNej9a0KGV
lCzeZ6PgLhdAuJzc9FZwNYZbcJTGs/q9MZpD5s89V08YE5YIpOE/EzgHUZPTKk5qZdvQHpejnUSM
QltZSQZkpuh06blC9u74FW8CT1wAZ5++qMdJOKngojZXp9NpdXKNJm0vqPjQY3vqjG2Hz/QRLn8D
8V5GeMKRV797E2egezPyBcJzKsUBMytuF51luBjVRYcPGEx5TvV5ByhjfL1Zmqh9hyIWAx6gssBa
Ap9AUzqZToIcyesYbvOVWRqpnUOBj4aZEE8zBjhUkaskhBiz0jWaKI2Tir6XEvh4hbTGcI/W2Ax/
GWWXy4AgiCtBb8xyxBUkz2ahhf9Ho/w/Hs2YxTk8tZ7l8ssr4owz4qAFiiacICPZ4vEsYxaowYlE
K4ZGrkshSafbuT9Zu0uXDHyi5bI/jkL6p1FIEzmLMBLy4g7o9FDNi+f1HNaNPDmYkZ9ZDk7lkF90
sBibhq0c9SMDLgppg2EQjtEYhAb6sIs4MGQm0ZwasiBLzVMdzstgKD+vmNhmyk8J2kvEBlTKcPKb
PxB3ssDjNTKRTOqfg+644MEPOF4gBuIvIxMBbfvOwO8rW+XV7acrzPAptMaXK6siIRCC+YVACZJZ
SJmdwaSbMbAKfYwYZmYvo4uo75AMZw57yGogL0l43yuga0WtJ618H5lLXMk2EoavUzK0FEoOHdCu
PEe/NzMTMnTyLDKbyALdwQfmVwRciWrbcR5QgO9Lb5/pvXr3UVEX3AUcG9pEPjBkFUIJ8DVgqJVT
jZMPzehqsghwkMo8nxaIx8ksmTeul9YldaouAY9TnnyF01GY+w2Z7Be0a8dW+VmOeP5b9iOHXlS1
t3hKdqKrp+wk8Ncu+hFH4uoVtEqhqD4TI6eAsmsooBjQiO89wzSrXyIG4U5ZTT7UNWXfDTkjD+0I
OOxPJe/2lisZT5wfu+EsnHV6qLx0L+Sk6DRpOfKdPivVwTTDVYeTe+WN1oZT+pPG1sqW49VmeAKF
xF6/kXInWd3PpLcNj2sdBdYHXSTDNfh3GUYRAacTFUkgU8gMEkki0Zm4YDwNZ3TBSIGMkOsyH1jd
HPFp8O3cb2lRf8i7f+pG581bdRfhHlxSNG4+4V/iCzNgZsbCjd6q6PWKxUDvYwN7LHb5sxkTqGvY
DH6DvARjRVcZSs1kzGPp4GdlpmKDTpsv7M3M2gNqfmtLcn11a2nnqciOD9yIJILwgqun4g75eRTR
uxTPRnpfLdWlB+0P9moq88yRBgcfW44OxySZqQDno62QmpG9B5L5MNOeujpT+anuwKPB70Z7h6ZS
j5JIycIXPerFoy0qJyEtOK//bgumHWOb+zBhKL9PghPRR9a1sxdKqQyE81/e7I5rTS+SN5bVHig3
aHKp66fx6iO76+uPVBprk1tCFWHqZLUQVhteGETZEda/tyymKKwjWr5nd3IURIKiZpsxJSHHNxHW
8X7XVuBqfPv+ubt/9W9UlQjBtatgPp0sWyBXryhIb4NKOKQvLT7M45h8mQd8/vHH8PmDB+AdEgLe
HvJeEiy7fTMtMCrKn+rLMbK37eoVKKXyYrt6mByT6NzEtt3AlBsScay4RFYJBXtztJC1V9ivycjO
1SjLtuVHAh9L3gAycSqOS2rOlTfkmnIOQHtWuwpC+ffcQB20umxAKeRU6fR7gFeDJlFOOG43ZJcW
GKCsSqivPB11DirA6Ty+XIJOXTtNuyrkYcei8zcUrSpeWwxd/LVvwIiS/GUqg6BPO2TpOSPk1dB3
lCwXmHST2ownTNhqHo/TcAK2ocukCXvFeos+J7eabsE5/tHU+8RXGLGhnmcxqkZqVK00/gmNFqPC
E9yE0zhG2g4t6dU7m6Lp/F1BI6w7+mxUn64a+J9KHh4p35eXtluXnaaT526MUSthFWRf39ef05N9
hzAmOlOqZMQWW+kpuCBvkd96nQd5x4Jhx6jncWZcUsX+RF1hbIcEIy06nmYm0zAgVKqbGTxzpobf
fo80cy59ibfudPbeEXpCA7mVsXExa+F6jWV6ppuHuXb28kO8/VCCBeJq2cxqzS04wnebLg4MPNhE
JhmFPDXoKn/BBf04C0/ZGl1mlqD4SGXcePINanyvLXEn7IrWTUdS5WcDj+YMJj5KKtFWqw+nNSoh
iFeo3yXW84m8CafvE3QVkLfrOVd+z7jS6wuLhOLiwsN1dRdC+tIsdub22dDQt74PCVtn8T8qFr77
1xmPQ+Ia2fNmCeKWbF6z+P39decF/AdHvH9to0xuxvW4J7V34J5Z0L8tRc98GzPnmw0n5aK1pVVr
yPNR9ho6SvDo8CQZWlvm5wwIpTEDIun8ROuRAWKt4FrpKOyg8QhaKbNk9ICFGaMHdFt8hJrIsI/s
t5Z7YbSLv6B7VgN88XyReGo19WuqfQxrQA8Te4yWFGZZWhR4Vta/9DJxCSB2uQtCW5IbmhqNbZXZ
FXuKBVNhLe0z/sapiEXyrRyZR+ZvIRI35Hd9/uUnHZ1V8m2g+FHolhoPQTWdwKny1XoogxqesL2y
OQuSd3wUZvr4b8g0f3/QMsyaMpjfLExbnn0kw1/Tpak//Cyxnr5p+Y4UIeXr5aWrYBYE+qqD+f9z
g2Lvnb1yojpp8X/doP5nAveM5VdMuKGbWicWW2Zc+AuI/tjBlVeWV5ZVdX94PqPd4nZD99EVp8x5
SKb4bdq9I0x+MFh2vOtsRQf9bxyQCSs3w7qEbfKY4E2ZO2A5bOtKrf5lXcBiEwviBYl4AYtlppEL
2zmH9JLhpSWkoBC3VElJSAFntkN2jGBnvaDK3vZYob09sjX2Y/X2DgzzL9lNIGMKZW5kc3RyZWFt
CmVuZG9iago4IDAgb2JqCjw8IC9UaXRsZShXaWxsaWFtIFMuIFBhZ2UpCi9EZXN0L2NoYXB0ZXIu
MQovUGFyZW50IDYgMCBSCi9QcmV2IDcgMCBSCj4+CmVuZG9iago1IDAgb2JqCjw8L3BhZ2UuMSBb
NCAwIFIgL1hZWiAxMzQuOTk1MzQ2IDY5Mi4wNTU2MDMgbnVsbF0KL0RvYy1TdGFydCBbNCAwIFIg
L1hZWiAxMzQuOTk1MzQ2IDY4Ni4wMzU3NjcgbnVsbF0KL2NoYXB0ZXIuMSBbNCAwIFIgL1hZWiAx
MzQuOTk1MzQ2IDY4Ni4wMzU3NjcgbnVsbF0KL3NlY3Rpb24qLjEgWzQgMCBSIC9YWVogMTM0Ljk5
NTM0NiAzMTcuMzM4MzE4IG51bGxdCi9jaXRlLkpTMSBbNCAwIFIgL1hZWiAxMzQuOTk1MzQ2IDMx
Ni4zMzgzMTggbnVsbF0KL2NpdGUuVEQxIFs0IDAgUiAvWFlaIDEzNC45OTUzNDYgMjkyLjEyNzg2
OSBudWxsXQovY2l0ZS5ESzEgWzQgMCBSIC9YWVogMTM0Ljk5NTM0NiAyNzAuMzI2NDE2IG51bGxd
Ci9jaXRlLldTUDEgWzQgMCBSIC9YWVogMTM0Ljk5NTM0NiAyNDguMTYzNjM1IG51bGxdCi9jaXRl
LkFQMSBbNCAwIFIgL1hZWiAxMzQuOTk1MzQ2IDIyNi4zNjIxODMgbnVsbF0+PmVuZG9iago0MyAw
IG9iago8PC9MZW5ndGggMTM0OT4+c3RyZWFtCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVN
ME1wQ2VoaUh6cmVTek5UY3prYzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+
Cjx4OnhtcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1wdGs9J1hNUCB0b29sa2l0
IDIuOS4xLTEzLCBmcmFtZXdvcmsgMS42Jz4KPHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3
LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFk
b2JlLmNvbS9pWC8xLjAvJz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9JzAwZDJmZWFjLTNk
NzEtMTFkYy0wMDAwLTFkNjQ1MmQxZWYyMicgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29t
L3BkZi8xLjMvJyBwZGY6UHJvZHVjZXI9J2R2aXBzICsgTWlLVGVYIEdQTCBHaG9zdHNjcmlwdCA4
LjU0Jy8+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PScwMGQyZmVhYy0zZDcxLTExZGMtMDAw
MC0xZDY0NTJkMWVmMjInIHhtbG5zOnhhcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycg
eGFwOk1vZGlmeURhdGU9JzIwMDctMDctMjUnIHhhcDpDcmVhdGVEYXRlPScyMDA3LTA3LTI1Jz48
eGFwOkNyZWF0b3JUb29sPk1pS1RlWCBHUEwgR2hvc3RzY3JpcHQgOC41NCBQREYgV3JpdGVyPC94
YXA6Q3JlYXRvclRvb2w+PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFi
b3V0PScwMGQyZmVhYy0zZDcxLTExZGMtMDAwMC0xZDY0NTJkMWVmMjInIHhtbG5zOnhhcE1NPSdo
dHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJyB4YXBNTTpEb2N1bWVudElEPScwMGQyZmVh
Yy0zZDcxLTExZGMtMDAwMC0xZDY0NTJkMWVmMjInLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJv
dXQ9JzAwZDJmZWFjLTNkNzEtMTFkYy0wMDAwLTFkNjQ1MmQxZWYyMicgeG1sbnM6ZGM9J2h0dHA6
Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+
PGRjOnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+KCk8L3JkZjps
aT48L3JkZjpBbHQ+PC9kYzp0aXRsZT48ZGM6Y3JlYXRvcj48cmRmOlNlcT48cmRmOmxpPigpPC9y
ZGY6bGk+PC9yZGY6U2VxPjwvZGM6Y3JlYXRvcj48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRG
Pgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQg
ZW5kPSd3Jz8+CmVuZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihkdmlwcyArIE1p
S1RlWCBHUEwgR2hvc3RzY3JpcHQgOC41NCkKL0NyZWF0aW9uRGF0ZShEOjIwMDcwNzI1MjExNDA2
KQovTW9kRGF0ZShEOjIwMDcwNzI1MjExNDA2KQovQ3JlYXRvcihMYVRlWCB3aXRoIGh5cGVycmVm
IHBhY2thZ2UpCi9UaXRsZSgpCi9TdWJqZWN0KCkKL0F1dGhvcigpCi9LZXl3b3JkcygpPj5lbmRv
YmoKeHJlZgowIDQ0CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwNTEwMCAwMDAwMCBuIAowMDAw
MDI3NTU4IDAwMDAwIG4gCjAwMDAwMDQ5ODYgMDAwMDAgbiAKMDAwMDAwNDc1NCAwMDAwMCBuIAow
MDAwMDI1Njg4IDAwMDAwIG4gCjAwMDAwMDUwNDUgMDAwMDAgbiAKMDAwMDAwNTI0MiAwMDAwMCBu
IAowMDAwMDI1NjAxIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwNDczMyAwMDAw
MCBuIAowMDAwMDA1MzU4IDAwMDAwIG4gCjAwMDAwMDg1MjMgMDAwMDAgbiAKMDAwMDAyMjUxNyAw
MDAwMCBuIAowMDAwMDA4MjIzIDAwMDAwIG4gCjAwMDAwMjA3NTUgMDAwMDAgbiAKMDAwMDAwNzU5
OSAwMDAwMCBuIAowMDAwMDEzNjQ2IDAwMDAwIG4gCjAwMDAwMDczNjggMDAwMDAgbiAKMDAwMDAx
Mjk5MyAwMDAwMCBuIAowMDAwMDA3MDU5IDAwMDAwIG4gCjAwMDAwMTE2NDkgMDAwMDAgbiAKMDAw
MDAwNTQwMCAwMDAwMCBuIAowMDAwMDA1NTMyIDAwMDAwIG4gCjAwMDAwMDU2NjQgMDAwMDAgbiAK
MDAwMDAwNTc5NiAwMDAwMCBuIAowMDAwMDA1OTI5IDAwMDAwIG4gCjAwMDAwMDYwNjEgMDAwMDAg
biAKMDAwMDAwNjcwMCAwMDAwMCBuIAowMDAwMDA4OTI0IDAwMDAwIG4gCjAwMDAwMDYyMzkgMDAw
MDAgbiAKMDAwMDAwNjQwNyAwMDAwMCBuIAowMDAwMDA2NTgxIDAwMDAwIG4gCjAwMDAwMDY2MTMg
MDAwMDAgbiAKMDAwMDAwOTIzMyAwMDAwMCBuIAowMDAwMDExODc1IDAwMDAwIG4gCjAwMDAwMTMy
MDAgMDAwMDAgbiAKMDAwMDAxNDA5NyAwMDAwMCBuIAowMDAwMDIwOTkwIDAwMDAwIG4gCjAwMDAw
MjI3ODMgMDAwMDAgbiAKMDAwMDAwNzUxMyAwMDAwMCBuIAowMDAwMDA4MDk1IDAwMDAwIG4gCjAw
MDAwMDg4MzUgMDAwMDAgbiAKMDAwMDAyNjE1OSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDQ0
IC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCi9JRCBbPERCNDMyRkZBMjI0MjUzRkRBMjYxODlBQ0I4
M0U4ODZGPjxEQjQzMkZGQTIyNDI1M0ZEQTI2MTg5QUNCODNFODg2Rj5dCj4+CnN0YXJ0eHJlZgoy
Nzc2MgolJUVPRgo=
------=_Part_150548_24245255.1185468879658--

\start
Date: Thu, 26 Jul 2007 12:41:06 -0500
From: Tim Daly
To: Bill Page
Subject: Fricas

Bill,

> A fork is a failure to communicate.

A fork is a separate project. 
<http://en.wikipedia.org/wiki/Fork_(software_development)>

A failure to communicate is what you and I have.

\start
Date: Thu, 26 Jul 2007 12:50:57 -0500
From: Tim Daly
To: Bill Page
Subject: Fricas

Bill,

> Are you going to say if I happen to mention FriCAS once or twice that
> I am somehow mis-using Axiom "resources, history, goodwill", etc.?

When I go into a restaurant and order a "coke" I frequently get asked
"Is Pepsi ok?". There is a reason why they bother to ask.

How often, and in what context, is Pepsi mentioned in a Coca-Cola seminar?
It certainly is reasonable to compare and constrast the products.

Use your best judgement. Make your own choices. I have no right, and no
need to exercise control over what you say. I do request that you try
not to confuse the two projects. Confusion hurts us, fricas, and the
end users in the long run.

\start
Date: Thu, 26 Jul 2007 13:04:08 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom meeting

On Tue, 24 Jul 2007, Bill Page wrote:

| Dear Axiom Users and Developers,
| 
| Based on Gaby's suggestion I wrote to the ISSAC 2007 conference
| organizers asking to schedule a meeting about Axiom during the
| conference next week, to which they agreed. It is tentatively
| scheduled for Monday (July 30) 7:30 PM to 9:30 PM with conference room
| still to be determined.
| 
| I would greatly appreciate it if you could let me know if you are
| interested and able to attend.

Bill --

  Many thanks for finalizing all this.

(I was temporarily out of network reach).

\start
Date: Thu, 26 Jul 2007 14:05:43 -0400
From: Bill Page
To: Tim Daly
Subject: Re: Fricas

On 7/26/07, Tim Daly wrote:
>
> Bill Page wrote:
> > A fork is a failure to communicate.
>
> A fork is a separate project.
>
> http://en.wikipedia.org/wiki/Fork_(software_development)

Wherein we may read (in part):

---

Forks are considered an expression of the freedom made available by
free software, but a weakness since they duplicate development efforts
and can confuse users over which forked package to use. Developers
have the option to collaborate and pool resources with free software,
but it is not ensured by free software licenses, only by a commitment
to cooperation. That said, many developers will make the effort to put
changes into all relevant forks, e.g. amongst the BSDs.

The Cathedral and the Bazaar stated in 1997 [2] that "The most
important characteristic of a fork is that it spawns competing
projects that cannot later exchange code, splitting the potential
developer community." However, this is not common present usage.

In some cases, a fork can merge back into the original project or
replace it. The Experimental/Enhanced GNU Compiler System was a fork
from GCC which proved more vital than the original project and was
eventually "blessed" as the official GCC project. Some have attempted
to invoke this effect deliberately, e.g. Mozilla Firefox was an
unofficial project within Mozilla that soon replaced the Mozilla Suite
as the focus of development.

----

>
> A failure to communicate is what you and I have.
>

Then why do we agree that the article that you mention above is a good one?

Maybe what we need is more of this: "commitment to cooperation" thing ...

BTW, I specifically referenced this same article in the edits that you
asked me to remove.

\start
Date: Thu, 26 Jul 2007 14:08:13 -0500 (CDT)
From: Gabriel Dos Reis
To: list
Subject: Re: [fricas-devel] Re: Fricas

On Thu, 26 Jul 2007, Bill Page wrote:

| 
| Tim,
| 
| I am truly shocked and saddened by your demand to remove my updates
| concerning the FriCAS project from the axiom-developer server. !!!
| :-((  ?

I did not have network access for four days, so I'm having trouble
following all this saga from where I'm currently sitting.

The feedback I have on the recent saga around Axiom, in my understanding,
is largely negative and make some very skilled people determined not to
approach Axiom within any miles -- they would prefer redoing everything from
scratch than to getting entangled in personal ego and drama.  That is NOT 
what we want.

[...]

| So now what are you intentions? Are you really trying to alienate
| everyone involved in the project?  I asked you a few weeks ago: "Do
| you have any idea how much damage you are causing?". I guess that
| question still stands. I really thought you had recovered from the
| state that lead to the current acrimonious situation and so we could
| just move on. Sigh. But now you have even *me* feeling like some of
| our other colleagues who have already announced their resignation from
| the project. I feel like I have been trying hard to do some damage
| control and keep the Axiom project together but you have just stabbed
| me in the back!

:-(

In light of this and recent events, I believe I start understanding the
reactions of people in the room, back at

   http://nicolas.thiery.name/CalculFormelLibre/workshop.html

when Tim was proposing to get together around Axiom.  I even understand
more when very few people are showing up for Axiom, while the demand for 
an advanced, open source, computer algebra system is so pressing.

Tim --

  If you truly ant the Axiom project to succeed, be alive, and attract
talented people., then this is not what you want.  You should take a 
break and enjoy the summer.

\start
Date: 26 Jul 2007 14:21:13 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Fricas

Tim Daly writes:

| I strongly object to the dilution of the Axiom name and resources
| implied by your action. A fork implies the decision NOT to share
| resources. Please do NOT promote Fricas as Axiom in any forum.
| They are two entirely separate projects.
| 
| We clearly disagree on this point.
| 
| Until we have a mechanism for voting in place, and a vote is taken
| that results in community discussion and agreement that Fricas should
| be promoted as you have done, I ask you to remove your edits.

Tim --

  You have no right to decide which is in or out of the Axiom 
community.  You, as a single individual, have your right to believe
in whatever you like -- including deciding that you view Fricas as
an unfriendly alien -- but that remains only your view and your own.

  All good "citizens" of the open source community I know of have
links to related projects.  And Fricas certainly is a project
related to Axiom.  If you want to be hostile to everybody, that is
fine -- and within your contitutional rights.  However, I completely
disagree with you promoting that hostile view for the Axiom community.

  I strongly disagree with your "order" to remove links to Fricas
for the Axiom community webpage.

\start
Date: 26 Jul 2007 14:33:41 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Fricas
Cc: list

Tim Daly writes:

| > Much better for Axiom would be if we get Waldek back into the boat.
| > Isn't that simple? Cooperation, not separation.
| 
| There has been no discussion against Waldek participating in Axiom.
| I, for one, would welcome his participation at any time. I participate
| in a couple computer algebra systems and a few other projects. At no
| time is this a personal issue.  At no time have I ever claimed that
| Waldek is not welcome.

Many of your writings concerning him -- stating things opposite to
factual evidences -- can rightfully be read as unwelcoming.

[...]

|            Creating public branches without posting trunk diffs is not
| cooperative behavior. 

any edits to the Axiom SVN repo at SF is *publically recorded* on the
axiom-commit list at SF. As diffs/patches.

\start
Date: 26 Jul 2007 14:36:15 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Fricas

Tim Daly writes:

| Bill,
| 
| > Are you going to say if I happen to mention FriCAS once or twice that
| > I am somehow mis-using Axiom "resources, history, goodwill", etc.?
| 
| When I go into a restaurant and order a "coke" I frequently get asked
| "Is Pepsi ok?". There is a reason why they bother to ask.

For all I know, proof by analogy is fraud.

\start
Date: Thu, 26 Jul 2007 15:58:06 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Fricas

On 26 Jul 2007 14:36:15 -0500, Gabriel Dos Reis wrote:
> Tim Daly writes:
> ...
> | When I go into a restaurant and order a "coke" I frequently get asked
> | "Is Pepsi ok?". There is a reason why they bother to ask.
>
> For all I know, proof by analogy is fraud.
>

http://jyte.com/cl/proof-by-analogy-is-no-proof

\start
Date: Thu, 26 Jul 2007 13:28:59 -0700 (PDT)
From: Cliff Yapp
To: Bill Page,	Tim Daly
Subject: re: Fricas
 
> If for whatever reason we can't work together with Waldek in the
> Axiom project then at least Axiom still has access to his skills
> and the work of some other people through FriCAS. It is not the ideal
> situation but it is not a net loss. (I think at least Clifford Yapp
> agrees with me on this.)

Yes.  That is the situation so long as everyone maintains compatible
licensing arrangements, which I see no reason to change.  I don't think
either project should constrain itself in order to maintain
compatibility with the other, however - that defeats most of the point.
 There is a good chance that the paths will diverge to an incompatible
point, depending on the directions taken by each project.  The code
base is in a very early state right now, and will probably be
extensively re-worked.  (Axiom may go with Steve's new SPAD and FriCAS
might not, for example - who knows?)

> Devoting a little of the Axiom project's
> resources to track what is happening in FriCAS just seems very
> sensible to me.

Can't we just follow the FriCAS development list and logs?  I can see
adding a link to FriCAS as part of a general listing of CAS's,
something along these lines: 
http://maxima.sourceforge.net/compalg.shtml
That's pretty typical of most projects, in my experience.  But I do
agree that FriCAS should have its own independent identity.

> > If someone writes algebra that only works in FriCAS and not in
> > Axiom but says that it is "Axiom algebra", could someone be
> > confused?
> 
> No. This can be easily explained to any beginning user of Axiom and
> FriCAS - especially if no one closes their eyes about what is
> happening in the FriCAS project.

I have to say Bill in such a case as an end user I might get confused
when I tried to run "Axiom Algebra" in Axiom and it didn't work.  Isn't
it simple enough to just call it FriCAS algebra?

FriCAS is (or will almost certainly become) different from Axiom much
as Macsyma Inc. became different from DOE Macsyma, Vaxima, etc., except
in this case both projects are still active.  Making sure Algebra from
either project will work in the other is a separate QA effort and may
require porting.

> Are you confused about algebra that
> only works in Aldor but not Aldor in Axiom? Right now FriCAS is
> identical to Axiom in the algebra code that it runs. But FriCAS has
> solved some problems with the algebra bootstrap that have not been
> solved yet in Axiom. So the potential certainly exists for new
> algebra code to be written that can not (yet) be compiled in Axiom.

In that case (working in FriCAS but not Axiom) it is probably not a
good idea to confuse it with Axiom's algebra, just from an end-user
standpoint.  As an end user I just want to know which CAS to run the
Algebra in, not that it might work in another CAS.

> (We have been discussing that in another thread on MonoidRing.) As
> far as I know it is the intention of everyone involved that Axiom
> will eventually be able to compile this code.

I doubt the FriCAS project will want to spend effort on that though -
they will probably incorporate the fix and move on.  Eventually Axiom
may be able to use the new code, but it could be a while.  If we move
Axiom to building off of full fleged Category Theory everything may
need to be re-thought.

> > If a paper appears at ISSAC next year stating it was done on Axiom
> > but was done on FriCAS and won't work on Axiom what can we say?
> > Could someone be confused?
> 
> I don't think so. All it takes is one sentence of explanation.

I would think it would be better to specify FriCAS.  If I'm a user of
FriCAS and want my code to work there I'm not worried about Axiom - I
just need to know to download FriCAS.

> Well, I think *most* people would like to continue to use the name
> Axiom generically to refer to computer algebra systems that have
> evolved from the IBM ScratchPad project. I don't think there is much
> room for confusion here - certainly not more than already exists. It
> would be very easy to include both FriCAS and Aldor as categories in
> the IssueTracker system on the Axiom Wiki.

>From an end user perspective I can see that getting confusing,
personally.  I know you don't like the FriCAS name Bill but in the end
does it make much difference?

> > If someone demonstrates FriCAS and it has abilities that don't
> > work in Axiom could someone be confused?
> 
> That is easily explained and one very good reason why I think FriCAS
> should continued to be discussed in the Axiom email lists and on the
> Axiom wiki. To do otherwise is just to invite the type of confusion
> to which you refer.

Um - isn't that an argument for the projects to be separate?  I would
have thought the closer they were tied together the more confusion
there would be.

When Xorg forked from XFree86, the projects essentially went their
separate ways despite starting from a virtually identical code base. 
(Granted there were licensing issues there.)  There is no doubt Xorg is
a separate product from XFree86.

> > FriCAS is capable of developing its own resources.
> > That's what a fork is.
> 
> A fork is a failure to communicate (which also happens to be the
> cause of most wars :-(

I would have thought this fork could be characterized as a desire to
pursue different project goals and methods.  Either way, better a fork
and ongoing work in forks (particularly with compatible licensing being
maintained) than endless arguing and no work in one project.

\start
Date: 26 Jul 2007 15:39:50 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: Fricas

Cliff Yapp writes:

[...]

| When Xorg forked from XFree86, the projects essentially went their
| separate ways despite starting from a virtually identical code base. 
| (Granted there were licensing issues there.)  There is no doubt Xorg is
| a separate product from XFree86.

and (almost) the same people re-united again :-)

\start
Date: 26 Jul 2007 15:41:27 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: Fricas

Cliff Yapp writes:

[...]

| > > FriCAS is capable of developing its own resources.
| > > That's what a fork is.
| > 
| > A fork is a failure to communicate (which also happens to be the
| > cause of most wars :-(
| 
| I would have thought this fork could be characterized as a desire to
| pursue different project goals and methods.

It strikes that people are trying hard to speculate on Fricas goals
and methods, much more than the originator of the Fricas project :-)

\start
Date: 26 Jul 2007 16:42:24 -0400
From: Stephen Wilson
To: Tim Daly
Subject: Re: Fricas

*,

Perhaps what we need is a page on the wiki which describes the goals
of the Axiom project in a succinct way.  That page can be developed
and driven by a community effort.

It can contain a listing of all of the current branches which
describes the efforts underway to realize some of those objectives.

It can include a link to FriCAS, stating clearly that it is a fork of
the project, and has a different set of goals.  It could say something
to the effect of "see the FriCAS page for details".  That section
should be little more than an FYI type entry.  Let the FriCAS page do
its own self promotion.

In that way, we promote the Axiom project and its goals/ideals
unambiguously, and give the reader the opportunity to explore an
alternative approach so that they may form their own opinion about the
merits of each project.

\start
Date: 26 Jul 2007 15:58:17 -0500
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Fricas

Stephen Wilson writes:

| *,
| 
| Perhaps what we need is a page on the wiki which describes the goals
| of the Axiom project in a succinct way.  That page can be developed
| and driven by a community effort.
| 
| It can contain a listing of all of the current branches which
| describes the efforts underway to realize some of those objectives.
| 
| It can include a link to FriCAS, stating clearly that it is a fork of
| the project, and has a different set of goals.  It could say something
| to the effect of "see the FriCAS page for details".  That section
| should be little more than an FYI type entry.  Let the FriCAS page do
| its own self promotion.

I agree with that suggestion.

\start
Date: Thu, 26 Jul 2007 13:57:43 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: re: Fricas

--- Gabriel Dos Reis wrote:

> It strikes that people are trying hard to speculate on Fricas goals
> and methods, much more than the originator of the Fricas project :-)

Point - in fact, a very good point.  Waldek isn't joining this fray so
far, but I'll quote from
http://www.math.uni.wroc.pl/~hebisch/fricas/fricas-reg.html

"FriCAS will use traditional methodology for new developement and
gradually convert other files back to traditional form..."

(as opposed to literate form, if I understand his statement correctly.)

"FriCAS will use lightweight developement, allowing much faster
evolution."

That seems to be sufficiently different from Axiom as I have understood
it to be defined to merit a separate project.  (And is probably a good
canditate for a description on the Axiom website.) In my opinion, it is
also to lead to a system which will diverge quite rapidly from Axiom's
current form.  Since Axiom itself will be diverging from its current
point (although probably more slowly) compatibility is likely to be a
difficult goal to strive for.  Particularly if one or both projects
start re-examining fundamental design decisions.

I have seen no responses to my previous question, which I think defines
the issue:  are there defining goals of Axiom the project that should
result in development in directions incompatible with those goals
becoming new projects?

\start
Date: Thu, 26 Jul 2007 17:17:11 -0400
From: Bill Page
To: Cliff Yapp
Subject: re: Fricas

On 7/26/07, C Y wrote:
> ...
> > (We have been discussing that in another thread on MonoidRing.)
>>  As far as I know it is the intention of everyone involved that Axiom
> > will eventually be able to compile this code.
>
> I doubt the FriCAS project will want to spend effort on that though -
> they will probably incorporate the fix and move on.  Eventually Axiom
> may be able to use the new code, but it could be a while.  If we move
> Axiom to building off of full fleged Category Theory everything may
> need to be re-thought.

Just so we are clear on at least this one technical issue: The problem
apparently is that the current  Axiom build uses a fixed initial
database (in src/share) to bootstrap the Algebra. This was a part of
the bootstrap problem that was *not* solved by including parallel Lisp
code along with the "bootstrap subset" of initial categories, domains
and packages. It makes it impossible to make certain fundamental
changes to the algebra code without (somehow) making parallel changes
to the databases. But the databases are binary files that (normally)
only re-built when re-compiling the entire Axiom system. There is
actually some pretty good documentation on the structure of these
files, but editing them manually also requires a fairly deep knowledge
of other Axiom internals.

Note: The reason why I say the database files are binary files, in
spite of the fact that they are editable in a normal text editory is
because then include specific byte offsets into the file. These
offsets would be wrong on a system like Windows that uses two-byte
line endings (CR/LF).

You might recall from the record in the very earlier axiom-devel list
archives that even before the first version of open source Axiom was
available we had a problem very similar to the current problem of
compiling MonoidRingCategory. In that case one of the required Axiom
domains refused to compile with the database files that Tim received
from NAG and included in the new open source distribution. In that
case the solution was to replace these database files with new ones
generated by Jergen Wiess using an entirely different Lisp system
(CMUCL).

I suggested this sort of approach to Tim, i.e. copying the new
database files generated by FriCAS back into Axiom, but he did not
reply. But without trying it I am not 100% sure if this would work
however since FriCAS has also dropped many unused domains that used to
connect with the NAG numerical libraries.

One of the things that is new in FriCAS and which I would really like
to see in Axiom but all of this fracas over goals and motivations got
in the way, is the new bootstrap system that completely eliminates the
need to keep any parallel Lisp code in the Algebra files and does not
require any initial database files. This is what makes it possible to
easily compile the MonoidRing changes of interest to Franz Lehner in
FriCAS. This change is essentially a trivial change just making a
locally defined category, i.e. a macro, available as a real Axiom
category, but Axiom refuses to compile it due to some conflict with
the fixed databases. Some other change to the Axiom build process
*might* make this possible but in my opinion the general solution
provided in FriCAS is much preferable especial if we contemplate
making deep changes to the Algebra such as those that might be
motivated by category theory.

What is really needed here is someone with sufficient knowledge of
Axiom internals and time to take a look at Waldek's changes to FriCAS
and implement them in Axiom (along with the prerequisite literate
documentation). In my opinion Waldek has already done a fairly
credible job of writing thing documentation in pamphlet form. But one
thing stopping all this is that the changes also depend on extensive
changes to the build system accomplished in the build-improvements
branch. Until those changes a ported to Axiom all of this is blocked
or made significantly extra difficult.

\start
Date: Thu, 26 Jul 2007 17:22:51 -0400
From: Bill Page
To: Stephen Wilson
Subject: Re: Fricas

On 26 Jul 2007 16:42:24 -0400, Stephen Wilson wrote:
>
> Perhaps what we need is a page on the wiki which describes the goals
> of the Axiom project in a succinct way.  That page can be developed
> and driven by a community effort.
>

Well that is certainly what I had in mind when I made the changes that
Tim asked me to remove.

> It can contain a listing of all of the current branches which
> describes the efforts underway to realize some of those objectives.
>

I think most of that is already on the Axiom Wiki.

> It can include a link to FriCAS, stating clearly that it is a fork of
> the project, and has a different set of goals.  It could say something
> to the effect of "see the FriCAS page for details".  That section
> should be little more than an FYI type entry.  Let the FriCAS page do
> its own self promotion.
>

I believe that is exactly what I did. But unless you are subscribed to
the Axiom Wiki itself (some Axiom developers are and some are not) you
probably did not get a chance to read what I wrote before I did what
Tim asked me to do and deleted the page from the Wiki.

> In that way, we promote the Axiom project and its goals/ideals
> unambiguously, and give the reader the opportunity to explore an
> alternative approach so that they may form their own opinion about the
> merits of each project.
>

Sounds good to me. Only this time you start it and maybe no one will
ask you to delete it again. :-(

\start
Date: Thu, 26 Jul 2007 18:23:22 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: re: Fricas

> | When Xorg forked from XFree86, the projects essentially went their
> | separate ways despite starting from a virtually identical code base.
> | (Granted there were licensing issues there.)  There is no doubt Xorg is
> | a separate product from XFree86.
>
> and (almost) the same people re-united again :-)

Yes and in other forks (Gnome, GCC (I think), Compiz/Beryl....). I wonder
if Waldek is going to ISSAC. I hope you, Tim, Bil, Martin can get
together, have couple
of drinks and solve these differences. If I it was in NYC, I would
have invited you myself.

It feels like the project needs a reboot.

\start
Date: 26 Jul 2007 19:13:42 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: Fricas

You had mentioned a week or two ago about posting some slides on the
'net detailing a talk you gave about Axiom, which IIRC contained some
personal ideas about future directions.  Did these ever get online?
Apologies in advance if I somehow missed them.

\start
Date: Thu, 26 Jul 2007 19:23:37 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Take a break.

In light of your recent posting 
<http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00601.html>
I believe I'll take your suggestion. Since I'm clearly the reason that
"very few people are showing up for Axiom" I think I'll go back to my
policy of silence and continue to code.

Since I clearly "want the Axiom project to succeed, be alive, and attract
talented people" I plan to skip the Axiom meeting at ISSAC. I hope it is
well attended and I anticipate a flood of new developers.

\start
Date: Fri, 27 Jul 2007 01:38:49 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Take a break.

On Thu, 26 Jul 2007, Tim Daly wrote:

| Since I clearly "want the Axiom project to succeed, be alive, and attract
| talented people" I plan to skip the Axiom meeting at ISSAC. I hope it is
| well attended and I anticipate a flood of new developers.

Well, that is entirely within your rights, but obviously that is not
what I would be doing if I were in your shoes.

\start
Date: Fri, 27 Jul 2007 01:48:20 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: Fricas

On Thu, 26 Jul 2007, C Y wrote:

| --- Gabriel Dos Reis wrote:
| 
| > It strikes that people are trying hard to speculate on Fricas goals
| > and methods, much more than the originator of the Fricas project :-)
| 
| Point - in fact, a very good point.  Waldek isn't joining this fray so
| far, but I'll quote from
| http://www.math.uni.wroc.pl/~hebisch/fricas/fricas-reg.html
| 
| "FriCAS will use traditional methodology for new developement and
| gradually convert other files back to traditional form..."
| 
| (as opposed to literate form, if I understand his statement correctly.)
| 
| "FriCAS will use lightweight developement, allowing much faster
| evolution."
| 
| That seems to be sufficiently different from Axiom as I have understood
| it to be defined to merit a separate project.

I'm not arguing that Fricas is the same project as Axiom.  There is a 
whole world of difference between being a different project and a hostile
project.  I've not seen anything in Fricas' published manifesto that would
make me (as an Axiom user or Axiom developer) nourrish a hostility with
respect to Fricas.  In fact, I hope that after this summer heat, we would 
be all back into the same boat again.

| (And is probably a good
| canditate for a description on the Axiom website.) In my opinion, it is
| also to lead to a system which will diverge quite rapidly from Axiom's
| current form.  Since Axiom itself will be diverging from its current
| point (although probably more slowly) compatibility is likely to be a
| difficult goal to strive for.  Particularly if one or both projects
| start re-examining fundamental design decisions.

Well, I believe "compatibility" needs qualification.

>From user perspective, I don't really care how the internal
algebra is built as far as my existing programs continue to work.

| I have seen no responses to my previous question, which I think defines
| the issue:  are there defining goals of Axiom the project that should
| result in development in directions incompatible with those goals
| becoming new projects?

If you were expecting ans answer from me, I did not give one simply because I
do not believe I understand the question correctly to give a meaningful
answer.

\start
Date: Fri, 27 Jul 2007 01:55:33 -0500 (CDT)
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: re: Fricas

On Thu, 26 Jul 2007, Alfredo Portes wrote:

| > | When Xorg forked from XFree86, the projects essentially went their
| > | separate ways despite starting from a virtually identical code base.
| > | (Granted there were licensing issues there.)  There is no doubt Xorg is
| > | a separate product from XFree86.
| >
| > and (almost) the same people re-united again :-)
| 
| Yes and in other forks (Gnome, GCC (I think), Compiz/Beryl....). I wonder
| if Waldek is going to ISSAC. I hope you, Tim, Bil, Martin can get
| together, have couple
| of drinks and solve these differences.

I hope too -- as many people here do, at SNC/PASCO'07.

| If I it was in NYC, I would have invited you myself.
| 
| It feels like the project needs a reboot.

:-)

\start
Date: Fri, 27 Jul 2007 03:15:47 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Take a break.

On Thu, 26 Jul 2007, Tim Daly wrote:

| In light of your recent posting 
| <http://lists.gnu.org/archive/html/axiom-developer/2007-07/msg00601.html>
| I believe I'll take your suggestion. Since I'm clearly the reason that
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^  
| "very few people are showing up for Axiom" I think I'll go back to my
| policy of silence and continue to code.

For the record, the above is *your* conclusion, not my statement.

\start
Date: Fri, 27 Jul 2007 04:07:46 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: Fricas

On Thu, 26 Jul 2007, Stephen Wilson wrote:

| Gaby,
| 
| You had mentioned a week or two ago about posting some slides on the
| 'net detailing a talk you gave about Axiom, which IIRC contained some
| personal ideas about future directions.  Did these ever get online?
| Apologies in advance if I somehow missed them.

Many thanks for the reminder.  I just uploaded it.

   http://parasol.tamu.edu/~gdr/Axiom/talks/lille-2007-06.pdf

I wrote the content before "the" fork, but I would not change
anything if I had to write it based on what I know today.

Someone (CY?) asked for a video record; the facilities were not set up
that way.  Although there does not seem to be many slides, the 
discussion covered about 2 hours, and it was very enjoyable,
pleasant, and fruitful.  

\start
Date: Fri, 27 Jul 2007 09:52:49 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Fricas

On 7/27/07, Gabriel Dos Reis wrote:
> ...
> Many thanks for the reminder.  I just uploaded it.
>
>    http://parasol.tamu.edu/~gdr/Axiom/talks/lille-2007-06.pdf
>
> I wrote the content before "the" fork, but I would not change
> anything if I had to write it based on what I know today.
>

Gaby,

Thanks for providing this link.

I noticed one small typo/error in your slides. On p.7 title "Axiom
Today" you wrote:

...
lead: Tim Daly Jr.

Actually, Tim Daly Jr. would normally refer to Tim Daly's son. As far
as I know he is no longer active in the Axiom project.

\start
Date: Fri, 27 Jul 2007 09:02:57 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Fricas

On Fri, 27 Jul 2007, Bill Page wrote:

| On 7/27/07, Gabriel Dos Reis wrote:
| > ...
| > Many thanks for the reminder.  I just uploaded it.
| >
| >    http://parasol.tamu.edu/~gdr/Axiom/talks/lille-2007-06.pdf
| >
| > I wrote the content before "the" fork, but I would not change
| > anything if I had to write it based on what I know today.
| >
| 
| Gaby,
| 
| Thanks for providing this link.
| 
| I noticed one small typo/error in your slides. On p.7 title "Axiom
| Today" you wrote:
| 
| ...
| lead: Tim Daly Jr.
| 
| Actually, Tim Daly Jr. would normally refer to Tim Daly's son. As far
| as I know he is no longer active in the Axiom project.

Oops.  I'll fix that.  Thanks!
Apologies to Tim.

\start
Date: Fri, 27 Jul 2007 16:17:50 +0200 (CEST)
From: Franz Lehner
To: list
Subject: Re: Fricas

> My problem with Bill's actions is that he does things like post FriCAS
> patches on the axiom mailing list. This is entirely off-topic. 
well, perhaps not entirely. The patch Bill posted was _exactly_ identical 
to my original axiom patch with the exception of the database issue which 
is at least for me not resolved in Axiom yet. Later the discussion 
continued on the F***** mailing list.

\start
Date: Fri, 27 Jul 2007 10:39:39 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: schedule

I'm nearly ready with another major patch.
I don't want to disrupt your autoconf patch.
When can we expect your autoconf patch to silver?

\start
Date: Fri, 27 Jul 2007 10:49:05 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: schedule

On Fri, 27 Jul 2007, Tim Daly wrote:

| Gaby,
| 
| I'm nearly ready with another major patch.
| I don't want to disrupt your autoconf patch.
| When can we expect your autoconf patch to silver?

Please, move full speed ahead.  Send your patch.

The main reason, as you'd be tired hearing it again, is that I'm
still on travel with only my windows machine handy.  So, no Autconf
work proper has been done.  This is going to be the case for the next
week or two :-(

\start
Date: Fri, 27 Jul 2007 14:46:51 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Project directions

I'll make one more stab at asking my question, using a more concrete
illustration this time.

Gaby's slides reminded me of the ongoing Lisp vs. Boot situation we
have in the Axiom project - there are two camps both firmly committed
to Lisp or Boot respectively.

Unlike the question of literate programming tools, this is fundamental
- pursuing both goals at the same time in the same project is
nonsensical.  Both camps appear to be willing to do the work, but at
some point if work on both directions continues there will be a
collision between the two.

In that case, it seems logical that two projects would exist -
different goals are being pursued.  (This does NOT imply hostility,
just a recognition of different directions.)  Since they both wouldn't
be Axiom, one would have to be Axiom while the other becomes something
new.  In that situation, how do we resolve reasonably which group
becomes the new project and which remains Axiom?

That's why I was asking if there are fundamental project goals,
established when Axiom was originally started, that can be used as
"defining" goals associated with the Axiom name and used to select
which project should stay with the Axiom name.  Unless I'm missing
something there seems to be an inevitibility about this - one side
isn't going to abandon Lisp and the other isn't going to abandon Boot.

\start
Date: Sat, 28 Jul 2007 08:00:43 +1000
From: Alasdair McAndrew
To: list
Subject: How do I apply a patch?

Sorry if this has been covered before... I'm using the axiom linux
binary - how do I apply a patch, or add a patch of my own?  Is it just
a matter of changing the .spad file in

/usr/local/axiom/mnt/linux/src/algebra

or do I need to do some sort of recompiling?  If this is a dumb
question, I humbly apologize, but I still don't know how to do it...

\start
Date: Sat, 28 Jul 2007 08:27:35 +1000
From: Alasdair McAndrew
To: list
Subject: Re: How do I apply a patch?

Sorry, I should have been more specific: all I want to do at the
moment is add the single function definition

x mod y == integer MOD(x,y)$Lisp

to si.spad (or possible integer.spad).  How do I do that?

-Alasdair

On 7/28/07, Alasdair McAndrew wrote:
> Sorry if this has been covered before... I'm using the axiom linux
> binary - how do I apply a patch, or add a patch of my own?  Is it just
> a matter of changing the .spad file in
>
> /usr/local/axiom/mnt/linux/src/algebra
>
> or do I need to do some sort of recompiling?  If this is a dumb
> question, I humbly apologize, but I still don't know how to do it...

\start
Date: Fri, 27 Jul 2007 17:34:32 -0500
From: Tim Daly
To: Alasdair McAndrew
Subject: posting a patch

To create a patch for a single file:

suppose the original file is in ./original/file.spad.pamphlet
suppose the changed file is in ./changed/file.spad.pamphlet

diff -Naur ./original/file.spad.pamphlet ./changed/file.spad.pamphlet >file.patch

send the patch file to the mailing list. 

\start
Date: Fri, 27 Jul 2007 17:40:01 -0500
From: Tim Daly
To: Alasdair McAndrew
Subject: applying a patch

Alasdair,

To apply a patch for a single file:

suppose the original file is in ./original/file.spad.pamphlet
suppose the patch is file.patch

patch <file.patch

Patch will ignore non-patch garbage so you can generally just 
save the email file containing the patch and feed it directly
to the patch command.

There are a lot of useful flags on the patch command. The one I 
tend to use most is "-p". The -p flag ignores levels in the 
hierarchy. So if I have a whole tree patch where the tree lives
under, say silver, and my changes live under bronze the patch
file will say something like:

 silver/src/algebra/file.spad.pamphlet
 bronze/src/algebra/file.spad.pamphlet

But you might have a different location, such as mysilver/src/algebra
You can use the "-p" command to throw away directory levels.
So you can do:

  cd mysilver
  patch -p1 <file.patch

and it will skip the (silver,bronze).

\start
Date: Fri, 27 Jul 2007 17:46:03 -0500
From: Tim Daly
To: Alasdair McAndrew
Subject: adding the mod function

Alasdair,

1) create the patch

  cd youraxiom/src/algebra
  cp si.spad.pamphlet si.spad.pamphlet.new
  edit si.spad.pamphlet.new
add the line to the file
save the file
  diff -Naur si.spad.pamphlet si.spad.pamphlet.new >si.patch

2) test the patch in a clean system

  rm si.spad.pamphlet.new
  patch <si.patch
  cd youraxiom
  export AXIOM=`pwd`/mnt/linux
  export PATH=$AXIOM/bin:$PATH
  make clean
  make

put some test cases in an input file, say si.input
  cd youraxiom
  export AXIOM=`pwd`/mnt/linux
  export PATH=$AXIOM/bin:$PATH
  axiom 
  )read si.input

if it all looks good to you then post si.patch and si.input to the list.  

\start
Date: Fri, 27 Jul 2007 17:58:29 -0500
From: Tim Daly
To: Alasdair McAndrew
Subject: adding the mod function

Alasdair,

Depending on what source code control system you use they can
also automatically create a patch file for you. I don't use these
commands but I believe that 
  cvs diff
  svn diff
  git diff
all do essentially the same thing, creating an overall patch.

\start
Date: Sat, 28 Jul 2007 01:12:59 +0200 (CEST)
From: Waldek Hebisch
To: Alasdair McAndrew
Subject: re: How do I apply a patch?

On 7/28/07, Alasdair McAndrew wrote:
> On 7/28/07, Alasdair McAndrew wrote:
> > Sorry if this has been covered before... I'm using the axiom linux
> > binary - how do I apply a patch, or add a patch of my own?  Is it just
> > a matter of changing the .spad file in
> >
> > /usr/local/axiom/mnt/linux/src/algebra
> >
> > or do I need to do some sort of recompiling?  If this is a dumb
> > question, I humbly apologize, but I still don't know how to do it...

> Sorry, I should have been more specific: all I want to do at the
> moment is add the single function definition
> 
> x mod y == integer MOD(x,y)$Lisp
> 
> to si.spad (or possible integer.spad).  How do I do that?
> 

First: spad files are compiled so you need to recompile.  I you use
patch prepared by some other person the simplest way (but using a
lot of computer time) is to apply the patch to source tree and
rebuild from scratch.  The next posibility is to run make, but
that assumes that you have build Axiom from sources and keep the
build directory.  Also, running make sometimes recompiles too
little so you may get errors that are not present in a full
build.  You may also recompile by hand only thing that needs
recompilation, but finding what to recompile and the commands to
do this may be tricky.

Coming to your specific question:  you hit one of serious problems
with current Axiom.  What you you want to do should be very
easy, but currently is quite hard (at least if you try to this
directly).  The problem is that to _use_ your new function you
must to add declaration to some category or domain, say to Integer
domain.  However, this changes type of Integer.  To make sure
that Axiom sees consistent types you need to recompile parts
of algebra which depends on Integer.  Unfortunatly, almost all of
Axiom algebra depends on Integer -- in most cases this dependence
is trival, but you may get pretty weird errors if you do
not recompile other parts.  Moreover, Axiom stores type information
in *.daase files, so after re-compiling algebra files you need to 
re-generate the *.daase files.  Let me say that the whole process
is tricky and there is no satiscatory description.  You can look
into MonoidWithZero tread for more details.

In your case much simpler approach is to add mod operation separately.
Create .spad file and define inside a package which contains your
function.  If you compile the package you will be able to use
the function in the same Axiom session.  If you just compile the
package Axiom will forget about the definition when you quit
current session -- you can use )lib command to load compiled
file in new session.  Alternatively, you can re-generate Axiom
databases so that Axiom will remember your package.

\start
Date: Fri, 27 Jul 2007 21:56:42 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Project directions

On 7/27/07, C Y wrote:
> I'll make one more stab at asking my question, using a more concrete
> illustration this time.
>
> Gaby's slides reminded me of the ongoing Lisp vs. Boot situation we
> have in the Axiom project - there are two camps both firmly committed
> to Lisp or Boot respectively.
>

I think this is not an accurate description of the situation since
Boot is written in Lisp and it is *part* of Axiom. In other words no
matter what we do, Axiom is written in Lisp. Period.

This is a question of *how* to use Lisp in Axiom, i.e. whether to use
Lisp to first implement an intermediate application-specific
higher-level language (Boot) and then use it in turn to implement
Axiom (Spad and Interpreter). Note: this is a development strategy
also used in some other large software projects besides Axiom. Or
whether to dispense with the intermediate language and write
everything at the same level.

> Unlike the question of literate programming tools, this is fundamental
> - pursuing both goals at the same time in the same project is
> nonsensical.  Both camps appear to be willing to do the work, but at
> some point if work on both directions continues there will be a
> collision between the two.
>
> In that case, it seems logical that two projects would exist -
> different goals are being pursued.  (This does NOT imply hostility,
> just a recognition of different directions.)  Since they both wouldn't
> be Axiom, one would have to be Axiom while the other becomes something
> new.  In that situation, how do we resolve reasonably which group
> becomes the new project and which remains Axiom?
>

Writing everything at the same level is a reversal of one of the
design decisions made by the original Axiom developers. I think this
could be cited as grounds for not applying the name "Axiom" to this
approach.

> That's why I was asking if there are fundamental project goals,
> established when Axiom was originally started, that can be used as
> "defining" goals associated with the Axiom name and used to select
> which project should stay with the Axiom name.  Unless I'm missing
> something there seems to be an inevitibility about this - one side
> isn't going to abandon Lisp and the other isn't going to abandon Boot.
>

I agree that having defined a sufficiently general higher-level
intermediate language (as Boot, arguably nearly is) it is in principle
possible to imagine eliminating the need for the language in which it
was originally written (Lisp) at least after you first solve the
bootstrap problem. This is what happened with the most of the ML
languages for example. Perhaps this is the direction in which Gaby has
imagined taking Boot.

But if one were really inclined to make this rather big step, then I
think one would be much better off at the level of Spad, rather than
Boot. To do this it would be necessary to improve Spad sufficiently
that it could take over the role of Boot. But in effect we already
have this! It's name is Aldor. And as far as I can see that is exactly
the direction in which the original Axiom project was headed.

But realistically in the short to medium term I do not see any
practical way to really abandon Lisp as fundamental to Axiom. At best
one might hope to do (as Gaby outlined in his slides) would be to
define a much reduced and streamlined subset of Lisp whose specific
purpose is was to efficiently implement Axiom. This is (more or less)
exactly what NAG was attempting to do with the use of CCL in its
commercial version of Axiom.

I hope that what I am saying is clear. Please ask or state if I you
think I have gotten any of this wrong.

\start
Date: Fri, 27 Jul 2007 21:59:29 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Project directions

--- Bill Page wrote:
> I think this is not an accurate description of the situation since
> Boot is written in Lisp and it is *part* of Axiom. In other words no
> matter what we do, Axiom is written in Lisp. Period.

Currently, true.  As we have discussed earlier, Lisp is regarded by
some as a ghetto in the software world and thus a possible intellectual
"dead end."  (I don't think it is, but that ground has been covered.) 
I had taken that as a desire on the part of some people to shift
entirely off of Lisp to something else (Aldor, for example.)
 
> This is a question of *how* to use Lisp in Axiom, i.e. whether to use
> Lisp to first implement an intermediate application-specific
> higher-level language (Boot) and then use it in turn to implement
> Axiom (Spad and Interpreter). Note: this is a development strategy
> also used in some other large software projects besides Axiom. Or
> whether to dispense with the intermediate language and write
> everything at the same level.

To me, the logic should work like this:

A new programming language should only be introduced when the
expressive power gained by implementing the new language is sufficient
to counteract the cost of the inevitable definition work, programmer
learning curves, compiler debugging cycles, and ongoing maintainance
involved with the creation and use of the new language.

Lisp is a language with a stable definition, considerable expressive
power, and several high quality free implementations.  It also has a
mass of useful utility libraries, although I concede it is missing a
few key ones such as a native graphics toolkit (McCLIM isn't quite
there yet).  

My own guess (and it is just a guess, I have no way of quantifying
this) is that there are only three situations in Axiom which justify
the introduction of a language other than Lisp.

1)  Interactive mathematical language (B-natural) - make the
interactive environment feel as much like "human" mathematics as is
practical.  If you don't do this, you don't get end users.

2)  Mathematical library programming.  This task is likely to involve
such a large total percentage of the effort involved in creating Axiom
that the effort required to create a language tuned to support it will
be more than paid back in code quality and productivity, in spite of
the extra work it requires.  Hence, SPAD or Aldor.

3)  Proof languages - not as native languages, but I can see being able
to "speak" the various languages of proof engines.  Proof engines are
highly non-trivial and confirming results in multiple engines only adds
to the credibility of a solution - hence flexibility is worth some
effort.  Being demonstrably correct is probably the single biggest
chance Axiom has of being something more than "just another CAS."

I suppose you could regard LaTeX as a forth case, if you wanted to.

> Writing everything at the same level is a reversal of one of the
> design decisions made by the original Axiom developers. I think this
> could be cited as grounds for not applying the name "Axiom" to this
> approach.

The intent of every branch I am aware of is to have at least two levels
- one for the Algebra and one for the supporting layers.  Tim has
related to us some of the history of the Lisp vs. Boot question in the
original project, IIRC - so we're carrying on an age old tradition in
that respect ;-).
 
> I agree that having defined a sufficiently general higher-level
> intermediate language (as Boot, arguably nearly is) it is in
> principle possible to imagine eliminating the need for the language
> in which it was originally written (Lisp) at least after you first
> solve the bootstrap problem. This is what happened with the most of
> the ML languages for example. Perhaps this is the direction in which
> Gaby has imagined taking Boot.

If I understand correctly, Aldor does not in fact require Lisp at all?

> But if one were really inclined to make this rather big step, then I
> think one would be much better off at the level of Spad, rather than
> Boot. To do this it would be necessary to improve Spad sufficiently
> that it could take over the role of Boot. But in effect we already
> have this! It's name is Aldor. And as far as I can see that is
> exactly the direction in which the original Axiom project was headed.

Then, we also have the 30 year horizon goals that were the beginning of
the open source Axiom project.

> But realistically in the short to medium term I do not see any
> practical way to really abandon Lisp as fundamental to Axiom. At best
> one might hope to do (as Gaby outlined in his slides) would be to
> define a much reduced and streamlined subset of Lisp whose specific
> purpose is was to efficiently implement Axiom. This is (more or less)
> exactly what NAG was attempting to do with the use of CCL in its
> commercial version of Axiom.

That's just it - some of us want to do that, and some of us want to
embrace Lisp.  IIRC it sounded like even in the original commercial
Axiom team there was disagreement about how to handle this, although
I'll have to go back and re-read the emails describing it.

\start
Date: 28 Jul 2007 03:36:43 -0400
From: Stephen Wilson
To: axiom-devel <list>
Subject: Axweb, a literate programming tool

*,

Well, I think the code is ready for a BETA release. 

Axweb is a pretty decent replacement for noweb and I believe it has a
lot of potential.  It is written in Common Lisp and can be tightly
integrated with Axiom as a consequence.  I am going to work with it in
the Axisp branch and try to get some interesting things happening with
it.  Initial ideas are to integrate it with an ASDF based build
environment, the SPAD parser I have worked on, and to have pamphlets
call out to the lisp system as they are being processed, among other
things.

I created a minimal sub-page of the Axisp portion of the wiki which
provides some links to the tangled source, the literate pamphlet, and
a pdf version of the woven program.  The pdf would be a good grab to
see the kind of output it produces.  Take a look here:

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

Since I objected to the latex only approach to pamphlets this is my
counter proposal :)  

I would very much appreciate any feed back, suggestions, criticisms,
etc.  I would especially like to hear about new directions which the
tool can move towards now that a basic functioning substrate is
available.

\start
Date: 28 Jul 2007 07:36:29 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Project directions

Cliff Yapp writes:

[...]

| If I understand correctly, Aldor does not in fact require Lisp at all?

Indeed, and that is a Good Thing (TM).

\start
Date: Sat, 28 Jul 2007 09:27:58 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Project directions

On 28 Jul 2007 07:36:29 -0500, Gabriel Dos Reis wrote:
> Cliff Yapp writes:
>
> [...]
>
> | If I understand correctly, Aldor does not in fact require Lisp at all?
>
> Indeed, and that is a Good Thing (TM).
>

But Aldor does have FOAM which in most respects is still a good subset
of Lisp. And for Axiom's sake Aldor is designed so that it's runtime
environment can be easily re-targeted to Lisp. So it is not really
accurate to say "does not require Lisp at all".

\start
Date: Sat, 28 Jul 2007 08:32:35 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Project directions

On Sat, 28 Jul 2007, Bill Page wrote:

| On 28 Jul 2007 07:36:29 -0500, Gabriel Dos Reis wrote:
| > Cliff Yapp writes:
| >
| > [...]
| >
| > | If I understand correctly, Aldor does not in fact require Lisp at all?
| >
| > Indeed, and that is a Good Thing (TM).
| >
| 
| But Aldor does have FOAM which in most respects is still a good subset
| of Lisp.

Yes, but the point is that, unlike Axiom, Aldor does not require a Lisp
compiler or runtime system.

| And for Axiom's sake Aldor is designed so that it's runtime
| environment can be easily re-targeted to Lisp. So it is not really
| accurate to say "does not require Lisp at all".

Lisp is optional, not a requirement as for Axiom.
If you don't have Lisp you can still write and run Aldor programs.
That is not the case for Axiom.

\start
Date: Sat, 28 Jul 2007 09:57:57 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: Project directions

On 7/28/07, Gabriel Dos Reis wrote:
> On Sat, 28 Jul 2007, Bill Page wrote:
>
> | On 28 Jul 2007 07:36:29 -0500, Gabriel Dos Reis wrote:
> | > Cliff Yapp writes:
> | >
> | > [...]
> | >
> | > | If I understand correctly, Aldor does not in fact require Lisp at all?
> | >
> | > Indeed, and that is a Good Thing (TM).
> | >
> |
> | But Aldor does have FOAM which in most respects is still a good subset
> | of Lisp.
>
> Yes, but the point is that, unlike Axiom, Aldor does not require a Lisp
> compiler or runtime system.
>
> | And for Axiom's sake Aldor is designed so that it's runtime
> | environment can be easily re-targeted to Lisp. So it is not really
> | accurate to say "does not require Lisp at all".
>
> Lisp is optional, not a requirement as for Axiom.
> If you don't have Lisp you can still write and run Aldor programs.
> That is not the case for Axiom.
>

Yes. So what we can do is take (for example) CCL with a bunch of
Axiom-specific optimatizations as was done by NAG and just bundle it
with Axiom. We don't need to call it Lisp. It is just becomes the
abstract machine level for Axiom. Over time, moving towards more Boot
and more SPAD code, less of Axiom needs to be written at the abstract
machine level.

What is the substantial difference?

\start
Date: Sat, 28 Jul 2007 09:28:50 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Project directions

On Sat, 28 Jul 2007, Bill Page wrote:

| Yes. So what we can do is take (for example) CCL with a bunch of
| Axiom-specific optimatizations as was done by NAG and just bundle it
| with Axiom. We don't need to call it Lisp. It is just becomes the
| abstract machine level for Axiom. Over time, moving towards more Boot
| and more SPAD code, less of Axiom needs to be written at the abstract
| machine level.
| 
| What is the substantial difference?

At a point you'll see that the subset of CCL used is shrinking, and you
do not have to worry about Lisp (not just because you don't call it Lisp
anymore).

The substantial difference is that one between a plateform specific
assembly language (such as x86) and a portable high level language
(such as SML or Haskell).

\start
Date: 28 Jul 2007 12:05:04 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: Project directions

Gabriel Dos Reis writes:
> The substantial difference is that one between a plateform specific
> assembly language (such as x86) and a portable high level language
> (such as SML or Haskell).

I am curious about the goal.  Is it to write a new
compiler/interpreter/runtime for a new Universal Assembly Language
from scratch?  Modify an existing (simple) Lisp system to provide only
the fundamental building blocks (like CCL)?  Use a combination of
existing tools to implement the foundation (new gcc front end say, or
targeting LLVM. Addressing runtime issues using common garbage
collectors like Bohem-GC plus a good chunk of custom code, etc).  Or
is the goal to identify the minimal requirements and attempt to
provide back end translators to various hosting environments (JVM,
.NET, etc) which provide the needed facilities?  Perhaps a mixture of
the above?

Clearly this has nothing to do with Lisp.  Using a full Common Lisp
system to host an assembly type language which provides nothing more
than primitives like arrays, integer arithmetic, access to system
level resources -- only to reimplemented many of Common Lisp's
features on top of -- is pure bloat.

Perhaps just picking an existing back end which was designed for such
purposes (like LLVM), and writing a boot/spad/aldor compiler on top of
it, would give the best long term results (flexibility via embedded
jit compilation, efficiency in execution, custom crafted runtime
support, native interface to C/C++ libraries, etc, etc).

I am just interested in understanding what the strategy is.
Constructing Axiom on top of a custom UAL implies a lot of work, but
certainly has its advantages.  

Of course, I am not at all confident that the end result would be any
better than just using Lisp to begin with (and in particular, choosing
one lisp, GCL, and allow ourselves to exploit all of its non-standard
features), but I am trying to keep an open mind.

\start
Date: Sat, 28 Jul 2007 23:27:37 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: diff-Naur 20070721.01.tpd.patch

Tim,

I would feel happy if

1) you make clear what the guidelines are that somebody get's included 
into that list (maybe on MathAction?),

2) you (or whoever wants to add someone to that list) could give at 
least a line on why that person counts as a contributor. (It's enough if 
this appears in the mailing list.)

... just a suggestion ...

Giving credit is fine, but if the whole world is credited that doesn't 
make mean credit at all.

I am not at all against this patch, but a little more information would 
be welcome.

Ralf

On 07/21/2007 06:54 PM, Tim Daly wrote:
> Attached is a changeset to update the list of contributors
> to the Axiom project. This list is available in Axiom with
> the )credits command.
> 
> You can apply this patch to your tree by 
>   cd your-axiom-root
>   patch -p1 <20070721.01.tpd.patch
> 
> Note that, by default, patch tries to skip any leading garbage,
> apply the diff, and then skip any trailing garbage. Thus you can
> save this whole email as a file, run the above patch command, and
> patch will "do the right thing".
> 
> Tim
> 
> diff --git a/changelog b/changelog
> index 3ac5da7..0c9e91d 100644
> --- a/changelog
> +++ b/changelog
> @@ -1,3 +1,5 @@
> +20070721 tpd src/interp/setq.lisp update contributor name list
> +20070721 tpd readme update contributor name list
>  20070716 tpd src/doc/axiom.bib move developernotes to bookvol4
>  20070716 tpd src/doc/Makefile move developernotes to bookvol4
>  20070716 tpd src/input/Makefile add chtheorem.regress
> diff --git a/readme b/readme
> index 2ce2d10..112fa70 100644
> --- a/readme
> +++ b/readme
> @@ -166,24 +166,27 @@ which contains this list. Typing
>  )credits 
>  at the axiom command prompt will prettyprint the list.
>  
> -"An alphabetical listing of contributors to AXIOM (to October, 2006):"
> +"An alphabetical listing of contributors to AXIOM (to July, 2007):"
>  "Cyril Alberga          Roy Adler              Christian Aistleitner"
>  "Richard Anderson       George Andrews         S.J. Atkins"
>  "Henry Baker            Stephen Balzac         Yurij Baransky"
>  "David R. Barton        Gerald Baumgartner     Gilbert Baumslag"
> -"Fred Blair             Vladimir Bondarenko    Mark Botch"
> +"Jay Belanger           David Bindel           Fred Blair"
> +"Vladimir Bondarenko    Mark Botch"
>  "Alexandre Bouyer       Peter A. Broadbery     Martin Brock"
>  "Manuel Bronstein       Florian Bundschuh      Luanne Burns"
>  "William Burge"
>  "Quentin Carpent        Robert Caviness        Bruce Char"
> -"Cheekai Chin           David V. Chudnovsky    Gregory V. Chudnovsky"
> -"Josh Cohen             Christophe Conil       Don Coppersmith"
> -"George Corliss         Robert Corless         Gary Cornell"
> -"Meino Cramer           Claire Di Crescenzo"
> +"Ondrej Certik          Cheekai Chin           David V. Chudnovsky"
> +"Gregory V. Chudnovsky  Josh Cohen             Christophe Conil"
> +"Don Coppersmith        George Corliss         Robert Corless"
> +"Gary Cornell           Meino Cramer           Claire Di Crescenzo"
> +"David Cyganski"
>  "Timothy Daly Sr.       Timothy Daly Jr.       James H. Davenport"
> -"Jean Della Dora        Gabriel Dos Reis       Michael Dewar"
> -"Claire DiCrescendo     Sam Dooley             Lionel Ducos"
> -"Martin Dunstan         Brian Dupee            Dominique Duval"
> +"Didier Deshommes       Michael Dewar"
> +"Jean Della Dora        Gabriel Dos Reis       Claire DiCrescendo"
> +"Sam Dooley             Lionel Ducos           Martin Dunstan"
> +"Brian Dupee            Dominique Duval"
>  "Robert Edwards         Heow Eide-Goodman      Lars Erickson"
>  "Richard Fateman        Bertfried Fauser       Stuart Feldman"
>  "Brian Ford             Albrecht Fortenbacher  George Frances"
> @@ -191,33 +194,36 @@ at the axiom command prompt will prettyprint the list.
>  "Marc Gaetano           Rudiger Gebauer        Kathy Gerber"
>  "Patricia Gianni        Holger Gollan          Teresa Gomez-Diaz"
>  "Laureano Gonzalez-Vega Stephen Gortler        Johannes Grabmeier"
> -"Matt Grayson           James Griesmer         Vladimir Grinberg"
> -"Oswald Gschnitzer      Jocelyn Guidry"
> -"Steve Hague            Satoshi Hamaguchi      Richard Harke"
> -"Vilya Harvey           Martin Hassner         Arthur S. Hathaway"
> -"Waldek Hebisch         Ralf Hemmecke          Henderson"
> -"Antoine Hersen"
> +"Matt Grayson           Klaus Ebbe Grue        James Griesmer"
> +"Vladimir Grinberg      Oswald Gschnitzer      Jocelyn Guidry"
> +"Steve Hague            Satoshi Hamaguchi      Mike Hansen"
> +"Richard Harke          Vilya Harvey           Martin Hassner"
> +"Arthur S. Hathaway     Waldek Hebisch         Ralf Hemmecke"
> +"Henderson              Antoine Hersen         Gernot Hueber"
>  "Pietro Iglio"
>  "Richard Jenks"
>  "Kai Kaminski           Grant Keady            Tony Kennedy"
>  "Paul Kosinski          Klaus Kusche           Bernhard Kutzler"
> -"Larry Lambe            Frederic Lehobey       Michel Levaud"
> -"Howard Levy            Rudiger Loos           Michael Lucks"
> -"Richard Luczak"
> -"Camm Maguire           Francois Maltey        Bob McElrath"
> -"Michael McGettrick     Ian Meikle             David Mentre"
> -"Victor S. Miller       Gerard Milmeister      Mohammed Mobarak"
> -"H. Michael Moeller     Michael Monagan        Marc Moreno-Maza"
> -"Scott Morrison         Joel Moses             Mark Murray"
> +"Larry Lambe            Franz Lehner           Frederic Lehobey"
> +"Michel Levaud          Howard Levy            Rudiger Loos"
> +"Michael Lucks          Richard Luczak"
> +"Camm Maguire           Francois Maltey        Alasdair McAndrew"
> +"Bob McElrath           Michael McGettrick     Ian Meikle"
> +"David Mentre           Victor S. Miller       Gerard Milmeister"
> +"Mohammed Mobarak       H. Michael Moeller     Michael Monagan"
> +"Marc Moreno-Maza       Scott Morrison         Joel Moses"
> +"Mark Murray"
>  "William Naylor         C. Andrew Neff         John Nelder"
>  "Godfrey Nolan          Arthur Norman          Jinzhong Niu"
> -"Michael O'Connor       Kostas Oikonomou       Humberto Ortiz-Zuazaga"
> +"Michael O'Connor       Summat Oemrawsingh     Kostas Oikonomou"
> +"Humberto Ortiz-Zuazaga"  
>  "Julian A. Padget       Bill Page              Susan Pelzel"
> -"Michel Petitot         Didier Pinchon         Jose Alfredo Portes"
> +"Michel Petitot         Didier Pinchon         Ayal Pinkus"
> +"Jose Alfredo Portes"
>  "Claude Quitte"
>  "Norman Ramsey          Michael Richardson     Renaud Rioboo"
>  "Jean Rivlin            Nicolas Robidoux       Simon Robinson"
> -"Michael Rothstein      Martin Rubey"
> +"Raymond Rogers         Michael Rothstein      Martin Rubey"
>  "Philip Santas          Alfred Scheerhorn      William Schelter"
>  "Gerhard Schneider      Martin Schoenert       Marshall Schor"
>  "Frithjof Schulze       Fritz Schwarz          Nick Simicich"
> @@ -234,8 +240,8 @@ at the axiom command prompt will prettyprint the list.
>  "Stephen Wilson         Shmuel Winograd        Robert Wisbauer"
>  "Sandra Wityak          Waldemar Wiwianka      Knut Wolf"
>  "Clifford Yapp          David Yun"
> -"Richard Zippel         Evelyn Zoernack        Bruno Zuercher"
> -"Dan Zwillinger"
> +"Vadim Zhytnikov        Richard Zippel         Evelyn Zoernack"
> +"Bruno Zuercher         Dan Zwillinger"
>  
>  Pervasive Literate Programming
>  
> diff --git a/src/interp/setq.lisp.pamphlet b/src/interp/setq.lisp.pamphlet
> index a4fc0ed..6f23778 100644
> --- a/src/interp/setq.lisp.pamphlet
> +++ b/src/interp/setq.lisp.pamphlet
> @@ -722,24 +722,27 @@
>  (setq |$profileCompiler| nil)
>  
>  (setq credits '(
> -"An alphabetical listing of contributors to AXIOM (to October, 2006):"
> +"An alphabetical listing of contributors to AXIOM (to July, 2007):"
>  "Cyril Alberga          Roy Adler              Christian Aistleitner"
>  "Richard Anderson       George Andrews         S.J. Atkins"
>  "Henry Baker            Stephen Balzac         Yurij Baransky"
>  "David R. Barton        Gerald Baumgartner     Gilbert Baumslag"
> -"Fred Blair             Vladimir Bondarenko    Mark Botch"
> +"Jay Belanger           David Bindel           Fred Blair"
> +"Vladimir Bondarenko    Mark Botch"
>  "Alexandre Bouyer       Peter A. Broadbery     Martin Brock"
>  "Manuel Bronstein       Florian Bundschuh      Luanne Burns"
>  "William Burge"
>  "Quentin Carpent        Robert Caviness        Bruce Char"
> -"Cheekai Chin           David V. Chudnovsky    Gregory V. Chudnovsky"
> -"Josh Cohen             Christophe Conil       Don Coppersmith"
> -"George Corliss         Robert Corless         Gary Cornell"
> -"Meino Cramer           Claire Di Crescenzo"
> +"Ondrej Certik          Cheekai Chin           David V. Chudnovsky"
> +"Gregory V. Chudnovsky  Josh Cohen             Christophe Conil"
> +"Don Coppersmith        George Corliss         Robert Corless"
> +"Gary Cornell           Meino Cramer           Claire Di Crescenzo"
> +"David Cyganski"
>  "Timothy Daly Sr.       Timothy Daly Jr.       James H. Davenport"
> -"Jean Della Dora        Gabriel Dos Reis       Michael Dewar"
> -"Claire DiCrescendo     Sam Dooley             Lionel Ducos"
> -"Martin Dunstan         Brian Dupee            Dominique Duval"
> +"Didier Deshommes       Michael Dewar"
> +"Jean Della Dora        Gabriel Dos Reis       Claire DiCrescendo"
> +"Sam Dooley             Lionel Ducos           Martin Dunstan"
> +"Brian Dupee            Dominique Duval"
>  "Robert Edwards         Heow Eide-Goodman      Lars Erickson"
>  "Richard Fateman        Bertfried Fauser       Stuart Feldman"
>  "Brian Ford             Albrecht Fortenbacher  George Frances"
> @@ -747,33 +750,36 @@
>  "Marc Gaetano           Rudiger Gebauer        Kathy Gerber"
>  "Patricia Gianni        Holger Gollan          Teresa Gomez-Diaz"
>  "Laureano Gonzalez-Vega Stephen Gortler        Johannes Grabmeier"
> -"Matt Grayson           James Griesmer         Vladimir Grinberg"
> -"Oswald Gschnitzer      Jocelyn Guidry"
> -"Steve Hague            Satoshi Hamaguchi      Richard Harke"
> -"Vilya Harvey           Martin Hassner         Arthur S. Hathaway"
> -"Waldek Hebisch         Ralf Hemmecke          Henderson"
> -"Antoine Hersen"
> +"Matt Grayson           Klaus Ebbe Grue        James Griesmer"
> +"Vladimir Grinberg      Oswald Gschnitzer      Jocelyn Guidry"
> +"Steve Hague            Satoshi Hamaguchi      Mike Hansen"
> +"Richard Harke          Vilya Harvey           Martin Hassner"
> +"Arthur S. Hathaway     Waldek Hebisch         Ralf Hemmecke"
> +"Henderson              Antoine Hersen         Gernot Hueber"
>  "Pietro Iglio"
>  "Richard Jenks"
>  "Kai Kaminski           Grant Keady            Tony Kennedy"
>  "Paul Kosinski          Klaus Kusche           Bernhard Kutzler"
> -"Larry Lambe            Frederic Lehobey       Michel Levaud"
> -"Howard Levy            Rudiger Loos           Michael Lucks"
> -"Richard Luczak"
> -"Camm Maguire           Francois Maltey        Bob McElrath"
> -"Michael McGettrick     Ian Meikle             David Mentre"
> -"Victor S. Miller       Gerard Milmeister      Mohammed Mobarak"
> -"H. Michael Moeller     Michael Monagan        Marc Moreno-Maza"
> -"Scott Morrison         Joel Moses             Mark Murray"
> +"Larry Lambe            Franz Lehner           Frederic Lehobey"
> +"Michel Levaud          Howard Levy            Rudiger Loos"
> +"Michael Lucks          Richard Luczak"
> +"Camm Maguire           Francois Maltey        Alasdair McAndrew"
> +"Bob McElrath           Michael McGettrick     Ian Meikle"
> +"David Mentre           Victor S. Miller       Gerard Milmeister"
> +"Mohammed Mobarak       H. Michael Moeller     Michael Monagan"
> +"Marc Moreno-Maza       Scott Morrison         Joel Moses"
> +"Mark Murray"
>  "William Naylor         C. Andrew Neff         John Nelder"
>  "Godfrey Nolan          Arthur Norman          Jinzhong Niu"
> -"Michael O'Connor       Kostas Oikonomou       Humberto Ortiz-Zuazaga"
> +"Michael O'Connor       Summat Oemrawsingh     Kostas Oikonomou"
> +"Humberto Ortiz-Zuazaga"  
>  "Julian A. Padget       Bill Page              Susan Pelzel"
> -"Michel Petitot         Didier Pinchon         Jose Alfredo Portes"
> +"Michel Petitot         Didier Pinchon         Ayal Pinkus"
> +"Jose Alfredo Portes"
>  "Claude Quitte"
>  "Norman Ramsey          Michael Richardson     Renaud Rioboo"
>  "Jean Rivlin            Nicolas Robidoux       Simon Robinson"
> -"Michael Rothstein      Martin Rubey"
> +"Raymond Rogers         Michael Rothstein      Martin Rubey"
>  "Philip Santas          Alfred Scheerhorn      William Schelter"
>  "Gerhard Schneider      Martin Schoenert       Marshall Schor"
>  "Frithjof Schulze       Fritz Schwarz          Nick Simicich"
> @@ -790,8 +796,8 @@
>  "Stephen Wilson         Shmuel Winograd        Robert Wisbauer"
>  "Sandra Wityak          Waldemar Wiwianka      Knut Wolf"
>  "Clifford Yapp          David Yun"
> -"Richard Zippel         Evelyn Zoernack        Bruno Zuercher"
> -"Dan Zwillinger"
> +"Vadim Zhytnikov        Richard Zippel         Evelyn Zoernack"
> +"Bruno Zuercher         Dan Zwillinger"
>  ))
>  
>  @

\start
Date: Sun, 29 Jul 2007 00:09:01 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Project directions

Hello,

On 07/27/2007 11:46 PM, C Y wrote:
> I'll make one more stab at asking my question, using a more concrete
> illustration this time.
> 
> Gaby's slides reminded me of the ongoing Lisp vs. Boot situation we
> have in the Axiom project - there are two camps both firmly committed
> to Lisp or Boot respectively.
> 
> Unlike the question of literate programming tools, this is fundamental
> - pursuing both goals at the same time in the same project is
> nonsensical.  Both camps appear to be willing to do the work, but at
> some point if work on both directions continues there will be a
> collision between the two.

Why does everyone see collisions? We should aim for a modular Axiom,
   compiler
   interpreter
   runtime system
   algebra libraries
   user interface
   etc.

with a clear specification it doesn't matter whether the compiler is 
written in Boot, SPAD, LISP, or C or Haskell. The compiler should be 
called if needed. Why would the language it is written in matter?

Similar for the interpreter or runtime system, etc.

Why cannot that all live under the hat of "Axiom"? Some people like to 
have a compiler in LISP, some in BOOT. Those people don't agree, which 
will probably lead to two compilers that do the same thing. It is only 
inportant that the specification is clear. Would it be bad to have two 
compilers? Three?

Clearly, if people don't agree on one language that splits developers, 
but the goal is to provides a mathematical and intuitive user interface 
that is supported by a typed programming language. We all work to that 
goal don't we? There is no need to fork again just because some people 
like LISP and some don't. The common goal lives some levels up.

Collaboration, not separation.

\start
Date: 28 Jul 2007 18:34:49 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: Re: Project directions

Hi Ralf,

I think you have made an excellent observation.

Ralf Hemmecke writes:
[...]
> with a clear specification it doesn't matter whether the compiler is
> written in Boot, SPAD, LISP, or C or Haskell. The compiler should be
> called if needed. Why would the language it is written in matter?

One of the main problems is simply getting all of the different
components to play well together.  This basically means defining a
representation for a byte stream which can be passed back and fourth
from one application to the next.  No real difference conceptually
than an internet protocol on the one hand and a file format on the
other.  The big issue is that the byte stream (what ever that may
be. There would in every likely hood be many sorts) be interpreted
efficiently and universally by all system components.

Using the same programming language to implement them all alleviates
that problem significantly since everything is internal data.  Thus,
the former approach introduces real engineering problems.  

[...]
> Why cannot that all live under the hat of "Axiom"? Some people like to
> have a compiler in LISP, some in BOOT. Those people don't agree, which
> will probably lead to two compilers that do the same thing. It is only
> inportant that the specification is clear. Would it be bad to have two
> compilers? Three?

Fundamentally however, there is no problem with this in principle.  Of
course having everyone cooperate on realizing compatible
interpreters/compilers is a much bigger challenge than simply agreeing
on what the proper programming language to use is.

It is also difficult (and not nearly as enjoyable, which is important
in open source work) to write systems which are trying to reach new
horizons when you constrain fundamental interactions to byte-streams
:)

> Clearly, if people don't agree on one language that splits developers,
> but the goal is to provides a mathematical and intuitive user
> interface that is supported by a typed programming language. We all
> work to that goal don't we? There is no need to fork again just
> because some people like LISP and some don't. The common goal lives
> some levels up.
> 
> Collaboration, not separation.

I could not agree more.  It does not matter to the user -- whose
opinion in the end is what matters most -- what language the system is
implemented in.  Unfortunately some of us prefer different approaches
to meeting the expectations.  I personally see no problem with having
different groups of developers pursue common goals along different
paths, even if it does divide an already scarce resource.  Too many of
the ideas, designs, concepts, etc, transcend the programming language
used.  Rich collaboration in any event is certainly possible.

\start
Date: Sat, 28 Jul 2007 17:43:20 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: axiom credit list

Ralf,

There are no criteria for adding someone's name to the list except
that you, I, or anyone else believes the name should be added.

The list is meaningless in the sense that, as a set, there is no
rule for deciding membership. It isn't an attempt at academic credit.

The )credit command and the credit list exists because of my personal
experience with IBM. I worked on several projects there and
occasionally I watched as people who left had their name expunged from
the documentation after leaving the project. The particular example
that caused me to make the original list was that I worked for years on
a project and wrote a couple hundred page document. It had 4 names on
the front cover. Within a week after leaving the project the document
had 3 names on the cover. It felt like people had simply walked off
with several years worth of work without so much as mentioning my
name.  That seemed unjust.  So I spent a while dragging thru all of
the scratchpad documentation, mailing lists, and people's memories to
try to find names of people who had contributed to scratchpad. Thus
the list was born.

If you look at the very last line, the first entry in the changelog
file, you'll see that I added Mike O'Connor to the credits list. This
was due to a conversation with Dick Jenks shortly before he died. 
Mike never worked on the project but helped Dick with early VM-based
versions of the system. Mike had an IBM/370 board that fit into an
IBM/PC and was helpful in shaking out portability bugs. Only Dick 
mentioned his contribution, and that was after it was open source.

Every so often I drag thru the mailing lists, my other correspondence,
and other contacts that I have had trying to find people who had passed
thru the project, had an effect, and might have been missed.

Credit is costless to share and there is always enough blame to go
around.  If someone you know has contributed to Axiom in some form
feel free to add them to the list of credits. No explanation is
necessary. There are no rules and no guidelines, just your own private
judgement that they deserve to be mentioned.

\start
Date: Sun, 29 Jul 2007 00:51:06 +0200
From: Ralf Hemmecke
To: Stephen Wilson
Subject: Re: Axweb, a literate programming tool

>   http://wiki.axiom-developer.org/AxWeb

> Since I objected to the latex only approach to pamphlets this is my
> counter proposal :)  

Could you update http://wiki.axiom-developer.org/PamphletSyntax and add 
a link to AxWeb there.

I've tried to be objective on that site, but might have failed. Nobody 
has added pros and cons so far to the PamphletSyntax site and it's 
already two days old. :-(

\start
Date: 28 Jul 2007 18:58:30 -0400
From: Stephen Wilson
To: Ralf Hemmecke
Subject: Re: Axweb, a literate programming tool

Ralf Hemmecke writes:

> >   http://wiki.axiom-developer.org/AxWeb
> 
> > Since I objected to the latex only approach to pamphlets this is my
> > counter proposal :)
> 
> Could you update http://wiki.axiom-developer.org/PamphletSyntax and
> add a link to AxWeb there.

Sure. No problem.

> I've tried to be objective on that site, but might have failed. Nobody
> has added pros and cons so far to the PamphletSyntax site and it's
> already two days old. :-(

I was thinking of adding a few things but thought it might be
inappropriate as my opinions cannot be taken as strictly objective in
this context.  

I too was hoping for a bit more feedback on this page.  I will
probably add a few notes this evening when I update it with the axweb
link.

\start
Date: Sun, 29 Jul 2007 01:01:48 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: axiom credit list

Thank you, Tim.

> Credit is costless to share and there is always enough blame to go
> around.  If someone you know has contributed to Axiom in some form
> feel free to add them to the list of credits. No explanation is
> necessary. There are no rules and no guidelines, just your own private
> judgement that they deserve to be mentioned.

Still, I'd like that people who add other people's names should inform 
the list what he/she has done. So all on the list learn a bit more of 
history or the present and not just a name.

I think you should commit that patch to trunk.
If somebody is against it s/he should speak *now*.

\start
Date: Sun, 29 Jul 2007 01:20:34 +0200
From: Ralf Hemmecke
To: Stephen Wilson
Subject: Re: Axweb, a literate programming tool

>> Could you update http://wiki.axiom-developer.org/PamphletSyntax and
>> add a link to AxWeb there.

> I was thinking of adding a few things but thought it might be
> inappropriate as my opinions cannot be taken as strictly objective in
> this context.  

Well, as you see, I've also marked some items with my name. They are 
meant to be personal opinion.

That is why I wrote at the top of the page:

   Please add your pros and cons or any other notes into the text.
   Try to state facts, not opinions. If you feel that you must
   present your opinion, attribute it by your name.

I don't want just an opinion page, but rather factual things. We had 
discussions enough, now it's time to try to list pros and cons that are 
based on facts (not opinions).

\start
Date: Sat, 28 Jul 2007 22:51:16 -0500
From: Tim Daly
To: list
Subject: literate programming

This paper contains clear arguments for literate programming.
<http://www-stat.stanford.edu/~donoho/Reports/1995/wavelab.pdf>
and appears to have been done in 1995. We seem to be a bit behind
the curve on this idea.

\start
Date: Sat, 28 Jul 2007 23:13:07 -0500
From: Tim Daly
To: Jocelyn Guidry
Subject: literate programming and Claerbout's Insight

>From <http://www-stat.stanford.edu/~donoho/Reports/1995/wavelab.pdf>
Buckheit, Jonathan B., Donoho, David L. "WaveLab and Reproducible Research"

Jon Claerbout's Insight

  An Article about computational science in a scientific publication
  is not the scholarship itself, it is merely advertising of the
  scholarship. The actual scholarship is the complete software
  development environment and the complete set of instructions which
  generated the figures.

That says it all exactly. They published CDs of their work.

We need reproducible research in computational mathematics.
And it has to rest on a literate, proven base of open code.
This can't be done in a commercial system.
Axiom has the opportunity to be the base of computational mathematics.
Now all we have to do is document axiom and prove the code correct.
I suspect that effort will take the next 30 years.
Look to the horizon.

\start
Date: Sat, 28 Jul 2007 23:29:37 -0500
From: Tim Daly
To: list
Subject: literate programming,	Claerbout's Insight and Doyen

Now that memory kicks in I recall that one original motivation 
for the Doyen project was to create particular "snapshots" for
a particular piece of research that could always be reproduced.

Jose has carefully documented the process of creating a Doyen
CD so a paper could be published on the CD along with a complete
Axiom system to sit behind the paper.

The idea is that you can always reproduce and rerun the paper
even if the world moves. So Axiom development could continue
but you could still run last year's papers.

Thus Martin could build and distribute an environment that has
the necessary scripts to run his algebra. Or Ralf could distribute
the combinat environment on a Doyen CD along with traditional
publications.

\start
Date: Sun, 29 Jul 2007 00:30:00 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: literate programming

Hi Tim,

> This paper contains clear arguments for literate programming.
> <http://www-stat.stanford.edu/~donoho/Reports/1995/wavelab.pdf>
> and appears to have been done in 1995. We seem to be a bit behind
> the curve on this idea.

I almost give you credit for it, never heard of the term until you came
up with the Doyen idea :-).

I really like the post from Ed Borasky regarding R and their weave tool.
This example, http://www.stat.umn.edu/~charlie/Sweave/foo.pdf,
looks very similar to what your idea for the pamphlets. It is similar to
what Bill show with \begin{sageblock}..... I wonder how difficult will be
to have the same with the new AxWeb or Cliff version.

I do not know how many are familiar with this:
http://www.cs.auc.dk/~normark/elucidative-programming/

It is a different approach to Literate Programming. Two things I like
about it are the use of modern tools (browser) and the separation of
the code/documentation. Even when documentation/code are one
in the LP sense, I would like to have an editor capable of presenting
two views. One will be the regular editing of the pamphlet and another
will be a tangle view of a particular chunk, similar to what MathAction
does, but being able to edit and compile the code, debug it, etc.
Modifications on both views would modify the pamphlet.

\start
Date: Sun, 29 Jul 2007 00:36:01 -0400
From: Alfredo Portes
To: Tim Daly
Subject: Re: literate programming, Claerbout's Insight and Doyen

It is still the idea of the project ;-). I do not know if you ever
read this post by Emil Sit,
http://www.emilsit.net/blog/archives/tools-for-repeatable-research/ .

He actually mentions you and the Doyen idea for what he calls
repeatable research.

On 7/29/07, Tim Daly wrote:
> Now that memory kicks in I recall that one original motivation
> for the Doyen project was to create particular "snapshots" for
> a particular piece of research that could always be reproduced.
>
> Jose has carefully documented the process of creating a Doyen
> CD so a paper could be published on the CD along with a complete
> Axiom system to sit behind the paper.
>
> The idea is that you can always reproduce and rerun the paper
> even if the world moves. So Axiom development could continue
> but you could still run last year's papers.
>
> Thus Martin could build and distribute an environment that has
> the necessary scripts to run his algebra. Or Ralf could distribute
> the combinat environment on a Doyen CD along with traditional
> publications.

\start
Date: 29 Jul 2007 00:32:11 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: literate programming and Claerbout's Insight
Cc: Jocelyn Guidry

Tim Daly writes:

[...]

| Axiom has the opportunity to be the base of computational mathematics.

When it manages to meet the needs of the working computational
mathematicians.  It cannot do that by building self-made ghetto
with an autistic attitute of the workers.

I have spoken to many people at SNC/PASCO '07.  It is incredible how
the two factors:

  (1) Axiom's history
  (2) lack of seamless integration to working computational
      mathematicians's development environment and insistance on
      relic technology

generate strong negative reactions.

We can write diatribes and pamphlets against commmercial systems and
library approches all we want, but Axiom has a hard convincing task
before it, and proving passe techniques is not going to convince
anyone when nobody is interested in or using passe techniques.

Take a look at recent research papers and have a closer look at what
people are using, are developing, what they think is the future trend
of the field. 


I have heard the following (friendly) characterization of Axiom in the
last couple of days:

  * If you're doing computer algebra for leaving, then:
      (i) Axiom lacks supports in many key areas;
     (ii) most of the Axiom algorithms are a couple of generations
          behind;

  * If you're a casual user, then using Axiom is like flying a
    helicoptere to buy milk at the store next door.


With the inclusion of standard disclaimer about analogy, think about
the above.

\start
Date: Sun, 29 Jul 2007 18:30:11 +1000
From: Alasdair McAndrew
To: Gabriel Dos Reis, list
Subject: Re: literate programming and Claerbout's Insight

It may be that the negative views of Axiom are simply due to Axiom
being very poorly (read "not at all") marketed - there are no
elementary books about the use of Axiom, and if you go to the Axiom
website, it is hard to find introductory beginner's or tutorial
articles.  Contrast this last with Maxima - at the Maxima website
there are quite a few links to tutorials, which makes Maxima seem in
the realm of usability by beginners or casual users.

Another problem - which I see as major - is that there is no native
windows version with documentation (HyperDoc) and graphics.  This is
not a problem for me personally (I use linux) but I believe it is a
problem in having Axiom more widely used.  Again, compare this with
Maxima, where under windows there is the pleasant wxMaxima interface.

I am testing out Axiom this semester with a cryptography class; in
fact I am preparing lab sheets using both Axiom and Maxima,  and I'm
letting the students decide which they'd like to use.  The idea is
that the students can download the software to use at home, which is
not the case with Maple, for which my Department has a limited
license.

I have indicated my willingness to write a few expository articles
about Maxima and Axiom for the Australian Mathematical Society; when I
have them done I'll let y'all know.  I would welcome any suggestions
about nice topics to include.

Now - back to cooking dinner!

cheers,
Alasdair

On 29 Jul 2007 00:32:11 -0500, Gabriel Dos Reis wrote:
> Tim Daly writes:
>
> [...]
>
> | Axiom has the opportunity to be the base of computational mathematics.
>
> When it manages to meet the needs of the working computational
> mathematicians.  It cannot do that by building self-made ghetto
> with an autistic attitute of the workers.
>
> I have spoken to many people at SNC/PASCO '07.  It is incredible how
> the two factors:
>
>   (1) Axiom's history
>   (2) lack of seamless integration to working computational
>       mathematicians's development environment and insistance on
>       relic technology
>
> generate strong negative reactions.
>
> We can write diatribes and pamphlets against commmercial systems and
> library approches all we want, but Axiom has a hard convincing task
> before it, and proving passe techniques is not going to convince
> anyone when nobody is interested in or using passe techniques.
>
> Take a look at recent research papers and have a closer look at what
> people are using, are developing, what they think is the future trend
> of the field.
>
>
> I have heard the following (friendly) characterization of Axiom in the
> last couple of days:
>
>   * If you're doing computer algebra for leaving, then:
>       (i) Axiom lacks supports in many key areas;
>      (ii) most of the Axiom algorithms are a couple of generations
>           behind;
>
>   * If you're a casual user, then using Axiom is like flying a
>     helicoptere to buy milk at the store next door.
>
>
> With the inclusion of standard disclaimer about analogy, think about
> the above.

\start
Date: Sun, 29 Jul 2007 05:30:17 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: literate programming and Claerbout's Insight

--- Gabriel Dos Reis wrote:

> Tim Daly writes:
> 
> [...]
> 
> | Axiom has the opportunity to be the base of computational
> mathematics.
> 
> When it manages to meet the needs of the working computational
> mathematicians.  It cannot do that by building self-made ghetto
> with an autistic attitute of the workers.

Nor can it do so without being able to supply concrete, verifiable
reasons of why it is technically able to serve as such a foundation. 
This is why I regard the consideration of proof system integration as
fundamental to the future of the project - I don't see how we can be
credible otherwise.  Why should anyone trust us?

> I have spoken to many people at SNC/PASCO '07.  It is incredible how
> the two factors:
> 
>   (1) Axiom's history
>   (2) lack of seamless integration to working computational
>       mathematicians's development environment and insistance on
>       relic technology
> 
> generate strong negative reactions.

Um.  I can understand the lack of seamless integration, but why would
Axiom's history cause a negative reaction?

As for relic technology, do you mean Axiom's current Algebra algorithms
or use of Lisp?  Or maybe the 1980s look of Hyperdoc and graphics?

> We can write diatribes and pamphlets against commmercial systems and
> library approches all we want, but Axiom has a hard convincing task
> before it, and proving passe techniques is not going to convince
> anyone when nobody is interested in or using passe techniques.

The idea is (eventually) to be able to develop the proof as the
technique is being developed.

Also, APPLIED CAS usage (e.g. Physics) won't always be inventing new
mathematics to do what they need to do.  They need known techniques
they can trust, to give them answers they can trust.

There is more than one target audience here.

> Take a look at recent research papers and have a closer look at what
> people are using, are developing, what they think is the future trend
> of the field. 

I think it is premature to characterize the Axiom project's output - we
are in the early stages of a monumental task and how things look now
are very likely to change dramatically.  Certainly Axiom in its current
form looks dated, but changing that is a non-trivial task in ANY
toolkit.  I don't personally think Axiom is ready for heavy end user
activity.

> I have heard the following (friendly) characterization of Axiom in
> the last couple of days:
> 
>   * If you're doing computer algebra for leaving, then:
>       (i) Axiom lacks supports in many key areas;
>      (ii) most of the Axiom algorithms are a couple of generations
>           behind;

There is only one way to fix that, and it will take a lot of time.

>   * If you're a casual user, then using Axiom is like flying a
>     helicoptere to buy milk at the store next door.

Very true.  Fortunately, Maxima exists for those cases.
 
> With the inclusion of standard disclaimer about analogy, think about
> the above.

Casual use is not (as I understand it) the target of the Axiom system
as yet.  My guess (and it is only that) is end user friendly systems
will eventually come from defining assumptions in the "default" user
interaction environment.  Most systems make these assumptions unstated
- we should make them explicit.  That again means taking the long road.

FriCAS will fill the need for those who need something Axiom-like
working now.  My interest is the long term goals.

\start
Date: Sun, 29 Jul 2007 08:01:46 -0500 (CDT)
From: Gabriel Dos Reis
To: Alasdair McAndrew
Subject: Re: literate programming and Claerbout's Insight

On Sun, 29 Jul 2007, Alasdair McAndrew wrote:

| It may be that the negative views of Axiom are simply due to Axiom
| being very poorly (read "not at all") marketed - there are no
| elementary books about the use of Axiom, and if you go to the Axiom
| website, it is hard to find introductory beginner's or tutorial
| articles.

Most people at SNC/PASCO '07 I spoke with are people who used to be strong 
believers in Axiom -- many of them contributed Axiom algebras, some did
their PhD with Axiom.  Those don't seem to be needing elementary books 
about the use of Axiom. 

\start
Date: Sun, 29 Jul 2007 08:03:10 -0500 (CDT)
From: Gabriel Dos Reis
To: Alasdair McAndrew
Subject: Re: literate programming and Claerbout's Insight

On Sun, 29 Jul 2007, Alasdair McAndrew wrote:

| Another problem - which I see as major - is that there is no native
| windows version with documentation (HyperDoc) and graphics.

I agree.

\start
Date: Sun, 29 Jul 2007 08:20:58 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: literate programming and Claerbout's Insight

On Sun, 29 Jul 2007, C Y wrote:

| Um.  I can understand the lack of seamless integration, but why would
| Axiom's history cause a negative reaction?

Well, this is something one should oneself ask directly to the interested
people.  Do you believe Axiom's history is not a factor to Tim's committment
to Axiom?  The point is if you believe the history can cause
positive reaction (committment), it can also be source of negative
reaction -- some consider that they have been "burnt" many times in the past.

| As for relic technology, do you mean Axiom's current Algebra algorithms
| or use of Lisp?  Or maybe the 1980s look of Hyperdoc and graphics?

Almost all of those.

| 
| > We can write diatribes and pamphlets against commmercial systems and
| > library approches all we want, but Axiom has a hard convincing task
| > before it, and proving passe techniques is not going to convince
| > anyone when nobody is interested in or using passe techniques.
| 
| The idea is (eventually) to be able to develop the proof as the
| technique is being developed.
| 
| Also, APPLIED CAS usage (e.g. Physics) won't always be inventing new
| mathematics to do what they need to do.  They need known techniques
| they can trust, to give them answers they can trust.

Yes, but the technology used in applied cas has evolved; algorithms
have been improved and Axiom is lagging two generations behind.  CAS
applications to real world problem have put pressure on improving
the knwon algorithms.  Other CASes (mostly commercial) have managed 
to integrate the work (improvements) of the working computational sciences.

| There is more than one target audience here.

Definitely.  Which is Axiom's?   I doubt it is the one that prefers 
failing or poor algorithms.

| > Take a look at recent research papers and have a closer look at what
| > people are using, are developing, what they think is the future trend
| > of the field. 
| 
| I think it is premature to characterize the Axiom project's output - we

Indeed, Axiom has been around for only more than 2 decades.  Now, we seem
to be looking at a moving target of 30 years horizon.

[...]

| >   * If you're a casual user, then using Axiom is like flying a
| >     helicoptere to buy milk at the store next door.
| 
| Very true.  Fortunately, Maxima exists for those cases.

Riiiight.  So, who is Axiom's audience?  
Those who are doing CAS for leaving cannot use it.  Those who are
casual users are encouraged to look elsewhere.
Amateurs?

\start
Date: Sun, 29 Jul 2007 07:22:10 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: literate programming and Claerbout's Insight

--- Gabriel Dos Reis wrote:

> On Sun, 29 Jul 2007, C Y wrote:
> 
> | Um.  I can understand the lack of seamless integration, but why
> | would Axiom's history cause a negative reaction?
> 
> Well, this is something one should oneself ask directly to the
> interested people.  Do you believe Axiom's history is not a factor
> to Tim's committment to Axiom?  The point is if you believe the
> history can cause positive reaction (committment), it can also be
> source of negative reaction -- some consider that they have been
> "burnt" many times in the past.

Sure, as a commercial product.  Open source is a different ballgame;
whether for better or not is not yet established.

> | As for relic technology, do you mean Axiom's current Algebra
> | algorithms or use of Lisp?  Or maybe the 1980s look of Hyperdoc
> | and graphics?
> 
> Almost all of those.

Well, we've had the Lisp issue out many times before.  As for the
others, I agree too - but fixing them is non-trivial.

> Yes, but the technology used in applied cas has evolved; algorithms
> have been improved and Axiom is lagging two generations behind.

Being developed on limited/no resources for years will do that.

> CAS applications to real world problem have put pressure on improving
> the knwon algorithms.  Other CASes (mostly commercial) have managed 
> to integrate the work (improvements) of the working computational
> sciences.

Sure.  That means it's on our todo list, once we get a foundation we
can build on.

> | There is more than one target audience here.
> 
> Definitely.  Which is Axiom's?   I doubt it is the one that prefers 
> failing or poor algorithms.

That seems to be a bit up in the air, or perhaps "too early to tell" -
no one wants failing or poor algorithms, but replacing them will most
likely come naturally as part of the literate re-write.

> | I think it is premature to characterize the Axiom project's output
> 
> Indeed, Axiom has been around for only more than 2 decades.  Now, we
> seem to be looking at a moving target of 30 years horizon.

Axiom as an open source project has not existed for 2 decades, and
working through legacy code to update/modernize/document is neither
sexy nor quick.

> | >   * If you're a casual user, then using Axiom is like flying a
> | >     helicoptere to buy milk at the store next door.
> | 
> | Very true.  Fortunately, Maxima exists for those cases.
> 
> Riiiight.  So, who is Axiom's audience?  
> Those who are doing CAS for leaving cannot use it.  Those who are
> casual users are encouraged to look elsewhere.
> Amateurs?

CAS developers, at the moment - those interested in what a CAS CAN be,
rather than what they are today.  We are building the tools.  They must
be built before they can be used.  Who our audience will eventually be
depends entirely on what we can create.  It is probably safe to say it
won't be heavy duty speed critical numerical simulations (e.g. those
who optimize down to the assembly level) and it is not clear yet
whether a system can strive for rigor in the mathematical sense and
remain a good "engineering/casual use CAS."  For me, the target
audience is the audience that wants to be as sure as humanly possible
that the answers they are getting to questions put to the CAS are
correct mathematically.  Whether other applications follow from that
remains to be seen.  But of course, that's just me.

\start
Date: Sun, 29 Jul 2007 09:41:20 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: literate programming and Claerbout's Insight

On Sun, 29 Jul 2007, C Y wrote:

| Sure, as a commercial product.  Open source is a different ballgame;

What are the concrete differences?

The algorithms have not gotten better, for example.  The documentation
is no really better than what they had before; windows support is worse.

[...]

| > | There is more than one target audience here.
| > 
| > Definitely.  Which is Axiom's?   I doubt it is the one that prefers 
| > failing or poor algorithms.
| 
| That seems to be a bit up in the air, or perhaps "too early to tell" -

well, very few people want to be on board of something with
the audience "too early to tell", but surely casual users are encouraged
to look elsewhere. We should not forget that experts, and those doing CAS for 
living, once started as casual users.  In a heathly, growing community, there
are more "novices" than experts.

[...]

| > | I think it is premature to characterize the Axiom project's output
| > 
| > Indeed, Axiom has been around for only more than 2 decades.  Now, we
| > seem to be looking at a moving target of 30 years horizon.
| 
| Axiom as an open source project has not existed for 2 decades, 

that is true, but you can rewrite history.  Axiom has more than 2 decade
history.  For practical purposes, Axiom as a open source currently
-- for many -- is no better than what it was before.  Are the algorithms
better?  Are the known, documented, bugs fixed?  

| and
| working through legacy code to update/modernize/document is neither
| sexy nor quick.

Right!  And yet we want to attract people.

| > | >   * If you're a casual user, then using Axiom is like flying a
| > | >     helicoptere to buy milk at the store next door.
| > | 
| > | Very true.  Fortunately, Maxima exists for those cases.
| > 
| > Riiiight.  So, who is Axiom's audience?  
| > Those who are doing CAS for leaving cannot use it.  Those who are
| > casual users are encouraged to look elsewhere.
| > Amateurs?
| 
| CAS developers, at the moment - those interested in what a CAS CAN be,
| rather than what they are today.

but those do CAS for living; they are working computational scientists.
We seem to be ignoring them.

\start
Date: Sun, 29 Jul 2007 10:56:39 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: literate programming and Claerbout's Insight
Cc: Gabriel Dos Reis

On 7/29/07, Cliff Yapp wrote:
>
> --- Gabriel Dos Reis wrote:
>
> > On Sun, 29 Jul 2007, C Y wrote:
> >
> > | Um.  I can understand the lack of seamless integration, but why
> > | would Axiom's history cause a negative reaction?
> >
> > Well, this is something one should oneself ask directly to the
> > interested people.  Do you believe Axiom's history is not a factor
> > to Tim's committment to Axiom?  The point is if you believe the
> > history can cause positive reaction (committment), it can also be
> > source of negative reaction -- some consider that they have been
> > "burnt" many times in the past.
>
> Sure, as a commercial product.  Open source is a different ballgame;
> whether for better or not is not yet established.
>

No, I don't think the people with a negative reaction to Axiom only
date from the short time that Axiom was a commercial product.

I do not agree that open source is a completely "different ballgame".
As Tim has explained even when Axiom was a research project at IBM is
was quite freely given out to those researchers who had a real
interest in it.

And even during the time that Axiom has been officially open source,
by far the majority of the new Axiom users would seem to prefer to be
able to use Axiom in essentially the same way as if it were a
commercial product. If it doesn't work rather quickly for them, then
they just look elsewhere rather than joining the project and trying to
improve it. Only a small minority are willing to do that.

> > | As for relic technology, do you mean Axiom's current Algebra
> > | algorithms or use of Lisp?  Or maybe the 1980s look of Hyperdoc
> > | and graphics?
> >
> > Almost all of those.
>
> Well, we've had the Lisp issue out many times before.  As for the
> others, I agree too - but fixing them is non-trivial.
>

But the point is that these would better be addressed *first* before
settling in to even harder to achieve long term goals like making all
of Axiom a literate program.

> > Yes, but the technology used in applied cas has evolved; algorithms
> > have been improved and Axiom is lagging two generations behind.
>
> Being developed on limited/no resources for years will do that.
>

I think most people would be willing to concede this point if they get
the feeling that something is really being done about it.

> > CAS applications to real world problem have put pressure on improving
> > the knwon algorithms.  Other CASes (mostly commercial) have managed
> > to integrate the work (improvements) of the working computational
> > sciences.
>
> Sure.  That means it's on our todo list, once we get a foundation we
> can build on.
>

What is truly wrong with the foundation on which Axiom was originally
built? The build environment inherited from the 80's and which for the
most part persists in the Axiom Gold and Silver was certainly not
consistent with what is currently considered best practice, but that
his been addressed in the build-improvements branch.

Contrary to when I started working with Axiom, I no longer consider
literate program an essential part of this foundation. I think that is
a different issue. I still believe literate programming to be a
worthwhile long term goal - especially for the the Axiom library
(Spad) code. I am just not convinced that we really know how to do it.
And I don't think this should stop the further development of Axiom
until we learn to do it right.

> > | There is more than one target audience here.
> >
> > Definitely.  Which is Axiom's?   I doubt it is the one that prefers
> > failing or poor algorithms.
>
> That seems to be a bit up in the air, or perhaps "too early to tell" -
> no one wants failing or poor algorithms, but replacing them will most
> likely come naturally as part of the literate re-write.
>

I seriously doubt that this "literate re-write" will ever really
occur. Instead it seems most likely to me that improvements will
continue to be made via bug fixes and by major new contributions by
researchers and dedicated Axiom users if there are a sufficient number
of these so that chances of someone both motivated and qualified is
sufficiently high.

> > | I think it is premature to characterize the Axiom project's output
> >
> > Indeed, Axiom has been around for only more than 2 decades.  Now, we
> > seem to be looking at a moving target of 30 years horizon.
>
> Axiom as an open source project has not existed for 2 decades, and
> working through legacy code to update/modernize/document is neither
> sexy nor quick.
>

Reading Spad code is particularly easy. That is what it was designed
to be: a highly expressive and easy to understand notation for
mathematical algorithms. In most cases when you look at Spad code and
compare it to published algorithms the connection and details of the
implementation and obvious.

> > | >   * If you're a casual user, then using Axiom is like flying a
> > | >     helicoptere to buy milk at the store next door.
> > |
> > | Very true.  Fortunately, Maxima exists for those cases.
> >
> > Riiiight.  So, who is Axiom's audience?
> > Those who are doing CAS for leaving cannot use it.  Those who are
> > casual users are encouraged to look elsewhere.
> > Amateurs?
>
> CAS developers, at the moment - those interested in what a CAS CAN be,
> rather than what they are today.  We are building the tools.  They must
> be built before they can be used.  Who our audience will eventually be
> depends entirely on what we can create.

I think this is completely the wrong attitude. It is the "If you build
it, they will come." approach. (Do you remember that movie of a decade
ago about the guy who built the baseball diamond on the middle of his
corn field? What was the title?) Even in the big wide world of the
Internet I do not think there is any reason to believe that this
approach will work.

> It is probably safe to say it
> won't be heavy duty speed critical numerical simulations (e.g. those
> who optimize down to the assembly level) and it is not clear yet
> whether a system can strive for rigor in the mathematical sense and
> remain a good "engineering/casual use CAS."  For me, the target
> audience is the audience that wants to be as sure as humanly possible
> that the answers they are getting to questions put to the CAS are
> correct mathematically.  Whether other applications follow from that
> remains to be seen.  But of course, that's just me.
>

I think you are wrong. You should take a very close look at the large
number of developers in the Sage project and the kind of (mostly
leading edge) things they are doing. People have very high
expectations for computer algebra systems these days. Afterall this is
the seventh year of the twenty first century.

\start
Date: Sun, 29 Jul 2007 10:04:33 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: literate programming and Claerbout's Insight

On Sun, 29 Jul 2007, Bill Page wrote:

| I think you are wrong. You should take a very close look at the large
| number of developers in the Sage project and the kind of (mostly
| leading edge) things they are doing.

This is a very good point. 

I'm very impressed by the diligence with which people involved in Sage
are working to help sort out issues on the Fricas list.  
Why is that not happening for Axiom?

\start
Date: Sun, 29 Jul 2007 10:14:42 -0500
From: Tim Daly
To: Martin Rubey
Subject: Algebra and literate documentation

Martin,

Normally I wouldn't mention this as an on-list post but....

I spent the last two weeks rearranging Axiom so people can add
algebra code to the system. I've been using your algebra as the
test case for this change. Like all test cases this work has been
done one step at a time. Now it appears that the system can allow
new algebra to be installed.

I started adding your algebra to the system. I ran into a problem.
It appears that mantepse.spad.pamphlet will not format correctly.
When I looked into the problem you define a chunk:

  <<domain UFPS UnivariateFormalPowerSeries>>=

but later in the document you try to use the chunk as:

  <<dom: UFPS UnivariateFormalPowerSeries>>

Thinking this might be a typo in my copy of your algebra I checked
wh-sandbox where the algebra is known to work. The wh-sandbox code
has exactly the same code. 

Thus you posted algebra that will not weave.

I recall that you threatened to quit over an OPTIONAL change to the
weave syntax. And you insisted that the project needs to be reorganized 
into a democracy based on an OPTIONAL change to the weave syntax. 

The project has been in turmoil over your demands.

Yet you posted supposedly well tested, ready for public release, 
algebra which you clearly never tried to weave. And clearly nobody
else has tried to weave, including the wh-sandbox branch. This 
has cost me a tremendous amount of time.

Please post a working pamphlet file (English is preferred), along
with test cases. I cannot construct cases for things like GUESSINT.

\start
Date: Sun, 29 Jul 2007 08:17:45 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: literate programming and Claerbout's Insight
--- Gabriel Dos Reis wrote:

> On Sun, 29 Jul 2007, C Y wrote:
> 
> | Sure, as a commercial product.  Open source is a different
> | ballgame;
> 
> What are the concrete differences?

For one thing, there is no legal problem with fixing problems yourself
and distributing the results to the world free of charge.

> The algorithms have not gotten better, for example.  The
> documentation is no really better than what they had before; 
> windows support is worse.

The differences are not concrete yet - I consider the intangible ones
very important but perhaps that is not a shared opinion.

> well, very few people want to be on board of something with
> the audience "too early to tell", but surely casual users are
> encouraged to look elsewhere. We should not forget that experts, 
> and those doing CAS for living, once started as casual users.  In a
> heathly, growing community, there are more "novices" than experts.

Well, in my case I found Axiom only after being introduced to the idea
of CAS on more "friendly" systems - Mathematica and Maxima.  However, I
now understand at least in part the merit of Axiom's complexity -
correctness is not simple.  Perhaps this means Axiom will never be a
logical candidate for an "entry level system."

> | Axiom as an open source project has not existed for 2 decades, 
> 
> that is true, but you can rewrite history.  Axiom has more than 2
> decade history.  For practical purposes, Axiom as a open source
> currently -- for many -- is no better than what it was before.  Are
> the algorithms better?  Are the known, documented, bugs fixed?  

Certainly it is not better yet.  I believe it eventually will be, but
it will take a LOT of time to get there.  Open source is not magic - it
is an opportunity to create something better, no more and no less.

> | working through legacy code to update/modernize/document is neither
> | sexy nor quick.
> 
> Right!  And yet we want to attract people.

So as far as I can see the only thing to do seems to be to get through
the "grunt work" and make a system that will attract people.

> | CAS developers, at the moment - those interested in what a CAS CAN
> | be, rather than what they are today.
> 
> but those do CAS for living; they are working computational
> scientists. We seem to be ignoring them.

I would say we aren't ready for use cases where people want to simply
use the CAS without developing it in the process.  If that doesn't
appeal to "working computational scientists" I'm not sure what the
answer is - the ground work needs to be done.

\start
Date: Sun, 29 Jul 2007 10:33:02 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: literate programming and Claerbout's Insight

On Sun, 29 Jul 2007, C Y wrote:

| 
| --- Gabriel Dos Reis wrote:
| 
| > On Sun, 29 Jul 2007, C Y wrote:
| > 
| > | Sure, as a commercial product.  Open source is a different
| > | ballgame;
| > 
| > What are the concrete differences?
| 
| For one thing, there is no legal problem with fixing problems yourself
| and distributing the results to the world free of charge.

for many, that is not a practical difference -- since they are already
using commercial systems.

[...]

| Well, in my case I found Axiom only after being introduced to the idea
| of CAS on more "friendly" systems - Mathematica and Maxima.  However, I
| now understand at least in part the merit of Axiom's complexity -
| correctness is not simple.  Perhaps this means Axiom will never be a
| logical candidate for an "entry level system."

Currently, Axiom isn't.  But if its proponents are convinced that they do
should their best to chase away "novices", then the system is doomed to
premature death.

[...]

| I would say we aren't ready for use cases where people want to simply
| use the CAS without developing it in the process.

yes, but do you want Axiom to indefinitely stay in that state?

\start
Date: 29 Jul 2007 11:38:58 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: literate programming and Claerbout's Insight

Hello Gaby,

Is it your contention that Axiom should be more devoted to the
perpetual task of meeting the common consensus on what qualifies as
`state of the art', as opposed to the perpetual task of trying to
redefine the meaning of the term?

I can understand that having a CAS today which working mathematicians
can use to push forward the frontiers of their own research is a very
valuable thing.  I just don't quite understand why CAS developers
cannot push forward themselves simultaneously.

Or perhaps you are not trying to say such things?

If Axiom is not moving forward, why?  Because of `archaic' technology?
Autistic developers?  Ghettos?  I would be very interested in some
concrete proposals to remedy the situation, if it exists, ASAP.

You have mentioned a bunch of other faults too, like Axioms history
and the impact that has on perception.  How are we to remedy this?
Perhaps the answers to my previous paragraph suffice?

What are we going to do about the `two generation' gap between Axiom's
algorithms and those available today?  This is one of the questions I
am hoping to help answer by the compiler work I am doing.  A robust
compiler will go a long way, I hope.  I might be able to update/add a
few domains to the algebra, but unfortunately I do not have the skill
set to make an appreciable dent in the problem.

At the moment I see various people with various sets of skills
contributing in whatever way they can -- all of whom have good
intentions.  How are we to ensure that this does not damage the
project further in the eyes of the wider community of experts?

\start
Date: Sun, 29 Jul 2007 08:49:54 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: literate programming and Claerbout's Insight
Cc: Gabriel Dos Reis

--- Bill Page wrote:

> I do not agree that open source is a completely "different ballgame".
> As Tim has explained even when Axiom was a research project at IBM is
> was quite freely given out to those researchers who had a real
> interest in it.

Well, I can't speak for others but for myself I would have had little
interest in such a tool.  Part of the appeal of open source is that it
is an explicit, public granting of permission to modify, tweak, and
distribute.  The last step sounds legally problematic without that
guarantee - there's too much chance of managers/lawyers shutting the
party down.
 
> And even during the time that Axiom has been officially open source,
> by far the majority of the new Axiom users would seem to prefer to be
> able to use Axiom in essentially the same way as if it were a
> commercial product.

Of course!  We all want a finished product we can use, but Axiom ISN'T
THERE YET.  So the project is to create that tool, using the released
code from IBM/NAG as a starting point.  HOW we do that seems to be the
issue at hand.  FriCAS is trying a different approach, and I fully
expect for the majority of users it will be (in the short term) the
more appealing output.  But for myself immediate appeal is less
important than long term foundation building, even at the cost of
longer lead times.

> If it doesn't work rather quickly for them, then
> they just look elsewhere rather than joining the project and trying
> to improve it. Only a small minority are willing to do that.

That was my impression from the beginning.  However, the long term
potential of the Axiom approach was ultimately what convinced me to
stay here rather than resume with Maxima - the up front effort looks to
me like it has an impressive long term payoff.  Maybe I'm just a
statistical anomaly.

> But the point is that these would better be addressed *first* before
> settling in to even harder to achieve long term goals like making all
> of Axiom a literate program.

Isn't that what FriCAS is likely to achieve?
 
> I think most people would be willing to concede this point if they
> get the feeling that something is really being done about it.

Eventually I expect it will.  I don't think we are ready to tackle
Algebra design yet - certainly not without either SPAD or Aldor in good
shape, at a minimum.

> What is truly wrong with the foundation on which Axiom was originally
> built? The build environment inherited from the 80's and which for
> the most part persists in the Axiom Gold and Silver was certainly not
> consistent with what is currently considered best practice, but that
> his been addressed in the build-improvements branch.

In the long term, you want ALL the code in the project to be literate,
easily understandable, and easily fixed.  As I understand it, the
original foundation in Axiom doesn't really satisfy any of those goals.

> Contrary to when I started working with Axiom, I no longer consider
> literate program an essential part of this foundation.

I disagree.

> I think that is a different issue. I still believe literate
> programming to be a worthwhile long term goal - especially for the
> the Axiom library (Spad) code. I am just not convinced that we really
> know how to do it.

Well, I don't know how we will figure it out unless we try.

> And I don't think this should stop the further development of Axiom
> until we learn to do it right.

We're trying to do it in parallel.  Steve's new tool should be enough
to build on, and if I can get my part of this in some kind of working
order we can begin sorting out system components and examining them.

Note that this doesn't need to stop any sort of work in other branches.
 What is stopping the development of Axiom in other directions?

> I seriously doubt that this "literate re-write" will ever really
> occur. Instead it seems most likely to me that improvements will
> continue to be made via bug fixes and by major new contributions by
> researchers and dedicated Axiom users if there are a sufficient
> number of these so that chances of someone both motivated and
> qualified is sufficiently high.

Well, we will see.  Nothing is stopping any of that from happening, and
a few of us are going to try a literate re-write.  It's an experiment -
it may succeed or fail.  But I believe it is worth trying.

> Reading Spad code is particularly easy. That is what it was designed
> to be: a highly expressive and easy to understand notation for
> mathematical algorithms. In most cases when you look at Spad code and
> compare it to published algorithms the connection and details of the
> implementation and obvious.

Once we can focus on the mathematical parts of this issue I think
things will begin working MUCH better as a project.

> I think this is completely the wrong attitude. It is the "If you
> build it, they will come." approach. (Do you remember that movie of
> a decade ago about the guy who built the baseball diamond on the
> middle of his corn field? What was the title?) Even in the big wide
> world of the Internet I do not think there is any reason to believe
> that this approach will work.

Bill, there is nothing stopping anyone from taking any approach they
like.  A few of us want to pursue the idealistic long term goals. 
Waldek's FriCAS is more pragmatic about getting things done.  Perhaps
the various goals will converge in the end, but I don't think anyone is
going to abandon his/her particular goals at this point.

> > It is probably safe to say it won't be heavy duty speed critical
> > numerical simulations (e.g. those who optimize down to the assembly
> > level) and it is not clear yet whether a system can strive for
> > rigor in the mathematical sense and remain a good
> > "engineering/casual use CAS."  For me, the target audience is the
> > audience that wants to be as sure as humanly possible that the
> > answers they are getting to questions put to the CAS are correct
> > mathematically.  Whether other applications follow from that
> > remains to be seen.  But of course, that's just me.
> 
> I think you are wrong.

What do you mean wrong?  I said "for me, the target audience is...".  I
make no claim that it is a large target audience, the most practical
audience to work toward acquiring, or a shared target audience of the
Axiom developers.  That is strictly a definition of the goals I have in
mind when I work on Axiom, nothing more.  Perhaps success would mean a
re-shaping of the mathematical/computational community methods and
expectations, to REQUIRE such correctness proofs as a starting point.

> You should take a very close look at the large
> number of developers in the Sage project and the kind of (mostly
> leading edge) things they are doing. People have very high
> expectations for computer algebra systems these days. Afterall this
> is the seventh year of the twenty first century.

Certainly.  I never said Sage wasn't an impressive project, but their
goals are different from mine.  Sage is pulling together lots of
different tools to create a very useful system.  Looking at SAGE's long
term goals:  http://sage.scipy.org/sage/doc/html/tut/node6.html  I
don't see anything about incorporating proof generation and checking
into all the various tools they are tying in.  How will they ensure
mathematically correct results across all of those different libraries?
 It looks like they are having to trust the developers of the various
libraries.  Can those libraries all be used to produce proofs of
correctness?

If you go for maximum functionality, that's a good way to get an
audience and do lots of useful things.  I have a somewhat different
interest - I have absolutely nothing against functionality but I want
to be able to provide a robust answer to the question "why should I
trust that this answer is correct?"

\start
Date: 29 Jul 2007 12:17:16 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: literate programming and Claerbout's Insight
Cc: Gabriel Dos Reis

Hi Bill,

Just trying in these posts to get a few concrete suggestions on how
the problems raised can be solved. 

[...]
> ... the majority of the new Axiom users would seem to prefer to be
> able to use Axiom in essentially the same way as if it were a
> commercial product. If it doesn't work rather quickly for them, then
> they just look elsewhere rather than joining the project and trying to
> improve it. Only a small minority are willing to do that.

How does noticing this help the situation?  Are new users more likely
to join in and help improve the project when they get the impression
that the system `just works'?  Certainly this is true for the
algebra, but for the rest of the system?  What is the best approach to
getting a high quality compiler/interpreter/hyperdoc etc working which
does not require rethinking the current system or building new tools?

> > > | As for relic technology, do you mean Axiom's current Algebra
> > > | algorithms or use of Lisp?  Or maybe the 1980s look of Hyperdoc
> > > | and graphics?
> > >
> > > Almost all of those.
> >
> > Well, we've had the Lisp issue out many times before.  As for the
> > others, I agree too - but fixing them is non-trivial.
> >
> 
> But the point is that these would better be addressed *first* before
> settling in to even harder to achieve long term goals like making all
> of Axiom a literate program.

What is harder: Fixing the system and documenting it along the way. Or
fixing the system and documenting it afterward?  I believe the second
approach is much more difficult.  It is almost equivalent to fixing
the system twice.  If you think literate programming should be a long
term goal but not an immediate goal, how do we plan today for the
things we want to do tomorrow without complicating future plans? 


[...]
> I still believe literate programming to be a worthwhile long term
> goal - especially for the the Axiom library (Spad) code. I am just
> not convinced that we really know how to do it.  And I don't think
> this should stop the further development of Axiom until we learn to
> do it right.

How do we learn how to do it without trying?

[...]
> I seriously doubt that this "literate re-write" will ever really
> occur. Instead it seems most likely to me that improvements will
> continue to be made via bug fixes and by major new contributions by
> researchers and dedicated Axiom users if there are a sufficient number
> of these so that chances of someone both motivated and qualified is
> sufficiently high.

I partially agree.  For example, for myself, it is much easier to
write new code in literate form than it is to re-write the existing
system into literate form.  Bug fixes and so on can be accompanied by
modest documentation which can be `reworked' over time into a polished
form if the code it describes is not superseded by other work.
Such modest documentation is not that much different than writing
normal code and supplying a decent paragraph of in-source comments.

[...]
> > CAS developers, at the moment - those interested in what a CAS CAN be,
> > rather than what they are today.  We are building the tools.  They must
> > be built before they can be used.  Who our audience will eventually be
> > depends entirely on what we can create.
> 
> I think this is completely the wrong attitude. It is the "If you build
> it, they will come." approach. (Do you remember that movie of a decade
> ago about the guy who built the baseball diamond on the middle of his
> corn field? What was the title?) Even in the big wide world of the
> Internet I do not think there is any reason to believe that this
> approach will work.

What is the right attitude?  Should I stop building anything more and
just contribute bug fixes?  I might be willing to do that if someone
was paying me.  Perhaps you have an answer which is both productive
and enjoyable?

\start
Date: Sun, 29 Jul 2007 09:40:51 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: literate programming and Claerbout's Insight

--- Gabriel Dos Reis wrote:

> for many, that is not a practical difference -- since they are
> already using commercial systems.

For many, yes.  If functionality is all that is important and the
budget is there, commercial systems are the current obvious choice -
that's why they are commercial successes, after all.

There are other intangible reasons people support open systems and
software.  Open source is often pragmatic in a "get the job done"
sense, but sometimes it really is the concrete manifestation of
idealism.  Like, say, the principle that a system be subject to audit
for correctness down to its foundations by anyone who is interested in
doing so.

> Currently, Axiom isn't.  But if its proponents are convinced that
> they do should their best to chase away "novices", then the system is
> doomed to premature death.

I don't see that we are chasing away novices - we ARE setting goals
that are not easy to meet.  That can be intimidating (Axiom was
initially very intimidating for me) but now I see the reasons for the
methods and the learning curve.  "Nothing worth doing is easy."

> | I would say we aren't ready for use cases where people want to
> | simply use the CAS without developing it in the process.
> 
> yes, but do you want Axiom to indefinitely stay in that state?

No!  But I DO want it to exit that state in a condition that will
establish it as something rock solid, maintainable, and a product
bringing something unique to the CAS world.  I accept that this will
take time and a lot of work - the only way up a mountain is to climb
it.

\start
Date: Sun, 29 Jul 2007 09:53:51 -0700 (PDT)
From: Jocelyn Guidry
To: list
Subject: goals and direction, axiom vs fricas

Gaby,

Would the Fricas project better suit your needs and vision for an open
source CAS?  If not, why?

I also pose that question to Bill Page.

Just curious,
J.G.

\start
Date: Sun, 29 Jul 2007 18:34:27 -0500 (CDT)
From: Gabriel Dos Reis
To: Stephen Wilson
Subject: Re: literate programming and Claerbout's Insight

On Sun, 29 Jul 2007, Stephen Wilson wrote:

[...]

| How does noticing this help the situation?  Are new users more likely
| to join in and help improve the project when they get the impression
| that the system `just works'?

On first order, yes.  I look at other systems, such as GCC, linux, GDB, etc. 

\start
Date: Sun, 29 Jul 2007 18:37:06 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: literate programming and Claerbout's Insight

On Sun, 29 Jul 2007, C Y wrote:

[...]

| > Currently, Axiom isn't.  But if its proponents are convinced that
| > they do should their best to chase away "novices", then the system is
| > doomed to premature death.
| 
| I don't see that we are chasing away novices - we ARE setting goals
| that are not easy to meet. 

When they are told that to look somewhere else, that clearly indicates that
they are not welcome.

\start
Date: Sun, 29 Jul 2007 17:22:19 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: literate programming and Claerbout's Insight

--- Gabriel Dos Reis wrote:

> On Sun, 29 Jul 2007, C Y wrote:
> 
> [...]
> 
> | > Currently, Axiom isn't.  But if its proponents are convinced that
> | > they do should their best to chase away "novices", then the
> system is
> | > doomed to premature death.
> | 
> | I don't see that we are chasing away novices - we ARE setting goals
> | that are not easy to meet. 
> 
> When they are told that to look somewhere else, that clearly
> indicates that they are not welcome.

No, it just means that Axiom is probably not (currently) the tool they
need and may not become that tool given the directions the project is
developing in.  It is an attempt to be helpful, not an attempt to chase
away.  Like any product, Axiom is not suitable for all purposes.

\start
Date: Sun, 29 Jul 2007 22:55:15 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: literate programming and Claerbout's Insight

On Sun, 29 Jul 2007, C Y wrote:

| 
| --- Gabriel Dos Reis wrote:
| 
| > On Sun, 29 Jul 2007, C Y wrote:
| > 
| > [...]
| > 
| > | > Currently, Axiom isn't.  But if its proponents are convinced that
| > | > they do should their best to chase away "novices", then the
| > system is
| > | > doomed to premature death.
| > | 
| > | I don't see that we are chasing away novices - we ARE setting goals
| > | that are not easy to meet. 
| > 
| > When they are told that to look somewhere else, that clearly
| > indicates that they are not welcome.
| 
| No, it just means that Axiom is probably not (currently) the tool they
| need and may not become that tool given the directions the project is
| developing in. 

And when will it be the tool they can use for their need?  In 30 years when
they are retired?

\start
Date: 29 Jul 2007 23:27:26 -0500
From: Gabriel Dos Reis
To: Jocelyn Guidry
Subject: Re: goals and direction, axiom vs fricas

Jocelyn Guidry writes:

| Gaby,
| 
| Would the Fricas project better suit your needs and vision for an
| open source CAS?  If not, why? 

Borrowing a metaphor from a friend, it is like trying to get five cars
to California with only four drivers; standard disclaimer included.  

I believe I've already expressed my opinions about the fork when
Waldek originally posted his intent to fork.

Ideally, I would like a system that gets in a state that attracts the
working mathematicians, in the very short term; not in 30 years.  I
would like them to use Axiom as a vehicule of choice, so that we don't
have to wait two generations before finding hobbyists  that translate
algorithms passe or or no interest to Axiom.  However that possible,
we have to be concrete, we have to get real even though we are aiming
at ideals.  

I fundamentally disagree with the opinion that welcomes the fork so as 
to have the perfect asnwer "go away; go to Fricas."

\start
Date: 30 Jul 2007 01:04:32 -0400
From: Stephen Wilson
To: Gabriel Dos Reis
Subject: Re: goals and direction, axiom vs fricas
Cc: Jocelyn Guidry

Hi Gaby,

Gabriel Dos Reis writes:
> I would like them to use Axiom as a vehicule of choice, so that we
> don't have to wait two generations before finding hobbyists that
> translate algorithms passe or or no interest to Axiom.

I believe I understand the overall point of your response but I am
having difficulty understanding the above sentence.  Could you please
explain?

\start
Date: Mon, 30 Jul 2007 01:49:06 -0400
From: Bill Page
To: Jocelyn Guidry
Subject: Re: goals and direction, axiom vs fricas

On 7/29/07, Jocelyn Guidry wrote:
>
> Would the Fricas project better suit your needs and vision for an open
> source CAS?  If not, why?
>

Yes, from a technical point of view FriCAS currently does better suit
my needs for a ScratchPad-like CAS because of improvements in FriCAS
that are not yet part of Axiom, but I would have to say that it does
not really suit my vision for an open source CAS.  My vision would be
for a project that has a strong appeal both, to a large number of
talented mathematicians as a collaborative research platform and to a
large number of advance users of computer algebra. Because of it's
history I think Axiom has a better chance of this than a project that
was created as a fork of Axiom.

\start
Date: Mon, 30 Jul 2007 02:10:17 -0400
From: Bill Page
To: Stephen Wilson
Subject: Re: goals and direction, axiom vs fricas
Cc: Jocelyn Guidry, Gabriel Dos Reis

On 30 Jul 2007 01:04:32 -0400, Stephen Wilson wrote:
>
> Gabriel Dos Reis writes:
> > I would like them to use Axiom as a vehicule of choice, so that we
> > don't have to wait two generations before finding hobbyists that
> > translate algorithms passe or or no interest to Axiom.
>
> I believe I understand the overall point of your response but I am
> having difficulty understanding the above sentence.  Could you please
> explain?
>

This is my interpretation: He wants working mathematicians to be able
to choose Axiom now for their research rather than emphasizing the 30
year view which he thinks is likely to appeal only to hobbyists who
may have little or no interest in translating more advanced computer
algebra algorithms created meanwhile by mathematicians working with
other systems.

\start
Date: Mon, 30 Jul 2007 10:30:03 +0200 (CEST)
From: Franz Lehner
To: list
Subject: Re: literate programming and Claerbout's Insight

On Sun, 29 Jul 2007, Alasdair McAndrew wrote:
> It may be that the negative views of Axiom are simply due to Axiom
> being very poorly (read "not at all") marketed - there are no
> elementary books about the use of Axiom, and if you go to the Axiom
> website, it is hard to find introductory beginner's or tutorial
> articles.
IMHO the problem are not tutorials, but reference.
)di op operator
)sh domain
are nice but only helpful for the expert.
Somehow the ++ documentation present in the algebra files should make it 
to the terminal as well.

I held a "computer mathematics" class for first year mathematics students 
last year, which was meant to give the students an overview over available 
computer tools, presenting latex, maple, mathematica, matlab/octave, and 
axiom.
Before handing out individual homework assignments at the end, I 
circulated a list and asked them to tell me their favourite CAS.
Out of 44 students, I got the following distribution:

Maple       30
Mathematica  2
Octave      10
Axiom        2

The main argument for maple was the extensive help system with many useful 
examples and the vast number of examples available on the web (well this 
is another bootstrap problem ...); and of course in the first year maple 
is the most useful system for symbolic linear algebra.

> Another problem - which I see as major - is that there is no native
> windows version with documentation (HyperDoc) and graphics.
This is indeed a major problem.
I was surprised that even in this audience, where I expect computer 
literacy to be above average, out of 44 students only 2 were not using 
windows ... 1 Mac, 1 Linux.
In the end at least one of them installed linux just because of axiom ...

\start
Date: Mon, 30 Jul 2007 12:02:15 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: literate programming, Claerbout's Insight and Doyen

On 07/29/2007 06:29 AM, Tim Daly wrote:
> Now that memory kicks in I recall that one original motivation 
> for the Doyen project was to create particular "snapshots" for
> a particular piece of research that could always be reproduced.
> 
> Jose has carefully documented the process of creating a Doyen
> CD so a paper could be published on the CD along with a complete
> Axiom system to sit behind the paper.
> 
> The idea is that you can always reproduce and rerun the paper
> even if the world moves. So Axiom development could continue
> but you could still run last year's papers.
> 
> Thus Martin could build and distribute an environment that has
> the necessary scripts to run his algebra. Or Ralf could distribute
> the combinat environment on a Doyen CD along with traditional
> publications.

CDs are, of course dying out. I would rather like to follow the idea of
LogiWeb. (Recent thread starts at 
http://lists.nongnu.org/archive/html/axiom-developer/2007-06/msg00658.html)

LogiWeb already has the idea of being like a journal. It's like a 
version control system but about scientific papers. Now, if those 
scientific papers contain code or not does not matter. If they contain 
code, all the better. Starting from the references of a paper, it can be 
found out on which other papers (code) the paper rests. So the paper 
plus the logiweb infrastructure actually gives a way to produce exactly 
the same running system as the author had when he produced the paper.

Of course there has to be some thought of how bugs are fixed in such a 
system and how one deals with progressing underlying hardware. But the 
basic idea should be like that.

For bugs, I think one has to review the "change file" idea of Knuth. (I 
did not find time to even find a good reference. But time will come when 
that will be important.)

\start
Date: Mon, 30 Jul 2007 12:54:36 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: mantepse.spad

Hello,

>   <<domain UFPS UnivariateFormalPowerSeries>>=

>   <<dom: UFPS UnivariateFormalPowerSeries>>

I don't know what happened to that file, but on
http://wiki.axiom-developer.org/images/mantepse.spad.pamphlet.pamphlet
I don't find "<<domain ...>>=". But as Tim said, it is in wh-sandbox.
And there it is wrong. Tim, maybe you try the version from the wiki.

> Thus you posted algebra that will not weave.

Tim, you must have meant "tangle". For "weave" that error is completely 
irrelevant.

Waldek, how come that mantepse.spad.pamphlet does not lead to an error 
at tangle time?

wh-sandbox/src/algebra>notangle mantepse.spad.pamphlet > aaa.spad
undefined chunk name: <<dom: UFPS UnivariateFormalPowerSeries>>

The error code of noweb is 2. That should be caught by the document command.

\start
Date: Mon, 30 Jul 2007 04:02:37 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis, Jocelyn Guidry
Subject: Re: goals and direction, axiom vs fricas

-- Gabriel Dos Reis wrote:

> Jocelyn Guidry writes:
> 
> | Gaby,
> | 
> | Would the Fricas project better suit your needs and vision for an
> | open source CAS?  If not, why? 
> 
> Borrowing a metaphor from a friend, it is like trying to get five
> cars to California with only four drivers; standard disclaimer
> included.  

If I understand this correctly, your wish here would be that everyone
concentrate their resources on an immediately practical CAS?

But some of us are not interested in going to California, at least not
now (to further risk the metaphor).  It is a volunteer project.
 
> Ideally, I would like a system that gets in a state that attracts the
> working mathematicians, in the very short term; not in 30 years.  I
> would like them to use Axiom as a vehicle of choice, so that we
> don't have to wait two generations before finding hobbyists  that
> translate algorithms passe or or no interest to Axiom.  However that
> possible, we have to be concrete, we have to get real even though we
> are aiming at ideals.  

If we can get some basic patches merged into the Silver branch, perhaps
we can get close enough to a properly functional state in the main
branch that people can use the system without undue pain.

But what do we do when the Boot centric branch and the Lisp centric
branch begin to diverge?  Which one is "Axiom?"  I appreciate Ralf's
thought of multiple implementations but I would be surprised if it
turns out to be practical.

> I fundamentally disagree with the opinion that welcomes the fork so
> as to have the perfect answer "go away; go to Fricas."

So your stance is rather that everyone should have the same goal?  I
think that is unlikely.  Even if "Axiom" as a project decides to vote
for the "get real" approach all that will do is move the work on other
goals to another venue.  Six of one, half a dozen of the other - same
result in the end.

\start
Date: Mon, 30 Jul 2007 07:05:41 -0500 (CDT)
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: goals and direction, axiom vs fricas
Cc: Jocelyn Guidry

On Mon, 30 Jul 2007, C Y wrote:

| But some of us are not interested in going to California, at least not
| now (to further risk the metaphor).  It is a volunteer project.

I know it is a volunteer project, that is why I don't say 
"everybody must do this".  However, as a volunteerr I suspect I can
express opinion about what where I would like the project to go.

I have no problem with your working on a system that will target
only retirees in 30 years.

\start
Date: Mon, 30 Jul 2007 08:13:45 -0700 (PDT)
From: Jocelyn Guidry
To: Gabriel Dos Reis
Subject: Re: goals and direction, axiom vs fricas

--0-1045709264-1185808425=:36782


Gaby,
Thanks for responding.  This is my "why?"
I've
been following the recent postings and have noticed that many are
political and personal, not technical.  I probably wade a toe depth
into the technical end of the pond, maybe less.  That said, all of this
discord affects my personal life so I am trying to understand it.  I am
qualified for political and personal.:-)

Borrowing a metaphor from a friend, it is like trying to get five cars
to California with only four drivers; standard disclaimer included.  

Meaning the limited resource of developers?

Ideally, I would like a system that gets in a state that attracts the
working mathematicians, in the very short term; not in 30 years.  

Two questions:
1.  Isn't that Fricas' direction?

2.  Was it not clear that Axiom's fundamental goals and direction at
it's inception as this project, were for the long term, LP and
documentation?

I fundamentally disagree with the opinion that welcomes the fork so as 
to have the perfect asnwer "go away; go to Fricas."

I do not believe that anyone "welcomes" a fork.  It appears that there
is a fundamental divergence of direction and resulting cleaving of
flesh.  That's painful.  I can see "welcoming" the cessation of pain,
finish the tear so the flesh can heal.  My toe is hurting.  It must be
much worse for others.

Do you see this divergence as anything but inevitable?  Is that so
bad?  Doesn't it give more choices for developmental models to use?
Do you see anyway these two paths can run concurrently and then merge?
If not, then you can't stop the river.  Let it flow and pick which
side to build your house. I ask these questions to you because you
seem to be the most vocally discontented.  I do apologize in advance
to you or anyone having to deal with my ignorance or naivete of
situation and past discussions.  My intent is not to frustrate or stir
discord but maybe offer a fresh observations.

\start
Date: Mon, 30 Jul 2007 10:25:02 -0500 (CDT)
From: Gabriel Dos Reis
To: Jocelyn Guidry
Subject: Re: goals and direction, axiom vs fricas

On Mon, 30 Jul 2007, Jocelyn Guidry wrote:

| 
| Gaby,
| Thanks for responding.  This is my "why?"
| I've
| been following the recent postings and have noticed that many are
| political and personal, not technical.  I probably wade a toe depth
| into the technical end of the pond, maybe less.  That said, all of this
| discord affects my personal life so I am trying to understand it.  I am
| qualified for political and personal.:-)

this issue affects, I believe, the personal life of many people.

However, I'm not certain the issue is entirely personal or political.

| > Borrowing a metaphor from a friend, it is like trying to get five cars
| > to California with only four drivers; standard disclaimer included.  
| 
| Meaning the limited resource of developers?

limited, scarce, resource of contributors; yes, that is one aspect of it.

| > Ideally, I would like a system that gets in a state that attracts the
| > working mathematicians, in the very short term; not in 30 years.  
| 
| Two questions:
| 1.  Isn't that Fricas' direction?
| 2.  Was it not clear that Axiom's fundamental goals and direction at
  it's inception as this project, were for the long term, LP and
  documentation?

Some people seem to believe that the point of disagreement is that of
LP and documentation.  That is strawman argument -- at least, as far as
I'm concerned or I'm linked to the disagreement.  I've already expressed
my points here many times, and recently posted a link a publically available
document that outlines my views.  As you would notice, they are mostly
technical. 

\start
Date: Tue, 31 Jul 2007 03:12:27 -0400
From: Bill Page
To: list
Subject: Axiom meeting at ISSAC

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

took place on Monday July 30 as planned. There was however very little
discussion about Axiom. :-( In attendance where Barry Trager, Steven
Watt, Emil Volcheck, Gaby Dos Reis, Bill Page plus a few other people
from the ISSAC conference that I did not recognize by name. Notably
absent (though attending ISSAC) was Tim Daly. Needless to say that
considerably reduced the possibility of addressing most of the topics
listed in the meeting proposal.

Never the less it was a useful meeting because Steven Watt was
available to discuss the decision to release Aldor as open source on
August 31.

http://www.aldor.org

The new Aldor open source license

http://www.aldor.org/AldorPublicLicense2_0.html

is a modified BSD-style license which contains a "for non-commerical
use only clause" making it incompatible with GPL. This potentially has
an impact on the possibility of using and distributing Aldor as part
of Axiom unless Axiom were to adopt a compatible license, however that
would mean that Axiom would also become incompatible with GPL.

The only solution offered by Steven Watt was the possibility of
providing the Axiom developer with two or three separate downloads and
corresponding source code respositories, e.g. one for each of GCL,
Axiom and Aldor - each with separate and mutually incompatible
licenses. To completely build Axiom from source code then would
require that the developer or user to download the three components
separately and only combine them in the final build. If would be
possible to distribute a binary version of Axiom with Aldor for
non-commercial use-only provided that it was not built using a GCL
version of Lisp.

Obviously discussion of these licensing conditions could get
complicated and technical in a legal sense and not of interest to all
Axiom developers so I would proposed that we continue the discussion
of this issue (if at all) only on the separate axiom-license email
list.

There was also a short discussion of a similar nature about the legal
status of the name Axiom, e.g. is it a trademark or not. The general
conclusion was that if the name still has any status as a trademark it
would very likely be held by NAG. The proposal therefore was to
address this question to Mike Dewar.

There was no discussion about the recent fork of Axiom called FriCAS
except to note that open source licensing allows the creation of such
new projects and that this would also apply to the new release of
Aldor provided of course that it's licensing conditions were met.
Stephen Watt stated that he would "welcome" such a development in the
case of the Aldor project.

\start
Date: Tue, 31 Jul 2007 05:29:26 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Axiom meeting at ISSAC

--- Bill Page wrote:

> http://www.aldor.org/AldorPublicLicense2_0.html
> 
> is a modified BSD-style license which contains a "for non-commerical
> use only clause" making it incompatible with GPL. This potentially
> has an impact on the possibility of using and distributing Aldor as
> part of Axiom unless Axiom were to adopt a compatible license,
> however that would mean that Axiom would also become incompatible
> with GPL.

Yep.
 
> The only solution offered by Steven Watt was the possibility of
> providing the Axiom developer with two or three separate downloads
> and corresponding source code respositories, e.g. one for each of
> GCL, Axiom and Aldor - each with separate and mutually incompatible
> licenses.  To completely build Axiom from source code then would
> require that the developer or user to download the three components
> separately and only combine them in the final build. If would be
> possible to distribute a binary version of Axiom with Aldor for
> non-commercial use-only provided that it was not built using a GCL
> version of Lisp.

Right.  SBCL or CMUCL could probably be used for such a purpose,
assuming anyone wanted to develop that direction.

> Obviously discussion of these licensing conditions could get
> complicated and technical in a legal sense and not of interest to all
> Axiom developers so I would proposed that we continue the discussion
> of this issue (if at all) only on the separate axiom-license email
> list.

Fair enough if we get into the nitty gritty, but one question here - is
there anyone who is interested in using Aldor given this non-commercial
clause?

> There was also a short discussion of a similar nature about the legal
> status of the name Axiom, e.g. is it a trademark or not. The general
> conclusion was that if the name still has any status as a trademark
> it would very likely be held by NAG. The proposal therefore was to
> address this question to Mike Dewar.

So you don't agree with Tim's analysis here? 
http://lists.nongnu.org/archive/html/axiom-developer/2007-07/msg00147.html

I suppose there's no reason not to ask NAG, but clearly they aren't
selling Axiom any longer and their commercial trademark HAS lapsed:

http://tess2.uspto.gov/bin/showfield?f=doc&state=nv64tg.4.1
http://tess2.uspto.gov/bin/showfield?f=doc&state=nv64tg.4.2

>From that standpoint, I think Tim HAS established a clear common law
right to the Axiom name, unless someone was using it before him - from
the uspto FAQ http://www.uspto.gov/web/offices/tac/tmfaq.htm#Basic001

What are common law rights?

Federal registration is not required to establish rights in a
trademark. Common law rights arise from actual use of a mark.
Generally, the first to either use a mark in commerce or file an intent
to use application with the Patent and Trademark Office has the
ultimate right to use and registration. 

and from the Application section:

Who may file an application?

Only the owner of the trademark may file an application for its
registration. An application filed by a person who is not the owner of
the mark will be declared void. Generally, the person who uses or
controls the use of the mark, and controls the nature and quality of
the goods to which it is affixed, or the services for which it is used,
is the owner of the mark. 

Tim's project in its original form clearly picked up the name after
NAG's claim lapsed, unless I'm missing something.  If he's actually
gotten competent legal advice about the point, and both that advice and
the FAQ section of uspto.gov seem to indicate the same thing... what am
I missing?  Is there a reason I'm not aware of that Tim WOULDN'T have
the trademark?

> There was no discussion about the recent fork of Axiom called FriCAS
> except to note that open source licensing allows the creation of such
> new projects and that this would also apply to the new release of
> Aldor provided of course that it's licensing conditions were met.
> Stephen Watt stated that he would "welcome" such a development in the
> case of the Aldor project.

That's probably a moot point, at least at the present time - why would
anyone want to fork Aldor?

My opinion is that the non-commercial restriction is a no-go - I would
prefer to work with Steven on his new language.  (Which I really should
quit calling SPAD+ - maybe since the ADA implementation copped the A#
name (I had forgotten about that) we could call a new SPAD for Axiom B#
and the eventual improved user language B-Natural? Those are even
sound-alikes for the purposes of the languages - "Be sharp" for
rigorous math and "Be natural" for user interaction fits pretty well.)

\start
Date: Tue, 31 Jul 2007 10:13:11 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Axiom meeting at ISSAC

On 7/31/07, Cliff Yapp wrote:
> --- Bill Page wrote:
>
> Fair enough if we get into the nitty gritty, but one question here - is
> there anyone who is interested in using Aldor given this non-commercial
> clause?
>

Certainly there are since there are some people using Aldor now and
none of these would qualify as commercial as fas as I know.

Can you suggest a credible commercial use? Do you know of any
commercial use of Axiom? I dont think this is really the issue. The
problem as I see it is lack of compatibility with GPL.  According to
Stephen this is deliiberate on the part of NAG. Apparently they object
to the "viral" natue of GPL.

>
> So you don't agree with Tim's analysis here?
> http://lists.nongnu.org/archive/html/axiom-developer/2007-07/msg00147.html
> ...

I dont know anything about Intellectual property laws in the US but
isnt "Axiom" too common a word to qualify as a trademark?

\start
Date: Tue, 31 Jul 2007 17:03:49 +0200
From: Ondrej Certik
To: Bill Page
Subject: Re: Axiom meeting at ISSAC

> Certainly there are since there are some people using Aldor now and
> none of these would qualify as commercial as fas as I know.
>
> Can you suggest a credible commercial use? Do you know of any
> commercial use of Axiom? I dont think this is really the issue. The
> problem as I see it is lack of compatibility with GPL.  According to
> Stephen this is deliiberate on the part of NAG. Apparently they object
> to the "viral" natue of GPL.

The main problem is, that the new license is not open source according
to the OSI definition (http://www.opensource.org/docs/definition.php),
the very first sentence
"The license shall not restrict any party from selling or giving away
the software as a component of an aggregate software distribution...."

So it cannot go to the Debian main distribution, and that of course is
a major problem, at least for me. There are many open source licenses
incompatible with GPL, for example the old BSD license, so Aldor could
use that one.

\start
Date: Tue, 31 Jul 2007 08:43:12 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Axiom meeting at ISSAC

--- Bill Page wrote:

> On 7/31/07, Cliff Yapp wrote:
> > --- Bill Page wrote:
> >
> > Fair enough if we get into the nitty gritty, but one question here
> > - is there anyone who is interested in using Aldor given this
> > non-commercial clause?
> 
> Certainly there are since there are some people using Aldor now and
> none of these would qualify as commercial as fas as I know.

At the moment, probably not.

> Can you suggest a credible commercial use?

Yes.  Suppose a scientific journal decides to adopt the literate
programming journal concept, using Axiom as its foundation.  The papers
in the journal would become part of the functionality of the system. 
In order to maintain the organization and ensure the development
activity needed to keep Axiom working on all target platforms, they
need enough of a revenue stream to survive.  A logical way to do this
is to have the latest and greatest papers and Axiom available only to
subscribers.  After some time period (5 years seems logical to me) the
previous work is released into the Modified BSD Axiom for the world to
build off of.  In this fashion, they maintain a large user base but get
support from researchers and companies needing the latest and greatest
work.  (Those people, incidently, would also be the most logical
financial supporters of such an effort.)  It would probably be a good
plan to have an option to publish for immediate release, at some extra
cost to the publishing institution, or to have a "fund" for each paper
that once it reaches a certain point, if that point is before the
automatic 5 year release, it is "let go" early.

The development of Ghostscript proceeds in a similar way, although it
is not commercial in its initial stages - the latest version uses
Aladdin public license (IIRC) and older versions are released as GPL.

If Axiom depended on Aldor, it could not be used for such an
undertaking.

> Do you know of any commercial use of Axiom?

At the moment, no.  I am not willing to postulate that there will never
be such use.

> I dont think this is really the issue. The
> problem as I see it is lack of compatibility with GPL.  According to
> Stephen this is deliiberate on the part of NAG. Apparently they
> object to the "viral" natue of GPL.

Erm.  That's very unfortunate, as it automatically introduces a
collision with a large part of the open source world.

> > So you don't agree with Tim's analysis here?
> >
>
http://lists.nongnu.org/archive/html/axiom-developer/2007-07/msg00147.html
> > ...
>
> I dont know anything about Intellectual property laws in the US but
> isnt "Axiom" too common a word to qualify as a trademark?

The fact that NAG DID have it registered as a trademark when it was a
commercial product would seem to be conclusive proof that it is not too
common to qualify.  Many other "common" words act as trademarks - have
a look in the uspto's trademark search engine.

\start
Date: Tue, 31 Jul 2007 18:05:58 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Axiom meeting at ISSAC

On 7/31/07, Cliff Yapp wrote:
> --- Bill Page wrote:
> ...
> > The problem as I see it is lack of compatibility with GPL.  According to
> > Stephen this is deliiberate on the part of NAG. Apparently they
> > object to the "viral" natue of GPL.
>
> Erm.  That's very unfortunate, as it automatically introduces a
> collision with a large part of the open source world.
>

Yes, I agree. Several people including me have been trying hard to
convince NAG of this but they were not convinced. At least they are
going ahead with an "open source" release of some kind. I don't think
this is the last statement on this issue and there may yet be ways to
convince them to change the license to something more compatible. In
particular Emil Volcheck from ACM is also a strong supporter of a
truly open source license for Aldor and has offered som advice on how
to promote this through the official "political" processes at ACM.

\start
Date: Tue, 31 Jul 2007 20:54:05 -0400
From: Didier Deshommes
To: list
Subject: Axiom meeting at ISSAC

---------- Forwarded message ----------


On 7/31/07, didier deshommes Didier Deshommes wrote:
> ...
> How much of Axiom is written using Aldor?

None of the open source version of Axiom is written in Aldor.

> Will it become an important part of Axiom in the future?

Many people hope so.

> Does Axiom really need Aldor?

Aldor is the "2nd generation SPAD" compiler. Compared to SPAD, Aldor
is very pleasant to use. It gives meaningful error messages and
implements a subset of Spad that is very convenient for many
programming tasks (esp. full implementation of dependent types).

> I'm asking because Aldor is mentioned a lot on this list, even though it is
> currently a product that has incompatible license with Axiom (and was
> even previously a closed-source program).
>

So was Axiom. In fact what Axiom was a commerical program Aldor was
included with Axiom. It is just a historical accident based on the
personal motivations of the people involved in the decision to open
source Axiom that Aldor was not already included when Axiom was made
open source. Unfortunately now the people involved at NAG have a
different idea about what they want to do with this software.

> I'm not a developer, so I don't know how important Aldor is to Axiom.
> If it's really important, than maybe Axiom should consider changing to
> a more accommodating license. If not, I say we forget about Aldor (and
> maybe even build something better).  It seems to me that one year from
> now, we will still be talking about this and not much progress will
> have been made.
>

That might well be the decision made by the Axiom project based on
similar comments to this effect previously made by Tim Daly. I have
previously argued that that will have a negative impact on Axiom's
future and I am still of that opinion.

\start
Date: 31 Jul 2007 21:18:26 -0400
From: Stephen Wilson
To: Didier Deshommes
Subject: Re: Axiom meeting at ISSAC

Didier Deshommes writes:
> > If not, I say we forget about Aldor (and maybe even build
> > something better).  It seems to me that one year from now, we will
> > still be talking about this and not much progress will have been
> > made.

FYI, this is already being seriously pursued in an experimental branch
of the Axiom system, and the Aldor question does not impact that
effort.  If at all interested in the details, please do not hesitate
to ask.

\start
Date: 31 Jul 2007 21:54:16 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Axiom meeting at ISSAC

Greetings!  AFAICT:

1) You can build axiom atop a stripped down version of GCL under an
   LGPL license, removing the conflict.  It could still never get into
   Debian.

2) The only rationale for a non-commercial use clause that I can see
   is to keep open the possibility of a controlled separate licensing
   to particular entites for commercial use.  Thus, open Aldor ideally
   could make significant strides which would be available to the
   commercial version, but the latter could "embrace and extend" the
   former, effectively co-opting this work and potentially draining
   open Aldor of its user and developer base.  The copyright holder
   can argue that they earn the moral right to this option with the
   initial source release, but the point as I see it is that no
   volunteer should consider sinking in large quantities of time and
   labor in scaling a steep learning curve and improving the system
   for free if the system isn't effectively guaranteed a very long
   lifetime as a vibrant open source project.  The calculus for a
   volunteer is that the benefit accrued from one's own learning and
   that of many others over a long payoff period more than compensates
   for the time lost upfront scaling the learning curve and possibly
   tailoring the system to any particular needs.

Just my $0.02.

Take care,

  "Bill Page"
   Bill Page writes:

> On 7/31/07, Cliff Yapp wrote:
> > --- Bill Page wrote:
> > ...
> > > The problem as I see it is lack of compatibility with GPL.  According to
> > > Stephen this is deliiberate on the part of NAG. Apparently they
> > > object to the "viral" natue of GPL.
> >
> > Erm.  That's very unfortunate, as it automatically introduces a
> > collision with a large part of the open source world.
> >
> 
> Yes, I agree. Several people including me have been trying hard to
> convince NAG of this but they were not convinced. At least they are
> going ahead with an "open source" release of some kind. I don't think
> this is the last statement on this issue and there may yet be ways to
> convince them to change the license to something more compatible. In
> particular Emil Volcheck from ACM is also a strong supporter of a
> truly open source license for Aldor and has offered som advice on how
> to promote this through the official "political" processes at ACM.

\start
Date: 31 Jul 2007 22:24:49 -0400
From: Stephen Wilson
To: Camm Maguire
Subject: Re: Axiom meeting at ISSAC

Camm Maguire writes:

> Greetings!  AFAICT:
> 
> 1) You can build axiom atop a stripped down version of GCL under an
>    LGPL license, removing the conflict.  It could still never get into
>    Debian.
> 
> 2) The only rationale for a non-commercial use clause that I can see
>    is to keep open the possibility of a controlled separate licensing
>    to particular entites for commercial use.  Thus, open Aldor ideally
>    could make significant strides which would be available to the
>    commercial version, but the latter could "embrace and extend" the
>    former, effectively co-opting this work and potentially draining
>    open Aldor of its user and developer base.  The copyright holder
>    can argue that they earn the moral right to this option with the
>    initial source release, but the point as I see it is that no
>    volunteer should consider sinking in large quantities of time and
>    labor in scaling a steep learning curve and improving the system
>    for free if the system isn't effectively guaranteed a very long
>    lifetime as a vibrant open source project.  The calculus for a
>    volunteer is that the benefit accrued from one's own learning and
>    that of many others over a long payoff period more than compensates
>    for the time lost upfront scaling the learning curve and possibly
>    tailoring the system to any particular needs.
> 
> Just my $0.02.

Thats worth a lot more than $0.02, IMHO.
\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
