[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