Finding the arity of a function
Mathew Sanders
function names that can be used and the functions arity to the
algorithm so that the GA can know how many arguments the function
needs when a random programme is being generated.
However I'd much rather have that happen automatically.
Does anyone know of a function in lisp that given another function
returns the arity?
Any help would be gratefully appreciated,
thanks, Matt Sanders
Coby Beck
"Mathew Sanders" <ma...@projectsolutions.co.nz> wrote in message
news:df7bac2d.01091...@posting.google.com...
check out function-lambda-list
CL-USER 357 > (defun foo (a b c &optional d) nil)
FOO
CL-USER 358 > (function-lambda-list 'foo)
(A B C &OPTIONAL D)
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
Peter Wood
Isn't that a LW extension? CL has #'function-lambda-expression, and
"any implementation may legitimately return nil as the lambda
expression of any function".
Regards,
Peter
Coby Beck
"Peter Wood" <peter...@worldonline.dk> wrote in message
news:804rq06...@localhost.localdomain...
> "Coby Beck" <cb...@mercury.bc.ca> writes:
> > check out function-lambda-list
> > CL-USER 357 > (defun foo (a b c &optional d) nil)
> > FOO
> >
> > CL-USER 358 > (function-lambda-list 'foo)
> > (A B C &OPTIONAL D)
> >
>
> Isn't that a LW extension? CL has #'function-lambda-expression, and
> "any implementation may legitimately return nil as the lambda
> expression of any function".
You are correct.
Apologies for replying too hastily.
Erik Naggum
> Does anyone know of a function in lisp that given another function
> returns the arity?
The arity of a function in Common Lisp is given by two values, not just
one, the lower bound being the number of required arguments and an upper
bound being the number of additional &optional arguments, and finally,
may not be bounded except by sysetm limits on the number of &rest or &key
arguments. The various implementations have different ways to access
this information, which is usually kept in some other place in addition
to the code that checks for the correct number of arguments.
I think LWW's choice of name for the accessor, function-lambda-list, is
good, so this function will give you the same function portably bewteen
LWW and Allegro CL:
#+allegro
(defun function-lambda-list (function)
(excl:arglist function))
Usually, the function describe will tell you about argument lists and
other useful stuff, and in the free Common Lisp implementations, you can
find out how they do that by looking at the source.
///
Sam Steingold
> * On the subject of "Finding the arity of a function"
> * Sent on 17 Sep 2001 23:37:51 -0700
> * Honorable ma...@projectsolutions.co.nz (Mathew Sanders) writes:
>
> Does anyone know of a function in lisp that given another function
> returns the arity?
there is no standard function for that in ANSI CL.
most implementations do provide this functionality though.
<http://clocc.sf.net>; <http://www.podval.org/~sds/data/port.html>
CLOCC/PORT/sys.lisp:
(defun arglist (fn)
"Return the signature of the function."
#+allegro (excl:arglist fn)
#+clisp (sys::arglist fn)
#+cmu (values (let ((st (kernel:%function-arglist fn)))
(if (stringp st) (read-from-string st)
(eval:interpreted-function-arglist fn))))
#+cormanlisp (ccl:function-lambda-list
(typecase fn (symbol (fdefinition fn)) (t fn)))
#+gcl (let ((fn (etypecase fn
(symbol fn)
(function (si:compiled-function-name fn)))))
(get fn 'si:debug))
#+lispworks (lw:function-lambda-list fn)
#+lucid (lcl:arglist fn)
#+sbcl (values (let ((st (sb-kernel:%function-arglist fn)))
(if (stringp st) (read-from-string st)
#+ignore(eval:interpreted-function-arglist fn))))
#-(or allegro clisp cmu cormanlisp gcl lispworks lucid sbcl)
(error 'not-implemented :proc (list 'arglist fn)))
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
Never let your schooling interfere with your education.
Erik Naggum
> there is no standard function for that in ANSI CL.
> most implementations do provide this functionality though.
> (defun arglist (fn) ...)
Thank you for the portable code, but would it be possible to rename the
portable function to function-lambda-list? With that name, it much more
closely mimics function-lambda-expression and programmers have a hope of
finding it with apropos and in the documentation without knowing its name.
///
Sam Steingold
> * On the subject of "Re: Finding the arity of a function"
> * Sent on Wed, 19 Sep 2001 16:20:25 GMT
1. `arglist' is what Emacs uses -- `lisp-arglist-command' and
`lisp-show-arglist' -- so I would expect that to be what people use.
2. out of the 8 implementations I support, 5 use `arglist', 2
`function-lambda-list' and 1 something else.
3. this code was released 2-3 years ago, so this incompatible change
might break the user code.
So I doubt that the renaming is justified.
OTOH, I can add
(setf (fdefinition `function-lambda-list') (fdefinition 'arglist))
if the users want it.
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
Let us remember that ours is a nation of lawyers and order.
Christophe Rhodes
> > * In message <32099052...@naggum.net>
> > * On the subject of "Re: Finding the arity of a function"
> > * Sent on Wed, 19 Sep 2001 16:20:25 GMT
> > * Honorable Erik Naggum <er...@naggum.net> writes:
> >
> > * Sam Steingold <s...@gnu.org>
> > > there is no standard function for that in ANSI CL.
> > > most implementations do provide this functionality though.
> > :
> > > (defun arglist (fn) ...)
> >
> > Thank you for the portable code, but would it be possible to rename the
> > portable function to function-lambda-list? With that name, it much more
> > closely mimics function-lambda-expression and programmers have a hope of
> > finding it with apropos and in the documentation without knowing its name.
>
> OTOH, I can add
> (setf (fdefinition `function-lambda-list') (fdefinition 'arglist))
> if the users want it.
There's an alternative, which you may not yet have considered:
deprecating arglist, writing (defun function-lambda-list (fn) ...),
and writing
(defun arglist (fn)
"Deprecated version of function-lambda-list"
(warn "ARGLIST is deprecated. Please use FUNCTION-LAMBDA-LIST instead.")
(function-lambda-list fn))
Breaking backwards compatibility isn't necessarily a great idea, but
neither is atrophy.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Kent M Pitman
The copyright notice for the PORT system says the code is covered by LGPL.
Is the above code encumbered?
Kent M Pitman
>
> Sam Steingold <s...@gnu.org> writes:
>
> > > * In message <32099052...@naggum.net>
> > > * On the subject of "Re: Finding the arity of a function"
> > > * Sent on Wed, 19 Sep 2001 16:20:25 GMT
> > > * Honorable Erik Naggum <er...@naggum.net> writes:
> > >
> > > * Sam Steingold <s...@gnu.org>
> > > > there is no standard function for that in ANSI CL.
> > > > most implementations do provide this functionality though.
> > > :
> > > > (defun arglist (fn) ...)
> > >
> > > Thank you for the portable code, but would it be possible to
> > > rename the portable function to function-lambda-list? With
> > > that name, it much more closely mimics
> > > function-lambda-expression and programmers have a hope of
> > > finding it with apropos and in the documentation without
> > > knowing its name.
I concur with Erik here.
> > OTOH, I can add
> > (setf (fdefinition `function-lambda-list') (fdefinition 'arglist))
> > if the users want it.
>
> There's an alternative, which you may not yet have considered:
> deprecating arglist, writing (defun function-lambda-list (fn) ...),
> and writing
>
> (defun arglist (fn)
> "Deprecated version of function-lambda-list"
> (warn "ARGLIST is deprecated. Please use FUNCTION-LAMBDA-LIST instead.")
> (function-lambda-list fn))
>
> Breaking backwards compatibility isn't necessarily a great idea, but
> neither is atrophy.
I also think this is a good idea.
Erik Naggum
> 1. `arglist' is what Emacs uses -- `lisp-arglist-command' and
> `lisp-show-arglist' -- so I would expect that to be what people use.
Those must be ILISP functions. For obvious reasons, Franz's ELI uses
arglist, too, but there is nothing in Emacs Lisp that exports the name
"arglist" so you can ask for it for an existing function. Perhaps you
mean XEmacs, or maybe something has happened in Emacs 21, which I have
tried to run several times, but I value response times and not crashes.
> 2. out of the 8 implementations I support, 5 use `arglist', 2
> `function-lambda-list' and 1 something else.
This is highly irrelevant, IMNSHO.
> 3. this code was released 2-3 years ago, so this incompatible change
> might break the user code.
A renaming would obviously not remove the old name.
> So I doubt that the renaming is justified.
None of the arguments support this conclusion.
> OTOH, I can add
> (setf (fdefinition `function-lambda-list') (fdefinition 'arglist))
> if the users want it.
I suggets you do it the other way around, after renaming it.
///
Sam Steingold
> * On the subject of "Re: Finding the arity of a function"
> > 1. `arglist' is what Emacs uses -- `lisp-arglist-command' and
> > `lisp-show-arglist' -- so I would expect that to be what people use.
>
> Those must be ILISP functions. For obvious reasons, Franz's ELI uses
> arglist, too, but there is nothing in Emacs Lisp that exports the name
> "arglist" so you can ask for it for an existing function. Perhaps you
> mean XEmacs, or maybe something has happened in Emacs 21, which I have
> tried to run several times, but I value response times and not crashes.
I do not use ILISP or XEmacs. These variables have been in the standard
GNU Emacs inf-lisp.el since it was written in 1988 (I think); you can
certainly see them in Emacs 19.34.
> > 2. out of the 8 implementations I support, 5 use `arglist', 2
> > `function-lambda-list' and 1 something else.
> This is highly irrelevant, IMNSHO.
this reflects what the implementors considered to be a reasonable name.
shouldn't their opinion count?
> > 3. this code was released 2-3 years ago, so this incompatible change
> > might break the user code.
> A renaming would obviously not remove the old name.
when I rename a file, I cannot refer to it using the old name, right?
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
My inferiority complex is the only thing I can be proud of.
Sam Steingold
> * On the subject of "Re: Finding the arity of a function"
> * Sent on Wed, 19 Sep 2001 17:17:00 GMT
> * Honorable Kent M Pitman <pit...@world.std.com> writes:
>
> Sam Steingold <s...@gnu.org> writes:
>
> > there is no standard function for that in ANSI CL.
> > most implementations do provide this functionality though.
> >
> > <http://clocc.sf.net>; <http://www.podval.org/~sds/data/port.html>
> > CLOCC/PORT/sys.lisp:
>
> LGPL. Is the above code encumbered?
yes.
this does not prevent you from using it in a proprietary program though
- just forces you to distribute my code with all your changes and
to keep LOAD in the image.
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
Even Windows doesn't suck, when you use Common Lisp
Erik Naggum
> this reflects what the implementors considered to be a reasonable name.
> shouldn't their opinion count?
Only if they _had_ an opinion, i.e., if they thought about another name.
If they did not consider alternatives, but just copied someone else,
there is nothing to consider in their quantity. You obviously want this
to be a stupid quantity contest instead of considering the valued opinion
of people who express them, so I shall leave you alone.
> > > 3. this code was released 2-3 years ago, so this incompatible change
> > > might break the user code.
> > A renaming would obviously not remove the old name.
>
> when I rename a file, I cannot refer to it using the old name, right?
Are you being intentionally obtuse or just incredibly dense? You gave us
the code to "alias" arglist to function-lambda-list and you cannot figure
out how to do it the other way around? Sorry, but this level of exchange
is just not worth engaging in, and I regret that you found it useful to
revert to your old mode of so unintelligent communication.
///
Kent M Pitman
> > * In message <sfw3d5j...@world.std.com>
> > * On the subject of "Re: Finding the arity of a function"
> > * Sent on Wed, 19 Sep 2001 17:17:00 GMT
> > * Honorable Kent M Pitman <pit...@world.std.com> writes:
> >
> > Sam Steingold <s...@gnu.org> writes:
> >
> > > there is no standard function for that in ANSI CL.
> > > most implementations do provide this functionality though.
> > >
> > > <http://clocc.sf.net>; <http://www.podval.org/~sds/data/port.html>
> > > CLOCC/PORT/sys.lisp:
> >
> > The copyright notice for the PORT system says the code is covered by
> > LGPL. Is the above code encumbered?
>
> yes.
>
> this does not prevent you from using it in a proprietary program though
> - just forces you to distribute my code with all your changes and
> to keep LOAD in the image.
I think you should not post code on comp.lang.lisp out of context that
is covered by a license restriction without posting notice of the license.
Mathew Sanders
> check out function-lambda-list
> CL-USER 357 > (defun foo (a b c &optional d) nil)
> FOO
>
> CL-USER 358 > (function-lambda-list 'foo)
> (A B C &OPTIONAL D)
>
> Coby
Thank you Coby, and everyone else.
I'm using LW so this is a perfect solution :)
Tim Bradshaw
> (defun arglist (fn)
> "Deprecated version of function-lambda-list"
> (warn "ARGLIST is deprecated. Please use FUNCTION-LAMBDA-LIST instead.")
> (function-lambda-list fn))
I think a nicer approach in genera is to write a compiler macro for
ARGLIST (or whatever function you want to deprecate) which emits a
warning and then declines to provide an expansion. That means you get
a warning at compile time, when it's useful, and not a million
warnings when the code runs, which are generally not useful.
Of course for ARGLIST this might not be ideal, because most uses of it
may be interactive calls from the toplevel. I think that in the
context of this thread - where a program wanted to know the arity -
the approach above would be better though.
(It's nice that CL has enough power in the language to let you do
things like this kind of compile-time warning about things).
--tim
Christophe Rhodes
> * Christophe Rhodes wrote:
> > (defun arglist (fn)
> > "Deprecated version of function-lambda-list"
> > (warn "ARGLIST is deprecated. Please use FUNCTION-LAMBDA-LIST instead.")
> > (function-lambda-list fn))
>
> I think a nicer approach in genera is to write a compiler macro for
> ARGLIST (or whatever function you want to deprecate) which emits a
> warning and then declines to provide an expansion. That means you get
> a warning at compile time, when it's useful, and not a million
> warnings when the code runs, which are generally not useful.
Indeed. Before I wrote the above I did try to come up with the
relevant incantation to tell the compiler this, but my experience with
compiler-macros is somewhat limited. Would you mind being explicit?
Thanks,
Tim Bradshaw
> Indeed. Before I wrote the above I did try to come up with the
> relevant incantation to tell the compiler this, but my experience with
> compiler-macros is somewhat limited. Would you mind being explicit?
I think something like this:
(defun foo (x y)
(values x y))
(defun deprecated-foo (y x)
;; old version of FOO, takes arguments in wrong order, now
;; implemented in terms of FOO
(foo x y))
(define-compiler-macro deprecated-foo (&whole form x y)
(declare (ignore x y))
(warn "DEPRECATED-FOO is deprecated, use FOO instead,
remembering the new argument order")
form)
If you were doing this a lot you'd probably want to define a DEPRECATE
macro which did this automatically. Hmm. You might want to use an
ARGLIST/FUNCTION-LAMBDA-LIST function in the definition of this
macro (actually you can just use &rest, but having the arglist might
let you do better reporting)...
--tim
Pierre R. Mai
> * Christophe Rhodes wrote:
>
> > Indeed. Before I wrote the above I did try to come up with the
> > relevant incantation to tell the compiler this, but my experience with
> > compiler-macros is somewhat limited. Would you mind being explicit?
>
> I think something like this:
>
>
> (defun foo (x y)
> (values x y))
>
> (defun deprecated-foo (y x)
> ;; old version of FOO, takes arguments in wrong order, now
> ;; implemented in terms of FOO
> (foo x y))
>
> (define-compiler-macro deprecated-foo (&whole form x y)
> (declare (ignore x y))
> (warn "DEPRECATED-FOO is deprecated, use FOO instead,
> remembering the new argument order")
> form)
You might even want to go so far as doing
(define-compiler-macro deprecated-foo (&whole form y x)
(warn "DEPRECATED-FOO is deprecated, use FOO instead,
remembering the new argument order, i.e. turning
~:<~@{~S~^ ~}~:@>
into
~:<~@{~S~^ ~}~:@>"
form `(foo ,x ,y))
form)
thereby relieving the harried programmer from having to look up the
definition of FOO in order to make the change. Note though that this
should only be done IFF FOO and DEPRECATED-FOO really only differ in
name and argument-list order, and don't have other semantic changes
that would invalidate "automatic" conversions.
Regs, Pierre.
--
Pierre R. Mai <pm...@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
wis...@inetmi.com
> I think a nicer approach in genera is to write a compiler macro for
> ARGLIST (or whatever function you want to deprecate) which emits a
> warning and then declines to provide an expansion. That means you
> get a warning at compile time, when it's useful, and not a million
> warnings when the code runs, which are generally not useful.
That is a cool idea. I wish there were a place where knowledge like
this could be kept.
John
Christophe Rhodes
Cliki?
There's a lot fewer of the programming-hints and -style there than
exists in the collective consciousness :-)
Cheers,
James A. Crippen
> wis...@inetmi.com writes:
>
> > Tim Bradshaw <t...@cley.com> writes:
> >
> > > I think a nicer approach in genera is to write a compiler macro for
> > > ARGLIST (or whatever function you want to deprecate) which emits a
> > > warning and then declines to provide an expansion. That means you
> > > get a warning at compile time, when it's useful, and not a million
> > > warnings when the code runs, which are generally not useful.
> >
> > That is a cool idea. I wish there were a place where knowledge like
> > this could be kept.
>
> Cliki?
>
> There's a lot fewer of the programming-hints and -style there than
> exists in the collective consciousness :-)
Hear hear. I think that's an excellent place to put such knowledge,
particularly since it is easy for others to append further notes on a
topic.
I'd actually like to see a CLiki area started specifically for
Lisp programming hints, tricks, and traps. Certainly a few good books
have been written on this topic, but most of them cover broader
subjects and don't cover simple hacks like the above that are only
worth a paragraph of mention.
'james
--
James A. Crippen <ja...@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.