home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!pipex!warwick!uknet!edcastle!aiai!jeff
- From: jeff@aiai.ed.ac.uk (Jeff Dalton)
- Newsgroups: comp.lang.lisp
- Subject: Re: SETF vs. SETQ
- Message-ID: <8227@skye.ed.ac.uk>
- Date: 21 Jan 93 19:45:54 GMT
- References: <HAL.93Jan13083812@monsun.si.no>
- Sender: news@aiai.ed.ac.uk
- Organization: AIAI, University of Edinburgh, Scotland
- Lines: 31
-
- In article <HAL.93Jan13083812@monsun.si.no> hal@si.no (Hallvard Tretteberg) writes:
- >In article <1iupurINNih2@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
- > No, there's only a MULTIPLE-VALUE-SETQ.
- >
- > In hindsight, having separate SETQ and SETF was a bad design, IMHO.
- >
- >I agree. In a Lisp style guide I wrote the general rule was to use the
- >most specific construct when choosing among several alternative ways
- >of doing the same thing. But, when it came to SETF vs. SETQ I
- >recommended using SETF all the time.
-
- I disagree with the most-specific rule in general, and I don't see
- anything wrong with using SETQ. Does anyone seriously want to argue
- that SETQ is unclear, for instance?
-
- >One argument for using SETQ could be that it is easier to spot which
- >uses are fast-simple-variable access, compared to
- >slow-complicated-slot access where SETF should be used. But with
- >SYMBOL-MACROLET you can be fooled by an innocent SETQ, because it, as
- >I understand, is treated like a SETF.
-
- You can be fooled by an innocent (SETF <symbol> ...) as well.
-
- >One thing that annoys me is that one can't use #'(setf
- >struct-slot-reader) because struct-slot setters can be implemented as
- >setf-macros and not as methods.
-
- That annoys me too, but struct-slot setters should be functions
- (not methods) just like struct-slot readers are.
-
- -- jd
-