Subject: Re: Type specifier: list of <subtype>?
From: Erik Naggum <>
Date: 1997/08/15
Newsgroups: comp.lang.lisp
Message-ID: <>

* Don Geddis
| An example of the code would be:
| 	(defun foo (x)
| 	  (declare (type list x))
| 	  (dolist (item x)
| 	     (print (elt item 0)) ))
| I know that I could add more type info further downstream.  E.g. I could
| declare that "item" is a string type.  But sometimes this is
| inconvenient, or it may be difficult for me to do the type inference
| myself in convoluted code.  Is there any type specifier I could use in
| the original declaration of the variable "x" that would mean "a list of
| strings"?

`elt' is the most general of all the sequence accessors, so if you are
inclined to declare "item" of type string or "x" of type list of strings,
you're probably much better off using a more specific accessor, such as
`char' or `schar'.

to me, `elt' communicates "this function needs to deal with sequences of
unknown type", and that would be contradicted by a declaration of the type
of the sequence such as with (declare (string item)).

on the other hand, one of the few annoying things about Common Lisp is that
the effect of declarations is so hard to predict, both in portable code and
in particular implementations.  often, the code is exactly the same unless
(declaim (optimize (speed 3) (safety 0) (debug 0))) is in effect when
compiling highly declared code.  since declarations are mainly optimization
tools in Common Lisp, you may find it instructive to profile the code, use
the most type-specific functions to your data, and review the algorithm for
inherent time- and space-related costs before you start introducing strong
type declarations, since they introduce a rigidity that makes the code much
harder to maintain, develop and reason about, not to mention that people
who read code with lots of declarations will overlook performance problems
in the algorithm -- just like C/C++ programmers tend to optimize the hell
out of inherently slow algorithms.  optimization is perhaps the single most
counter-intuitive of all the complex tasks programmers have to deal with.
like everything else, I guess the "easy answers" attract people, but don't
succumb to the siren songs of trivial optimizations -- they make the more
important optimizations much harder to locate.

404 Give me a URL I cannot refuse.