[slime-devel] Re: sbcl sources support

[Helmut Eller]

I integrated your patch in the CVS version.  It does basically the
same as your patch, but the functionality is a bit better separated
between front-end and backend.  As a side-effect, *readtable-alist* can
now be used to associate readtables with packages.

Helmut.


Christophe Rhodes <csr21 at cam.ac.uk> writes:

> Helmut Eller <e9626484 at stud3.tuwien.ac.at> writes:
>
>> I think it's rather unlikely, that someone works on SBCL and another
>> project with conflicting reader macros.  
>
> Relatively unlikely, I grant you -- but not beyond the bounds of
> possibility.  (A number of projects I work on have their own
> readtables, and it would be awkward if a minor bugfix to sbcl in the
> interim caused odd things to happen).
>
>> What do you think about a command like:
>>
>> (defun set-sbcl-syntax ()
>>   (setf *readtable* (sb-introspect:sbcl-readtable))
>>   (sb-introspect:advice-find-package))
>
> What I would like to happen is that, when a user does e.g. M-. to find
> the source of an sbcl function, that the normal slime commands work as
> expected without user intervention.  The precise mechanism to achieve
> this doesn't worry me so much (though I think global advising of
> find-package, and global setting of *readtable*, is a lot uglier than
> advice in the dynamic contour of slime evaluation -- this is in fact a
> defect of my patch, which handles slightly too many
> BOOTSTRAP-PACKAGE-NOT-FOUND conditions: during evaluation as well as
> compilation.)
>
> The problem from my point of view with the requirement of an explicit
> command is that it only marginally lowers the barrier of entry.  If
> you want a typical use case, I can imagine someone wishing to find the
> location of the error emitted from defconstant when a constant is
> being redefined, and redefine the checking function; notwithstanding
> the fact that there may be better ways of achieving the ultimate aim,
> I think this kind of interaction should be supported.  I don't think
> that this ability to treat the system as incrementally modifiable is
> assisted very much (over the current situation) by having to run an
> explicit command...
>
> Cheers,
>
> Christophe
>
> (Lest my tone be too negative: for the record I really appreciate the
> work you, Luke and others have done.  The fact that I'm even
> contemplating incremental modification of sbcl via slime should be
> testimony to that! :-)