I'd like to add haskell scripting (ghc) support to vim. Passing the cmd to a .hsc module already works fine. But I can't imagine yet how to expose vim functions to the session started with newSession from the GHC API.

Of course one way to go is interprocess communication (opening kind of pipe sending events/ commands replies..) But maybe you can think of someting easier ?

as an otherwise happy vim user, about the only gripe i have with vim are the consequences of its answer to ':help design-not': VIM IS... NOT *design-not* - Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger. This should work the other way around: Use Vim as a component from a shell or in an IDE. A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)" while there was a point in having a simpler editor by focussing on editing, this particular phrasing ignores completely that having a single standard portable way of running and controlling asynchronous subprocesses is a simple but powerful enabler, not a source of complexity itself. the sad consequence is that vim has dozens of workarounds for getting similar effects in different contexts, but no supported standard. to get something portable, your best bet (and with no good odds) would be to establish ghc at the same level as the other supported vim scripting interfaces: perl, tcl, python, etc. but that would mean a change to vim sources, and would need to be distributed with standard vim distributions to be useful (some debugger interfaces rely on patched vims, but who wants to install non-standard vims to support your scripts?). there are of course various ways to cheat around this limitation, but none are satisfactory, imho. some examples: - interprocess communication: hard to get supported in a portable fashion (think windows users..), especially if you only rely on the standard vim-distributions. it was the route we chose for HaRe some years ago, to enable a vim session to call a running refactorer process, but i never liked using sockets for this (perhaps there's an easier way now that you don't have to worry about win98 anymore?) - vim's client/server feature: the main escape route, but gets fragile if you need to escape command strings; HaRe used this for the refactorer to call back into the Vim session, which seems to be your question? - dynamic loading support: a bit rudimentary last time i looked, but possibly workable - but if your script crashes, vim will, too, and you still need to be able to call back to vim - you might also be able to re-purpose one of the several tool-specific vim interfaces - or you can move beyond standard distributions and require perl or python support compiled in, then use their interprocess communication support. but then you require your users to install perl or python, which will be loaded dynamically into the vim session just to run a 20-line script for calling the ghc session:-( because of its many useful applications, the topic comes up again and again on the vim lists, so perhaps Bram will give in at some point.. claus ps: if you don't need much session state (and why would you with haskell?), you could simply start a new ghc session for each haskell script. such synchronous subprocesses are easy in vim and todays machines are fast, especially if the scripts are non-trivial.