Constrained dynamically extensible layout events: a patch

David, Spencer et al, are there any problems with restricting layoutMsg
arguments to being members of the (open) Message class? I'd (strongly)
prefer this over just Dynamic, since it restores most of the static
checking we'd need.
The only change for something like Mosaic would be to add the mosaic
events to Message, with instance Message MyType, and to switch layoutMsg
to sendMessage (its our 'throw' for dynamically extensible messages, in
fact).
The idea of constrained extensible messages is from SimonM's 06 HW paper
on extensible exceptions.
Comments?
-- Don
New patches:
[Constrain layout messages to be members of a Message class
Don Stewart

dons:
David, Spencer et al, are there any problems with restricting layoutMsg arguments to being members of the (open) Message class? I'd (strongly) prefer this over just Dynamic, since it restores most of the static checking we'd need.
Oh, I forgot an example. This is why Dynamic-only is scary: , ((modMask, xK_h ), layoutMsg "hey Joe!") , ((modMask, xK_l ), layoutMsg Expand) is well typed. Under the new system, it becomes a static error: Config.hs:157:43: No instance for (Message [Char]) arising from use of `sendMessage' at Config.hs:157:43-65 -- Don

dons:
dons:
David, Spencer et al, are there any problems with restricting layoutMsg arguments to being members of the (open) Message class? I'd (strongly) prefer this over just Dynamic, since it restores most of the static checking we'd need.
Oh, I forgot an example. This is why Dynamic-only is scary:
, ((modMask, xK_h ), layoutMsg "hey Joe!") , ((modMask, xK_l ), layoutMsg Expand)
is well typed. Under the new system, it becomes a static error:
Config.hs:157:43: No instance for (Message [Char]) arising from use of `sendMessage' at Config.hs:157:43-65
-- Don
Ah, and a version that actually applies, given Spencer's last changes. -- Don

On Fri, May 04, 2007 at 06:07:52PM +1000, Donald Bruce Stewart wrote:
dons:
David, Spencer et al, are there any problems with restricting layoutMsg arguments to being members of the (open) Message class? I'd (strongly) prefer this over just Dynamic, since it restores most of the static checking we'd need.
Oh, I forgot an example. This is why Dynamic-only is scary:
, ((modMask, xK_h ), layoutMsg "hey Joe!") , ((modMask, xK_l ), layoutMsg Expand)
is well typed. Under the new system, it becomes a static error:
Config.hs:157:43: No instance for (Message [Char]) arising from use of `sendMessage' at Config.hs:157:43-65
I personally like the ability to send unaccepted messages. It can't pose a problem on the receiving end, since every layout has to be able to handle messages it knows nothing about. So the only danger is foolish users who send messages that have no effect, but that really seems harmless to me. I guess getting better error checking is nice, but it seems like you're talking about error checking for something that really isn't likely to be a problem. This is different from the NonEmpty list issue, which still is working on avoiding the dangers of foolish users--who define an empty layout list--but in that case those foolish users could actually crash xmonad, rather than simply defining a key binding that has no effect. -- David Roundy http://www.darcs.net

droundy:
On Fri, May 04, 2007 at 06:07:52PM +1000, Donald Bruce Stewart wrote:
dons:
David, Spencer et al, are there any problems with restricting layoutMsg arguments to being members of the (open) Message class? I'd (strongly) prefer this over just Dynamic, since it restores most of the static checking we'd need.
Oh, I forgot an example. This is why Dynamic-only is scary:
, ((modMask, xK_h ), layoutMsg "hey Joe!") , ((modMask, xK_l ), layoutMsg Expand)
is well typed. Under the new system, it becomes a static error:
Config.hs:157:43: No instance for (Message [Char]) arising from use of `sendMessage' at Config.hs:157:43-65
I personally like the ability to send unaccepted messages. It can't pose a
You can still send unaccepted messages, but you can't accidentally send a non-message type anymore.
problem on the receiving end, since every layout has to be able to handle messages it knows nothing about. So the only danger is foolish users who
Right.
send messages that have no effect, but that really seems harmless to me. I guess getting better error checking is nice, but it seems like you're talking about error checking for something that really isn't likely to be a problem.
Well, its pretty light, and more static checking is always good, in my view. This guides the user a bit more towards valid code. Is there any downside?
This is different from the NonEmpty list issue, which still is working on avoiding the dangers of foolish users--who define an empty layout list--but in that case those foolish users could actually crash xmonad, rather than simply defining a key binding that has no effect.
And that issue is fixed today, too, safeLayouts = case defaultLayouts of [] -> (full, []); (x:xs) -> (x, xs) I think the combination of a Message class, and the non-empty layout handled via another mechanism, covers the holes we opened up. -- Don

On Sat, May 05, 2007 at 12:20:07AM +1000, Donald Bruce Stewart wrote:
Well, its pretty light, and more static checking is always good, in my view. This guides the user a bit more towards valid code. Is there any downside?
It makes the code more complicated without IMO sufficient justification. Stefan
participants (3)
-
David Roundy
-
dons@cse.unsw.edu.au
-
Stefan O'Rear