🚀 go-pugleaf

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