Why does `defcommand' export the command symbol?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Why does `defcommand' export the command symbol?

Diogo F. S. Ramos-2
The `defcommand' macro has a (export ',name) form to export the symbol
`name', which gives the defining command its name.

Why does it do it?

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why does `defcommand' export the command symbol?

David Bjergaard
Hi Diogo,

I think its there because a defcommand exposes commands to the user, and
so it makes sense that their exported from the package.  This is more a
policy than a requirement. (if the user can call the command, then other
parts of StumpWM itself should be able to call the command too.)

I'm pretty sure the name is actually stored in the *command-hash* and
the call to make-command.  Maybe someone with more knowledge can
comment.

Notice that the deprecated `DEFINE-STUMPWM-COMMAND' doesn't export
anything. It just defun's the name and stores the name (with metadata)
in the *command-hash*.

    Dave

"Diogo F. S. Ramos" <[hidden email]> writes:

> The `defcommand' macro has a (export ',name) form to export the symbol
> `name', which gives the defining command its name.
>
> Why does it do it?
>
> _______________________________________________
> Stumpwm-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why does `defcommand' export the command symbol?

Diogo F. S. Ramos-2
> I think its there because a defcommand exposes commands to the user, and
> so it makes sense that their exported from the package.  This is more a
> policy than a requirement. (if the user can call the command, then other
> parts of StumpWM itself should be able to call the command too.)
>
> I'm pretty sure the name is actually stored in the *command-hash* and
> the call to make-command.  Maybe someone with more knowledge can
> comment.
>
> Notice that the deprecated `DEFINE-STUMPWM-COMMAND' doesn't export
> anything. It just defun's the name and stores the name (with metadata)
> in the *command-hash*.

I see.

I am asking because such policy cause me a problem.

By using `defcommand' in a module (separate package), I couldn't
redefine the package because the symbols defining the commands were
exported but they were not listed in my new package redefinition.

Even if StumpWM should be able to call commands like the user, it won't
happen as things are, because exported symbols need to be prefixed by
the package exporting it.

I wonder if we are better of by not exporting `defcommand' symbols.

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why does `defcommand' export the command symbol?

David Bjergaard
"Diogo F. S. Ramos" <[hidden email]> writes:

>> I think its there because a defcommand exposes commands to the user, and
>> so it makes sense that their exported from the package.  This is more a
>> policy than a requirement. (if the user can call the command, then other
>> parts of StumpWM itself should be able to call the command too.)
>>
>> I'm pretty sure the name is actually stored in the *command-hash* and
>> the call to make-command.  Maybe someone with more knowledge can
>> comment.
>>
>> Notice that the deprecated `DEFINE-STUMPWM-COMMAND' doesn't export
>> anything. It just defun's the name and stores the name (with metadata)
>> in the *command-hash*.
>
> I see.
>
> I am asking because such policy cause me a problem.
>
> By using `defcommand' in a module (separate package), I couldn't
> redefine the package because the symbols defining the commands were
> exported but they were not listed in my new package redefinition.
>
> Even if StumpWM should be able to call commands like the user, it won't
> happen as things are, because exported symbols need to be prefixed by
> the package exporting it.
>
> I wonder if we are better of by not exporting `defcommand' symbols.
Hmm,

This is a good point. If you were willing to do some archaeology, you
could see when the `export` was added.  To make sure I understand your
issue:

If you call (stumpwm:defcommand foo ...) from an external package, you
export foo from your package (ie module:foo), but you never defined
module:foo for your package, so your encountering an error?  

I have some vague memory of this being added in a pull request shortly
after I started maintaining stump...

Cheers,

    Dave

PS. Sorry for top posting

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why does `defcommand' export the command symbol?

Diogo F. S. Ramos-2
>> By using `defcommand' in a module (separate package), I couldn't
>> redefine the package because the symbols defining the commands were
>> exported but they were not listed in my new package redefinition.
>
> If you call (stumpwm:defcommand foo ...) from an external package, you
> export foo from your package (ie module:foo), but you never defined
> module:foo for your package, so your encountering an error?  

The error occurs when I try to redefine a package using `defpackage'.
It is not something one has to do, but it can happen during interactive
development.

Suppose I have a module like:

(defpackage #:my-module
  (:use #:cl))

(in-package #:my-module)

(stumpwm:defcommand my-command () ()
  "This is my command."
  (values))

Now I change my mind about the `defpackage' form and I want to compile a
new one to import the symbol `defcommand' from the package `stumpwm'.

(defpackage #:my-module
  (:use #:cl)
  (:import-from #:stumpwm #:defcommand))

SBCL won't let me because `defcommand' exported the symbol `my-command'
and my redefinition does not list it as an exported symbol.

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why does `defcommand' export the command symbol?

Diogo F. S. Ramos-2
In reply to this post by David Bjergaard
> I have some vague memory of this being added in a pull request shortly
> after I started maintaining stump...

The commit might be 0df1e87.

The commit message reads:

  Defcommand exports the command to the UI. Obviously it should export
  the command t the API.

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why does `defcommand' export the command symbol?

Michael Raskin-3
>> I have some vague memory of this being added in a pull request shortly
>> after I started maintaining stump...
>
>The commit might be 0df1e87.
>
>The commit message reads:
>
>  Defcommand exports the command to the UI. Obviously it should export
>  the command t the API.

And the reason for that was that without that most of the modules break
because they use otherwise-unexported commands from StumpWM UI.

Also, I think I have the same situation that you describe with SBCL and
SBCL gives a continuable warning for this (i.e. I do asdf:load-system
and see the warning and then the load succeeds).




_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why does `defcommand' export the command symbol?

Diogo F. S. Ramos-2
>>> I have some vague memory of this being added in a pull request shortly
>>> after I started maintaining stump...
>>
>>The commit might be 0df1e87.
>>
>>The commit message reads:
>>
>>  Defcommand exports the command to the UI. Obviously it should export
>>  the command t the API.
>
> And the reason for that was that without that most of the modules break
> because they use otherwise-unexported commands from StumpWM UI.

StumpWM has an inconsistency set of exported symbols.  In my module, I
use exported and internal ones.  So it is possible, and sometimes
necessary, to use internal StumpWM symbols within modules.  So it is not
strictly necessary for `defcommand' to export symbols defining new
commands.

There is also no consistence on how modules are written.  Some use
(in-package :stumpwm), so they access all StumpWM symbols and define new
symbols for the StumpWM packages.  Others define separate packages and
hence are affected by symbol visibility, but like I said in the first
paragraph, they might need to access internal symbols anyway.

I am talking from the point of view of a module writer.  Defining new
commands doesn't mean I want to export symbols.  And exporting symbols
inside the macro was surprising and caused a little problem.

Maybe StumpWM should have two `defcommands'?  One for internal use of
StumpWM, which exports symbols, and one for modules, which doesn't?

I am not so sure myself tho.  That is why I asked for the reason for the
exporting in the first place.

> Also, I think I have the same situation that you describe with SBCL and
> SBCL gives a continuable warning for this (i.e. I do asdf:load-system
> and see the warning and then the load succeeds).

Your warning might be related to this, but like I said in a previous
message, my error is triggered when I try to compile a new definition of
`defpackage' after defining some commands in the package.

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why does `defcommand' export the command symbol?

David Bjergaard
Hi,

Responses inline:
"Diogo F. S. Ramos" <[hidden email]> writes:

>>>> I have some vague memory of this being added in a pull request shortly
>>>> after I started maintaining stump...
>>>
>>>The commit might be 0df1e87.
>>>
>>>The commit message reads:
>>>
>>>  Defcommand exports the command to the UI. Obviously it should export
>>>  the command t the API.
>>
>> And the reason for that was that without that most of the modules break
>> because they use otherwise-unexported commands from StumpWM UI.
>
> StumpWM has an inconsistency set of exported symbols.  In my module, I
> use exported and internal ones.  So it is possible, and sometimes
> necessary, to use internal StumpWM symbols within modules.  So it is not
> strictly necessary for `defcommand' to export symbols defining new
> commands.
This is understood, which is why the official policy is to open an issue
requesting which symbol you need exported and why (ie you need to use it
in your module).

>
> There is also no consistence on how modules are written.  Some use
> (in-package :stumpwm), so they access all StumpWM symbols and define new
> symbols for the StumpWM packages.  Others define separate packages and
> hence are affected by symbol visibility, but like I said in the first
> paragraph, they might need to access internal symbols anyway.
Unfortunately, the modules are not good examples of how to write
modules. I can point out some that follow policy, but by and large they
are extremely inconsistent and were just wrapped enough to be loadable
by ASDF, before then they were simply (load)ed based on the contrib-dir
and the filename.

>
> I am talking from the point of view of a module writer.  Defining new
> commands doesn't mean I want to export symbols.  And exporting symbols
> inside the macro was surprising and caused a little problem.
I agree, this was the path of least resistance when handling the nasty
inconsistencies in how modules were written. While it seemed sound at
the time, I can see now that different developers have different
expectations when you use `defcommand'.

>
> Maybe StumpWM should have two `defcommands'?  One for internal use of
> StumpWM, which exports symbols, and one for modules, which doesn't?
No, this is not something I support.  If we're going to all agree that
defcommand shouldn't export commands, then we need to go back through
the sources and make sure that each defcommand'ed function is listed in
the export declaration.  

Two paths forward:
1. Keep the export command in and make module writers deal with this
   edge case.  Diogo, how many times on average would you run into this
   behavior? This only happens when you redefine the package right? I'm
   not trying to be dismissive, I really don't know how many times you
   would have to deal with this.  (My understanding is that you would
   have to completely reload your StumpWM instance to fix this)
2. Remove the export and manually move the defcommands into the export
   lines of the packages.  This involves a lot of tedious code changes,
   (not that I'm opposed). It also puts the responsibility on the person
   who defcommands to decide whether it should be exported.
   
Cheers,

    Dave

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why does `defcommand' export the command symbol?

Michael Raskin-3
In reply to this post by Diogo F. S. Ramos-2
>>>> I have some vague memory of this being added in a pull request shortly
>>>> after I started maintaining stump...
>>>
>>>The commit might be 0df1e87.
>>>
>>>The commit message reads:
>>>
>>>  Defcommand exports the command to the UI. Obviously it should export
>>>  the command t the API.
>>
>> And the reason for that was that without that most of the modules break
>> because they use otherwise-unexported commands from StumpWM UI.
>
>StumpWM has an inconsistency set of exported symbols.  In my module, I
>use exported and internal ones.  So it is possible, and sometimes
>necessary, to use internal StumpWM symbols within modules.  So it is not
>strictly necessary for `defcommand' to export symbols defining new
>commands.
>
>There is also no consistence on how modules are written.  Some use
>(in-package :stumpwm), so they access all StumpWM symbols and define new
>symbols for the StumpWM packages.  Others define separate packages and
>hence are affected by symbol visibility, but like I said in the first
>paragraph, they might need to access internal symbols anyway.

All the modules from contrib were moved into separate packages at once,
so I guess the current policy decision is to make this actually work…

As for StumpWM not exporting something needed by modules — this is a bug
to fix.

>I am talking from the point of view of a module writer.  Defining new
>commands doesn't mean I want to export symbols.  And exporting symbols
>inside the macro was surprising and caused a little problem.

Clean use of your module by downstream modules would probably require
the symbol to be exported.

>Maybe StumpWM should have two `defcommands'?  One for internal use of
>StumpWM, which exports symbols, and one for modules, which doesn't?
>
>I am not so sure myself tho.  That is why I asked for the reason for the
>exporting in the first place.

Maybe we want to make defcommand import the symbol into StumpWM and then
export from there? From UI vs. API point of view this would be quite
natural.

>> Also, I think I have the same situation that you describe with SBCL and
>> SBCL gives a continuable warning for this (i.e. I do asdf:load-system
>> and see the warning and then the load succeeds).
>
>Your warning might be related to this, but like I said in a previous
>message, my error is triggered when I try to compile a new definition of
>`defpackage' after defining some commands in the package.

My warning in my completely unrelated SBCL-using project are also when
I reload defpackage with a smaller set of exports.




_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why does `defcommand' export the command symbol?

Diogo F. S. Ramos-2
In reply to this post by David Bjergaard
>> Maybe StumpWM should have two `defcommands'?  One for internal use of
>> StumpWM, which exports symbols, and one for modules, which doesn't?
> No, this is not something I support.  If we're going to all agree that
> defcommand shouldn't export commands, then we need to go back through
> the sources and make sure that each defcommand'ed function is listed in
> the export declaration.  
>
> Two paths forward:
> 1. Keep the export command in and make module writers deal with this
>    edge case.  Diogo, how many times on average would you run into this
>    behavior? This only happens when you redefine the package right? I'm
>    not trying to be dismissive, I really don't know how many times you
>    would have to deal with this.  (My understanding is that you would
>    have to completely reload your StumpWM instance to fix this)

I just noticed it now, when redefining the package.

> 2. Remove the export and manually move the defcommands into the export
>    lines of the packages.  This involves a lot of tedious code changes,
>    (not that I'm opposed). It also puts the responsibility on the person
>    who defcommands to decide whether it should be exported.

Although it makes it a little inconvenient to do certain things, maybe
it makes sense for `defcommand' to export symbols.

I thought of commands like an UI thing, but this is not the only
interpretation.

I say we keep things like they are for now.

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel