lisp introspection/reflection question
in [Lisp]
|
Prev: Do as the Romans do
Next: managing large table of data
From: Andre Ramaciotti on 1 Feb 2010 14:57 You've got me curious now. Why you need the lambda list from a function? Can you give us an example? TIA
From: Thomas A. Russ on 1 Feb 2010 15:00 slash dot <tyntyfax(a)gmail.com> writes: > My ambition is limited to clisp for now; portability > is not an issue for the moment. In that case, perhaps EXT:ARGLIST will do exactly what you want. -- Thomas A. Russ, USC/Information Sciences Institute
From: joswig on 1 Feb 2010 15:07 On 1 Feb., 20:57, Andre Ramaciotti <andre.ramacio...(a)gmail.com> wrote: > You've got me curious now. Why you need the lambda list from a function? > Can you give us an example? > > TIA There are many uses for that. * one wants to print an overview of function names and their arglists of a package * one wants to write a graphical tool, where functions are represented by icons with ports, with ports for each argument the function has * you would want to create functions based on other functions, and want to reuse the original argument names for example you write macros that create functions based on other functions and you need the arglist of some other functions * you write a 'DSL' (domain specific language) that compiles to Lisp and want to retrieve arglists from Lisp * you are writing an inspector or similar development tools This and more were typical in Lisps, where the code has a representation in Lisp data. Either because the interpreter worked directly on Lisp forms or the source was stored in some data form also in a function object. In these case you could PRETTY-PRINT the source to the terminal, modify it and redefine it. With mostly-compiled Lisps some of the reflective capabilities became optional. But that does not mean that there is no use for it.
From: slash dot on 1 Feb 2010 17:23 On Feb 1, 8:11 pm, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > slash dot <tynty...(a)gmail.com> writes: > > 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. > > If your code already does it, then it is already automated. > What more automation do you want? > > Unless your code does (read) and you have to type manually the > argument list of each function when your code needs it... > > -- > __Pascal Bourguignon__ Well, you are an alert reader. "Unless your code does (read)..." My code doesn't (read), it gets the lambdas from an array and picks them by index as needed. Some of the lambdas need an argument, some don't. The caller inspects the lambda by one way or the other and passes an argument if needed. The alternative is to make all lambdas uniform in that all of them accept an argument, but some simply ignore it. However, there is a problem: the caller traverses a sequence and leaves maintaining the iterator to other parts of the system. If the caller fetches a value, passes it to the lambda, and the lambda does not need it, the system gets out of sync. The caller does something like (funcall my-lambda (next-item)) where (next-byte) advances the iterator. If the called lambda does not consume the passed value, it is supposed to be process by a subsequent call to a (potentially other) lambda. I hope you are still with me at this point. This route of a lambda-array saves a lot of code, because this representation of my data requires no parsing. Instead of deciphering some other representation and dispatching accordingly, the caller simply calls the unearthed lambda. For this to work, however, the caller must know whether the lambda will need the "next" item or not. What I can exploit here is the lucky coincidence that lambdas that need that particular data item expect it as an argument, and that this fact is reflected in the argument list. By inspecting the argument list, the caller can infer whether it is supposed to advance the iterator or not. Isn't that the lisp way?
From: slash dot on 1 Feb 2010 17:25
On Feb 1, 9:00 pm, t...(a)sevak.isi.edu (Thomas A. Russ) wrote: > slash dot <tynty...(a)gmail.com> writes: > > My ambition is limited to clisp for now; portability > > is not an issue for the moment. > > In that case, perhaps EXT:ARGLIST will do exactly what you want. > > -- > Thomas A. Russ, USC/Information Sciences Institute YES! EXT:ARGLIST does e x a c t l y what I want! Thanks bro! |