[Top][All Lists]

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

Re: [Axiom-developer] Re: lisp portability

From: Gabriel Dos Reis
Subject: Re: [Axiom-developer] Re: lisp portability
Date: Tue, 22 May 2007 17:06:05 -0500 (CDT)

On Tue, 22 May 2007, C Y wrote:

| --- Gabriel Dos Reis <address@hidden> wrote:
| > Here is what I'm suggesting:
| > 
| >   * Abandon the idea that Axiom should be rewritten completely in
| >     Lisp. That is both pointless, resource waste.
| As far as I know, the only parts of Axiom anyone was advocating doing
| this for were up to and including the SPAD compiler - after that point,
| Algebra would be done in SPAD (or Aldor, depending on how things work
| out.)  I assume this is what you are referring to?


| >   * Write as little as possible in Lisp.  Just the bare minimum 
| >     necessary to boot Boot.
| You mean, write a bootstrap only Boot in Lisp, and then use that to
| handle the "full" Boot?

Not Boot in Lisp.  Just the tiny bits that are need in Lisp.
See src/boot/initial-end.lisp for something that is close to what
I would consider the minimal bits needed.

| >   * Write the code of the compiler in Boot (when we cannot write it
| > in Spad). 
| >    
| >   * Improve Boot -- I already have enough to get rid of most of
| >     Lisp forms.
| > 
| >     In particular, pay attention to resist the temptation of letting 
| >     Lisp variabilities enshrine into the Boot interface.
| > 
| >     Rely on the mechanimsation at the Boot translator level to
| >     achieve things that are painful to do directly at the bar Lisp
| >     level.
| Um - "enshrining Lisp variabilities" - you mean basing any part of Boot
| on anything that may vary between Lisp implementations?

I would like Boot to completely shield us from those Lisp details that vary
from implementations to implementations.  Some people consider that 
long list of #+ and #- are good way to write good codes.  I don't.

| >   * For Axiom runtime system: Think of Lisp as just on assembly
| >     language Axiom can be compile to.  Define a Virtual Machine for
| >     Axiom (yes, I klnow of FOAM).  In particular, have the algebra
| >     files depend only on the Axiom Virtual Machine instruction set.
| I think that is a separate issue from Lisp, and one I think is a good
| idea - particularly from a theoretical standpoint.  That way, a formal
| verification in Axiom can take place in terms of the Axiom Virtual
| Machine, and it is up to the implementation to correctly implement the
| Virtual Machine behavior.


| I know I'm not really qualified to have an opinion on this issue, but I
| personally like working in the Lisp language and would like to continue
| with it.  I realize this is an opposing opinion (or at least
| preference) to some very smart people on the list, but if we have a
| proper Axiom Virtual Machine definition it should be a moot point
| anyway - we can have multiple Virtual Machines in the same way Java
| code can run on different implementations of the JVM.

When I say "Axiom Virtual Machine", I'm referring to the specification, not
the implementation.  JVM is the specification; it has many implementations 
[I note also that sometimes people uses JVM to refer to an implementation of
 the specification, instead of the specification itself.]
I do hope that we would have a single Axiom Virtual Machine, and many
implementations around.

-- Gaby

reply via email to

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