From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!news2.kpn.net!news.kpn.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Help wiht LISP Function (Newbie) References: <26176b48.0110221114.7c6ba0c6@posting.google.com> <26176b48.0110231323.258670ae@posting.google.com> Mail-Copies-To: never From: Erik Naggum Message-ID: <3212998581648846@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 48 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Oct 2001 11:36:26 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader1.kpnqwest.net 1004009786 193.71.66.49 (Thu, 25 Oct 2001 13:36:26 MET DST) NNTP-Posting-Date: Thu, 25 Oct 2001 13:36:26 MET DST Xref: archiver1.google.com comp.lang.lisp:18585 * Thomas F. Burdick | But of course, not every CL has an insanely huge CALL-ARGUMENTS-LIMIT. apply and reduce exhibit the same weird design problem exhibited by Unix systems that still have ridiculously small argument list limits because core memory was expensive back in the 1840's or whenever. Especially Linux, which in this regard still thinks it runs on Linus's first Amgia or whatever. Most Unices support 64-bit file offsets and 32-bit inode numbers, some even 32-bit user ids, but several still argue against more than 128K of argument list space, which makes many otherwise natural shell wild-card expansions impossible, makes it impossible to use the output of commands impossible to use as argument lists, etc. I patch every Linux kernel I install anywhere to increase that limit to 4M, but it is such a braindamaged thing to make so small. Common Lisp argument lists are different from shell argument lists in one crucial respect: You can pass a list as one argument. This obviates the need for most of the operations that take a huge argument list. Indeed, it is good coding practice to accept arbitrary-sized lists as lists, not as &rest arguments, since they would have to be spread and collected, and really bad coding practice to take some user input and give it to an internal function that does not do the user-interface error checking that a consumer of user input should do, but given all this, the value should at least be so large that a programmer can feel safe when constructing argument lists in programs. The standard requires that call-arguments-limit be no smaller than 50. I would argue that an implementation of Common Lisp that does not allow at least 500 arguments is useless, so this is a quality-of-implementation issue, but it is not just call-arguments-limit, lambda-parameters-limit and multiple-values-limit are also way too small (50 and 20) as specified. | If you do use APPLY for something like this, it certainly behooves you do | document the possible limitation so as not to give future porters | unnecessary headaches. And that, to me, sounds like more of a pain in | the butt than just using REDUCE. I think it would be a good idea for an application to document its requirements on the Common Lisp implementation as far as these limits go, since they are only _required_ to be really small. /// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- The purpose of computing is insight, not numbers. -- Richard Hamming