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

[Ralf Hemmecke]

> > 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?

I am not so sure about, the libalgebra sources. Though I have access to 
them, I have never seen them distributed from aldor.org. Does anyone 
have differen experience here?

The sources of libaldor are open. They are distributed in source in the 
1.0.2 release.

> > 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?

I guess, that is mostly true for libaldor, but I also added/corrected 
some tiny pieces of code.

A bit of history here... (please correct if you find errors here)
Aldor started with just the library libaxllib (when Aldor was still 
called AxiomXL). Then in the EU-project FRISCO a library basicmath has 
been developed (mostly by NAG, I guess).

Manuel Bronstein was not happy with axllib and started his own library 
salli (Standard Aldor Library).

At some point everything was put together. Salli basically became 
libaldor and many things from basicmath have been rewritten to work with 
libaldor.

Axllib is still in the CVS tree of Aldor, but I wonder who is still 
using it. Maybe Marc Moreno Maza, because I heard rumours that basicmath 
is still in existence an builds on axllib. (I have never really seen 
basicmath, though.)

So libalgebra is probabley mostly the work of Marc Moreno Maza and others.

Anyway, libaldor and libalgebra fall under the APL and there is no other 
license around.

> Axiom vs. Aldor libraries is only half the problem and the Aldor
> libraries are currently maybe only about 10% of the solution.

But that 10% would be a good and quick start in my opinion.

> 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.

Right. I would really like to see the interpreter decoupled from the 
library code. The interpreter should just interpret the code, i.e. 
manage information and not add information. Every little detail must be 
deducible from the library code (even by a humam (with some spare 
time)). Structuring things into digestible pieces is always a good idea.

It would be much better to design a clear interface between the library 
and the interpreter. That would probably mean add a "reflection" 
interface similar to reflections in JAVA. That interface would live very 
low in the domain hierarchy and might not even be of any use to the 
ordinary Aldor programmer, but it would be vital for an Aldor interpreter.

> > > 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.
>
> The Axiom interpret does this by design.

Well, of course, there is a little guess work done with the interpreter. 
But perhaps it would be cleaner to really work out how to implement 
BNatural.

> > > Type information that is guessed by the compiler is just an
> > > example.

> Could you give an example where type information is "guessed" by
> the SPAD compiler?

OK, I have to try a bit... But in the meantime you can look at this bug.

--- file mytype.spad
)abb domain MT MyType
MyType: Cat == Impl where
 Cat ==> with
  coerce: PositiveInteger -> %
  coerce: % -> Integer
 Impl ==> add
  Rep:=PositiveInteger
  coerce(n) == n
--- end file mytype.spad

(1) -> )co mytype.spad
(1) -> m:MT := 1
   Loading /home/hemmecke/scratch/FRAC/MT.NRLIB/code for domain MyType
   Loading /home/hemmecke/software/Axiom/mnt/linux/algebra/PI.o for
      domain PositiveInteger

 LISP output:
1
                                                                 Type: 
MyType
(2) -> i:INT := m
   Internal Error
   The function coerce with signature hashcode is missing from domain
      MyType

How can this be missing? ;-) That is what I meant by the line after the 
Rep. I actually meant both things by that line
  coerce(n) == n
and obviously the compiler understood what I had in mind otherwise it 
would have complained. But unfortunately, the resulting code is not 
correct in the sense I wanted it.

So, whether you see this as a bug of the spad compiler (which it clearly 
is, because it should have told me that my implementation does not 
satisfy the category) or whether this is an instance of the spad 
compiler adding type information does not matter. SPAD allows to write 
ambiguous code and that should clearly be forbidden.

If Axiom wants to be a system that is strongly typed, then there is no 
way out: eventually SPAD has to be left behind.

My suggestion would be even to switch off the SPAD compiler after the 
Axiom library has been built. An ordinary Axiom user should never be 
given the chance to compile SPAD code. He/she should immediately learn 
and use Aldor exclusively. With such a decision the Axiom Team clearly 
says where its future lies.
(I hope I don't get beaten by that suggestion.)

Ralf