[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.lisp

resolving symbol conflicts when loading a package

Jim Newton

3/30/2016 9:56:00 AM

When I load a CL package (in slime anyway) and symbol
conflicts are encountered, slime/sbcl gives me the following restarts.

I always choose restart=2, which shows me the two symbols and asks me
which one I want. But can someone explain to me what restart=0 and restart=1
do? In the example below, I want to use CLOSER-MOP::DEFGENERIC
rather than DISPATCH::DEFGENERIC. Can I do that by selecting restart=0
or restart=1? If so, couldn't the text of the restart be made to state that explicitly?


USE-PACKAGE #<PACKAGE "CLOSER-MOP"> causes name-conflicts in
#<PACKAGE "DISPATCH"> between the following symbols:
CLOSER-MOP:DEFGENERIC, COMMON-LISP:DEFGENERIC
[Condition of type NAME-CONFLICT]
See also:
Common Lisp Hyperspec, 11.1.1.2.5 [:section]

Restarts:
0: [KEEP-OLD] Keep symbols already accessible DISPATCH (shadowing others).
1: [TAKE-NEW] Make newly exposed symbols accessible in DISPATCH, uninterning old ones.
2: [RESOLVE-CONFLICT] Resolve conflict.
3: [RETRY] Retry compiling #<CL-SOURCE-FILE "dispatch" "src" "dispatch">.
4: [ACCEPT] Continue, treating compiling #<CL-SOURCE-FILE "dispatch" "src" "dispatch"> as having been successful.
5: [RETRY] Retry ASDF operation.
--more--

Backtrace:
0: (NAME-CONFLICT #<PACKAGE "DISPATCH"> USE-PACKAGE #<PACKAGE "CLOSER-MOP"> CLOSER-MOP:DEFGENERIC DEFGENERIC)
1: ((FLET SB-IMPL::THUNK :IN USE-PACKAGE))
3 Answers

William James

3/30/2016 11:09:00 AM

0

Jim Newton wrote:

> When I load a CL package (in slime anyway) and symbol
> conflicts are encountered, slime/sbcl gives me the following restarts.
>
> I always choose restart=2, which shows me the two symbols and asks me
> which one I want. But can someone explain to me what restart=0 and restart=1
> do?

OCaml:

#load "str.cma";;
open Str;;

let list =
"When I load a CL package (in slime anyway) and symbol
conflicts are encountered, slime/sbcl gives me the following restarts.
I always choose restart=2, which shows me the two symbols and asks me
which one I want. But can someone explain to me what restart=0 and
restart=1 do?"
|> global_replace (regexp "ich.*o s\\|mbols") ""
|> split (regexp "1[^?]+\\|[ \n]+") ;;

List.map (List.nth list) [33;34;35;24;1;21;22;4;7;42]
|> String.concat " "
|> replace_first (regexp " \\(\\?\\)") "\\1"
|> String.capitalize ;;

===>
"Can someone explain why I always choose CL slime?"

--
The report card by the American Society of Civil Engineers showed the national
infrastructure a single grade above failure, a step from declining to the point
where everyday things simply stop working the way people expect them to. ---
washingtonpost.com/local/trafficandcommuting/us-infrastructure-gets-d-in-annual-report/2013/03/19/c48cb010-900b-11e2-9cfd-36d6c9b5d7ad_story.html

Antsan

3/30/2016 4:53:00 PM

0

Am Mittwoch, 30. März 2016 11:56:12 UTC+2 schrieb Jim Newton:
> When I load a CL package (in slime anyway) and symbol
> conflicts are encountered, slime/sbcl gives me the following restarts.
>
> I always choose restart=2, which shows me the two symbols and asks me
> which one I want. But can someone explain to me what restart=0 and restart=1
> do? In the example below, I want to use CLOSER-MOP::DEFGENERIC
> rather than DISPATCH::DEFGENERIC. Can I do that by selecting restart=0
> or restart=1? If so, couldn't the text of the restart be made to state that explicitly?
>
>
> USE-PACKAGE #<PACKAGE "CLOSER-MOP"> causes name-conflicts in
> #<PACKAGE "DISPATCH"> between the following symbols:
> CLOSER-MOP:DEFGENERIC, COMMON-LISP:DEFGENERIC
> [Condition of type NAME-CONFLICT]
> See also:
> Common Lisp Hyperspec, 11.1.1.2.5 [:section]
>
> Restarts:
> 0: [KEEP-OLD] Keep symbols already accessible DISPATCH (shadowing others).
> 1: [TAKE-NEW] Make newly exposed symbols accessible in DISPATCH, uninterning old ones.
> 2: [RESOLVE-CONFLICT] Resolve conflict.
> 3: [RETRY] Retry compiling #<CL-SOURCE-FILE "dispatch" "src" "dispatch">.
> 4: [ACCEPT] Continue, treating compiling #<CL-SOURCE-FILE "dispatch" "src" "dispatch"> as having been successful.
> 5: [RETRY] Retry ASDF operation.
> --more--
>
> Backtrace:
> 0: (NAME-CONFLICT #<PACKAGE "DISPATCH"> USE-PACKAGE #<PACKAGE "CLOSER-MOP"> CLOSER-MOP:DEFGENERIC DEFGENERIC)
> 1: ((FLET SB-IMPL::THUNK :IN USE-PACKAGE))

I can't really tell which one you'd choose in this situation, but seeing
how you probably didn't load the DISPATCH package, then overwrite some symbols
and then reload the DISPATCH package again, I think you'd have to choose
1: [TAKE-NEW]
here.

Wait a second, that's not DISPATCH::DEFGENERIC but CL::DEFGENERIC!
Still, if you loaded the CL package first (which I assume is what most people
do) you'd take
1: [TAKE-NEW]

taruss

3/30/2016 8:18:00 PM

0

On Wednesday, March 30, 2016 at 2:56:12 AM UTC-7, Jim Newton wrote:
> When I load a CL package (in slime anyway) and symbol
> conflicts are encountered, slime/sbcl gives me the following restarts.
>
> I always choose restart=2, which shows me the two symbols and asks me
> which one I want. But can someone explain to me what restart=0 and restart=1
> do? In the example below, I want to use CLOSER-MOP::DEFGENERIC
> rather than DISPATCH::DEFGENERIC. Can I do that by selecting restart=0
> or restart=1? If so, couldn't the text of the restart be made to state that explicitly?

I would guess that the error text is designed to be more generic (sorry) and
also cover the case where there were multiple symbol names in conflict. In
that case it would offer to let you get all of the existing symbols or get all
of the new symbols.

> USE-PACKAGE #<PACKAGE "CLOSER-MOP"> causes name-conflicts in
> #<PACKAGE "DISPATCH"> between the following symbols:
> CLOSER-MOP:DEFGENERIC, COMMON-LISP:DEFGENERIC
> [Condition of type NAME-CONFLICT]
> See also:
> Common Lisp Hyperspec, 11.1.1.2.5 [:section]
>
> Restarts:
> 0: [KEEP-OLD] Keep symbols already accessible DISPATCH (shadowing others).
> 1: [TAKE-NEW] Make newly exposed symbols accessible in DISPATCH, uninterning old ones.
> 2: [RESOLVE-CONFLICT] Resolve conflict.
[snip]

Now, we don't know exactly what package loading you are doing that is
triggering this, so it is possible that this could be triggered by sequential
processing of some DEFPACKAGE "use" list. Or it could be because you are
explicitly calling (use-package) when in the DISPATCH package.

What you really want to use is
(SHADOWING-IMPORT ...) or the :SHADOWING-IMPORT-FROM keyword to DEFPACKAGE.

Then you will avoid the error message entirely.