It compiled without any problem, but when I trying to use that function as
(Wow a1 a2 a3 ..... a93)
I got an error. It only takes 63 variables. I double checked the all 93 variables over and over, but no error in there. So my dumb question is, is there any limitation of variables number for DEFUN? I use MCL 4.0.
Sungwoo Lim <sung...@cad.strath.ac.uk> writes: > is there any limitation of variables number for DEFUN? > I use MCL 4.0.
CALL-ARGUMENTS-LIMIT is a constant which defines the upper exclusive bound on many arguments a function can be given: it must be at least 50 and at least as great as LAMBDA-PARAMETERS-LIMIT. LAMBDA-PARAMETERS-LIMIT is an upper exclusive bound on the number of parameters in a lambda list: it must be at least 50.
Sungwoo Lim <sung...@cad.strath.ac.uk> writes: > How many variables DEFUN can handle?
Your implementation declares this through the constant variable LAMBDA-PARAMETERS-LIMIT. The standard says it should be at least 50. In ACL it seems to be 16384.
Sungwoo Lim <sung...@cad.strath.ac.uk> writes: > How many variables DEFUN can handle?
See the HyperSpec entries on LAMBDA-PARAMETERS-LIMIT and CALL-ARGUMENTS-LIMIT, both of which are implementation-defined constants which determine the maximum number of parameters and arguments allowed. The HyperSpec only specifies that they be >= 50, and encourages implementations to make them as large as feasible. Some implementations (IIRC MCL among them) have quite low limits on this.
In any case I don't see why you would ever want to have a function with 93 _named_ parameters. It seems to me that you should be using more complex data-structures like sequences, hash-tables, structures or objects, instead of passing huge numbers of things around as parameters.
Regs, Pierre.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
> > is there any limitation of variables number for DEFUN? > > I use MCL 4.0.
> CALL-ARGUMENTS-LIMIT is a constant which defines the upper exclusive > bound on many arguments a function can be given: it must be at least > 50 and at least as great as LAMBDA-PARAMETERS-LIMIT. > LAMBDA-PARAMETERS-LIMIT is an upper exclusive bound on the number of > parameters in a lambda list: it must be at least 50.
> The reason they are different is for things like
> (defun foo (&rest x) x)
> --tim
5 > call-arguments-limit 8192
As I see, the limitation is 8192!!!! But still I can't use more than 63? -_-;;; Strange.... Thanks!
> See the HyperSpec entries on LAMBDA-PARAMETERS-LIMIT and > CALL-ARGUMENTS-LIMIT, both of which are implementation-defined > constants which determine the maximum number of parameters and > arguments allowed. The HyperSpec only specifies that they be >= 50, > and encourages implementations to make them as large as feasible. > Some implementations (IIRC MCL among them) have quite low limits on > this.
MCL allows 8192 as below... but why I can't use more than 63? Hyperspec and The reference book doesn't mention that how can change this value...
5 > call-arguments-limit 8192
> In any case I don't see why you would ever want to have a function > with 93 _named_ parameters. It seems to me that you should be using > more complex data-structures like sequences, hash-tables, structures > or objects, instead of passing huge numbers of things around as > parameters.
> Regs, Pierre.
Actually, I made a structure which contains 93 slots with mixed type. What I tried to do with my silly DEFUN is that put values into the structure...
>> > is there any limitation of variables number for DEFUN? >> > I use MCL 4.0.
>> CALL-ARGUMENTS-LIMIT is a constant which defines the upper exclusive >> bound on many arguments a function can be given: it must be at least >> 50 and at least as great as LAMBDA-PARAMETERS-LIMIT. >> LAMBDA-PARAMETERS-LIMIT is an upper exclusive bound on the number of >> parameters in a lambda list: it must be at least 50.
>> The reason they are different is for things like
>> (defun foo (&rest x) x)
>> --tim
> 5 > call-arguments-limit > 8192
> As I see, the limitation is 8192!!!! > But still I can't use more than 63? -_-;;; > Strange....
No call-arguments-limit gives the number of arguments you can have when *calling* the function. If you have a (defun foo (&rest x) x) function then this function can take from 0 to call-arguments-limit arguments.
What you should look into is LAMBDA-PARAMETERS-LIMIT which seems to be 63 in MCL.
In article <9deib9$hao2...@ID-22205.news.dfncis.de>, Jochen Schmidt
<j...@dataheaven.de> wrote: > No call-arguments-limit gives the number of arguments you can have when > *calling* the function. If you have a (defun foo (&rest x) x) function then > this function can take from 0 to call-arguments-limit arguments.
> What you should look into is LAMBDA-PARAMETERS-LIMIT which seems to be 63 > in MCL.
> Regards, > Jochen
The value of LAMBDA-PARAMETERS-LIMIT is same with CALL-ARGUMENT-LIMIT. They are both 8192...
> The value of LAMBDA-PARAMETERS-LIMIT is same with CALL-ARGUMENT-LIMIT. > They are both 8192...
unless there's a bug in your code (do all the args have different names), I think you should ask digitool as this looks like it might be a bug in MCL then.
Sungwoo Lim <sung...@cad.strath.ac.uk> writes: > MCL allows 8192 as below... but why I can't use more than 63? > Hyperspec and The reference book doesn't mention that how can change > this value...
You can't change those values, since they are constants, and indeed these constants have to be hard-coded into the implementation, since they represent implementation limitations. But given that both of them are > 63, this isn't your problem.
> 5 > call-arguments-limit > 8192
Actually you need to look at LAMBDA-PARAMETERS-LIMIT for your particular case, but as you reported in another post, this, too, is bigger than 63, then you shouldn't be running up against this limit. So either you made a mistake in your lambda list (not unlikely with 93 arguments), or you have encountered a bug in MCL, which you should report to Digitool through the usual channels.
You might want to try the following:
(eval `(defun test-me ,(loop for i from 1 to 100 collect (intern (format nil "VAR-~D" i)))))
If this barfs, and the following returns true, then you've found a bug:
(< 100 lambda-parameters-limit)
> Actually, I made a structure which contains 93 slots with mixed type.
Then let me rephrase the question: Why do you need a structure with 93 slots? This too seems a bit excessive, except for very special circumstances.
> What I tried to do with my silly DEFUN is that put values into the > structure...
What kind of information are you storing for each stroke that you need 93 slots? I can't even imagine more then maybe 10 or so attributes that might be associated with a stroke:
- Starting and ending coordinates (or, if more coordinates are linked to a stroke, then a sequence of coordinates), which is between 1 and 4 (6 if 3D) slots,
- Time, pressure, velocity, maybe some button masks, probably 1-2 slots each,
- In drawing applications maybe things like color, width, etc.
> This is why my silly DEFUN takes 93 arguments...
If you need to resort to writing silly defuns, just to avoid the typing overhead, then this is a clear indication that your structure definition needs some rework...
> If there is another way to put these looong values, plz let me know...
Don't have them in such an unstructured form in the first place. If you explain the exact content of your defstruct, maybe someone can suggest ways of cutting down on the slot-count rather rapidly...
Regs, Pierre.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
> > How many variables DEFUN can handle? > [...] > In any case I don't see why you would ever want to have a function > with 93 _named_ parameters.
Dick Waters used to say "A function that has more than ten arguments has too few." I always took this to mean: once you exceed the 7+/-2 things you can store in your short term memory, you are likely to forget things if you start to just label them positionally.
I personally think it's stylistically improper to go anywhere over the ten arguments limit that Waters introduced me to.
What implementations do at that point is lamentable, but IMO you deserve what you get when you go outside of rational style guidelines...
Sungwoo Lim <sung...@cad.strath.ac.uk> writes: > Actually, I made a structure which contains 93 slots with mixed type. > What I tried to do with my silly DEFUN is that put values into the > structure...
At minimum, use keyword arguments. In most cases, you won't need all 93.
But I suggest consolidating some of the less-used arguments into layered structures, too, rather than having them all at toplevel.
In article <87bsp1vxqv....@orion.bln.pmsf.de>, Pierre R. Mai
<p...@acm.org> wrote: > You might want to try the following:
> (eval `(defun test-me ,(loop for i from 1 to 100 > collect (intern (format nil "VAR-~D" i)))))
> If this barfs, and the following returns true, then you've found a > bug:
> (< 100 lambda-parameters-limit)
I did exactly what you said, and I got follow result. ------------------------------------------------------------------------ 4 > (eval `(defun test-me ,(loop for i from 1 to 100 collect (intern (format nil "VAR-~D" i))))) ;Compiler warnings : ; Unused lexical variable VAR-100, in TEST-ME. ; Unused lexical variable VAR-99, in TEST-ME. ; Unused lexical variable VAR-98, in TEST-ME. ; Unused lexical variable VAR-97, in TEST-ME. ........ ; Unused lexical variable VAR-2, in TEST-ME. ; Unused lexical variable VAR-1, in TEST-ME. TEST-ME 5 > (< 100 lambda-parameters-limit) T ------------------------------------------------------------------------ So, is this the BUG of MCL? Then, I should report this to Digitool...
> Then let me rephrase the question: Why do you need a structure with > 93 slots? This too seems a bit excessive, except for very special > circumstances. > What kind of information are you storing for each stroke that you need > 93 slots? I can't even imagine more then maybe 10 or so attributes > that might be associated with a stroke:
> - Starting and ending coordinates (or, if more coordinates are linked > to a stroke, then a sequence of coordinates), which is between 1 and > 4 (6 if 3D) slots,
> - Time, pressure, velocity, maybe some button masks, probably 1-2 slots > each,
> - In drawing applications maybe things like color, width, etc.
What I am doing is not simple sketching application. I am trying to capture some vague information as many as possible from each sketch stroke. All informations are related to 3D coordinates, possible vertices and probabilities of hierarchical primitive shapes.
> Don't have them in such an unstructured form in the first place. If > you explain the exact content of your defstruct, maybe someone can > suggest ways of cutting down on the slot-count rather rapidly...
I attached whole 93 arguments in here. Very few argument I can obmit in there. I noted '<-' to some argument which possibly obmitted. So I can reduce the arguments upto 74 now... (but I have to modify a bunch of codes to obmit these values... >.<) So, now you may understand that why there are such a huge number of arguments...
In article <sfweltw8z97....@world.std.com>, Kent M Pitman
<pit...@world.std.com> wrote: > At minimum, use keyword arguments. In most cases, you won't need all 93.
> But I suggest consolidating some of the less-used arguments into layered > structures, too, rather than having them all at toplevel.
Yeah.. I think I should do that... I checked the whole arguments and possibly I can obmit 19, but need to modify a bunch of my code... painful. =) Thanks,
> You might want to try the following: > (eval `(defun test-me ,(loop for i from 1 to 100 > collect (intern (format nil "VAR-~D" i))))) > IF this barfs, and the following returns true, then you've found a > bug: > (< 100 lambda-parameters-limit)
Not to sound picky, but the barfage he got was at invocation time. So, after doing that eval, he should also invoke (apply #'test-me (loop for i from 1 to 100 collect i))
In article <y7c7kzomeir....@sindri.juniper.net>, Joel Ray Holveck
<jo...@juniper.net> wrote: > > You might want to try the following: > > (eval `(defun test-me ,(loop for i from 1 to 100 > > collect (intern (format nil "VAR-~D" i))))) > > IF this barfs, and the following returns true, then you've found a > > bug: > > (< 100 lambda-parameters-limit)
> Not to sound picky, but the barfage he got was at invocation time. > So, after doing that eval, he should also invoke > (apply #'test-me (loop for i from 1 to 100 collect i))
> Cheers, > joelh
? (eval `(defun test-me ,(loop for i from 1 to 100 collect (intern (format nil "VAR-~D" i)))))
? (apply #'test-me (loop for i from 1 to 100 collect i)) NIL ? (< 100 lambda-parameters-limit) T
I invoked your suggestion and got this result. Still same... Regards,
>> Not to sound picky, but the barfage he got was at invocation time. >> So, after doing that eval, he should also invoke >> (apply #'test-me (loop for i from 1 to 100 collect i)) > ? (eval `(defun test-me ,(loop for i from 1 to 100 > collect (intern (format nil "VAR-~D" i))))) > ? (apply #'test-me (loop for i from 1 to 100 collect i)) > NIL > ? (< 100 lambda-parameters-limit) > T > I invoked your suggestion and got this result. > Still same...
Sorry, then, but these results are inconclusive. You have successfully defined and called the function with 100 parameters.
I really should have taken a cue from Pierre and written the test using eval, not apply.
(eval `(test-me ,@(loop for i from 1 to 100 collect i)))
If that gets an error on execution, then that would indicate a bug. If not, then the results are, again, inconclusive.
Of course, I tend to agree with the others and add that any design which involves passing around 93 discrete parameters probably needs a good seeing-to anyway, so what I just proposed may not be the best way to proceed.
> > Error: Too many arguments (no opt/rest) > > While executing: PUT-STROKE-INFO
That looks like an argument count mismatch to me, specifically that you invoked the function with too many arguments relative to the number of parameters you specified in the lambda list.
Could you run the same examples I ran here for me?
(1) cl-user (defun example-1 (aa ab ac ad ae af ag ah ai aj ak al am an ao ap aq ar as at au av aw ax ay az ba bb bc bd be bf bg bh bi bj bk bl bm bn bo bp bq br bs bt bu bv bw bx by bz ca cb cc cd ce cf cg ch ci cj ck cl cm cn co cp cq cr cs ct cu cv cw cx cy cz da db dc dd de df dg dh di dj dk dl dm dn do dp dq dr ds dt du dv dw dx dy dz) (and aa ab ac ad ae af ag ah ai aj ak al am an ao ap aq ar as at au av aw ax ay az ba bb bc bd be bf bg bh bi bj bk bl bm bn bo bp bq br bs bt bu bv bw bx by bz ca cb cc cd ce cf cg ch ci cj ck cl cm cn co cp cq cr cs ct cu cv cw cx cy cz da db dc dd de df dg dh di dj dk dl dm dn do dp dq dr ds dt du dv dw dx dy dz)) (1) cl-user => example-1 (2) cl-user (example-1 'aa 'ab 'ac 'ad 'ae 'af 'ag 'ah 'ai 'aj 'ak 'al 'am 'an 'ao 'ap 'aq 'ar 'as 'at 'au 'av 'aw 'ax 'ay 'az 'ba 'bb 'bc 'bd 'be 'bf 'bg 'bh 'bi 'bj 'bk 'bl 'bm 'bn 'bo 'bp 'bq 'br 'bs 'bt 'bu 'bv 'bw 'bx 'by 'bz 'ca 'cb 'cc 'cd 'ce 'cf 'cg 'ch 'ci 'cj 'ck 'cl 'cm 'cn 'co 'cp 'cq 'cr 'cs 'ct 'cu 'cv 'cw 'cx 'cy 'cz 'da 'db 'dc 'dd 'de 'df 'dg 'dh 'di 'dj 'dk 'dl 'dm 'dn 'do 'dp 'dq 'dr 'ds 'dt 'du 'dv 'dw 'dx 'dy 'dz) => dz (3) cl-user (example-1 'aa 'ab 'ac 'ad 'ae 'af 'ag 'ah 'ai 'aj 'ak 'al 'am 'an 'ao 'ap 'aq 'ar 'as 'at 'au 'av 'aw 'ax 'ay 'az 'ba 'bb 'bc 'bd 'be 'bf 'bg 'bh 'bi 'bj 'bk 'bl 'bm 'bn 'bo 'bp 'bq 'br 'bs 'bt 'bu 'bv 'bw 'bx 'by 'bz 'ca 'cb 'cc 'cd 'ce 'cf 'cg 'ch 'ci 'cj 'ck 'cl 'cm 'cn 'co 'cp 'cq 'cr 'cs 'ct 'cu 'cv 'cw 'cx 'cy 'cz 'da 'db 'dc 'dd 'de 'df 'dg 'dh 'di 'dj 'dk 'dl 'dm 'dn 'do 'dp 'dq 'dr 'ds 'dt 'du 'dv 'dw 'dx 'dy 'dz nil) Error: example-1 got 105 args, wanted 104 args. [condition type: program-error]
So my bet it is either this or some function called by put-stroke-info that gets too many arguments for its lambda list.
In article <3198569747076...@naggum.net>, Erik Naggum <e...@naggum.net> wrote:
> So my bet it is either this or some function called by put-stroke-info > that gets too many arguments for its lambda list.
> #:Erik
I finally found what is wrong in my code. When I defined the PUT-STROKE-INFO I put the same number for two arguments, and it made a huge mass for me (and even for this news group). Because of too many argument I couldn't find it even though I checked 6 times. T.T
I found this when I trying to divide my structure as three part... Oh god. kinda hell... Thanks for everybody's help and sorry for too massy. Regards,
And the problem was totally caused by my silly mistake. I finally found what is wrong. When I defined the PUT-STROKE-INFO, I put same number to two arguments. I couldn't find it even I checked 6 times because of too many arguments... DANG DANG~ Thanks for everybody who trying to help me, and sorry for massy.... Regards,
Sungwoo Lim <sung...@cad.strath.ac.uk> writes: > In article <87bsp1vxqv....@orion.bln.pmsf.de>, Pierre R. Mai > <p...@acm.org> wrote:
> > You might want to try the following:
> > (eval `(defun test-me ,(loop for i from 1 to 100 > > collect (intern (format nil "VAR-~D" i)))))
> > If this barfs, and the following returns true, then you've found a > > bug:
> > (< 100 lambda-parameters-limit)
> I did exactly what you said, and I got follow result. > ------------------------------------------------------------------------ > 4 > (eval `(defun test-me ,(loop for i from 1 to 100 > collect (intern (format nil "VAR-~D" i))))) > ;Compiler warnings : > ; Unused lexical variable VAR-100, in TEST-ME. > ; Unused lexical variable VAR-99, in TEST-ME. > ; Unused lexical variable VAR-98, in TEST-ME. > ; Unused lexical variable VAR-97, in TEST-ME. > ........ > ; Unused lexical variable VAR-2, in TEST-ME. > ; Unused lexical variable VAR-1, in TEST-ME. > TEST-ME > 5 > (< 100 lambda-parameters-limit) > T > ------------------------------------------------------------------------ > So, is this the BUG of MCL? Then, I should report this to Digitool...
No, because it didn't barf. It just issued correct warnings that all the variables in the lambda-list aren't used. It is allowed to do that (although the unused variable warnings should be style warnings only, AFAIK, but that's a different kettle of fish).
But test-me has been accepted by the system, and hence should work as specified, i.e. try the following:
(eval `(test-me ,@(loop for i from 1 to 100 collect i)))
This should work and return nil.
And if it does, then your problem with the original defun is most likely a bug in your defun definition, than a bug in MCL.
> I attached whole 93 arguments in here. > Very few argument I can obmit in there. I noted '<-' to some argument > which possibly obmitted. So I can reduce the arguments upto 74 now... > (but I have to modify a bunch of codes to obmit these values... >.<)
Not necessarily: Since the information can be computed from other values in the struct, you can easily write new readers that return the information:
(defun stroke-info-first-x (info) ;; Compute it here (aref (stroke-array-x info) 0))
Now you only have to remove the code that tries to do a setf of stroke-info-first-x. And if you don't want to do that, because it's much work, you might kludge around by defining a dummy setf function for stroke-info-first-x.
I would only include the redundant information in the structure, if it was really necessary from a performance standpoint.
> So, now you may understand that why there are such a huge number of > arguments...
Yes, that all seems reasonable to include, but I would maybe try to break the information down into blocks and include those substructures into a new top-level structure.
In any case I now don't see the point of the original defun: The setf form it contains seems much more readable than a call to the defun will:
(fill-stroke-info info 1 2 3 4 5 6 7 8 ... 92)
Seems much less informative, and much easier to foul-up than
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
