[slime-devel] Re: Proof-of-concept Name-conflict resolution
Helmut Eller
heller at common-lisp.net
Sat Aug 9 19:30:33 UTC 2008
* 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.
More information about the slime-devel
mailing list