That seems reasonable, except for the fact that any non-algebra error that does
show up has to exhibit itself somehow. Worst case is a core dump. Spad does
not define robust error handling primitives. Local try-catch is reasonable but
it is not clear how to handle things like restarts, tracebacks, etc. when the
non-algebra error occurs. How would you model handling errors in Spad?
I do think that there might be an interesting research question of how to
handle classes of errors in computational mathematics. I had proposed
using Provisos to handle side-conditions on formulas. Hoon Hong and
Chris Brown have done a lot of work on QEPCAD for handling these.
Manuel Bronstein and I had long discussions about a SUCHTHAT domain
for encapsulating Provisos but little code resulted as the QEPCAD work
was still in the future at the time.
As for writing Axiom in Spad, you find that compiling Axiom to efficient but
generic code relies heavily on trampolines and symbol-plist lookups
to do dynamics dispatch. I can't imagine how to work that into a strong type
system so a compiler written in Spad might be a challenge.
Grab a copy of Axiom and try to move some of the code to Spad. I'd
recommend starting with eliminating any $Lisp calls in the algebra. That
will move the algebra away from the underlying Lisp. It will also bring a
lot of issues into focus. A non-lisp-based Spad cannot have $Lisp calls
so each would have to be replaced with a Spad implementation.
On the other hand, my current effort involves proving Axiom correct. That
should (in theory) eliminate whole classes of errors. This is at the expense