I think introducing a clean, simple interface for hooks for the user, and hiding the details in the type system means that just that: you can freely experiment (adding new hooks, changing the way hooks are implemented) without having the user adjust his configuration file. I don't see how that complicates the core.
If you're right, then people will use your system, when you introduce it to contrib. If one line of code added to their Config.hs is too much to make it worthwhile, I doubt it's going to proliferate anyhow.
Also note that there is a proliferation of hooks. At first, it was only the definition of key commands. Then came manageHooks. Later logHooks appeared. I'd almost bet that someone will want a initHook that runs once at start up. For propoer gap-STRUT-handling, an unmanageHook would be needed as well. I'd like to be able to add these hooks without breaking existing hooks and extensions, but also without having the user to figure out manually what extensions expose functions for what hooks and how to combine hooks from different extensions.
Yes, there are a number of different hook functions defined, but they don't require combinators to be useful. You're proposing an infrastructure for which it's not clear there's a need. You're proposing an API without a use (yet).
I think there is quite some use for it: Currently eight modules in Contrib seem to use hooks. And I know at least three possible hooks that should probably be added to allow more features to implemented in contrib modules (initHook, unmanageHook, clientMessageHook[1]). It does not feel right to have not a clear interface for adding new hooks, which is what stopped me from implementing features needing these hooks. So I think there is a need for an API.
I'd also like to stress that I'm proposing an interface for the Configuration and a possible implementation -- if someone comes up with a more suitable implementation, even better!
And what I'm saying is that the best way to propose an interface is with actual code for said interface, and the best way to do this is in contrib. If it's worthwhile, it'll stick around, and if it's small and elegant, it'll be moved to main.
I can understand that you want these things tested in contrib first, and I think I’ll create something for conrib once 0.4 is out. But then the users have to manually plug each existing hook (currently manageHook and logHook) into the new system manually, and the hook internals would not be hidden from the user, so two goals of my proposal can’t be really fulfilled without any changes to the core. But maybe this discussion should be postboned till after 0.4, when we will have code to talk about. Thanks, Joachim [1] Refering to the XEvent ClientMessage, needed for Ewmh compatibility. -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: joachimbreitner@amessage.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org