[Top][All Lists]

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

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

From: Ralf Hemmecke
Subject: [Axiom-developer] Re: Aldor and Axiom (was Re: What is SubDomain)
Date: Tue, 14 Feb 2006 13:35:20 +0100
User-agent: Thunderbird 1.5 (X11/20051201)

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?

I am not so sure about, the libalgebra sources. Though I have access to them, I have never seen them distributed from 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 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

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
  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:
Type: MyType
(2) -> i:INT := m
   Internal Error
   The function coerce with signature hashcode is missing from domain

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


reply via email to

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