I have a question. Is it possible to print a method body in its
original form using the mop after finding the method in a running lisp
process? I've been scratching my head trying to figure this out for way
to long and would appreciate any help explaining whether this is
possible or not. I know I can 'find-method and print/format the result,
but the result doesn't resemble the original. The mop book has
references to 'method-body, but I can't find reference to any such
method in a lisp that I'm running, nor can I seem to make sense of any
printing function to apply in this context.
Thanks in advance for any and all assistance,
Mike Ajemian
[ Mike Ajemian ]
> I have a question. Is it possible to print a method body in its
> original form using the mop after finding the method in a running lisp
> process?
I don't know the MOP, but I think this is a more general problem --
you are not likely to find the original form as it is in the source
file, as I would be surprised if any lisp retains the textual
representation of anything as it is before it is fed to the reader. I
think several IDEs are capable of locating the definition of something
in its source file; that might or might not help you.
Martin
--
"An ideal world is left as an exercise to the reader."
-Paul Graham, On Lisp
Martin Thornquist wrote:
> [ Mike Ajemian ]
>>I have a question. Is it possible to print a method body in its
>>original form using the mop after finding the method in a running lisp
>>process?
>
> I don't know the MOP, but I think this is a more general problem --
> you are not likely to find the original form as it is in the source
> file, as I would be surprised if any lisp retains the textual
> representation of anything as it is before it is fed to the reader. I
> think several IDEs are capable of locating the definition of something
> in its source file; that might or might not help you.
Yes the question is more general and pertains to functions in general,
but has nothing whatever to do with semantinc nonsense like "fed to
the reader." A function body is opaque regardless whether the lambda
expression that was the body was read by the reader, or was generated by
macroexpansion, or was otherwise created programmatically.
There are precisely three ways a function object can be created in Common
Lisp: (1) Execution of the FUNCTION special form where the subfoem is a
LAMBDA expression. (2) Execution of the COMPILE function where the second
argument is a lambda expression. (3) Execution of the COERCE functions
where the second argument specifies the function type.
Now, I purposely omit the familiar situations: Omitted are execution
of DEFUN and numerous other DEFmumble operators (such as DEFMETHOD and
DEFSETF) since all of these should macroexpand to something that executes
case (1) above then stores the resulting function somewhere, such as the
FDEFINITION of a symbol or some property of a symbol. I also do not
include loading a source or COMPILE-FILEd file that contains similar
defining forms, since loading a compiled file is supposed to work
the same as loading the uncompiled file, and loading the uncompiled file
is supposed to execute the top-level forms sequentially.
I also omit the FLET, LABELS, and MACROLET special forms. They deserve
to be added, in that they are independent special forms, but conceptually
and implementation they also reasonably depend upon the FUNCTION special
form and generated lambda expressions.
Now, each of the three situations identified above returns a function
object, and does not (necessarily) save the lambda expression argument.
A function object might (and preferably does) contain that lambda
expression translated into efficient machine instructions of some sort,
but a function object is basically opaque. Thre is relatively little
you can do with a function object in portable CL other FUNCALL or
APPLY it. You can print it, but the representation is not defined.
You can store it places, provided you are not concerned about equality.
The behavior of equality functions on FUNCTIONS is not mentioned in the
ANS; in other words, it is hard to prove using only the ANS whether the
result of (EQL #'EQL #'EQL) is true or false. I believe it is not
defined, but anyone is welcome to debate the point with me.
Any particular CL implementation can offer to save lambda expressions
and make them available later, but the only feature in standard ANSI CL
is the FUNCTION-LAMBDA-EXPRESSION function, which see. You can call
F-L-E on any function, and maybe the implementation will return the
lambda expression from which that FUNCTION was defined. Or maybe not,
since the success of F-L-E is not guaranteed. There may be declarations
or other advisatory controls provided by the implementation that either
encourage or discourage success of F-L-E, but you'll need to see the
documentation about extensions in your particular implementation to
learn about them.
Returning to the original request about methods, see the functions
FIND-METHOD in the ANS and METHOD-FUNCTION in the MOP as one path to
obtain a function to pass to F-L-E. SPECIALIZER-DIRECT-METHODS,
COMPUTE-APPLICABLE-METHODS, and DEFMETHOD itself are other paths to
obtaining METHOD objects.