Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.clos Subject: Re: Naming: clos generics vs common lisp fns Message-ID: <1990Dec5.052443.22093@Think.COM> Date: 5 Dec 90 05:24:43 GMT References: <9012042302.AA08997@caligula> Sender: news@Think.COM Distribution: inet Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 36 In article lgm@cbnewsc.ATT.COM (lawrence.g.mayka) writes: >Are functions such as AREF specifically documented as non-generic, or >are they merely documented as being of type FUNCTION? My >understanding was that GENERIC-FUNCTION is a subtype of FUNCTION, and >that therefore an implementor of ANSI Common Lisp is free to make any >or all Common Lisp functions generic. And indeed, I strongly >encourage vendors to do exactly that, to the extent that efficiency >considerations permit. Thus, AREF probably couldn't afford to be >generic just yet - at least not on conventional processors - but ELT >probably could be. Unless the spec documents a function as being generic, portable programs can't depend on it being so. Early drafts of CLOS actually allowed defining methods for functions not initially defined as generic. The function would be replaced with a generic function, and the old function definition would be made the default primary method. I don't remember precisely why this was removed, but I think it was felt that it would be better if DEFMETHOD could warn you that you'd reused a function name, rather than upgrading it to a generic function behind your back. For user-written programs, this lack isn't much of a problem, because the user can simply rewrite the function as a generic function. I think the original intent of the feature was to allow users to generify standard CL functions (e.g. AREF); however, other parts of the spec forbid the user from changing standard CL functions (to allow the implementation to use them internally), so there seemed to be little point to the automatic generification. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar Brought to you by Super Global Mega Corp .com