Version 1 (modified by Mark Evenson, 13 years ago) (diff)

Entered Tobias's analysis from email

Tobias Rittweiler (SLIME hacker and genrally froopy hood) outlined the following in an email conversation about directions to improve source location information in ABCL:

Low hanging fruits are the following:

 * Instead of just storing pathname & file-position also store:

        - a dspec that it what kind of the symbol is, e.g.

              (DEFUN FOO)
              (DEFMETHOD FOO (..specializers))
              (DEFVAR *FOO*)

       - a snippet of the source code.

       - You can also look into SBCL's compiler how it constructs
         source paths (indices paths into the AST), it's pretty easy to
         do but requires some work. It's called GET-SOURCE-CODE, iirc.

         (Midterm goal)

  * At the moment, only one source location is stored. That doesn't mix
    well with CL's nature that a symbol can represent many things, and
    in particular not with GFs and methods. E.g. at the moment, ABCL
    only remember the source location of the last-recently loaded

       - Long term goal: Store source location information in method /
         function objects themselves. Make it extensible, so users can
         add source-locations for their own objects.


Another thing:

SWANK-COMPILE-STRING must be implemented on top of COMPILE-FILE, the
current implementation is wrong.

However, if you use COMPILE-FILE you'll go over a temporary file,
messing up EXT:SOURCE-PATHNAME and -FILE-POSITION. SBCL does that by a
:PLIST argument for WITH-COMPILATION-UNIT, and accessors from
debug-infos. CCL provides special keyword arguments to
COMPILE-FILE. Look into their swank backends.