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. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
