padpowell@wateng.UUCP (PAD Powell[Admin]) (09/26/83)
Due to circumstances, I have been forced to learn Lisp in a big hurry. I put out an appeal for information to our local haques, and got a couple of references. I also have comments that I would like constructive (i.e.- any suggestions to change the situation) criticism on. 1. "Lisp", by P.Winston and B.Horn. Primer. The book's style is a bad cross between early McKeeman and late Knuth. However, most of the major parts of Lisp are covered. There are little exercises with answers which prove to be most invaluable. A major defect is the lack of a "dictionary" of list functions. While there is an index, a precise definition (or even vague definition) would be useful. 2. Franz Lisp. Where, by the thumbs of all the Lisp Freaks, is a good, read- able, non-telegraphic, complete introduction to the use of Franz Lisp? There is no "Introduction to FLISP" to explain how to use the guilty-of- maternal-incest compiler, interpreter, etc. When I am learning a language, I would like to have an example of a "session", a simple "compile and execute Towers of Hanoi" would be quite adequate. 3. To quote a collegue: "Lisp Sucks". Parenthesis. Atoms. CAR/CDR. EVAL. EEEEEYYYYYYEEEEEECCCCHHHHH! However, it is no more painful than learning APL. I have heard that most Lisp programmers have macro packages which transform Lisp into something almost readable. 4. LISP scope rules are truly horrible. This reeks of something from early days of IBM Fortran/Assembler or what ever. Perhaps there is some benefit to the "call by guess" rules, but I sure haven't heard any arguments. If you have any comments, I would be more than willing to listen. Documentation and macro packages gratefully accepted. Pointers to documents, etc. are nice, but we do not have many of the major references (MIT reports), and most are not available... Sigh. Patrick Powell, U. Waterloo, VLSI Research Group, Waterloo, Ont. (519) 885-1211 X3381 ...watmath!wateng!padpowell
thomas@utah-gr.UUCP (Spencer W. Thomas) (10/20/83)
The text I used when learning Lisp was "Anatomy of Lisp" by Allen, in the McGraw-Hill CS Series. Pretty heavy, but gives a good picture of how Lisp works - really helps in understanding why your program doesn't work, for example. Echoing Stan the l.h., a plug for PSL (available from U of Utah, call Loretta Cruse at (801)581-8224 or Cruse@Utah-20 or harpo!utah-cs!cruse) - one of its features is a "nice" Algol-like syntax called Rlisp. No Lots-of-Irritating-Single-Parentheses. You can even leave the parens off of calls to single argument functions, thus: a := first rest b; or for each i in l collect foo i; Of course it also has everybody's fav lisp syntax with all the parens, too, for you died-in-the-wool (sic) lisp hackers. =Spencer
shebs@utah-cs.UUCP (Stanley Shebs) (10/20/83)
(just can't restrain myself!) Spencer's remarks about PSL's RLISP mode are correct - it provides Lisp with a more conventional syntax. While at first it seems like a Good Thing, it's pretty much limited to C or Pascal programs that happen to be coded in Lisp. When things get really hairy, as in many AI programs, or in wild macros, RLISP becomes really obscure. A good example is the PSL kernel, which is written in RLISP (for obscure historical reasons). A lot of functions don't require parens around their args (like + and * , except that most functions are that way), and it's anybody's guess as to what some expressions mean. There's a semi-automatic translator between Lisp syntax and RLISP syntax, but the kernel's probably going to be rewritten some time, and then "proper" syntax can be used (gosh it's nice to have your lisp system be written entirely in lisp!) stan the l.h. utah-cs!shebs