AgentM

I spent a few hours trying to track this down. It's definitely related to forkIO because neither the websocket server nor the distributed-process server individually is swallowing the asynchronous UserInterrupt...

I suspect forkIO is somehow related, but I switched to forkIOWithUnmask with no change in behavior. I tried some simplified test cases with forkIO (threadDelay ...) which I was able...

Based on some conversations in the websockets issue, I believe what is happening here is that the main thread receives the UserInterrupt, but we don't kill off the secondary thread...

Yes, I wasn't able to make progress on this issue.

I should move this issue up in priority.

Yes, you can see more discussion about this in #42. I certainly understand your hesitation coming from a statically-typed interface and we are examining the options to have our own...

I am thinking tentatively that there should be indeed two classes: `Tupleable` and something else for the relvar name. The reason is that, if `Tupleable` has a single hard-coded relvar...

A shortcut here could be to wrap the specific list item with `newtype` and add an `Atomable` instance for it that does what you want. In general, `Tupleable` and `Atomable`...

@Valdsonjr , were you able to resolve this issue?

That code is pretty straightforward- I'll wrap it into Project:M36, if you don't mind. What bothers you about the constraints?