Transformers and effect libraries

[drlkf]

I'm having trouble integrating my existing code to be invoked within brick's EventM monad, notably while trying to use polysemy's Final IO and Final m given MonadIO m and/or MonadBaseControl IO m. Would it be possible to implement MonadBaseControl IO (EventM n s), or expose the EventM constructor so I could provide my own orphan instance?

[jtdaugherty]

Before I can entertain the possibility of providing such an instance, I'd need to know what are you trying to accomplish and why you want EventM to be the base monad for what you're trying to do.

[drlkf]

As I said I have handlers for a CLI tool I've made, that I've implemented as Final IO for things such as network requests, external commands, file operations and the likes; now I want to use them in the TUI program I'm making. Since I definitely need the final effect to be IO or MonadIO, and I can't have Embed (EventM n s) because I would then be stuck with two terminating effects since I have no natural transformation from EventM to IO (that would semantically be strange anyway). I also am stuck with Final IO and not Embed IO because of this compatibility issue between polysemy and lifted-async, so no runEmbedded with Members '[Embed IO, Embed (EventM n s)]. My only recourse is a MonadBaseControl IO m constraint with Final m as a replacement for Final IO, and unfortunately I have no way of making my own orphan instance of EventM with the current Brick.Types export.

Sorry if it's a bit hairy, let me know if you need a code example

[jtdaugherty]

As I said I have handlers for a CLI tool I've made

Perhaps I missed something, but I don't see where you mentioned this.

now I want to use them in the TUI program I'm making

Does this mean that you are hoping to run external commands and do network I/O from within your Brick event handlers?

Sorry if it's a bit hairy, let me know if you need a code example

A code example would not help me since I am more concerned with understanding your design objective.

[drlkf]

Does this mean that you are hoping to run external commands and do network I/O from within your Brick event handlers?

Yes that's what I intend to do. I was hoping to be able to use suspendAndResume and liftIO but unfortunately altering effects once the effect stack is already built is much harder than I expected, if not impossible in some cases.

[jtdaugherty]

Yes that's what I intend to do.

Okay, thanks, this is very helpful to know! The reason I wanted to understand your intentions better is because doing I/O of this sort in the event handler itself is going to cause rendering latency or flat-out application unresponsiveness. Instead of doing I/O in the event handler -- particularly blocking I/O -- I recommend doing it in another thread. There are lots of ways one could do that, but I often take an approach that I described in this thread.

Since equipping EventM to better support I/O is in some ways a miscommunication of how Brick applications should be designed, I am not currently open to adding more support to EventM along the lines that you originally requested. (Doing so sends the message that EventM is the proper place for richer I/O work, and that is definitely not advisable so I don't want to give that impression.) EventM should be treated like an interrupt handler since, after all, that's essentially what it is; and, like an interrupt handler, it should do as little as possible and finish as quickly as possible to get back to the rendering and event-handling of the application so as to avoid blocking and causing UI latency. If an application needs to do blocking I/O work, it's best if that work is handled in other threads with communication between those threads and the main event loop (essentially what I outlined in the approach that I linked to above).

[drlkf]

I see. So making another thread that would receive events and perform the requested IO would be the proper way to go then ?

Also regarding blocking IO, I've actually had this problem a few years ago when I made another TUI with brick (the API and documentation has improved a lot since then btw, great job), and I actually had to implement my own lock state since there was no suspendAndResume back then, and sometimes it just made sense to freeze everything until some data has been received e.g. in my case I was browsing pull requests from GitHub, and once I pressed Enter to enter the first view, it didn't really make sense to accept any input until the network request had actually returned something. Maybe you have some insight on this, since you seem to have made much larger apps than I did ?

[jtdaugherty]

I see. So making another thread that would receive events and perform the requested IO would be the proper way to go then ?

Yes, exactly - you can see a sketch of such a thing in the thread I linked. I'm happy to discuss it more if that would be helpful!

sometimes it just made sense to freeze everything until some data has been received e.g. in my case I was browsing pull requests from GitHub, and once I pressed Enter to enter the first view, it didn't really make sense to accept any input until the network request had actually returned something

Yeah, I could see this approach being practical, perhaps just when the application first starts up. Matterhorn (a chat client I work on) does this in its own way, where the main UI is not even shown until the initial HTTP fetches of application data have completed. But that's the only time that sort of thing happens, and after that, the main UI is always shown and all I/O is asynchronous.

[jtdaugherty]

Yes, exactly - you can see a sketch of such a thing in the thread I linked.

Another thing I don't think is clear from the thread I linked is that the event handler would send messages to the I/O thread, and then when the I/O thread had results ready or whatever, it would send messages back to the Brick event loop where they'd be received and used to update the Brick application state.

[jtdaugherty]

(This is why customMain must be used, and why the BChan that you create must be given to your I/O thread so it can use that to send "responses" to your main event loop.)

[jtdaugherty]

But also check out the CustomEventDemo program in the repo for an example of those bits.