Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!bionet!arisia!roo!lanning From: lanning@parc.xerox.com (Stan Lanning) Newsgroups: comp.lang.clos Subject: Re: Naming: clos generics vs common lisp fns Message-ID: Date: 5 Dec 90 18:43:44 GMT References: Sender: news@parc.xerox.com Distribution: comp Organization: Xerox PARC, Palo Alto, CA Lines: 40 In-reply-to: jsp@glia.biostr.washington.edu.'s message of 3 Dec 90 21:56:41 GMT There is more to a language then its semantics; languages have certain performance characteristics. They are not often written down, but they are a very real part of the common knowledge shared by users and implementers of the language. Knowing the performance ins-and-outs of a language is one of the things that separates novices from experts. Strictly speaking, these are attributes of an implementation and not the language. But without some common performance characteristics, programs can't be ported from one system to another. It is one of the reasons why some implementations that are semantically correct are viewed as "broken" -- things that should be fast aren't, so all the programmers expectations are violated. The array accessing primitives in Lisp are traditionally just that: primitives, with very low overhead. Turning them into generic functions may (depending on how smart your compiler is) violate some very real programmer expectations, and "break" the system. With that said, you may still decide that you are willing to pay the price because of some other benefit(s). In that case, it's easy to make AREF generic in your package, as long as your AREF isn't the system's AREF: (defpackage "FOO" (:shadow "AREF")) (in-package "FOO") (defgeneric aref (array &rest subscripts)) (defmethod aref ((a array) &rest subscripts) (apply 'common-lisp:aref a subscripts)) -- -- smL Stan Lanning lanning@parc.xerox.com Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304 (415)494-4880 USA Fax: (415)494-4777 Brought to you by Super Global Mega Corp .com