Scripting an application in haskell: howto expose application api ?

[Claus Reinke]

> 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.