From: Duane Rettig on
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
"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
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
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
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.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13
Prev: Do as the Romans do
Next: managing large table of data