Re: [Axiom-developer] Catching up on internals

[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 Wed, Nov 1, 2017 at 4:03 PM, Tim Daly <address@hidden> wrote:

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
Meta) that was part of the build process making life more complex. Boot
added to that complexity by making it unreasonable to write good lisp
code that takes advantage of Common lisp. Nobody writes CL code
using lists of lists of lists and cadadr accesses.

Common lisp code can be very readable. It is easy to write in a functional

style and structure the data in a more rational fashion. I've been working

in that direction.

You're right that nobody is going to change their minds about this issue,

of course. It's one of the reasons for a fork. But if you're going to put forth

the effort to rewrite the compiler in Spad it might be worthwhile to create

a specification of what it does now before trying to write Spad code.

There are a lot of subtle hacks (e.g. add chain searches) that would be

useful to explain.

Another thought is that Aldor was an attempt to re-write the world into

a higher level language. I spent 4 years of PhD research trying to move

Axiom's algebra library into Aldor. Aldor was supposed to be the

replacement compiler for Scratchpad. Unfortunately it suffers from

"the second system effect", losing sight of the primary goal. You could

consider moving the algebra to Aldor but I don't recommend it.

Tim

On Wed, Nov 1, 2017 at 2:05 PM, gad9972 <address@hidden> wrote:

On 31 Oct 2017 12:29 p.m., "Tim Daly" <address@hidden> 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 away from lisp. I would really like more mainstream base language that supports parallel code and more powerful libraries for graphics and so on. I think parallel code is very important, I think mathematics has a lot of inherent parallelism (vectors for example).

The main issue is that I find it extremely difficult to work out what a given piece of Lisp/boot code does. If I look at a given function there is  no clues about the structure of its parameters or what  variables are being used or what they are used for. I think it's because Lisp/boot uses a single type (feels like dynamic typing) and global variables it is very hard to understand code. I suspect your answer to this might be documentation and I agree that documentation is very important but I don't think it's a fix for spaghetti code.

I understand that Lisp is an epiphany language (i.e. you hate it until

you "get it" and then you love it) 

I can see that Lisp is quite mathematical (lambda calculus) and I can see that it allows the original programmer to be very creative, but when trying to understand other peoples code, creative is not what I need. I want a language with meaningful types and minimal global variables.

Sorry, I didn't mean this to be a discussion about the pros and cons of various languages. I am sure we won't change each others mind about this. I just wanted to explain why I'm keen to find a way to convert boot to SPAD as discussed on my web page.

Martin B