Subject: Re: Type specifier: list of <subtype>? From: Erik Naggum <clerik@naggum.no> Date: 1997/08/15 Newsgroups: comp.lang.lisp Message-ID: <3080595393603693@naggum.no> * 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)). <soapbox> 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. </soapbox> #\Erik -- 404 Give me a URL I cannot refuse.