jeff@aiai.ed.ac.uk (Jeff Dalton) (02/12/91)
In article <1991Jan30.225106.26561@Think.COM> barmar@think.com (Barry Margolin) writes: >(when I read (EQUAL ...) it forces me to think about why EQUAL was used, >whereas EQ is a very simple operation); use SETQ rather than SETF when >setting variables (again, seeing the more general operator forces the >reader to stop and think, although I suspect many people out there would >disagree with me on this particular point, and I sometimes wish the Common >Lisp designers had had the guts to get rid of SETQ); This is good advice, but unfortunately certain widely-used textbooks do such things as (1) use EQUAL everywhere to avoid explaining the difference between EQUAL, EQL, and EQ; (2) claim that SETQ (and CAR and CDR) are "old fashioned" and seldom used. My question is this: is it really the case that CAR and CDR are normally replaced by FIRST and REST in current programming practice? How about COND, for which the claim has also been made? Theer may be an sociologically interesting process here, one in which practice is changed by describing it as having changed already (assuming that programmers who learn Lisp from those texts go on to program in the style they've been taught).
miller@GEM.cam.nist.gov (Bruce R. Miller) (02/13/91)
In article <4092@skye.ed.ac.uk>, Jeff Dalton writes: > In article <1991Jan30.225106.26561@Think.COM> barmar@think.com > (Barry Margolin) makes some good comments about EQUAL vs EQ, SETF vs SETQ > > This is good advice, but unfortunately certain widely-used textbooks > do such things as (1) use EQUAL everywhere to avoid explaining the > difference between EQUAL, EQL, and EQ; (2) claim that SETQ (and CAR > and CDR) are "old fashioned" and seldom used. Redundancy or not, there are many ways to get the same thing done in Lisp. A personal annoyance of mine is Charniak,etal. Artificial Intelligence Programming (2nd ed, which is in CL). It was interesting to see thier code for `reinventing' loop. But, to me, VERY annoying to have to remember yet another iteration syntax while reading the rest of the book. Granted, the status of LOOP was not clear when they were writing, and too involved to include in the text. Still... Its otherwise a very good text. > My question is this: is it really the case that CAR and CDR are > normally replaced by FIRST and REST in current programming practice? > How about COND, for which the claim has also been made? I can only speak for myself, but here's my vote: I use FIRST, SECOND, & REST for destructuring when I want to emphasize the `flat' structure of the list, that is, when the list represents some (possibly ordered) sequence of `like' entitities. I use CAR, CDR, CxxR, etc, to emphasize a more tree-like structure. If in the latter case, the various places have some kind a distinct meaning (and if its being used `enough'), then I'm inclined to define a set of accessor macros, or even a defstruct. > Theer may be an sociologically interesting process here, one in > which practice is changed by describing it as having changed already > (assuming that programmers who learn Lisp from those texts go on to > program in the style they've been taught). I can believe that! Look at the whole `Lisp is dead' debate. What is the single most effective thing that is killing lisp [to the extent that it actually IS dying]? The statement that Lisp is Dead!!!!!
jay@wiley.uucp (Jay Nelson) (02/13/91)
In article <4092@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >In article <1991Jan30.225106.26561@Think.COM> barmar@think.com (Barry Margolin) writes: >> ... (again, seeing the more general operator forces the >>reader to stop and think... >My question is this: is it really the case that CAR and CDR are >normally replaced by FIRST and REST in current programming practice? >How about COND, for which the claim has also been made? My preference is always to use the operator which conveys the intent of the code. When dealing with lists, I use FIRST and REST. If for some reason I am using a cons cell, I use CAR and CDR. I don't understand the comment about COND. I use WHEN and UNLESS for single case instances, IF when I want two outcomes, and COND when a sequential set of conditions must be evaluated that doesn't fit the CASE construct. Jay Nelson (TRW) jay@wilbur.coyote.trw.com
hall@aplcen.apl.jhu.edu (Marty Hall) (02/13/91)
In article <4092@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: > >This is good advice, but unfortunately certain widely-used textbooks >do such things as (1) use EQUAL everywhere to avoid explaining the >difference between EQUAL, EQL, and EQ; (2) claim that SETQ (and CAR >and CDR) are "old fashioned" and seldom used. I confess to the "equal" sin in the early weeks of the AI classes I teach. Actually, I'm not sure it is such a terrible iniquity, as long as I admit the truth later on. Equally (:-), I have no qualms with an intro LISP text doing this in the early chapters in order to get the "big ideas" across without getting bogged down in the details. As to setq/setf for variables, I am ambivalent. Personally, I cannot break my pre-CL habit of using setq for variables. >My question is this: is it really the case that CAR and CDR are >normally replaced by FIRST and REST in current programming practice? I strongly prefer first/rest if what is being accessed can be best thought of as a list. My observation of colleagues on AI contracts I work on is that this appears to be the consensus. However, a cons doesn't have to be a list, and I have no objection to car/cdr when accessing trees, etc. Personally, I define my own accessor functions in such cases, but that is (to me) a perfectly reasonable argument for sometimes using car/cdr over the more mnemonic first, second, rest. A quick glance on my shelf shows only the following texts using first/rest for lists: Winston (_Lisp_, 3rd ed), Hasemer and Domingue (_Common LISP Programming for AI_), Norvig (_Paradigms of AI Programming_, upcoming) and Keene, if you count that (_O-O Programming in CL_). Using car/cdr is Charniak, et al (_AI Programming_), Tatar (_A Programmer's Guide to CL_), Touretzky (_CL: A Gentle Intro to Symbolic Computation_), Wilensky (_Common LISPcraft_) and Tanimoto (_The Elements of AI using CL_). >How about COND, for which the claim has also been made? I personally use "if" when there is a single "then" and possibly "else" clause, "cond" when I would need a progn or nested ifs. I tend to use when/unless also, but have no strong opinion on that. >Theer may be an sociologically interesting process here, one in >which practice is changed by describing it as having changed already >(assuming that programmers who learn Lisp from those texts go on to >program in the style they've been taught). This is a good point. - Marty Hall AI Lab, AAI Corporation and The Johns Hopkins University P/T CS Program
jeff@aiai.ed.ac.uk (Jeff Dalton) (02/13/91)
In article <27B8222F.3C70@wilbur.coyote.trw.com> jay@wiley.UUCP (Jay Nelson) writes: >In article <4092@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >>My question is this: is it really the case that CAR and CDR are >>normally replaced by FIRST and REST in current programming practice? >>How about COND, for which the claim has also been made? > >My preference is always to use the operator which conveys the intent >of the code. When dealing with lists, I use FIRST and REST. If for >some reason I am using a cons cell, I use CAR and CDR. Well, there I disagree. I don't mind using FIRST and REST, and agree that they are sometimes clearer, but I see nothing wrong with considering CAR and CDR as list operations. I think there is a residual prejudice against CAR and CDR even within the Lisp community, because they were originally derived from the names for parts of a machine work on the IBM 704 (I think that was it). Some critics of Lisp, and even people who are teaching Lisp as a language that is "strange", will say that CAR and CDR stand for "contents of address register" and "contents of decrement register". They are confusing the origin of a term with its meaning. >I don't understand the comment about COND. I use WHEN and UNLESS for >single case instances, IF when I want two outcomes, and COND when a >sequential set of conditions must be evaluated that doesn't fit the CASE >construct. That's more or less what I do too. But some people claim that COND is not used except in "old fashioned" code. The suggestion seems to be to use nested IFs instead. Even though COND is just about the hardest thing in Lisp to read, I don't think nested IFs are always a good alternative. On the other hand, if established practractice really is moving away from COND, I'd like to know that. Contrariwise, if the textbooks that claim COND is obsolete are wrong, I'd like to know _that_. -- Jeff
jeff@aiai.ed.ac.uk (Jeff Dalton) (02/13/91)
In article <1991Feb12.180213.18143@aplcen.apl.jhu.edu> hall@aplcen (Marty Hall) writes: >A quick glance on my shelf shows only the following texts using first/rest >for lists: Winston (_Lisp_, 3rd ed), Hasemer and Domingue (_Common LISP >Programming for AI_), Norvig (_Paradigms of AI Programming_, upcoming) >and Keene, if you count that (_O-O Programming in CL_). > >Using car/cdr is Charniak, et al (_AI Programming_), Tatar (_A Programmer's >Guide to CL_), Touretzky (_CL: A Gentle Intro to Symbolic Computation_), >Wilensky (_Common LISPcraft_) and Tanimoto (_The Elements of AI using CL_). I'm impressed. Thanks for taking the trouble to do this. BTW, I think Hasemer and Domingue's _Common LISP Programming for AI_ is a particularly interesting book from a certain, sort of sociological, perspective. Throughout, they talk about Lisp as if it were an AI toolkit (think ART, KEE, etc). Data structures are called knowledge representations, for example. This is probably a good idea if you want to encourage the use of Lisp in AI (where a number of people, for some reason, seem to think Lisp isn't useful _directly_). But it runs counter to the more widespread attempt to move Lisp more into the mainstream. -- jd
Lusky@vdle21 (Steve Lusky) (02/15/91)
In article <4115@skye.ed.ac.uk> you write: >In article <27B8222F.3C70@wilbur.coyote.trw.com> jay@wiley.UUCP (Jay Nelson) writes: >>I don't understand the comment about COND. I use WHEN and UNLESS for >>single case instances, IF when I want two outcomes, and COND when a >>sequential set of conditions must be evaluated that doesn't fit the CASE >>construct. > >That's more or less what I do too. > >But some people claim that COND is not used except in "old fashioned" >code. The suggestion seems to be to use nested IFs instead. Even >though COND is just about the hardest thing in Lisp to read, I don't >think nested IFs are always a good alternative. On the other hand, >if established practractice really is moving away from COND, I'd like >to know that. Contrariwise, if the textbooks that claim COND is >obsolete are wrong, I'd like to know _that_. It is what I do. I find COND with more than two conditions to be much simpler to understand than using nested IF's. It is like a Multiplexer circuit with only one allowed input. The code indents cleanly, and looks simpler. What is the reason for saying that COND is obsolete? (COND-EVERY is occasionally useful as well.) Steve
jeff@aiai.ed.ac.uk (Jeff Dalton) (02/18/91)
In article <1991Feb14.181140.25730@csc.ti.com> Lusky@vdle21 (Steve Lusky) writes: >>But some people claim that COND is not used except in "old fashioned" >>code. The suggestion seems to be to use nested IFs instead. Even >>though COND is just about the hardest thing in Lisp to read, I don't >>think nested IFs are always a good alternative. On the other hand, >>if established practractice really is moving away from COND, I'd like >>to know that. Contrariwise, if the textbooks that claim COND is >>obsolete are wrong, I'd like to know _that_. >What is the reason for saying that COND is obsolete? Maybe I should look up one of those claims that I say some people make. I think all they're saying is that modern (so to speak) Lisp programmers have moved away from it. I don't agree with then, though.