I noticed yesterday in my config, 'import qualified XMonad.StackSet as W', and I wondered - why do we do that? Is there some rationale behind it or is it just tradition? I ask because if the former, then there are quite a few modules in XMC which don't import it as W, or as anything at all; a quick grep: Actions/DwmPromote.hs:import XMonad.StackSet Actions/OnScreen.hs:import XMonad.StackSet hiding (new) Actions/Plane.hs:import XMonad.StackSet hiding (workspaces) Actions/CycleSelectedLayouts.hs:import qualified XMonad.StackSet as S Actions/UpdatePointer.hs:import XMonad.StackSet (member, peek, screenDetail, current) Actions/RotSlaves.hs:import XMonad.StackSet Actions/MessageFeedback.hs:import XMonad.StackSet ( current, workspace, layout, tag ) Actions/Commands.hs:import XMonad.StackSet hiding (workspaces) Actions/Promote.hs:import XMonad.StackSet Actions/FocusNth.hs:import XMonad.StackSet Doc/Extending.hs:Remember to import the module that defines the 'XMonad.StackSet.shift' Hooks/Place.hs:import qualified XMonad.StackSet as S Hooks/DynamicLog.hs:import qualified XMonad.StackSet as S Layout/Cross.hs:import XMonad.StackSet( focus, up, down ) Layout/Spiral.hs:import XMonad.StackSet ( integrate ) Layout/Grid.hs:import XMonad.StackSet Layout/Dishes.hs:import XMonad.StackSet (integrate) Layout/SimplestFloat.hs:import qualified XMonad.StackSet as S Layout/Maximize.hs:import qualified XMonad.StackSet as S Layout/Magnifier.hs:import XMonad.StackSet Layout/IndependentScreens.hs:import XMonad.StackSet hiding (filter, workspaces) Layout/Simplest.hs:import qualified XMonad.StackSet as S Layout/Circle.hs:import XMonad.StackSet (integrate, peek) Layout/PositionStoreFloat.hs:import qualified XMonad.StackSet as S Layout/HintedGrid.hs:import XMonad.StackSet Layout/Master.hs:import qualified XMonad.StackSet as S Layout/TwoPane.hs:import XMonad.StackSet ( focus, up, down) Layout/Square.hs:import XMonad.StackSet ( integrate ) Layout/TabBarDecoration.hs:import qualified XMonad.StackSet as S Layout/IM.hs:import qualified XMonad.StackSet as S Layout/SimpleFloat.hs:import qualified XMonad.StackSet as S Layout/DwmStyle.hs:import XMonad.StackSet ( Stack (..) ) Layout/Tabbed.hs:import qualified XMonad.StackSet as S Layout/Drawer.hs:import XMonad.StackSet as S Prompt/Layout.hs:import XMonad.StackSet ( workspaces, layout ) Util/Dzen.hs:import XMonad.StackSet If the former, then several of these need to be fixed or changed, I think. -- gwern
Gwern Branwen
I noticed yesterday in my config, 'import qualified XMonad.StackSet as W', and I wondered - why do we do that? Is there some rationale behind it or is it just tradition?
Because it clashes with some Data.List functions, such as index, delete, etc.; as some users may use parts of Data.List for various things, this is a kind of preventative measure.
I ask because if the former, then there are quite a few modules in XMC which don't import it as W, or as anything at all; a quick grep:
[snip]
If the former, then several of these need to be fixed or changed, I think.
They probably don't import Data.List. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
* On Monday, May 17 2010, Gwern Branwen wrote:
I noticed yesterday in my config, 'import qualified XMonad.StackSet as W', and I wondered - why do we do that? Is there some rationale behind it or is it just tradition?
I ask because if the former, then there are quite a few modules in XMC which don't import it as W, or as anything at all; a quick grep:
...
If the former, then several of these need to be fixed or changed, I think.
-- gwern
It's qualified because some names are reused: XMonad.StackSet.focus, XMonad.Operations.focus Consistent qualifications make it a bit easier to understand code, but you can usually tell between those: if you imported both modules as different random names, the types are sufficiently different that you can guess which is which (Window -> X ()) is used quite differently than (Stack a -> a). I'm not against widespread changes to import style in the name of consistency, but do take care to address unapplied patches beforehand, to avoid having to resolve conflicts. -- Adam
On Mon, May 17, 2010 at 5:49 PM, Adam Vogt
* On Monday, May 17 2010, Gwern Branwen wrote:
I noticed yesterday in my config, 'import qualified XMonad.StackSet as W', and I wondered - why do we do that? Is there some rationale behind it or is it just tradition?
I ask because if the former, then there are quite a few modules in XMC which don't import it as W, or as anything at all; a quick grep:
...
If the former, then several of these need to be fixed or changed, I think.
-- gwern
It's qualified because some names are reused: XMonad.StackSet.focus, XMonad.Operations.focus
Consistent qualifications make it a bit easier to understand code, but you can usually tell between those: if you imported both modules as different random names, the types are sufficiently different that you can guess which is which (Window -> X ()) is used quite differently than (Stack a -> a).
I'm not against widespread changes to import style in the name of consistency, but do take care to address unapplied patches beforehand, to avoid having to resolve conflicts.
XMonad.Operations is very rarely imported, it seems: [04:32 PM] 0Mb$ gr XMonad.Operations|g import Actions/MessageFeedback.hs:import XMonad.Operations ( updateLayout ) Actions/GroupNavigation.hs:import XMonad.Operations Actions/WindowGo.hs:import XMonad.Operations (windows) Util/Paste.hs:import XMonad.Operations (withFocused) Now, specifying the used operations seems to be safe, so I made the following changes to the module which doesn't enumerate its imports. hunk ./XMonad/Actions/GroupNavigation.hs 32 -import Control.Monad hunk ./XMonad/Actions/GroupNavigation.hs 35 -import Data.Maybe hunk ./XMonad/Actions/GroupNavigation.hs 41 -import XMonad.Operations +import XMonad.Operations (windows, withFocused) I don't know how those unnecessary imports got past -Wall, but I'm removing them while I'm at it. Unfortunately Adam, this change would conflict with your 'Use cabal's cpp macros to restore containers-0.2 compatiblity' patch. So perhaps we should move on that patch? (Once Operations imports are dealt with, I can look into fixing up the StackSet imports. I'd like a uniform approach which we could put into the hacking guidelines.) -- gwern
Hello Gwern,
On Tue, Jun 8, 2010 at 4:43 PM, Gwern Branwen
XMonad.Operations is very rarely imported, it seems:
It's re-exported by XMonad, if you check here: http://xmonad.org/xmonad-docs/xmonad/src/XMonad.html So whenever you have an import of XMonad.Operations, you can put an import of XMonad, if you don't mind bringing very many more names into scope.
hunk ./XMonad/Actions/GroupNavigation.hs 32 -import Control.Monad hunk ./XMonad/Actions/GroupNavigation.hs 35 -import Data.Maybe hunk ./XMonad/Actions/GroupNavigation.hs 41 -import XMonad.Operations +import XMonad.Operations (windows, withFocused)
I don't know how those unnecessary imports got past -Wall, but I'm removing them while I'm at it.
Which ghc do you use? Perhaps the imports are redundant, but ghc-6.12.1 here doesn't say so.
Unfortunately Adam, this change would conflict with your 'Use cabal's cpp macros to restore containers-0.2 compatiblity' patch. So perhaps we should move on that patch?
That patch is obsolete: we settled on a different patch that accomplished the same without CPP. I suppose I should have marked it as such on darcswatch.
(Once Operations imports are dealt with, I can look into fixing up the StackSet imports. I'd like a uniform approach which we could put into the hacking guidelines.)
Agreed: I'd like to see things consistent, though it's a rather low priority for me. -- Adam
participants (4)
-
adam vogt -
Adam Vogt
-
Gwern Branwen -
Ivan Lazar Miljenovic