padpowell@wateng.UUCP (PAD Powell[Admin]) (09/22/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
kramer@utcsrgv.UUCP (Bryan M. Kramer) (09/27/83)
In-reply-to: <350@wateng.UUCP>
Good books are:
1) "Functional Programming in LISP" by Hector Levesque (its not really
published but it is available in the U of Toronto textbook store.
This is probably the best ...
2) Charniak E., Riesbeck C., McDermott D. "Artificial Intelligence
Programming" Lawrence Earlbaum Associates, Hillsdale, N.J. 1980.
Once you have read 1), this book really shows you how to take advantage
of LISP.
Comments:
1) re. CAR, CDR: I think that names don't really matter, you have to
learn the concepts involved. Are words like "do" or "int" or symbols
like "{}" any more meaningful?
2) re. parentheses: if a LISP function is properly paragraphed, their
presence does not affect the readability of code. Both emacs and
vi provide facilities which make balancing parentheses trivial.
3) reference 2) above describes some useful macros which enhance
readability.
4) re. scope rules: LISP is simply call by value. If you are careful
with the use of non-local variables, dynamic scoping does not interfere.
Non-local variables are a pain in any language.
5) LISP is as much an environment as a language. Debugging, especially,
is much easier in LISP than in any other environment + language available
to me. When I have to program in other languages I find that I spend much
of my time duplicating things LISP offers as primitive.shebs@utah-cs.UUCP (10/01/83)
A few additional comments: 1. I completely agree about the Franz Lisp manual - there's a whole body of lore about how things *really* work. I learned most of what I know from Steve White at Boeing (ssc-vax!steve). 2. A convention that Charniak et. al. recommends to help with variables is to surround all global variables with stars. That includes any that are not standard local variables, in other words, anything not used in the same function in which it is created. Also, they should be minimized in number - the closer to pure Lisp your program is, the more reliable. 3. For ordinary programming, Lisp is hardly preferable to C, Pascal, or Modula-2 or whatever. But for AI work, it is far superior, and in fact, it's generally necessary to implement a Lisp-type interpreter sooner or later, if one tries to do AI in an ordinary language. 4. Finally, you might consider using PSL instead of Franz. I've been using PSL (well, Utah is the home of PSL) for the past month, and it's nicer than Franz in many ways - better documentation, a nice set of loop macros, and a good selection of string processing functions, and of course it's portable between a large number of machines. There's nothing quite like FTP'ing a program from a DEC-20 to a VAX, and having it work *with* *no* *changes* *whatsoever*. It's great... stan the l.h. utah-cs!shebs