David Lichteblau <david@...> writes:
> Interfaces like ELI and SLIME need to poke around in undocumented data
> structures to find information like source code locations.
> Would SBCL like to offer them publicly? For example, attached are two
> simple code extracts for ELI. (FUNCTION-LOCATION stopped working for
> generic functions some time ago...)
ILISP stopped working for me when I upgraded it the other day. So, yes, I
think this would be a good idea (in contrib/ even if not in the core)
FWIW, I can't persuade your function-location to give me a non-zero
source offset on any function (simple or generic) I try it on.
Stealing Christophe's proposal from IRC, because I like it: how about
a generic function definition-location, which returns one source
location. The source location is some kind of object which should
only be queried via accessors: accessors exist for pathname and
character offset, and if we think of others later we can add them.
Note that the character location may be broken if it was just stored
at compilation time, and the file has been edited since. I'm tempted
to say that this is a problem for the implementation, not the client:
if it detects the file has been edited since compilation, it can have
extra brownie points for rereading it and working out where the
definition is now. The client may not have a CL reader to hand, so
it's unreasonable to pass this requirement up to it.
http://www.cliki.net/ - Link farm for free CL-on-Unix resources=20