Hello,
This can be a very dumb question...
How many variables DEFUN can handle?
I made a function as
(defun Wow (a1 a2 ... a93)
(setf (function a1) a2
(function a1) a3
....
(function a1) a93))
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.
Thanks, (*_*)
Sungwoo
From: Tim Bradshaw
Subject: Re: [Q] Limitation of variables?
Date:
Message-ID: <nkjitj9ush0.fsf@tfeb.org>
Sungwoo Lim <·······@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.
The reason they are different is for things like
(defun foo (&rest x) x)
--tim
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org>
wrote:
> Sungwoo Lim <·······@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.
>
> 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!
Sungwoo
Sungwoo Lim wrote:
> In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org>
> wrote:
>
>> Sungwoo Lim <·······@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.
>>
>> 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.
Regards,
Jochen
In article <··············@ID-22205.news.dfncis.de>, Jochen Schmidt
<···@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...
Thanks,
Sungwoo
From: Tim Bradshaw
Subject: Re: [Q] Limitation of variables?
Date:
Message-ID: <nkjd79ht8il.fsf@tfeb.org>
Sungwoo Lim <·······@cad.strath.ac.uk> writes:
>
> 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.
--tim
Sungwoo Lim <·······@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.
--
Frode Vatvedt Fjeld
Sungwoo Lim <·······@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.
> I made a function as
>
> (defun Wow (a1 a2 ... a93)
> (setf (function a1) a2
> (function a1) a3
> ....
> (function a1) a93))
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 <····@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
In article <··············@orion.bln.pmsf.de>, Pierre R. Mai
<····@acm.org> wrote:
> Sungwoo Lim <·······@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.
>
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...
(defstruct stroke-info
(first-x 0.0 :type double-float)
(first-y 0.0 :type double-float)
........
(whatever 0 :type integer))
(setq a1 (make-stroke-info)
(defun put-stroke-info (a1 ... a93)
(setf (stroke-info-first-x a1) a2
(stroke-info-first-y a1) a3
........
(stroke-info-whatever a1) a93))
This is why my silly DEFUN takes 93 arguments...
If there is another way to put these looong values, plz let me know...
Thanks. =)
Sungwoo
Sungwoo Lim <·······@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...
>
> (defstruct stroke-info
> (first-x 0.0 :type double-float)
> (first-y 0.0 :type double-float)
> ........
> (whatever 0 :type integer))
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.
> (setq a1 (make-stroke-info)
> (defun put-stroke-info (a1 ... a93)
> (setf (stroke-info-first-x a1) a2
> (stroke-info-first-y a1) a3
> ........
> (stroke-info-whatever a1) a93))
>
> 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 <····@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
> 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
In article <···············@sindri.juniper.net>, Joel Ray Holveck
<·····@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,
Sungwoo
>> 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.
Best of luck,
joelh
Joel Ray Holveck <·····@juniper.net> writes:
> > 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))
Indeed he should, as I posted in my follow up to his reply. I was
under the mis-impression that he got a fault at definition time.
Regs, Pierre.
--
Pierre R. Mai <····@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
In article <··············@orion.bln.pmsf.de>, Pierre R. Mai
<····@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...
Regards,
Sungwoo
;---------------------------------------------
; information structure for each sketch stoke
;---------------------------------------------
(defstruct stroke-info
;---------------------------------
; analysis values for each stroke
;---------------------------------
(first-x 0.0 :type double-float) <-
(first-y 0.0 :type double-float) <-
(last-x 0.0 :type double-float) <-
(last-y 0.0 :type double-float) <-
(max-x 0 :type integer)
(max-y 0 :type integer)
(min-x 0 :type integer)
(min-y 0 :type integer)
(depth 0 :type integer)
(length 0 :type integer)
(adj-depth 0 :type integer)
(adj-length 0 :type integer)
(stroke-array-x nil :type vector)
(stroke-array-y nil :type vector)
(stroke-limit 0 :type integer)
(stroke-index 0 :type integer) <-
(possible-vertex-array-x nil :type vector)
(possible-vertex-array-y nil :type vector)
(index-number 0 :type integer)
(vertex-probabilities nil :type vector)
(ver-num 0 :type integer)
(self-intersection-array-x nil :type vector)
(self-intersection-array-y nil :type vector)
(self-intersection-probabilities nil :type vector)
(sel-num 0 :type integer)
(meaningful-ver-num 0 :type integer)
(minor-vertices-num 0 :type integer)
(vertexable-ver-num 0 :type integer)
(vertexable-inter-num 0 :type integer)
(vertex-exist-pro 0.0 :type double-float)
(copy-array-max nil :type vector)
(first-max 0.0 :type double-float) <-
(second-max 0.0 :type double-float) <-
(third-max 0.0 :type double-float) <-
(fourth-max 0.0 :type double-float) <-
(copy-array-min nil :type vector)
(first-min 0.0 :type double-float) <-
(second-min 0.0 :type double-float) <-
(third-min 0.0 :type double-float) <-
(fourth-min 0.0 :type double-float) <-
(copy-self-inter nil :type vector)
(first-inter 0.0 :type double-float) <-
(second-inter 0.0 :type double-float) <-
(third-inter 0.0 :type double-float) <-
(fourth-inter 0.0 :type double-float) <-
(vertices-for-polygon nil :type vector)
(ver-num-for-polygon 0 :type integer)
(maxpro-group nil :type vector)
(total-ver-num 0 :type integer)
;---------------------------------
; probabilities for each stroke
;---------------------------------
(close-pro 0.0 :type double-float)
(open-pro 0.0 :type double-float)
(cur-pro 0.0 :type double-float)
(poly-pro 0.0 :type double-float)
(strline-pro 0.0 :type double-float)
(cir-pro 0.0 :type double-float)
(ell-pro 0.0 :type double-float)
(free-pro 0.0 :type double-float)
(open-poly-pro 0.0 :type double-float)
(dis-tri-pro 0.0 :type double-float)
(dis-rec-pro 0.0 :type double-float)
(dis-other-pro 0.0 :type double-float)
(open-strline-pro 0.0 :type double-float)
(open-cur-pro 0.0 :type double-float)
(Odis-cirarc-pro 0.0 :type double-float)
(Odis-ellarc-pro 0.0 :type double-float)
(Odis-free-pro 0.0 :type double-float)
(closed-cur-pro 0.0 :type double-float)
(Cdis-cir-pro 0.0 :type double-float)
(Cdis-ell-pro 0.0 :type double-float)
(Cdis-free-pro 0.0 :type double-float)
(closed-poly-pro 0.0 :type double-float)
;----------------------------------------------------------
; hierarchically distributed probabilities for each stroke
;----------------------------------------------------------
(Op-Pol 0.0 :type double-float)
(Op-Pol-Tri 0.0 :type double-float)
(Op-Pol-Rec 0.0 :type double-float)
(Op-Pol-Other 0.0 :type double-float)
(Op-Str 0.0 :type double-float)
(Op-Cur 0.0 :type double-float)
(Op-Cur-CirArc 0.0 :type double-float)
(Op-Cur-EllArc 0.0 :type double-float)
(Op-Cur-Free 0.0 :type double-float)
(Cl-Cur 0.0 :type double-float)
(Cl-Cur-Cir 0.0 :type double-float)
(Cl-Cur-Ell 0.0 :type double-float)
(Cl-Cur-Free 0.0 :type double-float)
(Cl-Pol 0.0 :type double-float)
(Cl-Pol-Tri 0.0 :type double-float)
(Cl-Pol-Rec 0.0 :type double-float)
(Cl-Pol-Other 0.0 :type double-float)
;----------------------------------------------------------
; 3D related for each stroke
;----------------------------------------------------------
(first-z 0.0 :type double-float) <-
(last-z 0.0 :type double-float) <-
(stroke-array-z nil :type vector)
(possible-vertex-array-z nil :type vector)
(self-intersection-array-z nil :type vector)
) ; end of the DEFSTRUCT
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
Sungwoo Lim <·······@cad.strath.ac.uk> writes:
> In article <··············@orion.bln.pmsf.de>, Pierre R. Mai
> <····@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
(setf (stroke-info-first-x info) 1
(stroke-info-first-y info) 2
(stroke-info-last-x info) 3
(stroke-info-last-y info) 4
...
(stroke-info-self-intersection-array-z info) 92)
Regs, Pierre.
--
Pierre R. Mai <····@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
In article <··············@orion.bln.pmsf.de>, Pierre R. Mai
<····@acm.org> wrote:
> 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.
Yes, I did it now.
> 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
>
> (setf (stroke-info-first-x info) 1
> (stroke-info-first-y info) 2
> (stroke-info-last-x info) 3
> (stroke-info-last-y info) 4
> ...
> (stroke-info-self-intersection-array-z info) 92)
>
> Regs, Pierre.
True, many thanks. =)
Regards,
Sungwoo
Sungwoo Lim <·······@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 <···············@world.std.com>, Kent M Pitman
<······@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,
Sungwoo
"Pierre R. Mai" <····@acm.org> writes:
>
> Sungwoo Lim <·······@cad.strath.ac.uk> writes:
>
> > 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...
Can you say why you need this many?
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> Can you say why you need this many?
Yes, I reposted my all 93 arguments with some explanation
to Pierre. Plz take a look..
Regards,
Sungwoo
* Sungwoo Lim
> I got an error. It only takes 63 variables.
Could you post the _exact_ situation and the _exact_ error message?
#:Erik
--
Travel is a meat thing.
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Sungwoo Lim
> > I got an error. It only takes 63 variables.
>
> Could you post the _exact_ situation and the _exact_ error message?
>
> #:Erik
I made a defstruct with 93 arguments as I posted above somewhere.
It compiled without any error. However, when I called the function
(put-stroke-info a1 ... a3)
I got the follow error.
> Error: Too many arguments (no opt/rest)
> While executing: PUT-STROKE-INFO
So I checked the defun with
(put-stroke-info )
and MCL listener shows me it handles upto a63 arguments.
I tried following test, and got an interesting result..
Is this a bug?
> 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)
>
------------------------------------------------------------------------
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
------------------------------------------------------------------------
Regard,
Sungwoo
* Sungwoo Lim
> > 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.
#:Erik
--
Travel is a meat thing.
In article <················@naggum.net>, Erik Naggum <····@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,
Sungwoo
Sungwoo Lim <·······@cad.strath.ac.uk> writes:
> Hello,
>
> This can be a very dumb question...
>
> How many variables DEFUN can handle?
>
> I made a function as
>
> (defun Wow (a1 a2 ... a93)
> (setf (function a1) a2
> (function a1) a3
> ....
> (function a1) a93))
>
> It compiled without any problem, but when I trying to use that function
> as
>
> (Wow a1 a2 a3 ..... a93)
Errare humanum est, perseverare diabolicum. (If I remember my Latin).
Apart from the limit on function argument (see CALL-ARGUMENT-LIMIT and
LAMBDA-PARAMETERS-LIMIT), I still see vary bad symptoms of TclPerlite
in this approach of yours :) Maybe compounded by some Schemite,
further complicated by Currying excesses due to a mostly ML diet. :)
The
(setf (function a_x) a_x)
is a sign.
I suggest a return to more natural and middle way CL practices. CL has
42 Buddha Natures. :)
Cheers,
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
In article <···············@octagon.mrl.nyu.edu>, Marco Antoniotti
<·······@cs.nyu.edu> wrote:
> Errare humanum est, perseverare diabolicum. (If I remember my Latin).
>
> Apart from the limit on function argument (see CALL-ARGUMENT-LIMIT and
> LAMBDA-PARAMETERS-LIMIT), I still see vary bad symptoms of TclPerlite
> in this approach of yours :) Maybe compounded by some Schemite,
> further complicated by Currying excesses due to a mostly ML diet. :)
>
> The
> (setf (function a_x) a_x)
>
> is a sign.
>
> I suggest a return to more natural and middle way CL practices. CL has
> 42 Buddha Natures. :)
>
> Cheers,
Actual codes are as below.
(defstruct stroke-info
(first-x 0.0 :type double-float)
(first-y 0.0 :type double-float)
........
(whatever 0 :type integer))
(setq a1 (make-stroke-info)
(defun put-stroke-info (a1 ... a93)
(setf (stroke-info-first-x a1) a2
(stroke-info-first-y a1) a3
........
(stroke-info-whatever a1) a93))
So (setf (function a_x) a_x) is not what I wrote.
(setf (function a_x) a_y) should be correct.
Emm... I don't know what is TclPerlite?
Sounds like Tcl + Perl style something?
I just referred the book "Common Lisp The language second edition".
I never used Tcl,Perl,Scheme before, so...
I was born to be a TclPerlite? @@! LOL..
Cheers,
Sungwoo
* Sungwoo Lim
> Actual codes are as below.
>
> (defstruct stroke-info
> (first-x 0.0 :type double-float)
> (first-y 0.0 :type double-float)
> ........
> (whatever 0 :type integer))
>
> (setq a1 (make-stroke-info)
> (defun put-stroke-info (a1 ... a93)
> (setf (stroke-info-first-x a1) a2
> (stroke-info-first-y a1) a3
> ........
> (stroke-info-whatever a1) a93))
Does this imply that you reuse the instance assigned in a1? I think that
is fairly bad style. What if somebody kept a pointer to that instance?
What you do here requires an "ownership protocol" such that those who
think they might want to retain a pointer to the object longer than the
next instance, will have to make a copy. Violations of this protocol
means that some user of the instance will find that the data changes.
I suggest that you create a new instance every time you have a "stroke"
and instead of this "put-stroke-info", use the boa constructor option to
defstruct to make all of this (much, MUCH) more palatable.
(defstruct (stroke-info
(:constructor make-stroke-info (first-x first-y ... whatever)))
(first-x 0.0 :type double-float)
(first-y 0.0 :type double-float)
...
(whatever 0 :type integer))
Please note that the list of arguments to make-stroke-info (constructor)
may contain complex argument relationships and arbitrary computations.
The boa constructor assigns values to slots By Order of Arguments, and
you can use the value of previously specified arguments and even the
presence of such arguments in the boa lambda list.
Note also that the list of arguments to the simplest boa constructor may
be computed from the defstruct body, which a little snippet of Emacs Lisp
code can do for you if you do not want to write your own simple macro.
Also note that you defstruct by default makes a copy-stroke-info function
that copies every slot value from one instance to another such that the
slots are eql after the copy.
#:Erik
--
Travel is a meat thing.
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> Does this imply that you reuse the instance assigned in a1? I think that
> is fairly bad style. What if somebody kept a pointer to that instance?
> What you do here requires an "ownership protocol" such that those who
> think they might want to retain a pointer to the object longer than the
> next instance, will have to make a copy. Violations of this protocol
> means that some user of the instance will find that the data changes.>
Actually, I put the information into an array as below,
so I don't have to worry about the 'a1'.
(setf stroke-information (make-array 0 :adjustable t :fill-pointer 0))
(vector-push-extend a1 stroke-information)
> I suggest that you create a new instance every time you have a "stroke"
> and instead of this "put-stroke-info", use the boa constructor option to
> defstruct to make all of this (much, MUCH) more palatable.
>
> (defstruct (stroke-info
> (:constructor make-stroke-info (first-x first-y ... whatever)))
> (first-x 0.0 :type double-float)
> (first-y 0.0 :type double-float)
> ...
> (whatever 0 :type integer))
>
I tried the boa constructor, it seems much better and less code. =)
I instantly fired put-stroke-info. :)
Thanks alot.
Sungwoo