Re: [Axiom-developer] Embedding Axiom

[M. Edward (Ed) Borasky]

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
> address@hidden
> 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