[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Embedding Axiom

From: Tim Daly
Subject: Re: [Axiom-developer] Embedding Axiom
Date: Tue, 17 Nov 2009 18:24:20 -0500
User-agent: Thunderbird (Windows/20090302)

M. Edward (Ed) Borasky wrote:

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
Common lisp. For the simple reason that a slow transition from a working version to a working version on a daily basis does not lend itself to a complete language transition. The rewrite will move to ANSI lisp as a simple side-effect of newly written code so it should not matter what
Common lisp you use to host it.
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?

I am building unit-tests for the internal routines as I rewrite them so that I can verify that the rewrite is reasonably correct. The idea of refactoring code is much older than Ruby. See the
"On Lisp" book.

Axiom already has a complete test system built into the build. I rebuild the
system from scratch several times a day, usually after every few routines are merged.

I have spent a little time on the idea of "fuzz testing" Axiom but the pseudo-random generator is a challenge. On possible approach I'm studying is to use a hidden markov model against the Axiom test files to generate "random-but-nearly-valid" inputs. Especially challenging are random inputs that pass the parser and are mathematically "near valid". I think there is a
PhD thesis topic sneaking around in this problem.
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??

ACL2 is written in lisp and there has been a project goal of embedding ACL2 inside the Axiom machinery. There has been some discussion of this topic on this mailing list. ACL2 calls could be made on function definitions using an inherited set of mathematical decorations. Thus, the Group axioms could be added to the Group category and functions implementing operations on the elements could be shown to obey the Group laws (half a dozen PhD
thesis topics a year hidden here)

Why would Haskell be a better platform? Because Haskell is functional? Again, see the book "On Lisp" where the functional programming style is stressed. It was written in 1993.

A Scheme implementation would end up creating Common lisp on Scheme which would
be time consuming.
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.

There was a recent conference on parallel lisp systems (in Japan I think). There is no reason why an independent lisp system could not run each core. That is essentially the same technique as the Java-per-core implementations. A large portion of the lisp system can live in shared,
read-only memory as it works off separate heaps/stacks.

The "new idea" in Go about passing channels on channels is basically just passing closures, a very old lisp trick. Using a message passing paradigm (where objects can be shared or serialized through the message) is easy to do between lisps. Go "parallelism" appears to be implemented by lightweight programs added to a queue which managed dispatch. Go is not
really running on all of the processors but the lightweight threads are.
Speaking of all of this, have you all seen Jeff Bone's "rant":

Programming languages, operating systems, despair and anger

Yes, I saw Jeff's rant and, as an Elder of the Internet, and a very long-time programmer (nearly 39 years) I have to agree with him. I have a hard time finding a new technique that wasn't done in lisp years ago.

Python claims to be lisp-like but they have no clue about macros, program-data equivalence, the cons-nil-()-false equivalence, dynamic environments, real closures, and a host of other useful things. Even their python command-line interpreter doesn't seem to allow techniques that have been available in the lisp break loop. Try modifying a python function on the fly and continuing from
the breakpoint. And forget about creating your own syntactic elements.

Haskell has "lazy evaluation" (see the function "Delay" in the Axiom sources), monads (stateful pseudo-functional programs) which are trivial to write, pattern matching of arguments (see the
partial function definition sequence in Axiom or any prolog-in-lisp).

Go has interfaces without inheritance, a very old idea in Common lisp. I can't wait until they
introduce wrappers and whoppers.

Lisp can modify the compiler internals at compile time by supplying code to manipulate the compiler internal data structures (lisp is a self-syntax tree and macros are source-to-source transforms done at compile time). Lisp programs usually write lisp programs on the fly since programs and data are the same. Try that in Ruby. Or construct programs that learn by self-modification, growing organically to adapt to the input stream by permanent change. Without writing a whole parser/compiler chain I
have no idea how to write self-modifying Python programs.

Languages limit what you can think. Ask any Java programmer about their program and you are likely to hear "design patterns". Ask any lisp programmer about design patterns and be prepared for a laugh.

In any case, Axiom is firmly in the Common lisp camp for the forseeable future.

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?

I looked at the Clojure language running on the Java virtual machine and at the Azul system which is designed to host hundreds of Java VMs in parallel. But the question is, if you're going to use Java VMs why not use Lisp VMs? Lisp compiles to machine code, so why not not host hundreds of Lisps? With a proper implementation you only need separate stacks (or a spaghetti stack) and separate heaps or "clades within a common heap". A Clade-heap modification would allow object sharing or object transport between processes. Immutable data structures is a very interesting idea here.

As for the Axiom internals rewrite/refactor, the intention is to define "semantic layers" that make it perfectly clear where certain functionality should be supported. Algebra concepts should be fairly near the top of the tower with a gradual transition to raw lisp. I would ideally like to be able to write each "layer" in only a few pages of code expressed in the concepts of the previous layer.

If that can be done than it would be possible to teach Axiom by starting at a few-page pile of code and working your way upward or downward as appropriate. A perfect example of this is the standard definition of lisp in lisp code. Such elegance and brevity is the soul of the design.
Imagine understanding all of the algebra support code in two pages.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]