axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Re: SPAD and Aldor again


From: Martin Rubey
Subject: Re: [Axiom-developer] Re: SPAD and Aldor again
Date: 17 Nov 2006 16:41:21 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Dear Christian, Gaby, Waldek,

Christian, I'm copying this to you since I think that you have a lot to say
with respect to features and shortcomings of Aldor. I would like to ask you to
join the discussion, time permitting.

Gabriel Dos Reis <address@hidden> writes:

> I would like to see a discussion about what is necessary to support
> computational mathematics in Axiom, rather than how closely SPAD should
> ressemble another language.

I think that this is beyond a group of a dozen part-time developers, and in
fact, I believe that this is very likely beyond the abilities of the average
mathematician. As evidence I'd like to present the "languages" of maple and
mupad, which I believe to be quite inferior (maple: obviously, mupad: very
likely) to Aldor.

Of course, if you or somebody else has the resources, don't hesitate and go
ahead. If not, I'd rather stick (as far as possible) with the semantics of
Aldor.

Don't get me wrong, please: I would not insist on a clone of Aldor, but at
least in the beginning, I think it will be easier to clone certain features.

I did quite a bit of work with Aldor now (within the species project together
with Ralf), and I'm quite convinced of the features of this language. In
particular, the semantics of Aldor feel very "sound" to me, i.e., Aldor usually
does what I expect it to do and allows what I would expect it to allow.

There is another point for staying compatible with Aldor: In that case,
mathematically inclined developers can code using Aldor for the time being, and
switch to a free version when it is available. There is no way I can help with
improving the compiler. But I need dependent types now, not in one or two
years. Thus, I mainly need improvements of the interpreter.

Of course, there are things one might be able to improve, as you showed with
the Monoid - AbelianMonoid example.  However, I do not really see how to
circumvent this in a sensible way.

Furthermore, the restrictions on code in type context (see AUG Section 7.3),
where the Aldor language does not specify when code is evaluated, can be a
pain. (In fact, part of our code is not conforming with respect to this
restriction, although it "works".)

Waldek writes:

> I do not want to underestimate big things (dependent types) but getting
> little details 100% compatible would probably take more time.

I'm not sure about the amount of "little details". In fact, I am too blind to
see any "little details" at all. I don't care to much for exceptions currently,
for example. Is this a "little detail"? Generators, on the other hand, are
really useful, and, it seems to me, beautifully integrated. Other than that, I
guess we need that types are first class objects. 

Gaby pointed out that "==" has different semantics in Aldor and Axiom, but I
have the feeling that this difference is not so severe: in fact, I don't know
of a way to define a constant in SPAD, currently, other than to define a
macro. As far as I know, in Axiom "==" can only be used to define functions
and, in SPAD, types. (Aren't types just a special kind of functions?)

Should we copy this discussion to Stephen Watt? :-)

Martin





reply via email to

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