not a good week for such questions, as the Simons have gone on holiday, but here are some pointers. True, I forgot that...
- check out the emacs mode for haskell, which does a similar thing http://www.iro.umontreal.ca/~monnier/elisp/#haskell-mode
Thanks for the hint, from what I can tell (without having an Emacs near by), it just searches for "^\\*?[A-Z][\\._a-zA-Z0-9]*\\( \\*?[A-Z][\\._a-zA-Z0-9]*\\)*> " to be a prompt, which is hardly ideal...
- if you are serious about this (more than just a few buttons for the ghci/hugs commands;-), you might want to go for a tighter integration with the interactive Haskell implementations.
Its amazing what difference a few buttons makes, but yes, I am serious about turning this into something quite powerful. However, in order to make it quite powerful I don't think I really do need that much integration - just ":t" and a few others should be enough.
Hugs has (or had?) the Hugs Server API http://cvs.haskell.org/cgi-bin/cvsweb.cgi/hugs98/src/server.c?rev=1.6
Looks nice, but I know Hugs plays with setjmp longjmp internally, and thats one solid reason for wanting to be in a separate process from Hugs.
GHC has the GHC API (which is also used for the Visual Studio plugin)
As far as I was aware, the GHC API is about looking at the code (i.e. compiling and examining) - while the side I'm interested in is the execution. There are some big advantages to just spawning out to existing processes - the level of difference between Hugs/GHCi becomes much smaller, the program can just grab the users existing installation of the interpretter, and I'm not stuck tracking an unstable API. Of course, for higher levels of integration I need something better, but I hope this will suffice for a long time. Thanks Neil