Re: [Axiom-developer] Catching up on internals

2017-11-25 Thread Eugene Surowtz
-developer] Catching up on internals Date: Wed, 8 Nov 2017 08:13:00 -0500 From: Tim Daly <axiom...@gmail.com> To: Martin Baker <ax87...@martinb.com> CC: axiom-dev <axiom-developer@nongnu.org>, Tim Daly <d...@axiom-developer.org> Partial function checkin

Re: [Axiom-developer] Catching up on internals

2017-11-08 Thread Tim Daly
Partial function checking happens in ML-fathered languages also. It complains when I fail to fill out a pattern match with all the cases, for example. Proving partial functions implies a set of provisos (checks on the input). These checks could be inserted as an 'assert' on the calling arguments

Re: [Axiom-developer] Catching up on internals

2017-11-07 Thread Martin Baker
On 04/11/17 00:42, Tim Daly wrote: 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

Re: [Axiom-developer] Catching up on internals

2017-11-04 Thread Martin Baker
On 04/11/17 16:18, Tim Daly wrote: You're correct. My primary focus is on Spad code. Tim, Thanks for the explanation, interesting stuff, I'll be keen to read any progress reports if you get time to write them. Thanks, Martin B ___

Re: [Axiom-developer] Catching up on internals

2017-11-04 Thread Tim Daly
You're correct. My primary focus is on Spad code. In a logic setting there are things called Typeclasses which are roughly equivalent to Axiom Categories. Typeclasses have 3 parts: signatures-- just like Axiom carriers-- Axiom's Domain representation propositions -- formal

Re: [Axiom-developer] Catching up on internals

2017-11-04 Thread Martin Baker
On 04/11/17 00:42, Tim Daly wrote: 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. Tim, I know little

Re: [Axiom-developer] Catching up on internals

2017-11-03 Thread Tim Daly
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,

Re: [Axiom-developer] Catching up on internals

2017-11-03 Thread Martin Baker
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

Re: [Axiom-developer] Catching up on internals

2017-11-02 Thread Tim Daly
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. On

Re: [Axiom-developer] Catching up on internals

2017-11-01 Thread Tim Daly
The issue of the current lisp code is related to several factors. Scratchpad was implemented in maclisp, ported to lispvm, and then ported to common lisp (I did large portions of the CL port). So the code is a macro-mangled version of several lisps. In addition, there was another language (called

Re: [Axiom-developer] Catching up on internals

2017-11-01 Thread gad9972
On 31 Oct 2017 12:29 p.m., "Tim Daly" wrote: Martin, What possible advantage would it be to have the interpreter in Spad? Assuming you want to move away from Lisp you would also have to code the compiler in Spad. Tim, Well, at least it would be a first step in moving

Re: [Axiom-developer] Catching up on internals

2017-10-31 Thread Tim Daly
Martin, What possible advantage would it be to have the interpreter in Spad? Assuming you want to move away from Lisp you would also have to code the compiler in Spad. Spad is just a domain specific language on top of Lisp. It is useful for the target domain (mathematics) but not particularly

Re: [Axiom-developer] Catching up on internals

2017-10-28 Thread gad9972
On 27 Oct 2017 8:05 p.m., "Eugene Surowtz" wrote: Did anyone get back to you on this? Gene I have been trying to learn more about boot code, I have put the results of my investigations so far here: http://www.euclideanspace.com/prog/scratchpad/internals/boot/index.htm My

Re: [Axiom-developer] Catching up on internals

2017-10-27 Thread Eugene Surowtz
Did anyone get back to you on this? Gene On 9/5/2017 9:33 AM, Nicolas Doye wrote: Dear all, last time I looked at the internals (20 years ago) the parts I was interested in were all written in BOOT. I wrote all my tentative code in BOOT and patched one function (possibly coerceInteractive)

[Axiom-developer] Catching up on internals

2017-09-05 Thread Nicolas Doye
Dear all, last time I looked at the internals (20 years ago) the parts I was interested in were all written in BOOT. I wrote all my tentative code in BOOT and patched one function (possibly coerceInteractive) to accept it. I have several hundred lines of BOOT code that may be of interest to