[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] BAD tim
From: |
root |
Subject: |
[Axiom-developer] BAD tim |
Date: |
Mon, 31 Oct 2005 21:59:41 -0500 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Axiom-developer] BAD tim,
root <=