Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zaphod.mps.ohio-state.edu!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.lisp Subject: SETQ vs SETF (was Re: Question about INTERN) Message-ID: <1991Jan31.180524.21828@Think.COM> Date: 31 Jan 91 18:05:24 GMT References: Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 31 In article SEB1525@mvs.draper.com writes: >On 30 Jan 91 22:51:06 GMT Barry Margolin wrote: >>...and I sometimes wish the Common >>Lisp designers had had the guts to get rid of SETQ);... >Do you mean that you wish that SETQ had been flushed in favor of SETF, >or that side-effecting variables via assignment should have been >prohibited? SETQ should have been flushed in favor of SETF. In fact, except for error checking purposes, there's no reason SETQ and SETF couldn't have been made synonymous. SETF was originally an optional macro package in MacLisp, and it needed SETQ to be kept around so that it had something to expand into, as well as for compatibility with programs that examine other programs. However, in Common Lisp it is a required primitive, and there is no rule that says that SETF has to expand into a call to a documented function (e.g. there's no documented function for SETF of AREF to expand into). Instead of making SETF part of the language, they could simply have extended SETQ to allow generalized variables where it currently only allows regular variables. These are the kinds of things Lisp-bashers are referring to when they complain that Lisp is full of redundancies (actually, they're more often referring to the redundancy of having sequence functions, mapping functions, the DO family, and LOOP). A similar argument could be made for abolishment of RPLACD and RPLACA. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar