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 of proving new code correct which tends to get a negative reaction from developers. The upside is that "underneath Spad errors" should not occur. Proven code certainly moves away from "lots of (non-mainstream) stuff that's not really about the mathematics". On the other hand, it does make the mathematics hill-climb steeper. Unless you're up to speed on Heyting and Intuitionistic Logic, writing proven code is going to ruin your weekends, based on my current weekend experience :-) Axiom is fundamentally a research platform in the area of computational mathematics. I expect the user base to remain rather small, especially as it gets closer to a rigorous mathematical base. Tim On Fri, Nov 3, 2017 at 2:27 PM, Martin Baker <ax87...@martinb.com> wrote: > On 02/11/17 21:10, Tim Daly wrote: > >> Another thought... While people don't seem to like lisp as a platform >> it does have major advantages. I usually find myself using the lisp >> debugging facilities (trace, break, and REPL evaluation) to find >> out what failed and where. >> >> If you go from Spad to executable code you lose all of that. >> > > Tim, > > This is one of the problems, in my view, in that Lisp shows through > underneath SPAD. That is debugging, error messages, outputs, etc. are often > formatted as Lisp or require Lisp knowledge. I think this is particularly > important for potential new users. SPAD has a steep enough learning curve > on its own without needing to learn Lisp. Could it be things like this that > prevent new user take up and explain the limited amount of discussion here? > > What I would like would be a clean language for people interested in > mathematics without all the baggage of having to learn lots of > (non-mainstream) computer stuff that's not really about the mathematics. > > Martin B >
_______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org https://lists.nongnu.org/mailman/listinfo/axiom-developer
