Hi!
If I execute the following piece of code under lucid common lisp I get
the described error, #'+ called with 1000 arguments but only 512
arguments are allowed.
Is this something peculiar to lucid, or does lisp impose this
restriction in a standard way on all implementations?
(loop for i from 1 to 1000 collect (random 50)))
>>Error: + called with 1000 arguments, but at most 512 arguments are allowed
+:
Rest arg 0 (RESTARG): 48
:C 0: Ignore extra arguments
:A 1: Abort to Lisp Top Level
->
--
T. V. Raman <·····@cs.cornell.edu>Tel: (607)255-9202 R 272-3649
Office: 4116 Upson Hall,
Department of Computer Science, Cornell University Ithaca NY 14853-6201
Res: 226 Bryant Avenue Ithaca NY 14850
In article <·····················@cs.cornell.edu>, ·····@cs.cornell.edu (T. V. Raman) writes:
|>Relay-Version: VMS News - V6.0-3 14/03/90 VAX/VMS V5.5; site titan.ksc.nasa.gov
|>Path: titan.ksc.nasa.gov!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!raman
|>Newsgroups: comp.lang.lisp
|>Subject: Arbitrary limit on number of args to #'+ in lucid:
|>Message-ID: <·····················@cs.cornell.edu>
|>From: ·····@cs.cornell.edu (T. V. Raman)
|>Date: Tue, 9 Feb 93 16:18:59 EST
|>Organization: Cornell Univ. CS Dept, Ithaca NY 14853
|>Keywords: #'+ number of permitted arguments = 512?
|>Summary: Why is there a limit on the number of args here?
|>Lines: 27
|>
|>
|>
|>
|>Hi!
|>
|>If I execute the following piece of code under lucid common lisp I get
|>the described error, #'+ called with 1000 arguments but only 512
|>arguments are allowed.
|>
|>Is this something peculiar to lucid, or does lisp impose this
|>restriction in a standard way on all implementations?
|>
|>
|> (loop for i from 1 to 1000 collect (random 50)))
|>>>Error: + called with 1000 arguments, but at most 512 arguments are allowed
|>
|>+:
|> Rest arg 0 (RESTARG): 48
|>:C 0: Ignore extra arguments
|>:A 1: Abort to Lisp Top Level
|>
|>->
|>--
|> T. V. Raman <·····@cs.cornell.edu>Tel: (607)255-9202 R 272-3649
|> Office: 4116 Upson Hall,
|>Department of Computer Science, Cornell University Ithaca NY 14853-6201
|> Res: 226 Bryant Avenue Ithaca NY 14850
|>
Common Lisp specifies a variable called CALL-ARGUMENTS-LIMIT
which is a positive integer that is the upper exclusive bound on the number
of arguments taht may be passed to a function. The actual value is
implementation-dependant but can not be smaller than 50.
--
**
David Kuznick
·······@meglos.mdcorp.ksc.nasa.gov
MUTLEY! Do something! - D.D.
In article <·····················@cs.cornell.edu>, ·····@cs.cornell.edu (T. V. Raman) writes:
|> If I execute the following piece of code under lucid common lisp I get
|> the described error, #'+ called with 1000 arguments but only 512
|> arguments are allowed.
Common Lisp defines a constant named CALL-ARGUMENTS-LIMIT whose value "is a positive
integer that is the upper exclusive bound on the number of arguments that may be
passed to a function...[it] will not be smaller than 50 (CLtL2, p 147)." In Lucid
4.1 the value of CALL-ARGUMENTS-LIMIT is 512.
|> (loop for i from 1 to 1000 collect (random 50)))
|> >>Error: + called with 1000 arguments, but at most 512 arguments are allowed
|>
|> +:
|> Rest arg 0 (RESTARG): 48
|> :C 0: Ignore extra arguments
|> :A 1: Abort to Lisp Top Level
The call to LOOP above will not cause the error shown. The expression merely says
to *collect* 1000 random numbers. Perhaps you are applying #'+ to the resultant
list? Try:
(loop repeat 1000 sum (random 50))
..................................................
Len Charest, Jr.
JPL Artificial Intelligence Group
·······@aig.jpl.nasa.gov
Date: Tue, 9 Feb 1993 16:18 EST
From: "T. V. Raman" <·····@cs.cornell.edu>
If I execute the following piece of code under lucid common lisp I get
the described error, #'+ called with 1000 arguments but only 512
arguments are allowed.
Is this something peculiar to lucid, or does lisp impose this
restriction in a standard way on all implementations?
(loop for i from 1 to 1000 collect (random 50)))
>>Error: + called with 1000 arguments, but at most 512 arguments are allowed
+:
Rest arg 0 (RESTARG): 48
:C 0: Ignore extra arguments
:A 1: Abort to Lisp Top Level
Lisp implementations are allowed to place a limit on the maximum number
of arguments that may be passed in a single function call. The exact
limit varies from one implementation to another (and is indicated by the
constant CALL-ARGUMENTS-LIMIT), but it must be at least 50.
In article <·····················@cs.cornell.edu> ·····@cs.cornell.edu (T. V. Raman) writes:
>If I execute the following piece of code under lucid common lisp I get
>the described error, #'+ called with 1000 arguments but only 512
>arguments are allowed.
I assume you left the (apply #'+ ...) out of the example you included in
your message. Others have already answered your general question about
number of arguments.
In the case of associative functions such as + you can often use REDUCE
instead of APPLY and avoid any limit:
(reduce #'+ <list-of-numbers>)
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
From: Mark Kantrowitz
Subject: Re: Arbitrary limit on number of args to #'+ in lucid:
Date:
Message-ID: <C2AM6L.EFs.1@cs.cmu.edu>
In article <············@early-bird.think.com> ······@think.com (Barry Margolin) writes:
>In article <·····················@cs.cornell.edu> ·····@cs.cornell.edu (T. V. Raman) writes:
>>If I execute the following piece of code under lucid common lisp I get
>>the described error, #'+ called with 1000 arguments but only 512
>>arguments are allowed.
>
>I assume you left the (apply #'+ ...) out of the example you included in
>your message. Others have already answered your general question about
>number of arguments.
>
>In the case of associative functions such as + you can often use REDUCE
>instead of APPLY and avoid any limit:
>
>(reduce #'+ <list-of-numbers>)
Just for fun, I tried this out in Allegro and Lucid.
In Allegro CL 4.1 SPARC:
USER(15): (apply #'+
(loop repeat (1+ call-arguments-limit)
collect (random 50)))
(2 18 37 11 15 28 19 39 14 11 ...)
In Lucid CL 4.1 HP-Snake:
> (apply #'+
(loop repeat (1+ call-arguments-limit)
collect (random 50)))
11969
(BTW, call-arguments-limit is 512 in Lucid and 16384 in Allegro.)
What's going on here? Shouldn't this cause an error in both
implementations? It still works even if I replace
(1+ call-arguments-limit) with (* 2 call-arguments-limit).
It also happens in compiled code, so it doesn't seem to be an artefact
of the interpreter.
--mark
From: Zdzislaw Meglicki
Subject: Re: Series (was: Arbitrary limit on number...)
Date:
Message-ID: <1lsettINNc0d@manuel.anu.edu.au>
In article <·················@cbnewsc.ATT.COM>, ···@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
|> In article <················@di.epfl.ch> ········@di.epfl.ch (Fernando Mato Mira) writes:
|>
|> So consider learning SERIES, it is worthwhile, and a lot of fun.
|> Caveats:
|> 1.Shadow-import COMPILER-LET from CLtL1 when compiling the library.
|> 2.Remember to use series::let series::defun series::let*
|> series::multiple-value-bind when
|> defining series functions or binding series to lexical variables.
|> [...]
|>
|> I like SERIES too. It's unfortunate that no vendor, to my knowledge,
|> supports it. The disadvantages of lack of vendor support are shown by
|> the caveats above [...]
With David Sitsky (········@mehta.anu.edu.au) we have used recently the
series package to implement Bulirsch-Stoer rational function extrapolation
and the Bulirsch-Stoer ODE solver. This we then used to trace null
geodesics in Schwartzschild spacetime in order to image black hole. The
whole project was essentially a test of this particular programming
methodology against a more-or-less real scientific problem.
We didn't have any difficulties with Series. The installation under Lucid
went smoothly. We have used full installation into "user" so that we
didn't have to torture ourselves with invoking the package explicitly
(i.e, none of that series::let, series::defun, etc nonsense). We even got
it working on the CM-5 under *Lisp, although we quickly run out of memory
since unlike *let series::let doesn't release the stack.
The package provides beautiful facilities for a lot of things (including
even writing and reading files) and I heartily recommend it to other
programmers.
--
Zdzislaw Gustav Meglicki, ······@arp.anu.edu.au,
Automated Reasoning Program - CISR, and Plasma Theory Group - RSPhysS,
The Australian National University, G.P.O. Box 4, Canberra, A.C.T., 2601,
Australia, fax: (Australia)-6-249-0747, tel: (Australia)-6-249-0158
I worked quite a bit with the series package over this past summer,
on some research at Rockwell Science Center's Palo Alto Laboratory.
I found myself by and large very happy with series as I have a
strong preference for functional style over LOOP.
On the other hand, I found a couple of problems with the package
which I felt made it unusable until substantially revised:
1. Compatibility problems: Primary among these the problem cited in
earlier messages --- lack of compatibility with CLtL2. In
particular this means that installing the package under recent
versions of Allegro is about as pleasant as getting teeth pulled.
Furthermore, the SERIES macro is not compatible with CMU common
lisp. I believe this is largely because CMU CL takes type
declarations very seriously (generates type-checking code and does
type inference). One problem I encountered was variables declared
to be of type t being defined in the
(let (v)
(declare (type t v))
...
(setf v ...))
this fails if nil is not an element of type t. There were many
other problems, some caught at compile time, some only at run-time,
so I gave up my port in despair.
2. Limitations of Common Lisp's multiple-values constructs. In
particular I often found that I wanted to generate a series of, for
example, pairs of values, for applications that did things like
stepping along the range and image of a function in tandem. This is
really impossible to do in a syntactically appealing way, and I
suspect that it is impossible to do in a way that allows any
optimization. One always has to cons and de-cons tuples to come out
as the elements of one series and be filtered by the next. Sadly,
while problem #1 is fixable in the series package, I don't know what
can be done about this problem.
R
From: Fernando Mato Mira
Subject: SERIES status (was: Arbitrary limit on number of args to #'+ in lucid:)
Date:
Message-ID: <1993Feb17.105332@di.epfl.ch>
In article <·················@cbnewsc.ATT.COM>, ···@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
>
> I like SERIES too. It's unfortunate that no vendor, to my knowledge,
> supports it. The disadvantages of lack of vendor support are shown by
> the caveats above:
>
> - Obsolescence of the implementation (use of COMPILER-LET).
>
> - Lack of integration with the base system (need to use LET, LET*,
> etc., from a package other than COMMON-LISP).
>
> - Bugs (some usages fail).
>
> For these reasons, I may be forced to abandon it eventually.
>
From Dick Waters:
The latest version of series can be obtained as explained below.
There are definitely known bugs with regard to CL2. I am working on
an improved version, but it may be some time before it is completed.
When it is completed it will be available as described below. To my
knowledge no one other than me is working on an updated version.
Dick Waters
Mitsubishi Electric Research Laboratories
201 Broadway
Cambridge MA 02139
617-621-7508
The Series macro package is described fully in Waters R.C., "Automatic
Transformation of Series Expressions into Loops", ACM Transactions on
Programming Languages and Systems, 13(1):52--98, January 1991,
MIT/AIM-1082 and MIT/AIM-1083.
The source for SERIES can be obtained from the MERL.COM machine on the
INTERNET. You should connect with FTP (login as "anonymous") and copy
the file "/pub/series/s-code.lisp". A set of test cases is in the
file "/pub/series/s-test.lisp". Brief documentation is in the file
"/pub/series/s-doc.txt". As bugs are discovered and fixed, the source
and test cases will be updated. I suggest that you recopy the source
from time to time.
--
Fernando D. Mato Mira
Computer Graphics Lab "There is only one Language
Swiss Federal Institute of Technology and McCarthy is its prophet"
········@di.epfl.ch
FAX : +41 (21) 693 - 5328
Disclaimer:
disclaim([],[]).
disclaim([H|T],[DH,DT]) :- fixed_point_disclaimer(H,DH),
disclaim(T,DT).
fixed_point_disclaimer(Text,fixed_point_disclaimer(Text,_)).