[Axiom-developer] RE: Aldor and Axiom

[C Y]

--- Bill Page <address@hidden> wrote:
> > .. 
> > 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.
> 
> This suggestion has been made a few times so I think it's time
> I said that I think it is utterly ridiculous. There is **zero**
> change that we could find experienced Lisp resources to implement
> this idea. I think that someone could only make this suggestion
> if they have **zero** experience with implementing a compiler.
> Repeating this suggestion seems to me to be almost bordering
> on the "irresponsible". (Sorry Cliff, I don't mean to sound
> too harsh but we have so few resources working on Axiom that I
> worry that such unrealistic ideas can only serve to divert our
> attention from what we can actually accomplish.)

No problem - I definitely don't have experience with implementing
compilers, and I have no desire at all to be "irresponsible".  But from
my perspective (which may or may not be accurate) we are being hindered
by the uncertainty surrounding SPAD vs. Aldor.  If we can't implement
our own Aldor compiler, that's OK, but we can't wait forever for the
one that does exist to be released - projects can die from uncertainty
and lack of momentum.  If some resolution isn't found fairly soon I
would recommend we pick a direction and go, even if it's cleaning up
SPAD and not worrying about Aldor except maybe for a design idea or
two.  I'm more concerned that we get SOME definite direction we can
head in, although perhaps we already do have one and I'm just not
grasping it properly. 
 
> > 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 Aldor.org 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
> > Aldor.org knot?
> 
> No, I think this is the wrong way to think about the problem.
> The problem of licensing and Aldor.org is minor compared to re-
> implementing the Axiom library from the ground up.

I guess I had been under the impression that the work of making the
Axiom library files into true literate documents was going to be little
short of a rewrite no matter what direction was taken - perhaps that is
a mistake on my part.

> > 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?
> 
> Have you looked at any of the statistics about the existing Aldor
> compiler? Number of lines of code? Time and number of people it
> took to do the initial implementation?

A very good point.  My thought was that following an existing design
would require less effort than the orgininal development, but that's a
most uninformed thought so I concede the point.

> > Ralf wrote: 
> > > 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.
> 
> Axiom vs. Aldor libraries is only half the problem and the Aldor
> libraries are currently maybe only about 10% of the solution.
> The other half of the problem is the Axiom interpreter which
> encodes a great deal of knowledge about the Axiom library itself.
> Right now they are tightly couple and one could not throw away
> the Axiom library without also throwing away the interpreter.

Ah.

> > 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).
> 
> The phrase "real integer" is kind of dumb ... :) What other kinds
> of integers are there?

Heh.  None that I know of, but that's not saying much.  I thought units
and dimensions were simple too ;-)

> But the symbol 4 can certainly stand for
> other things besides the integer 4. But in the user interface,
> such as implemented by the Axiom interpreter, it is quite natural
> that unless stated otherwise, this symbol could be assumed to
> represent the element of the positive integers. On the other hand,
> in the SPAD and Aldor compilers, there should be no "guessing"
> of this kind.

OK.

> > I think a tutorial on moving SPAD code to Axiom will eventually
> > be a must.
> >  
> 
> There already is such a tutorial as part of the Aldor documentation.
> Converting SPAD to Aldor is usually very simple. There are just a
> few subtle cases such as the SubDomain construct that we have been
> discussing.

OK.  I guess my confusion comes in with what our actual plan is.  Are
we going to use Aldor.org to work with our existing code base, making a
few tweaks and updates to take advantage of Aldor's features but
keeping the rest as SPAD?  Are we going to try and completely retune
the Axiom codebase to center on the Aldor language?  How do we resolve
things like Aldor's libalgebra vs. Axiom's libraries?  Are we planning
to completely document and update the SPAD compiler?  Are we intending
to link the discussion and definitions of SPAD/Aldor to the core set
theory, category theory, and other foundational mathematical principles
that Axiom is built on?

I realize I'm almost useless for this kind of work, but since it seems
to be the biggest need of Axiom right now I would like to help if I
can, even if it's only something like creating a literate document
introducing basic set theory or category theory (e.g. something I might
be able to grasp in time, but also useful to documenting the core Axiom
system all other work must rely on.)  I guess what I'd most like to see
is a stage-by-stage kind of plan for the Algebra subproject.  Sort of
a:

a)  Document SPAD compiler, foundations in mathematical theory, core
structures of Axiom algebra
b)  Identify and document "core" functionality, which is to say
functionality which a large part of the Axiom system depends on.  Debug
code and concepts, possibly implement unit test framework.
c)  Work our way up the ladder, so to speak.  Higher level
functionality documented as the underpinnings become well documented
and well defined.

type of list.  Maybe this isn't workable with something as involved as
Axiom, but right now it's almost overwhelming - where should one look
first for the job of building a rock solid core on which the subsequent
tuning, debugging, and development can depend?    

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com