[Axiom-developer] BAD tim

[root]

Ah, language wars ... the only thing that out-emotions a license war

I suppose, having been cast as the bad guy in this morality play, that
I'm required to have the long monologue about my evil ways (so the hero
has time to sneak around behind me and kill me) :-) So sit back, grab
some coffee, and watch the opinions fly...


POINT 1: Axiom needs to be future-proofed.

   Axiom needs to be torn down, re-architected, re-thought
   and rewritten cleanly so it can be modularized, maintained, and
   extended. Which implies a major rewrite, likely done by me.


POINT 2: The rewriting will change existing code. 

   If we look at the "startup sequence" we see:

              restart (lisp)
   init-memory-config (lisp)
             initroot (lisp)
               reroot (lisp)
                 spad (boot)
              runspad (boot)
           ncTopLevel (boot)
            ncIntLoop (lisp)
              intloop (boot)
  SpadInterpretStream (boot)
   intloopReadConsole (boot)

  and, if you follow the side-paths you'll see the constant switching
  between boot and lisp at every level in nearly every function.

  This inhibits "collapsing and rewriting" code which will have to happen
  during the rewrite. Functions will either have to be collapsed into lisp
  or boot.

  Historically this interleaving occurs because new function was 
  added/deleted/replaced. The "nc" prefix implies "New Code", a newly
  rewritten parser that partially replaced the previously newly rewritten
  parser. The "shoe" code, which is the new, improved "boot" language
  exists in there. The "meta" code used to exist but is gone. Addition of
  Fortran support (for NAG), Foreign Language calls (for graphics and 
  the browser), Lisp vendor specific code, etc. required lisp.


POINT 3: Boot is a dead language. 

   There are approximately 10 people still living who have coded in
   boot and every one of them is doing something else with their
   life. You have to be careful in boot. It is case sensitive so APPEND
   is not the same as append. It is often not clear what a construct
   will translate to and you end up reading the lisp to learn. 
   A single, misplaced space will change the meaning of the code.

POINT 4: Boot SERIOUSLY complicates the Axiom system. For instance:

  1) Bootstrapping boot

   The boot compiler is written in boot and needs to be compiled
   using itself. If you have a running Axiom system this is not a
   problem. However if you start from a clean lisp system it is a
   big problem. I cheesed up a way to do this but it is fragile and
   ugly. But given that we build from scratch there is no other way.

  2) Makefiles come in multiple stages

   Boot forces Axiom to be built in stages. Thus Axiom cannot use modern
   tools like ASDF. A pure common lisp Axiom interpreter can be built
   and loaded directly into a lisp image, interpreted or compiled.

   Lisp, BOOTSYS, DEPSYS, INTERPSYS, AXIOMSYS. These can all be
   collapsed if Boot disappears.

  3) lsp, lisp, clisp, ${LISP}

   All of these exist because boot exists. For example, .clisp is a
   translated boot file whereas a lisp file is hand coded. ${LISP}
   exists to smooth over this bump. I won't go into the historical
   reasons why these came about but they exist as a side-effect of boot.

  4) The interpreter has a boot compiler built in

   There are complications to the interpreter to handle boot-related
   development from the command line which no-one is ever likely to
   do again. This code could disappear and, having gone away, simplify
   the interpreter



POINT 5: The boot language is undocumented 

   It is likely to remain so as one of the authors is dead and the other
   one might be. There are no primary sources of documentation.

POINT 6: Boot does not give you the full power of common lisp.

   Boot cannot handle backquote, defstruct, and other primitives
   not to mention CLOS, CLIM, etc. So as lisp evolves boot will
   "further fork" away from the living edge of lisp ideas and 
   limit the axiom programmer. 

   Witness the data structures used in boot, mostly lists. Frames
   are lists of lists, history is a circular list of lists, etc.
   Where are the data structures? Who will redesign, rewrite, and
   document boot extensions to fully cover common lisp?

POINT 7: Boot loses program-data symmetry.

   This is a matter of religion but having been at this game for 35
   years I've seen a hundred languages built on lisp that try to 
   "eliminate the parens" and all will eventually die (including Python).

   The paren syntax is fundamental. Look at how Axiom really works under
   the covers. It doesn't build boot functions, it builds lisp functions.
   Why? Because you can cons up a lisp function, compile it, and run it
   directly. Axiom code and data intermingle in the algebra lisp files.
   The databases have code and data in them. Data <==> Programs. Fundamental.

POINT 8: Tools don't support boot

   Emacs balances lisp parens. It lets me do lisp function lookups. It 
   understands the lisp syntax including escape chars. SLIME lives in 
   emacs and provides support. Code walkers walk lisp code. Pretty 
   printers understand lisp. Debuggers understand lisp (I want to fix
   it in the language I broke it in). ASDF can manipulate lisp. Programmers 
   speak lisp. Blank spaces don't break lisp.

   Boot is unsupported anywhere by anything.


POINT 9: Where are the programmers?

   Who will write in boot? I'm the only person likely to be hacking
   the interpreter for the near future, mostly because it is so big,
   ugly, unstructured, and undocumented. Even if people code in boot
   to maintain the interpreter how often will they do that? How will
   they maintain their skill at writing boot? I've written many, many
   thousands of lines of lisp and use it continuously. Who are the
   programmers who will do that in boot?

POINT 10: Boot was an experiment in surface syntax

   Historically Axiom was a platform for experimenting with many research
   topics. One of these topics was a favorite of Dick Jenks and Bill Burge,
   that of language design. Scratchpad, now called Axiom, was changed many
   times to introduce new ideas. This research is no longer the point of 
   Axiom and is better done elsewhere. We neither have the expertise nor
   the research goal of surface language design. Let Python do that. Or
   Spad/Aldor fans.

POINT 11: Do language design where it counts.

   If we are going to devote research effort toward language design
   lets do it at the Spad/Aldor level where it counts. This is where
   the real language expertise should be applied. For instance, why
   do I have to write programs to express functions? Why can't I
   write a domain using equations? Why doesn't the Spad language
   support that?

POINT 12: Future directions assume lisp

   Notice that one of the near future goals is to connect Axiom and
   ACL2. ACL2 understands lisp-ish kind of languages, not boot.


and now, on to the recent changes

POINT 13: Don't break code until you understand it.

   I'm working hard to understand the code so the existing code is a
   straightforward translation (well, mostly, with some rewrites that
   I know are logically equivalent).

   Once I've completely figured out the various twists and turns,
   uses and references, and other points I'll be recoding the whole
   process. There is no reason (other than historical) why there are
   a dozen entry points into the interpreter that set wierd, undocumented,
   stateful flags. All that cruft must go away.

   So the code is ugly. At the moment. But it will get better, cleaner,
   clearer, more robust, and easier to change. History and Frames, for
   example will use structures that don't depend on 
      (caar (cdddddr (cdddddr x)))

   It takes time. It takes work, probably 2-3 years worth of work.
  
and now, on to the personal...

POINT 14: I'm a lisp programmer 
   
   (clearly)

The Evil One,
Bad Tim