runInTerminal support

[alt-romes]

Fixes #15

[alt-romes]

@dmjio I'm using this change in the debugger successfully. Perhaps you'd like to review?

[dmjio]

Looks good, but wondering if we can reuse send here.

[alt-romes]

@dmjio I've simplified according to your suggestions.

I was also wondering about serviceClient and getRequest. I was trying to extend the communicate higher order function to receive Either ReverseCommand Command, to deal with reverse request responses.

(Currently, the code assumes the server will only ever send requests, but with reverse requests it will also send reverse request responses)

The issue is the request type argument to Adaptor-- why is it needed? request is instanced to Request in functions such as send and in calls such as getArguments. However, I was coming up with a new type for ReverseRequestResponse, which now doesn't fit in the Adaptor.

---

Why have the request type argument? Is it not always Request in practice? I was thinking briefly about a refactor where we could get rid of the request field in the AdaptorLocal reader environment. Instead, the higher order function passed to serviceClient receive a Either ReverseRequestResponse Request instead of Either ReverseCommand Command (where Command is an enum without fields and Request is a struct containing the Command enum plus the arguments which are currently fetched from the reader using getArguments).

Let me try this quickly...

[alt-romes]

Why have the request type argument? Is it not always Request in practice?

Ah, I see the point. We only have a Request in the environment when replying to a request. Notably, we don't have one in registerNewDebugSession but we do have one in communicate.

[alt-romes]

@dmjio I've added a third commit to allow receiving reverse-request-responses. Let me know what you think.

[alt-romes]

@dmjio I've also updated the CHANGELOG and bumped the version hoping we could do another 0.x.0.0 release with the added capability.

[dmjio]

I think ReverseRequestResponse in getRequest is reasonable. This is the first time we're adding support for the reverse flow, so maybe there is a more idiomatic way of doing things, but this seems fine to me.