axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Clarification


From: daly
Subject: [Axiom-developer] Clarification
Date: Sun, 6 Nov 2011 08:11:50 -0600

Waldek,

It appears that the topic of merging systems has hit the fricas mailing list.

Two comments puzzle me.

  "Concerning merge, IMO merging back with Axiom is out of question -- the
   project go in too different directions (one trivial (but easy to 
   understand) example beeing that I spent several months removing trash
   from FriCAS while Axiom at the same time added more trash)."

What "trash" has Axiom added?



  "In FriCAS I deliberately limited changes to Spad language (to maximize
   compatibility with existing code)..."

Actually there is a subtle issue that make FriCAS Spad code non-portable.
There are new lisp functions quietly introduced that only exist in FriCAS
(e.g. GETREFV32) but are referenced in the Spad code. This code compiles 
but fails at runtime. 

There is no mention of this incompatibility in the pamphlet file
(u32vec.spad.pamphlet). The whole reason to use literate programming
is to communicate such facts to other people.




The use of literate programming is likely to be the main reason why
FriCAS (and OpenAxiom) will never merge back. I would like to keep the
algebra compatible.  I do my best to keep up with the new and changed
algebra but it is a bit of a challenge. The new algebra is packaged in
pamphlet files but there is no actual use of the literate style. New
algebra is not explained, there is no connection shown between theory
and its reduction to practice. There are no examples. There are no notes
to explain why new domains have incompatibilities that deviate from the
Spad language and will not compile in Axiom.

In fact, there is no attempt to communicate with the reader at all. 
The files contain raw Spad code. Why do you keep pamphlet files?

Tim








reply via email to

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