Hi,
attached is a patch for name conflict resolution within SLIME (Zach Beane wrote about the issue quite some time ago: <http://xach.livejournal.com/96625.html
). The patch is not meant for immediate inclusion into SLIME, more
as a request for feedback.
There are some rough edges in there: * works only with SBCL at the moment. In case of a name conflict, SBCL signals a condition which gives access to the set of conflicting symbols, and also provides a RESOLVE-CONFLICT restart which lets me choose programmatically which symbol to favor out of the conflicting ones. Other Lisps provide different restarts to resolve conflicts, and after superficial looks they appear to be less amenable to programmatic use.
* works correctly only with *recent* SBCL (>= 1.0.19.15)
* In case of many conflicts (e.g., due to USEing a package), on top of the RESOLVE-CONFLICT restart one can build some automation: instead of ending up a zillion times in the debugger, I can choose to favor a package, and for the current request conflicts are resolved in favor of symbols from that package. If no symbol of the chosen package is in conflict set, I'll end up in the debugger again.
I found this behavior quite pleasant to work with in everyday situations.
* this is currently realized as a contrib, however, some hooks are needed. I think they are reasonable overall. I provided them as separate patch (0001).
* eval-in-emacs is used to trigger the UI (minibuffer & history list--- works for me), which might not be ideal.
Cheers, Michael
* Michael Weber [2008-08-05 23:47+0200] writes:
Hi,
attached is a patch for name conflict resolution within SLIME (Zach Beane wrote about the issue quite some time ago: <http://xach.livejournal.com/96625.html ). The patch is not meant for immediate inclusion into SLIME, more as a request for feedback.
I haven't tried the patch because my SBCL is probably to old.
There are some rough edges in there:
- works only with SBCL at the moment. In case of a name conflict,
SBCL signals a condition which gives access to the set of conflicting symbols, and also provides a RESOLVE-CONFLICT restart which lets me choose programmatically which symbol to favor out of the conflicting ones. Other Lisps provide different restarts to resolve conflicts, and after superficial looks they appear to be less amenable to programmatic use.
I guess, there is a certain danger that the functionality of the new restarts overlaps with the built-in restarts. That could be confusing.
- In case of many conflicts (e.g., due to USEing a package), on top of
the RESOLVE-CONFLICT restart one can build some automation: instead of ending up a zillion times in the debugger, I can choose to favor a package, and for the current request conflicts are resolved in favor of symbols from that package. If no symbol of the chosen package is in conflict set, I'll end up in the debugger again.
I found this behavior quite pleasant to work with in everyday situations.
Yes, that sounds useful. A command, which asks for two package names, and does the same resolution, is probably also feasible. That would be useful for Lisp which don't have a specific condition.
- this is currently realized as a contrib, however, some hooks are
needed. I think they are reasonable overall. I provided them as separate patch (0001).
The only problem with call-with-foo style hooks, is the clutter in the backtrace.
- eval-in-emacs is used to trigger the UI (minibuffer & history
list--- works for me), which might not be ideal.
Well, eval-in-emacs is now less broken than it used to be.
Helmut.
-
Helmut Eller -
Michael Weber