Supported interfaces for Lisp introspection (arglist, find-definition etc)

--=-=-=
Content-Transfer-Encoding: quoted-printable


Apologies for the wide crosspost.  You're getting this mail because
you're the contact point for one or more of ILISP, ELI, SLIME,
Jabberwocky or Portable Hemlock, or you're on sbcl-devel.=20=20
The Reply-to is set to [email protected], a brand-new list for
discussing Lisp introspection issues.  I think I've configured it to
allow posts from non-members for the time being, though that will
probably change in a few days.

This is a note to alert everyone I can think of to the news that I'm
creating a "supported" interface for SBCL to support some intersection
of these needs.  This will be an SBCL contrib package: so far, it
contains outline definitions of VALID-FUNCTION-NAME-P,
FUNCTION-ARGLIST, and FIND-DEFINITION.  I'd be interested to see
discussion and requests from the likely users of this interface, and
also in hearing from Lisp implementation hackers who would like to
implement the same or similar interface in their Lisp implementation.

Sourceforge cvsweb is being laggy as usual, so for the time being I've
stuck the work-in-progress source file up at=20

  http://ww.telent.net/sb-introspect.lisp

Here's a question to start with: the internal interface to "where is
the source of this function" in SBCL returns the offset within the
file as a number of forms, not a character position.  Is this a good
thing or a bad thing?

For: if the file has been edited since it was last compiled, a
form-number is more likely to still be correct than a character offset

Against: For non-Lisp editors a character position would be more
desirable: even for Emacs, you'd have to do special things to the
reader to cope with conditionals, read-macros etc.

The idea I had on the way back from lunch was to have SBCL convert
form offsets into character positions, then in Emacs set markers in
those places when the file is first visited.  We'd then treat
character positions passed back from find-definition-source calls
as opaque cookies that map to the markers on each form.

I don't do a lot of elisp, though, and the manual warns that using
lots of markers in a file may slow down editing; I don't know if the
slowdown is likely to be visible on modern machines or if that warning
has been there forever: I can't see any intrinsic reason that it
should be slower than, say, editing a file with text properties.  Even
if it is, maybe we could fake it with invisible text properties
instead.  Elisp hackers?


=2Ddan

=2D-=20

   http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/hssPHDK5ZnWQiRMRAnAeAJ92YL2Th6IZMiroO/ueCHcS3UxMTwCgsfGV
lbs+7hRF0OfQCu7/hc2+hw0=
=6ok6
-----END PGP SIGNATURE-----
--=-=-=--


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php