This week I’m also starting to prepare some slides; in two weeks’ time I will be presenting at PADL 2011 in Texas. That’s a talk that’s on the automated wiring that I’ve covered on the blog before. Once that trip is out of the way, I’m hoping to have a bit more time for Haskell coding again.

Like this:

Related

I’ve read your article yesterday. After sleeping with it’s ideas I have some remarks to express.

First, simple and technical. I see no reason why you require Monad instance for type wrapped into your InterleaveT. You can require Monad or Applicative on per operation basis. Most of functions in interleave package will require Applicative instance. But some, like State transformers, will require Monad instance.

Second. When I thought about your interleave abstraction I was stroked that it is very cool abstraction to program GUI. In console interactive application you have some flow of dialog that can be described by some grammar. You display some data to user and waits for him to enter some response. Response can be one of possible allowed alternatives that determines the rest of dialog. This is just an interpreter (all programs are compilers or interpreters after all) for some simple programming language (not Turing-complete one). And GUI is not so different. Instead of list of statements you have list of events (clicks, keystrokes etc). THE difference is that there are many interleaved dialog flows instead of one. I’ve tried to do some GUI programming in this style. You can see my attempt here: http://asviraspossible.livejournal.com/92551.html. I haven’t managed to implement Alternative instance for my Behavior type, but I believe that it is not so hard. I believe that with an Alternative instance and with your interleave package I can get very concise and correct descriptions of GUI logic. What do you think?