Schwamb@ics.UCI.EDU ("Karl B. Schwamb") (11/22/89)
OK, I give up. I can't stand grading the undergraduates' programs anymore. Can anyone suggest good comprehensive style guides for Common Lisp (or older versions of Lisp) as well as Prolog that I can just pick up and refer to or is this such a religous issue I'll have to make one up? A good C style guide I've seen included points about documentation, format, naming, syntactic conventions, and semantic considerations. I also vaguely remember there being a more generic guide on programming style akin to Strunk & White's for English. Thanks for your help ... Karl B. Schwamb schwamb@ics.uci.edu Information and Computer Science University of California, Irvine 92715
alms@cambridge.apple.com (Andrew L. M. Shalit) (11/22/89)
In article <8911211401.aa25148@PARIS.ICS.UCI.EDU> Schwamb@ics.UCI.EDU ("Karl B. Schwamb") writes: >> Can anyone suggest good comprehensive style guides for >> Common Lisp (or older versions of Lisp)... Good style in Common Lisp (which is lexically scoped) may be very different from good style for older dialects of Lisp. I think this is part of the reason that Lisp still has a reputation for being slow. Too many people program in Common Lisp as if it were Franz Lisp or Interlisp (e.g. they use lots of dynamic binding, call EVAL all over the place, etc). On a related note, a couple of years ago I saw a syllabus (sp?) for an "ai" course at Harvard. The teacher gave out a purported Lisp style guide. The only gem I remember was "for small operations, use macros instead of functions". I guess the teacher wanted them inline for speed, and wasn't considering all the problems associated with macros. The basic use of Lisp throughout the course seemed to be "cons up symbols and put them on the plists of other symbols. The symbols represent words with semantics, and that's how you do natural language." And this was two years ago. Sigh. . . -andrew
dlw@odi.com (Dan Weinreb) (11/23/89)
I don't know of a "style guide" per se, but you might look at the textbook "Lisp: A Gentle Introduction to Symbolic Computing". He uses very good Common Lisp style. For the higher level issues (e.g. why not to call EVAL all over the place, when to use and not use macros) he gives excellent explanations.
jeff@aiai.ed.ac.uk (Jeff Dalton) (12/21/89)
In article <ALMS.89Nov21182700@brazil.cambridge.apple.com> alms@cambridge.apple.com (Andrew L. M. Shalit) writes: >Good style in Common Lisp (which is lexically scoped) may be very >different from good style for older dialects of Lisp. I think this >is part of the reason that Lisp still has a reputation for being slow. >Too many people program in Common Lisp as if it were Franz Lisp or >Interlisp (e.g. they use lots of dynamic binding, call EVAL all over >the place, etc). I found that if I programmed for the compiler in Franz, I would have to think in terms of lexical variables, make explicit special declarations when needed, etc. This sort of programming style was easy to adapt to Common Lisp. From this point of view, what Common Lisp did was to make the lexical scoping rules apply even in the interpreter and to extend them so that bindings had indefinite extent (ie, provide lexical closures).