[no subject]

[DHD@MIT-AI]

(I don't really know who to send this to, but this mailing list is probably
about the best).
NOTE: This is a moby flame; pls read it only if you are concerned with the
software. I would appreciate a reply to any of my points if you have the time.

In general, I think the lisp machine is an excellent concept, but a concept can
be spoiled by execution; a collection of seemingly minor points can make the
lisp machine seem much less disirable to potential purchacers.  I would like to
point out a few things in the lisp machine that seem to fall in this category.

1. The initial base is octal, and it always reverts to octal when the debugger is
called.  The outside world - the chaps who would be buying your machine - are
prob. more used to decimil.  Having (+ 5 5) -> 12 inside the error handler does
nothing for user confidence!  A warm boot should not restore base to octal
unless it has assumed an illegal value.

2. The default font is way too small and very hard to change in the
read/eval/print loop (or rather to figure out how to change; i spent quite a
while on it).  However, I am glad to see that medfnt has been improved.
Another plus: ZWEI appears to have excellent control over variable-width fonts.

3. The "debugger" seems more oriented to debugging the lisp machine then user
programs!  The disassembled code thing (meta-l, etc.) is pretty to look at, but
not easy to understand. A grind command (like the stepper) would be far better.
   I think you may be too proud of the TV display (its true it looks nice, but
I've heard bad things about its reliablity), as you like to produce overlong
typeouts - like meta-l and DESCRIBE.  This system doesn't have a "personality"
like ITS has; a "heart" is missing. Try to make error messages, etc. sound more 
friendly.   Many function names are too long---"STRING-REVERSE-SEARCH-NOT-CHAR",
for instance.  A generalized string-search (for ex.) might be better - give it
options, and have them default sensibly; for instance, (string-search arg chars)
-> normal string search; (string-search arg chars 'r) = string-reverse-search,
etc. In any case, i think the neumonics could be made shorter and still
understandable.  TV-CLEAR-SCREEN doesn't need the TV- in front of it for inst.
It admittably helps organization; perhaps you could have the tv funs in one
package, the string funs in another, etc.  This may be impractical, of course; i
don't know how much the overhead of the pkg. system is.

4. DESCRIBE prints out a lot of info that is (as far as i can see) useless to
most users.  If anyone doubts this, pls tell me what an ADL is!  THIS IS NOT IN
THE MANUAL!   ARGLIST, however, is useful.
   I would make describe do the following:
a. Print out the value and arglist, as it does now.
b. Print out (as a string) the HELP property (if any) of the symbol. 
   This would make self-documentation much simpler, and - in my opinion - is
   worthwhile. If there is no HELP property, of course, nothing would be done.
c. The source-file-name property should also be displayed.
If the user really wants to find the other exotic things, he should just do a
(plist ...).  The current describe might be put on SI: or something if you
really want it; it should not, however, be the one the user sees. 

5. The graphics primitives are too low-level, and rather obscure.  TV-DRAW-LINE's
ALU argument should be optional, for instance.  There should be info on packages
- like the tv turtle - as well.  The low-level primitives should still exist, of
course, but most users would prob. rather use the tv turtle if it was made
available to them.  You should also offer documentation on the color display and
how to use it.  You should mention how many pixels to the inch.

6. Get into zwei, and type top-HB.  What happens then is symbolic.  (I created
the BASIC ZWEI file so that the annoying File-not-found error wouldn't occur,
and also to (hopefully) make you want to improve things a bit).  I, for one,
would like to know how to redefine keys, etc.; your doc doesn't seem to say
anywhere. The fill col should be in chars in font A rather then pixels (c.f. 5).

7. In the reader, ^L should perform the same function as FORM.  Most ITS users
are prob. more used to ^L then form.  The same complaint applies to vt vs. ^K.
In any case, for people like me who learned touch typing on a norm. typewriter,
these keys are too far away.  As i haven't used the new kbds, I don't know if 
this has been fixed or not.
   In ZWEI, the initial default environment should be the same as EMACS'; it
should be - of course - easily modifiable.  I like emacs' command convention of
having the command name and its args on the same line.

8. Logging out should destroy the environment (i.e. do a cold boot).  I don't
understand why it doesn't right now.  (LOGIN-SETQ ...) is not really an adequate
solution. (SETQ ....) and (DEFUN ...) should only be effective through login.

9. There should be an optional argument to login giving the name of an init file
to load or NIL to not load one at all.  You don't have to LOGIN to SUPDUP, but
you must login to read a file.  This should be changed.  Why force logins at
all? ITS doesn't.

10. The Lisp machine is STILL not really compatible with maclisp.  There should
be a package of routines that can be loaded automatically with the init to
produce absoloute compatiblity.  Ask the user community for contributions to
this library.  You might have a MACLISP package that could be put in the
hirarchy in between USER and GLOBAL.

11.  In maclisp, the FORMAT compatibility routine is too slow.  If enough people
use FORMAT on the lisp machine and try to convert their programs to MACLISP,
they will find this out.  If it  can be speeded up, pls try to do it.  Your
string functions are prob. not implemented well enough for lispm format to work
well. If anyone has time, it should be rewritten for maclisp.  (I might try
fooling around with that idea myself someday - might be interesting).  Many of
the lisp machine's FORMAT directives arn't present in maclisp.

12. As touched upon above, NOTHING is documented well enough.  If you'd give me
the opportunity, i might try writing new doc from bug & info-lispm msgs - might
be worth a try if none of you are up to it.

A lot of this may be obvious, but many lesser projects have lost because no one
thought of that kind of thing.  I hope you arn't too annoyed by this flame, but
i think someone had to do it - otherwise things like these might go unnoticed.
If anyone would like to make futher comments on this message - good or bad,
etc., please send to me or bug-lispm (I put myself on it).

		Best of luck - to all the lispm group,
			 David Dennis