So: a. Is it to be Common Lisp rather than Scheme? Should it work (and be tested) with all three major open-source platforms (clisp, sbcl and gcl)?
b. The kind of test / behavior driven development such a massive refactoring requires is "usually" done in Ruby these days. Are there Lisp-based tools for this so the project could "eat its own dog food", or would there need to be some "scaffolding" built in a "scripting language" like Ruby or Python? c. Aren't there more "Lisp-like" theories of mathematics and implementations of them? I'm thinking of Automath, but I suspect there are others. And there are certainly Prolog-like systems, proof engines, etc. The current crop of "functional" languages (Haskell, Erlang, OCaml, etc.) does seem like a better platform for this sort of thing than Common Lisp. Scheme would make sense if we wanted to push this into undergrad / high school curricula, though. Summer of Code?? d. Hardware? This stuff needs lots of cores and RAM - maybe another reason to use a more modern language like Erlang with explicit and "provably correct" concurrency primitives. Speaking of all of this, have you all seen Jeff Bone's "rant": Programming languages, operating systems, despair and anger http://bit.ly/1xtACU Perhaps computational mathematics should be designing their own operating system and programming language for computational mathematics, using something like the LLVM (low-level virtual machine) or DROPS (Dresden Real-time OPerating System) kernel. Or the Intellasys Forth-based SEAforth array processor? http://bit.ly/2t4e3C > A rewrite from scratch? Well, more like a "remolding of the clay" than a > rewrite. > The idea is to move from a working system to a working system with each > change, but > eventually restructure the internals cleanly. At the moment I am in the > process of > restructuring the interpreter/compiler into literate form (book volume 5). > As I do > this I am rewriting the code to be functionally equivalent. > > The above comment about finding the basis set for the algebra amounts to > finding > every lisp-source-level function call from every lisp algebra object. I > wrote a > "calls" function to walk lisp code and extract the non-common-lisp function > calls. > > This set will be gathered, arranged, and studied. The idea is to find the > "right level" > of abstraction (ala "On Lisp" and "Structure and Interpretation"). This > level of > abstraction forms the current base language hosting the algebra. It forms a > design > target for the top level embedded layer. Next we re-arrange the system to > make this layer > explicit (define an API, so to speak). Then we recurse the process with the > new layer. > > Code in the system that uses nothing but common lisp calls forms the other > end of > the spectrum. The game is to build the two layers toward each other in a > disciplined > way so that each layer embeds properly in the prior one. Because Axiom was > written by > so many different people the internals are more like "tent poles" of > functionality > where each one builds from nothing all the way to the top, reproducing > common ideas > in different ways. > > Along the way the code needs major cleanup work. On Lisp and SICP stress > using > functional programming but the Axiom internals are wildly coupled through > the use > of special variables. Some of these can be eliminated with extra arguments > and > most of those that cannot will still be able to be limited using lexical > closures. > > In addition, the use of Boot code led to a fantastic amount of list > processing > where it is not appropriate. Major structures in the system should be > defstruct > objects or some other kind of structuring. Because of the Boot idioms it is > next > to impossible to find all the places a data structure is modified. > Side-effecting > global state happens all over the place. Now that the boot code is gone the > data > can take a more natural and better disciplined shape. > > Even better for the long term would be to make each structure immutable (see > "Purely Functional Data Structure" by Chris Okasaki). This would make it > much easier > to move the system to a parallel base of code. This level of rewrite is on > the queue > to think about and study but might take some experimenting. > > I have roughly 140 files still to merge into the interpreter volume and it > takes about a > week of moving/testing/documenting/rewriting/xrefing/latexing for each one > so this > is going to take a while. > > > Tim > > > > _______________________________________________ > Axiom-developer mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/axiom-developer > -- M. Edward (Ed) Borasky http://borasky-research.net "I've always regarded nature as the clothing of God." ~Alan Hovhaness _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
