Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!edcastle!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp Subject: Re: SETQ vs SETF (was Re: Question about INTERN) Message-ID: <4124@skye.ed.ac.uk> Date: 13 Feb 91 16:26:35 GMT References: <1991Jan31.180524.21828@Think.COM> <4094@skye.ed.ac.uk> <1991Feb13.041244.17473@Think.COM> Reply-To: jeff@aiai.UUCP (Jeff Dalton) Organization: AIAI, University of Edinburgh, Scotland Lines: 92 In article <1991Feb13.041244.17473@Think.COM> barmar@think.com (Barry Margolin) writes: >In article <4094@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >>I think it would be better if SETF worked more like SET does in T. >>That is, (SETF (accessor ,@access-args) value) would expand to >>something like ((SETTER accessor) ,@access-args value). That is >>there would be set-function, and they'd be called (in effect) >>(SETTER accessor). Something like this was done for CLOS, where >>(SETF accessor) is a way to name the setter. But (last time I >>checked) this hadn't been propegated consistently though the >>language. > >It hasn't been propogated because it doesn't provide as much functionality >as the current mechanism, based on DEFINE-SETF-METHOD. By using a macro, >rather than a functional, style we allow SETF to perform more elaborate >transformations when necessary, and also to perform more of the work at >compile time. 1. There are only a few cases (eg, LDB) that need SETF to be a macro. This aspect of SETF is hard to understand, as the discussion of some of the cleanup issues showed. 2. If the functional approach were used, the compiler could still expand and compile SETFs in-line. 3. The functional appraoch is simpler and gives us names for the setter functions, which would often be useful. Moreover, it does it without adding a mess of new symbols to the LISP package. >Furthermore, I believe it provides better support for the >macros built on SETF, such as PUSH and ROTATEF; I think a functional >approach might need separate PUSHER and ROTATER functions (but I >admit that I haven't thought about this very hard). Nor have I. But I think PUSH and ROTATEF can use SETF as a black box, without having to get inside it (except maybe in the same small number of cases where SETF has to be a macro). So, let SETF be a macro, but also provide a standard way to name the setter functions. I think that in this case one can have the best of both worlds, so to speak. >>The idea that Lisp is full of redundancies because of mapping vs >>DO vs LOOP, etc, seems to me a bit strange. ... [comparison with C >>deleted]. >I think the redundancy complaint is due to the fact that there are several >almost equivalent facilities at about the same level of abstraction. >printf() and putc() are clearly at different levels, while DO-LIST and >MAPC are nearly interchangeable. I think you're right about putc, but I was thinking (or would have been if I'd been thinking more clearly) more of puts (for writing strings) and the claim (sometimes made) that people should never use printf unless they really have to. I probably should have compared printf to format as well. Moreover, I don't think do-list and mapc are a redundancy, because mapc is in a sense more general. >>I think a more serious problem with CL is that it's hard to >>extract a relatively simple kernel because some of the primitives >>are missing. > >CL intentionally contains the facilities needed by the *users*, not the >implementors. I agree. And the ability to extract a relatively simple kernel is important to users because (a) it provides a conceptual simplification, (b) it makes it more likely that the size of implementations can be controlled. Indeed, when saying primitives were missing, I meant it from the user's point of view. Implementations can have whatever primitives they want, but it doesn't necessarily do the users any good. >In general, primitives are missing because they would >probably only be used to implement the higher-level facilities. And it's a mistake to suppose that users will not want to build similar higher-level facilities that are slightly but importantly different. >Of course, >if the primitives were there I'm sure people would use them; on the other >hand, the language would be even bigger (and the current draft of the >standard is already about 1300 pages long). I would rather see us *remove* >RPLACA, RPLACD, and SET (since their main purpose is for SETF to expand >into) rather than to add back ASET and PUTPROP. See above. Call it (SETF GET) or (SETTER GET) rather than PUTPROP. -- jd