axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Re: OpenAxiom-1.2.1 released


From: root
Subject: Re: [Axiom-developer] Re: OpenAxiom-1.2.1 released
Date: Sat, 11 Apr 2009 03:37:26 -0400

> As Dick Jenks explained it to me when I joined the Axiom project in 1984,
> the Boot language was intended as a boot-strap step to eventually implement
> the entire system in the Spad language.  The idea was first to convert to a
> language that was syntactically similar to Spad, then convert it to actually
> use Spad.  Of course the second step never happened.  That's why the
> language was named Boot.
> While Boot does have the semantics of Lisp, to me, the distinguishing
> feature is it's very nice syntax for list pattern matching.  You can do the
> same things in Lisp, but the syntactic elegance of Boot for pattern matching
> is undeniable.  It was so nice that we got away without real structured data
> throughout the entire project.  I love the syntax:

Yes, and Dick was one of the authors of the Boot language.
Dick also used Meta, another language which has since been removed.




Boot's lack of data structures causes obscurity

The lack of structured data is the cause of so MANY of the random
$-variables with undescribed contents. I am trying to untangle the
contents of the Frame structure so I can explain it. I'm trying to
collect and manage the global state scattered in hundreds of $-variables.

There is a general )set data structure hidden in |$setOptions|
which could easily be a domain-specific language (DSL) if implemented
in lisp. I will eventually write a simple DSL to make this data structure
obvious and trivial to extend and maintain. But boot makes it impossible
to use these structures or DSLs, making the whole subsystem obscure.





Boot needlessly complicates the build process

Since boot was written in boot we had a situation where we needed a
running Axiom in order to build Axiom. This was also true of the
algebra in that you needed a running system to build a running system.
That was fine at IBM as we always had a running Axiom.

While we worked together at IBM I created a version of Scratchpad
that was a pure lisp implementation. It greatly simplified the build
process since we didn't need to build Meta or Boot. But Dick was quite
pleased with the "recursively defined" aspects and hated lisp syntax.
Thus, my pure lisp version died, greatly complicating my build work.
(Indeed, that's why there are .clisp, .lsp, and .lisp files in int.)

When the system was released to me I did not have permission to
distribute NAG's system and therefore did not have a way to bootstrap.
I needed to rearchitect the system so boot and the algebra could be
built without a running system. It took nearly a year of work to 
construct a version of Axiom that builds from scratch. Boot made 
part of that process painful.

This whole process makes the system build needlessly complicated.  One
of the CLEARLY STATED GOALS of the free version of Axiom was the goal
of rewriting boot into lisp and removing boot from the world.





Boot is a bad idea.

Boot adds nothing to the system but python-like syntax. We might as
well retarget boot to BE python-compatible so we would have people who
knew the language. There are NO active Axiom developers who have
developed new code in boot. Boot is a dead language, specified only by
its single implementation. It is not even a complete language as there
are many things implemented directly in lisp that you can't say in
boot. It is a syntactic-sugar, restricted subset of a real language.

Boot is yet-another-of-the-thousands of lisp-without-parens languages.
Every one of these lisp-without-parens languages misses the
fundamental point of the parens, which is that programs are data.

Boot takes away the source of the immense power of lisp to self-modify.
Boot takes away lisp's ability to build domain-specific languages in macros.
Boot takes away CLOS, data structures, and other tools.
Boot takes away "to the metal" optimizations.
Boot takes away the ability to debug in the language you write.

You add a boot-to-lisp translation which requires code to maintain.
You add a boot-to-lisp translation which complicates the build process.
You add a boot language which requires documentation and explanations.
You maintain an unspecified language nobody speaks.

Why?





The Common Lisp future of Axiom

Once boot goes away then Makefiles go away since I can use lisp to
build lisp.  The whole build process becomes....

  fire up a lisp image
  load code
  execute

(Well, there is noweb but Axiom can now read TeX files with tex-chunks
so noweb will disappear as soon as I finish removing boot. Thus the
sources will be literate lisp files as pure latex readable by Axiom)

So Axiom will be very simple to build and rather more simple to
understand since I'm literate documenting it as I go.  Axiom will be
easier to maintain since Common Lisp is a language with a published
standard used by people.

Back in the late 80s I set out to remove boot from Axiom.
It is a clearly stated goal of the Axiom project.
It is happening as I write this.

Tim







reply via email to

[Prev in Thread] Current Thread [Next in Thread]