added toMessage and doMessage

[wygulmage]

Description

toMessage wraps an instance of MessageClass in SomeMessage unless it's already SomeMessage; this can be
used in other functions to avoid excessive wrapping and re-wrapping.

doMessage acts as handleMessage but with error "handling" (userCodeDef)
and using toMessage to automatically wrap with SomeMessage when
necessary (see XMonad.Layout for why that's nice.)

I was wondering why XMonad.Operations.sendMessageWithNoRefresh was using catchX while general use of handleMessage could still throw on a poorly defined instance of LayoutClass. This puts the error "handling" (semi-ignoring) in as basic a function as possible and then use that as much as possible, rather than handleMessage.

XMonad.Layout defines an internal function handle to wrap with SomeMessage before calling handleMessage. doMessage as defined here can be used instead.

Possible complications of this include making SomeMessage an instance of Message (technically you could wrap SomeMessage arbitrarily deep if you didn't use toMessage), and the larger API of doMessage and handleMessage with identical signatures and equivalent function.

This would also slightly simplify the code in #291 by moving the error handling out of sendMessageWithNoRefresh.

Checklist

• I've read CONTRIBUTING.md

• I've confirmed these changes don't belong in xmonad-contrib instead

• I tested my changes with xmonad-testing

• I updated the CHANGES.md file

[wygulmage]

With the PatternSynonyms extension, it's possible to do this even more nicely and transparently. Rather than exporting toMessage, you:

• Change SomeMessage (..) to SomeMessage (SomeMessage) in the export list.
• Change data SomeMessage = forall a. Message a => SomeMessage a to data SomeMessage = forall a. Message a => Message a.
• add pattern SomeMessage x <- Message x where SomeMessage x = toMessage x.

Now you use SomeMessage just as before, except now when you do SomeMessage (foo :: SomeMessage), it gives back foo.

[slotThe]

With the PatternSynonyms extension, it's possible to do this even more nicely and transparently. Rather than exporting toMessage

I really like this idea 👍 I think we should go for that

[wygulmage]

Great, I like it better too!

Also, a quick bikeshedding question: Which do you like better: doMessage, passMessage, something else, or remove that from the pull request entirely to focus on the SomeMessage pattern synonym?

[slotThe]

GHC derives Typeable automatically for every type now, so this is probably superfluous

[wygulmage]

That's good news.

...and derive (Typeable) is now gone.

[slotThe]

Also, a quick bikeshedding question: Which do you like better: doMessage, passMessage, something else, or remove that from the pull request entirely to focus on the SomeMessage pattern synonym?

Well I do love me some bikeshedding :) My gut feeling was that doMessage sounds better, because passMessage almost sounds like "pass on the message to something else". But then we are passing the message onto the layout... Ultimately, both are probably fine—names are hard.

[wygulmage]

My gut feeling was that doMessage sounds better, because passMessage almost sounds like "pass on the message to something else". But then we are passing the message onto the layout... Ultimately, both are probably fine—names are hard.

With that in mind, passMessage would have made more sense for a flipped variant. I'll keep it as doMessage.

[slotThe]

LGTM; I'll wait for someone else to look at this before merging, but I've no more complaints myself

[liskin]

I'll be much more comfortable merging this if the newly added function(s) had some actual usage somewhere. That way it's easier to gauge the benefits and possible problems.

Also, I noticed that you fork has a lot of extra commits, some of which get submitted as PRs, sometimes. I wonder if that's just your experiments or if you eventually intend all of that to be upstreamed? Would you perhaps like to join the IRC channel so that we can coordinate efforts?

[wygulmage]

I'll be much more comfortable merging this if the newly added function(s) had some actual usage somewhere. That way it's easier to gauge the benefits and possible problems.

Good point. I didn't want to touch existing code (yet...), but there are a number of places where I think it would be useful, both in xmonad and for folks writing extensions (one less thing to be confused by). For example, it would marginally simplify the message-handling code in XMonad.Operations.

Also, I noticed that you fork has a lot of extra commits, some of which get submitted as PRs, sometimes. I wonder if that's just your experiments or if you eventually intend all of that to be upstreamed? Would you perhaps like to join the IRC channel so that we can coordinate efforts?

It's totally experimental. Occasionally something seems useful, small, and clear enough that I split it out into a PR, but for the most part I'd be terrified of accidentally introducing a bug into the venerable xmonad codebase.

[slotThe]

On Thu, Sep 09 2021 09:08, wygulmage wrote: For example, it would marginally simplify the message-handling code in XMonad.Operations.

Depending on how big of an undertaking this is, I think doing that as a "proof of concept" that this is a good change would be great!

[geekosaur]

Keep in mind that you can submit a PR with that change and mark it as a draft, so it won't be considered as an official PR.