RE: [Axiom-developer] Re: libaxiom.a

[Page, Bill]

Tim, 

On Tuesday, March 21, 2006 12:21 PM you wrote:
> 
> Greenspun's Tenth Rule:
> 
> Any sufficiently complicated C or Fortran program contains an
> ad hoc, informally specified, bug-ridden, slow implementation
> of half of Common Lisp.
> 
> Here known as the motto of the narrow minded :-)

No.

I (more or less) agree with "Greenspun's Tenth Rule". I don't
think it is narrow-minded at all. What I said was that to
think that "standalone" means *without* lisp is narrow-minded.
I think we agree, no? I think it is open-minded (in fact almost
essential) to include lisp - or something very much like lisp.

> ...
> The dream was to have a standalone version of the axiom
> compiler rather than an embedded version. I didn't believe
> this was useful then and I still don't believe it is useful
> now.
> ...
> > That's like saying that "stand alone" Fortran doesn't make
> > sense without the IBM 360 or that "C" is of no value without
> > Unix. That is clearly incorrect. As leading-edge compilers,
> > both SPAD and Aldor represent a great deal of value on their
> > own - whether they are used to write Axiom library code or
> > not.
> 
> No, you misinterpret what I wrote. Compilers are not libraries.
> Compilers are only a small part of what you think of as "C".
> It's the libraries that make C useful.

I disagree. It is "C" that made the C libraries possible. I am
not claiming that the libraries are irrelevant - far from it.
Almost all modern languages aim at providing a fundamental,
simple and minimal formalism with which to express algorithms
and they depend to a very great degree on the functionality
contained in the libraries that are written in the language
itself. But not all languages are created equal.

There is a huge discipline (I suppose I cannot say science)
of programming language design. Some languages are clearly
successful and others falter even though in theory they are
all formally equivalent in power when it comes to computation.
Not all of these failures are due to "political" or "personal"
reasons. Some have technical explanations based on credible
theories.

SPAD and Aldor were (and still are) great experiments in
programming language design. Even they were motivated primarily
by the need to solve the particular problems encountered in
symbolic mathematics, all computation is symbolic in the final
analysis so the design of SPAD and Aldor really applies directly
to general computation.

I think the relative inaccessibility of SPAD and Aldor to the
rest of the programming community, outside of the much smaller
subset of computer algebra programmers, has resulted in a
significant duplication of intellectual effort in "modern"
programming languages like Python, Ruby, Haskell, and even C++.
I expect that SPAD and Aldor still have a few "tricks" perhaps
not yet re-discovered by the mainstream, but the longer they
remain dormant, the less relevant they become. Axiom is
dependent on the continued support and development of SPAD
and/or Aldor, so the more widely accessible they are to the
programming language community as a whole, the better it is
for us Axiom users/developers. Otherwise before the "30 year
horizon" is up we (or those who come after us :) are likely
to find ourselves re-implementing the Axiom library in some
descendent of Python or Haskell...

> 
> Aldor is a compiler and, without libraries, is only an
> interesting demonstration of some techniques such as post-
> facto extensions. My argument is that Aldor is not very
> interesting without a strong library. The fundamental
> differences between spad and aldor are quite small.

I agree that the differences between SPAD and Aldor are quite
small. But disagree that they are not interesting without a
strong library. The point of programming language design is to
make it possible to efficiently create such "strong libraries"
in the first place.

Of course to apply SPAD and Aldor to computer algebra problems
does require a very "strong library" and of course the enormous
effort invested in the creation of Axiom's library is still
the strongest part of *Axiom*. But that is a separate issue
from the choice of language that we use to implement that
library.

> ... 
> The Axiom libraries took many, many years to build and they
> depend on an underlying common lisp. To use them standalone
> you necessarily have to duplicate the lisp functions.

Yes, I agree. But really that is not such a "big deal" since
as you already said: all programming languages (to a greater or
lesser degree) tend to implement at least some minimal subset
of lisp. Languages such as Python, Haskell and the even the
"stand alone", i.e. C-runtime environment, of Aldor all provide
the kind of basic functionality that is required implement the
Axiom library. For example, they all have an infinite precision
Integer data type, list data structures, product and union data
types etc.

> 
> If you really want to think about the world from the compiler 
> viewpoint then consider that GCL is just a large library of
> C code that gets linked with your Aldor code and the Axiom
> library code. The AXIOMsys image does all of this linking and
> saves a standalone image.

Yes.

> 
> > What would you suggest might be the minimal GCL environment
> > required to run most of the Axiom library code? Assuming that
> > we do not want to keep any of the Axiom interpreter but just
> > the minimum support for SPAD and/or the Aldor interface,
> > would it be a good idea to start with BOOTSYS or something
> > earlier in the bootstrap cycle? How much work would it be
> > to determine exactly what modules are required? And
> > realistically, how much memory are we likely to save in
> > the resulting "standalone" executable but dropping all
> > the stuff that we don't need?
> 
> Well, BOOTsys can clearly disappear :-)
>

I presume you mean the BOOT to Lisp compiler part of BOOTSYS?
Aren't there other modules compiled into the BOOTSYS image
that are required for the Axiom library? How can we get just
the "deep level" support environment necessary to run the
already previously compiled BOOT code?
 
> You'll notice that I've already done this analysis.
> There are two indications. First, you'll notice that
> some domains are pre-loaded into the AXIOMsys image. These
> are the most frequently referenced domains. Second, you'll
> see that certain lisp routines are autoloaded only when
> asked (the autoload subdirectory). Any routine that is not
> commonly referenced is already out of the image.

Yes, but aren't these domains loaded into a previously
saved Lisp image that already includes BOOTSYS and all
the other stuff that allowed us to get to that point in
the build cycle?

> 
> If you start up an AXIOMsys and "warm it up" by doing the
> kind of computations you want so that it won't have to
> load any more libraries then you can just drop into lisp
> and do a (save-system) call and you have "compiled,
> linked, and saved" a special purpose standalone program
> to do your task. What could be easier?
> 

Sure, but that is not what I would call a "minimal run-time
environment"! We still have all the Axiom interpreter, the
BOOT compiler and a lot of other stuff that we never intend
to use in our "stand alone" program.

Regards,
Bill Page.