From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!skynet.be!skynet.be!newsfeed.esat.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: &REST in VALUES type specifier References: <3C22D60C.F949D459@TCH.Harvard.edu> Mail-Copies-To: never From: Erik Naggum Message-ID: <3217916193397527@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 53 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Dec 2001 09:36:36 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader1.kpnqwest.net 1008927396 193.71.66.49 (Fri, 21 Dec 2001 10:36:36 MET) NNTP-Posting-Date: Fri, 21 Dec 2001 10:36:36 MET Xref: archiver1.google.com comp.lang.lisp:22879 * Alberto Riva | Is the VALUES declaration in BAR legal? Yes. (Although the term should be "conforming".) | I saw it used in a numerical integration package, and it seems to comply | with ANSI 4.4.22, although the explanation there is not very clear to me. Please note that entries in the dictionary clauses of the standard are not numbered. You should be aware of this if you use Franz Inc's modified version of the text of the standard. Please say "type specifier values" if that is the entry you are referring to. | So my question is: is the above one the correct way of using &rest in a | (values) specifier [...] or is the declaration wrong? It is the correct way of using &rest in a values type specifier. | (meaning that both ACL and LW are non-compliant in different ways) File bug reports and complain vociferously about this. Please let us know how the vendors respond. The nervousness that results from not being able to use the specification to which the product purports to conform as the basis of your own coding and expectations is a major detractor from fully exploiting the language. Just because nobody "needed" this sufficiently to make some vendor implement it so far, does not mean that it is not important. The fact that they have "overlooked" such a feature means that other advanced and seldom-used features are probably also "overlooked", which again means that in order to feel safe about using a language that has a stable and unchanging standard and specification since 1995, one has to figure out where the "mainstream" is and make sure to stay within it. That is _so_ not in the (Common) Lisp tradition. We have advanced and seldom-used features in the language because they turn out to be very useful when they _are_ needed. Causing a conforming program to fail either compilation or execution is _really_ bad when it comes to declarations, because it teaches people not to use them and not to trust them, and this is communicated to other users, either by reading about problems like this on USENET now or using various search engines, or by dangerous "memes" that hang around much longer than the bugs do. Like some incompetent C programmers feel _fear_ around memory management issues because they have been bitten by memory leaks and problems that crashed their toy computers years ago, Common Lisp newbies will learn that using the full power of the language causes wrong results and other unexpected behavior. This is detrimental to all the effort that went into creating a standard and a community around it. /// -- The past is not more important than the future, despite what your culture has taught you. Your future observations, conclusions, and beliefs are more important to you than those in your past ever will be. The world is changing so fast the balance between the past and the future has shifted.