axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] Re: libaxiom.a


From: Page, Bill
Subject: RE: [Axiom-developer] Re: libaxiom.a
Date: Fri, 24 Mar 2006 04:44:50 -0500

Ralf, 

On Wednesday, March 22, 2006 5:26 AM you wrote:
> ... 
> I grep'ped for $Lisp. Well, that makes 2568 occurrences and
> for my taste a very bad design. Wouldn't it be much better to 
> concentrate all the Lisp dependencies in just a few modules
> and write the rest depending on that modules in Aldor?

Actually all of these occurrences are in only about 90 of
the 350 .spad.pamphlet files, so they are not spread as
badly as the total number suggests. I am not convinced
however that these lisp dependencies are necessarily bad
or that they need to be concentrated into only a few
modules. I need to think about this some more ...

One can think of $Lisp as a package that naturally
accompanies the SExpression domain. The SExpression is a
very important domain for Axiom. Maybe more of the commonly
used Lisp constructs could be implemented in SExpression,
but the change would be mostly cosmetic at the expense of
some function call overhead.

The total number occurrences of $Lisp is not really that
bad. There are other domains in Axiom that are nearly as
widely used such as Integer and Polynomial, etc. In general
Axiom's library is very strongly interconnected and
mutually dependent.

Your argument might be that $Lisp is "too powerful" as a
package since it implements a complete, albeit lower-level,
symbolic programming language in itself. As such it allows
programmers to abuse this flexibility and write programs
that are more difficult to maintain. But in fact Aldor also
allows this flexibility via the 'import {} from foreign lisp'
statement.

> 
> For example, I see "NIL$Lisp" all over the place (153 times).
> Brrrhh. Wouldn't just "nil" do?

Well, no. NIL$Lisp is of type SExpression but nil is of
type List. Maybe NIL should really be a constant defined
in SExpression.

> And to be honest, I mostly wouldn't like to see NIL at
> all. Aldor/SPAD should deal with domains and their 
> elements and mostly forget about a pointer view.

I am not sure I understand what you mean by a "pointer
view". SExpression is a domain within SPAD whose
representation is provided by Lisp. NIL is a name for
the empty SExpression just like 'nil' is a name for the
empty List. Or "by "forget about pointer" are you
suggesting that we should discourage the use of such
mutable data structures as lists? I think this would
have unfortunate consequences for representing "infinite"
objects such as sequences and graphs/networks with
loops, etc.

> There would be only rare reasons to use NIL and
> they should be abstracted through an Aldor Pointer domain 
> (which then could be mapped to Lisp (or whatever)).

Could say a little more about the Aldor Pointer domain?
How is it used? I tend to think of NIL as equivalent
to emtpy() for a list. That seems to be how it is mainly
used in Axiom.

Perhaps you are saying that there really shouldn't be
two list-type structures in Axiom and that all of the
necessary SExpression functionality should be abstracted
as a List?

> 
> Except that we now have this Lisp'ish SPAD code for 
> historical reasons, I think it would be much cleaner
> to make a clear cut between the underlying Lisp
> infrastructure and the Algebra code.
> 
> Is my view so wrong (except that it means lots of
> work)?

It seems to me that only thing really "Lisp'ish" about
this is the use of SExpression as one of the fundamental
data structures. But this seems to me to be a deliberate
design decision on the part of the Axiom developers.
After all, symbolic computation was one of the main reasons
why Lisp was invented and S-expressions are it's basic
data structure. The $Lisp notation just makes it convenient
(too convenient?) to manipulate these structures with
Lisp itself.

Regards,
Bill Page.




reply via email to

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