I'm relatively new to Lisp, and I was wondering if there really is an upper limit to the "+" function.
(I guess this applies to all the other arithmetic functions "-", "/" etc.)
Reading Input from KeyboardThe read function is used for taking input from the keyboard. It may not take any argument. The read function reads characters from an input stream and interprets them by parsing as representations of Lisp objects.
Yes, there is an upper limit, but the exact upper limit is implementation-dependent. You're guaranteed to be able to pass at least 50, but it all depends. If you need to sum a list, you're probably better off with (reduce #'+ list)
, that should give you a much better scalability than any other method.
Common Lisp HyperSpec has some more info.
When it comes to value ranges there are two distinct cases, floats and integers. Floats are inherently limited by their size and an implementation that changed from single-floats to double-floats would surprise me a lot. With integers and rationals, CL seamlessly transition between fixnums and bignums, so the limit is a function of the usable address space available to the implementation. I suspect the same holds for complex numbers (complex integers and rationals -> go to bignums if needed; complex floats -> signal an out of range, or return an Inf or NaN).
Common Lisp has been defined in such a way that it could be implemented efficiently on a wide variety of hardware and software systems. Examples are processors like the Motorola 68000/20/30/40, the various Intel x86 processors, Lisp Machine stack-based processors, DEC VAX, RISC processors, super computers like those from Cray. In the 80s there were a lot of processor families competing, including processors developed for execution of Lisp code. Today we still have several processor families (x86, x86-64, ARM, SPARC, POWER, PowerPC, ...).
It can also be compiled to C, Scheme or other programming languages.
It can also be compiled to virtual machines like those of CMUCL, CLISP or the JVM / Java Virtual Machine (The Java Virtual Machine seems to have a limit of 254 arguments).
For example a Common Lisp compiler might compile Lisp code to straight-forward C code. Thus it would be good if as much of the function calling of the C compiler could be reused as possible. Especially also to make calling Lisp from C easier.
C/C++ has limits on that, too:
Maximum number of parameters in function declaration
Above gives numbers like 127 (C) and 256 for C++. So for a Lisp to C compiler these might be the limits. Otherwise the Lisp code would not use the C function calling.
The first such compiler KCL (Kyoto Common Lisp, later this implementation evolved into GCL / GNU Common Lisp and ECL / Embeddable Common Lisp) had a CALL-ARGUMENTS-LIMIT
of 64.
A 64bit implementation of LispWorks / Mac OS X for example has a value of 2047 for CALL-ARGUMENTS-LIMIT
.
CALL-ARGUMENTS-LIMIT
should be no smaller than 50.
Thus in Common Lisp, list processing and calling arguments are not related. If you want to process lists, you have to use the list processing tools (LIST, MAPCAR, APPEND, REDUCE, ...). Common Lisp provides a mechanism to access the arguments as a list using a &REST
parameter. But that should usually be avoided, since it might cause function calling overhead because a list of the arguments need to consed.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With