axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Future of Axiom design


From: Ralf Hemmecke
Subject: [Axiom-developer] Future of Axiom design
Date: Tue, 08 Nov 2005 13:05:32 +0100
User-agent: Thunderbird 1.4 (X11/20050908)

Hello,

I don't want to take part in that discussion about whether BOOT should remain or not. Good documentation is one thing, but there should be some goal of where we want to get Axiom finally.

Converting Boot code to Lisp is trivial - just run the compiler.
But the compiler's output is mostly useless. It only(?) uses lists and
maybe vectors and the code it generates is pretty ugly. I'm offering
to rewrite BOOT code in Lisp by hand. That requires some redesign,
especially considering that Aldor is the goal, and so I'm waiting for
Tim to tell me where to start or what to do.

From the mails I read so far, one point seems to be agreed upon.

Aldor should be the language of choice for further development of the ALGEBRA.

However, I have not seen a rough plan for the overall design of Axiom.
(Did I miss something?)

Now the discussion goes LISP vs. BOOT, but is there perhaps also some plan to finally replace both LISP and BOOT AND SPAD by Aldor? The Aldor compiler already exists (and it needs a lot of work to make it more stable). For license issues see
http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00276.html.

I have not much experience with (writing) interpreters, but I could imagine the following:

Build the ALGEBRA with the Aldor compiler generating .o (or .lisp) files.

Add "reflections" to the runtime-system (similar to reflections in JAVA) so that an interpreter (written in Aldor or any other language) can get information about the available types in order to do its job.

I have no knowledge about the internals of .o files, but wouldn't it be possible to have the interpreter call the functions from the .o files dynamically? For new functions the interpreter would call the compiler and generate some temporary .o files.

This would be my vision of how Axiom should be heading to.

I hope this motivates others to post their views on the future of Axiom.
Maybe we can converge to some steps that are needed to reach the final goal.

Ralf






reply via email to

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