Prev: Do as the Romans do
Next: managing large table of data
From: Duane Rettig on 1 Feb 2010 12:11 On Jan 31, 3:34 pm, slash dot <tynty...(a)gmail.com> wrote: > lisp is famous for is reflection capabilities, and, > indeed, a function like '10+' is reported to be > > #<FUNCTION 10+ (NUMBER) (DECLARE (SYSTEM::IN-DEFUN 10+)) > (BLOCK 10+ (+ 10 NUMBER))> > > in clisp. > > (Disturbingly, this only works if I bind #'10+ to a variable and > evaluate > the variable, but that's a clisp implementation detail, right? RIGHT?) > > So my question is: how can I inspect functions to find out how > many arguments it has, for example? I'm not sure why others on this thread are beating around the bush. One person asked why you don't know it already, but perhaps others are just toying with you, or perhaps being overly conservative with their answers for fear of it not working on a particular implementation. But you asked how to inspect a function, and the answer is "use the cl:inspect function". How much information you get is implementation- dependent, and perhaps the problem here is how people interpret the relationship between cl:inspet and cl:describe, but since their actions are both implementation dependent, implementations are free to diverge them as much as is necessary to achieve the intuitive result. On Allegro CL: CL-USER(1): (defun foo (a b c) (list a b c)) FOO CL-USER(2): (inspect #'foo) A NEW #<Interpreted Function FOO> lambda-list: (A B C) 0 excl-type ----> Bit field: #x88 1 flags --------> Bit field: #x48 2 start --------> Bit field: #x00000010000011bb 3 hash ---------> Bit field: #x0000000000008649 4 symdef -------> The symbol FOO 5 code ---------> (LAMBDA (A B ...) ...), a proper list with 3 elements 6 formals ------> (A B C), a proper list with 3 elements 7 cframe-size --> fixnum 0 [#x0000000000000000] 8 immed-args ---> fixnum 0 [#x0000000000000000] 9 locals -------> fixnum 0 [#x0000000000000000] [1i] CL-USER(3): (compile 'foo) FOO NIL NIL [1i] CL-USER(4): (inspect #'foo) A NEW #<Function FOO> lambda-list: (A B C) 0 excl-type ----> Bit field: #x88 1 flags --------> Bit field: #x88 2 start --------> Bit field: #x000000100095bef8 3 hash ---------> Bit field: #x000000000000864a 4 symdef -------> The symbol FOO 5 code ---------> short simple CODE vector (31) = #(33608 30956 35148 ...) 6 formals ------> (A B C), a proper list with 3 elements 7 cframe-size --> fixnum 0 [#x0000000000000000] 8 immed-args ---> fixnum 0 [#x0000000000000000] 9 locals -------> fixnum 0 [#x0000000000000000] [2i] CL-USER(5):
From: Pascal J. Bourguignon on 1 Feb 2010 12:17 "joswig(a)corporate-world.lisp.de" <joswig(a)lisp.de> writes: > I would avoid that, since most implementations > can return function arglists already. That's needed for > any inspector/describe/IDE feature showing a function's > arglist. Well, it would depend if you want to write programs running on "most implementations" or on any Common Lisp implementation, I'd guess... -- __Pascal Bourguignon__
From: joswig on 1 Feb 2010 12:47 On 1 Feb., 18:11, Duane Rettig <du...(a)franz.com> wrote: > On Jan 31, 3:34 pm, slash dot <tynty...(a)gmail.com> wrote: > > > lisp is famous for is reflection capabilities, and, > > indeed, a function like '10+' is reported to be > > > #<FUNCTION 10+ (NUMBER) (DECLARE (SYSTEM::IN-DEFUN 10+)) > > (BLOCK 10+ (+ 10 NUMBER))> > > > in clisp. > > > (Disturbingly, this only works if I bind #'10+ to a variable and > > evaluate > > the variable, but that's a clisp implementation detail, right? RIGHT?) > > > So my question is: how can I inspect functions to find out how > > many arguments it has, for example? > > I'm not sure why others on this thread are beating around the bush. > One person asked why you don't know it already, but perhaps others are > just toying with you, or perhaps being overly conservative with their > answers for fear of it not working on a particular implementation. I understood his question that he wanted to have the arglist as data. That's what 'reflection' is about: providing data structures that describe various parts of the programming elements (functions, classes, types, ...) in a certain program.
From: joswig on 1 Feb 2010 12:59 On 1 Feb., 18:17, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de> writes: > > I would avoid that, since most implementations > > can return function arglists already. That's needed for > > any inspector/describe/IDE feature showing a function's > > arglist. > > Well, it would depend if you want to write programs running on "most > implementations" or on any Common Lisp implementation, I'd guess... Isn't that usually pretty useless? I would prefer to think task oriented: I want to solve problem FOO and for that I need capability BAR. The requirement to solve it in any Common Lisp implementation on the planet under any circumstance sounds artificial to me. There are many capabilities of Common Lisp implementations that are not standardized, but still useful and used. If for a certain capability there is a standard version, I would use it. If there are non-standard capabilities for other stuff (like getting argument lists from functions) I still use them - instead of inventing my own. There are several ways to get portability. For function arglists, there is this capability already in many popular Common Lisp implementations in a very similar way. Here it is sufficient to have a function that just calls the implementation specific version. In fact that is what many Lisp programs do. From some SLIME/SWANK for CLISP: (defimplementation arglist (fname) (block nil (or (ignore-errors (let ((exp (function-lambda-expression fname))) (and exp (return (second exp))))) (ignore-errors (return (ext:arglist fname))) :not-available)))
From: slash dot on 1 Feb 2010 13:47
On Feb 1, 2:02 am, Paul Donnelly <paul-donne...(a)sbcglobal.net> wrote: > slash dot <tynty...(a)gmail.com> writes: > > lisp is famous for is reflection capabilities, and, > > indeed, a function like '10+' is reported to be > > > #<FUNCTION 10+ (NUMBER) (DECLARE (SYSTEM::IN-DEFUN 10+)) > > (BLOCK 10+ (+ 10 NUMBER))> > > > in clisp. > > > (Disturbingly, this only works if I bind #'10+ to a variable and > > evaluate > > the variable, but that's a clisp implementation detail, right? RIGHT?) > > > So my question is: how can I inspect functions to find out how > > many arguments it has, for example? > > Isn't that the sort of thing you should already know? My code needs a largish number of very similar lambdas. Right now the code does what you suggest. It maintains the information on its arguments in an extra data structure. The argument information is put into the data structure when the lambda is declared. This DOES work, but I was curious about automating this. |