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 <axiom...@gmail.com> 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 <gad9...@googlemail.com> wrote: > >> On 31 Oct 2017 12:29 p.m., "Tim Daly" <axiom...@gmail.com> 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 >> > >
_______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org https://lists.nongnu.org/mailman/listinfo/axiom-developer
