[plt-scheme] procedure instrospection

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

Eli Barzilay <eli at barzilay.org> writes:

>> 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).
> I'm not sure...  It would need to be some "proper" solution for it to
> be useful enough to be added.  For example, such an emacs facility
> would be very helpful (and in drscheme too, of course), but it should
> also deal with macros.  And macros should not be dismissed into "hard
> cases that are left with no solution for now" -- they are much more
> common than you'd think...  For example, contracted functions are
> actually macros.

i totally agree with you that macros should be supported too. i'll do my
best with manually parsing the results of reading the module as syntax
to provide partial support for them. i'm sure there are lots of
difficulties and corner cases i cannot even imagine now, but i'll try to
deal with them as i encounter them. i'm guessing that some things will
be more easily dealt with before macro expansion: for instance,
displaying information about contracted functions (seems that the
relevant info is already in the source forms before expansion).

imho, these difficulties are yet another reason to implement this
functionality natively in the core :)

>> 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.
> Yes, the arity list is still available.  In fact the mechanism that
> keeps track of the arity is the best place to add a facility like you
> want, but it's not hackable since it's in the core...

(providing ways to hook into that mechanism from outside, so that i can
implement the facility i want, would perhaps be an option in case you
don't think implementing it in the core is going to happen.)

> But it does point at yet another problem -- what are the argument
> names you'd expect for this:
>   (define foo
>     (case-lambda [(x)   "stuff"]
>                  [(a b) "other stuff"]))
> ?

(foo x #:optional y) 
(foo x [y])

or something similar (i'm using the first form in my emacs thing for
other schemes).


Posted on the users mailing list.