Vat*_*ine 11
是的,有一个上限,但确切的上限是依赖于实现的.你保证能够通过至少50,但这一切都取决于.如果你需要总结一个列表,你可能会更好(reduce #'+ list),这应该会给你一个比任何其他方法更好的可伸缩性.
Common Lisp HyperSpec有更多信息.
当涉及到值范围时,有两种不同的情况,浮点数和整数.浮动本身就受到它们的大小的限制,并且从单浮动到双浮动的实现会让我感到惊讶.对于整数和有理数,CL在fixnums和bignums之间无缝转换,因此限制是实现可用的可用地址空间的函数.我怀疑复杂的数字(复杂的整数和有理数 - >如果需要可以去bignums;复杂的浮点数 - >信号超出范围,或返回Inf或NaN).
Common Lisp的定义方式使其可以在各种硬件和软件系统上高效实现.例如摩托罗拉68000/20/30/40,各种英特尔x86处理器,基于Lisp Machine堆栈的处理器,DEC VAX,RISC处理器,以及来自Cray的超级计算机等处理器.在80年代,有许多处理器系列竞争,包括为执行Lisp代码而开发的处理器.今天我们仍然有几个处理器系列(x86,x86-64,ARM,SPARC,POWER,PowerPC ......).
它也可以编译为C,Scheme或其他编程语言.
它也可以编译为虚拟机,如CMUCL,CLISP或JVM/Java虚拟机(Java虚拟机似乎有254个参数的限制).
例如,Common Lisp编译器可能将Lisp代码编译为直接C代码.因此,如果可以尽可能多地重用C编译器的函数调用,那将是很好的.特别是从C调用Lisp更容易.
C/C++也有限制:
上面给出了类似127(C)和256的C++数字.因此,对于Lisp到C编译器,这些可能是限制.否则,Lisp代码不会使用C函数调用.
第一个这样的编译器KCL(Kyoto Common Lisp,后来这个实现演变成GCL/GNU Common Lisp和ECL/Embeddable Common Lisp)有CALL-ARGUMENTS-LIMIT64个.
例如,LispWorks/Mac OS X的64位实现的值为2047 CALL-ARGUMENTS-LIMIT.
CALL-ARGUMENTS-LIMIT 应不小于50.
因此,在Common Lisp中,列表处理和调用参数不相关.如果要处理列表,则必须使用列表处理工具(LIST,MAPCAR,APPEND,REDUCE,...).Common Lisp提供了一种使用参数作为列表访问参数的机制&REST.但是通常应该避免这种情况,因为它可能会导致函数调用开销,因为参数列表需要强制执行.