Re: lisp introspection/reflection question
- From: Chris Barts <chbarts+usenet@xxxxxxxxx>
- Date: Fri, 12 Feb 2010 21:41:37 -0700
slash dot <tyntyfax@xxxxxxxxx> writes:
On Feb 1, 10:03 am, "Captain Obvious" <udode...@xxxxxxxxxxxxxxxxxxxxx>
sd> So one cannot inspect a function, is that what's you're
sd> saying, Zach?
Common Lisp standard does not require functions to be inspectable.
Because Common Lisp is supposed to be compiled and be effective,
w.r.t. memory usage too, I guess.
But is is not a problem because you can extract information you
want via macro at time function is defined. Write your own defun-like
macro and capture whatever you want.
E.g. if you want some functions to be accessible via RPC of some sort,
you can make a macro defun-rpc which is pretty much like defun:
(defun-rpc 10+ (number) (+ 10 number))
But internally it counts parameters, publishes functions, whatever.
That is a Common Lisp way to do it.
sd> Have I fallen for an April fool's joke? No dice?
Some implementations provide functionality which is not required
I thought about a macro, thanks, but do you really suggest that?
Isn't that intrusive?
No, it really isn't: It lives in a package and does everything you want
in a way that's completely hidden from any other code in your universe
(the running Lisp image). Basically, it works like this: The client code
invokes your macro, which does whatever it does, and then your macro
invokes the defun macro, which does the rest. The defun macro doesn't
know what's going on inside your package and neither does the client
code. (You /can/ access symbols inside a package that are not
exported. You can also determine whether a firearm is loaded by peering
down the barrel and pulling the trigger. You can do a lot of dumb things
in this world.)
The fact macros are /not/ intrusive is one of the great advantages of
Lisps in general: The language is 'open' in precisely the same ways C
and Fortran are 'closed' (although you can do wonderful, terrible things
with the C preprocessor, too).