Re: Coping with a name conflict

Oh. Ouch. Oof. Defining ANY sort of custom code in an implementation 
package, such as CCL, is not a good idea unless you know what and why 
you are doing. My solution stands, but for even stronger reasons now.

On 21.03.2022 22:24, Tim Bradshaw wrote:
> No, he's not: he's in CC (look at the value of *package*), in which 
> DBG is defined but not exported.  So you're right, but it's worse...
>
> --tim
>
>> On 21 Mar 2022, at 21:10, Michał phoe Herda <[email protected]> wrote:
>>
>> 
>>
>> You're coding in package CL-USER which is allowed to contain imports 
>> from other packages, different across implementations; defining lots 
>> of code in CL-USER is generally a bad idea because of this.
>>
>> The solution is to fix up your modularity and create your own package 
>> that uses e.g. only CL. No naming conflicts this way.
>>
>> On 21.03.2022 22:00, Denis Lorrain wrote:
>>> Hello all,
>>>
>>> - Having updated from macOS 11.6.3 to 12.3, I had to change from the 
>>> old AppStore CCL 1.11.7 to CCL 1.12.1.
>>> - R. Matthew Emerson kindly gave me this last build:
>>> http://setf.clozure.com/~rme/ccl-1.12.1-ide-big-sur.zip
>>> - Happily, CCL 1.12.1 runs seemingly very well with macOS 12.3, 
>>> whereas CCL 1.11.7 was very problematic with macOS 11.6.3. So I'm 
>>> globally very satisfied with both changes.
>>>
>>> - Unfortunately CCL 1.12.1 now introduces a name conflict with my 
>>> own code, which did not occur before. Briefly summarized:
>>>
>>> ===========================================================
>>> Clozure Common Lisp Version 1.12.1 (v1.12.1-3-g2ae800e1) DarwinX8664
>>> For more information about CCL, please see http://ccl.clozure.com.
>>> CCL is free software.  It is distributed under the terms of the Apache
>>> Licence, Version 2.0.
>>> ? (function DBG)
>>> #<Compiled-function DBG #x30000015DD1F>
>>> ? *package*
>>> #<Package "CCL">
>>> ? (find-symbol "DBG")
>>> DBG
>>> :INTERNAL
>>> ? (defmacro dbg (forme &optional fonction)
>>>     (if fonction
>>>         `(format *standard-output* "~4Tdbg-> ~S : ~S = ~S~%"
>>>                (quote ,fonction) (quote ,forme) ,forme)
>>>       `(format *standard-output* "~4Tdbg-> ~S = ~S~%" (quote ,forme) 
>>> ,forme)))
>>> ; Warning: The function DBG is being redefined as a macro.
>>> ; While executing: (SETF MACRO-FUNCTION), in process Listener(4).
>>> DBG
>>> ? (dbg a) => crash: AltConsole
>>>                     Lisp Breakpoint
>>>                     ? for help
>>> [nnnn] Clozure CL kernel debugger:
>>> ===========================================================
>>>
>>> - The conflict is created by my definition of dbg as a 
>>> macro-function. You understand it's a simple developing help, 
>>> inserted for debugging, checking things on the fly, printing 
>>> internal values, etc.
>>>
>>> - The annoying point is that my dbg macro-function is everywhere in 
>>> my code, sometimes commented out, but often not. I could change its 
>>> name, but it would be quite tedious to edit all my source files, 
>>> written over the last 15 or 20 years...
>>>
>>> => Is there some package trick which could solve this name conflict? 
>>> So called shadowing? Unfortunately, my knowledge about packages 
>>> doesn't extend further than the clumsy demo above.
>>> => Could anyone suggest a hopefully simple solution?
>>>
>>> Sorry for this long message. Many thanks in advance,
>>>
>>>    DLO
>>> --
>>> Denis Lorrain
>>> http://www.denislorrain.org <http://denislorrain.org>
>>> Recordings of selected piano works:
>>> http://w <https://soundcloud.com/user-205054622>orks.denislorrain.org
>>> e-mail: [email protected]
>>> --