[Top][All Lists]

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

[Axiom-developer] Aldor and Axiom (was Re: What is SubDomain)

From: C Y
Subject: [Axiom-developer] Aldor and Axiom (was Re: What is SubDomain)
Date: Mon, 13 Feb 2006 11:42:20 -0800 (PST)

--- Ralf Hemmecke <address@hidden> wrote:

> To me it doesn't matter whether the code is in BOOT or LISP. BOOT is
> not well documented and LISP is too low-level for my taste. Why 
> cannot all this be written in Aldor? And without tricks, please. 
> And, of course, well documented in pamphlets.

I'm beginning to agree that everything that can be in Aldor should be,
for two reasons:

a)  It's more self contained - e.g. the parts that involve being
compatible with anything except Axiom/Aldor are minimized.

b)  It will minimize the "communicating between multiple languages" and
"neeed to learn multiple languages" problems

That said, if Tim has already redone a given part in Literate Lisp,
it's not worth redoing his work in Aldor for the forseeable future -
work of that quality can't be easily duplicated and for certain aspects
of Axiom Lisp is in fact a good match.

> The problem is that the Aldor compiler is still not open source. :-(
> But it already comes with a primitive FOAM-interpreter. I have no
> idea how difficult it would be to write a new interpreter from 
> scratch in  Aldor compared to clean the old interpreter/spad-
> compiler code.

I can't help wondering if the material in the Reference section of the
Aldor Users Guide might be enough for us to define at least a basic
Aldor compiler in Lisp, and build on that.  If I'm understanding
correctly, most of what we would like to use from Aldor actually is
available in source code form, with the BSD+extra rights for
license?  And the most critical, libaldor and libalgebra, are Manual
Bronstein's work and might be releasable under plain Modified BSD
without having to unravel the knot?

If this is the case, it might be workable to implement a minimal Aldor
compiler in Lisp, building off of the knowledge already existing in the
code for SPAD compilation and the Reference section in the Aldor User
Guide.  Call it A# to avoid confusion, at least once we have a working
version.  I imagine we might want to develop Aldor a bit, and if doesn't follow our changes it would be better not to confuse
the two.  That resolves two things:  a)  Both our existing Lisp code
and other useful Lisp code can still be easily handled and integrated
into Axiom, since the foundation language will still be Lisp and b)
will let us get down to business ordering, documenting, designing, and
making robust the Aldor level algebra of Axiom.  

> >>Right. That is the reason why it is actually easy to learn 
> >>Aldor. There are only a few language constructs that you have
> >>to remember. It is much harder to learn what is available
> >>through libraries. Unfortunately, there are several libraries
> >>around and except that builds upon,
> >>there are many incompatibilities between libaxiom and
> >>libalgebra.

Would it be a forlorn hope that, if Aldor is easier to learn because
there are only a few language constructs, its compiler might also be
easier to define?

> > In Axiom I think we only get to use libaxiom. Using the Aldor
> > native library would be very complicated because of differing
> > internal implementations. Right?
> The Axiom algebra code must be put into proper pamphlets anyway. It 
> should be translated into Aldor. So way not taking the libalgebra 
> sources of Aldor? That spares some rewriting of the code. Don't
> believe that it is so simple to translate SPAD into Aldor. I 
> somehow think it would be cleaner to start building from existing
> Aldor libraries.

I'm beginning to agree.  They would still need to be audited to make
sure they are up to Axiom's standards as Literate Documents, but if
they are cleaner and more robust while building on the same basic ideas
as Axiom's algebra it would make many things simpler.

> Having for a while two branches while adding code from Axiom to the 
> Aldor libraries. That is a lot of work, but I would feel better 
> concerning the foundations of the domains and categories in Axiom.

I think a more robust foundation will save work down the road.  The
grunt work of converting source code into literate papers documenting
the ideas will be the same regardless.

> What I really don't like is that in Axiom sometimes information is
> added by the compiler/interpreter which does not exist in the .spad
> file  itself. Type information that is guessed by the compiler is
> just an example.

Hmm.  But aren't there some cases where you want this, like (say)
knowing that 4 is a real integer without having to explicitly say that?
 (Sorry that's probably a dumb question).

> > I think it should be possible to implement NNI (NonNegative
> > Integer) and PI (Positive Integer) without the use of SubDomain.
> > Maybe just an import of Integer would do? I do not know of any
> > specific case where the knowledge that NNI and PI are "subdomains"
> > of Integer is actually used.
> Oh, that is a good suggestion. But maybe some code relies on
> elements being NNI or PI. To find this out, one can only go by hand
> through all the tons of code lines. :-( So it cannot be discarded
> immediately.
> But when transferring to Aldor, one has to decide anyway what to do.

I think a tutorial on moving SPAD code to Axiom will eventually be a

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

reply via email to

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