[plt-scheme] procedure instrospection

From: Jose A. Ortega Ruiz (jao at gnu.org)
Date: Sat Apr 18 03:33:27 EDT 2009

Eli Barzilay <eli at barzilay.org> writes:

> On Apr 18, Jose A. Ortega Ruiz wrote:
>> i see. that's useful, thanks. i was wondering whether it'd be
>> possible to somehow hook into the module evaluation process to
>> collect metadata while the module is read (or evaluated/expanded),
> Some of the information that you originally mentioned is only
> collectible while (or after) the code is running, for example, the
> callers and callees.  See the code in Matthew's recent post or in the
> new `profile' collection on how to get such data.  (But this is will
> not be accurate at all...)

yes, i understand that callers/callees is hairy, and for that reason
it's low priority in my list. i'll take a look at Matthew's profile,
though. thanks for the pointer.
>> specially for the case of formals names. i'm thinking of something
>> simple, and not necessarily 100% accurate--a hash table maintained
>> separately, say, recording metadata computed during evaluation.
> The real way to do that is if there was a way at the core to make
> procedures somehow remember their arguments.  It's not difficult to
> add a `lambda' form that does that, but it won't help with existing
> code.

given that it doesn't seem difficult to accomplish, any chance that it
could be added to a future relase? for instance, it'd be very nice to
have a 'status bar' in DrScheme showing this information (i'll be
showing it in an emacs mode i'm working on).

>> or, as you suggest, i could also read the module source as data, and
>> parse it to obtain/cache the information i want (although that
>> sounds a bit brittle and more inaccurate, since it relies on the
>> program's text instead of syntax data)... i'm guessing that plt
>> already provides procedures to help in the task (for instance, ports
>> remembering line and columns): any advice on what would be the best
>> way to accomplish that?
> You can get pretty accurate with that -- for example, reading the
> module as syntax (using `read-syntax') and expanding it will catch any
> macros that expanded into function definitions.

excellent. i'll try my hand at that.

> But it will still be a problem to get the argument names of a
> definition like
>   (define foo (let (...) (lambda (x y z) ...)))
> and it won't help at all with:
>   (define blah (compose foo bar))

right. but my guess is that those case are not that common, and for them
i can fall back to displaying an argument list derived from arity
information (is that still available for them?) with dummy arg names.


Posted on the users mailing list.