Comm. with ghci from Haskell / using GHC API

[Jost Berthold]

Hi,

Thanks a lot for your worthwhile clarifications.

Simon, you are perfectly right! IMHO, investigating the GHC API for our 
project is definitely a must. However, we first followed Neil's 
approach, since a first prototype can be achieved much easier with a 
separate OS process and inter-process communication. But we have perhaps 
reached the limits of this approach now.

To clarify the background of the question:
Our starting point for the project has been to build a GUI for ghci, 
ghci with a hugs "look and feel". The current version uses a single 
window where the user can type input at a prompt, and output as well as 
errors are written into the same window, as they would be in a ghci 
console session, or hugs. Implemented by a ":set prompt"-like trick by 
Matthias, but watching both stdout and stderr.
We are currently looking at the /support for interactive programs/, 
where the issues are a bit more complex (put simply: the prompt is 
defined by the program!), and AFAICT not solved either by gui-haskell or 
by the GHC API (pls. correct me otherwise).
Consider the case of a simple "getLine >>= putStrLn" as the evaluated 
expression:
* In gui-haskell, the user types input into a separate text field, and 
it is sent to the running process regardless of its current activity. So 
when the user types "getLine >>= putStrLn" into it, simply the next 
input to the text field will be read by getLine. Since input and output 
are in separate windows, this is not how the program would look like 
when compiled and run.
* Using the GHC API, what happens when evaluating "getLine >>= 
putStrLn"? Most likely (we just started experiments with the GHC API, so 
without having a solid test...), the interpreted program will expect the 
input on a console where the /interpreter/ program has been started, not 
from somewhere inside a haskell GUI. We see no means to send input to an 
evaluation in progress inside the GHC API. OTOH, there must be a way 
ghci handles this case... or does it simply rely on the console where 
ghci is run?

[Following the inter-process approach, our idea and question was whether 
it is possible to trigger a signal every time the ghci process expects 
input.]

Have you got some hints concretely for this problem?
Thank you very much.
Jost Berthold

cvs-ghc-request at haskell.org wrote:
>    2. RE: communication with ghci from haskell (Simon Peyton-Jones)
>    8. Re: communication with ghci from haskell (Neil Mitchell)
> Message: 2
> Date: Fri, 24 Nov 2006 08:44:43 +0000
> From: Simon Peyton-Jones <simonpj at microsoft.com>
> Subject: RE: communication with ghci from haskell
> To: "Hackler at Mathematik.Uni-Marburg.de"
> 	<Hackler at Mathematik.Uni-Marburg.de>,	"cvs-ghc at haskell.org"
> 	<cvs-ghc at haskell.org>
> Message-ID:
> 	<DCA83D5F3861C941808187D4D3878750332AD2FC at EA-EXMSG-C312.europe.corp.microsoft.com>
> 	
> Content-Type: text/plain; charset="us-ascii"
> 
> Is there some reason you need to run GHCi as a separate process?  By doing so, you constrain yourself to communicating with it using inter-process communication (like pipes).  Maybe signals too.. but that becomes jolly tricky when you want to port across platforms.
> 
> The obvious alternative is to use GHC as a library.  That is the way GHCi currently works: a small interactive loop sitting on top of a big library.  Very partial info here
>         http://haskell.org/haskellwiki/GHC/As_a_library
> 
> I think that'd be a lot easier.  If you want to maintain responsiveness of the GUI, when kicking off an evaluation that uses lots of time, you can use Haskell threads.
> 
> Simon
> ...
> 
> Message: 8
> Date: Fri, 24 Nov 2006 11:45:01 +0000
> From: "Neil Mitchell" <ndmitchell at gmail.com>
> Subject: Re: communication with ghci from haskell
> To: "Simon Peyton-Jones" <simonpj at microsoft.com>
> Cc: "cvs-ghc at haskell.org" <cvs-ghc at haskell.org>,
> 	"Hackler at Mathematik.Uni-Marburg.de"
> 	<Hackler at mathematik.uni-marburg.de>
> Message-ID:
> 	<404396ef0611240345n5295f0ado1a0b46776aea6564 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hi
> 
>> Is there some reason you need to run GHCi as a separate process?  By doing so,
>> you constrain yourself to communicating with it using inter-process communication
>> (like pipes).  Maybe signals too.. but that becomes jolly tricky when you want to
>> port across platforms.
> 
> In my case I'd like to work against something which is a bit more
> stable, keep the binary size small, and interface with Hugs and GHC as
> well as GHCi, which means I'd have to do the inter-process stuff
> anyway. Also its not actually that hard in Haskell, no need for pipes,
> runInteractiveProcess gives you most of what you need. However, using
> an API is generally a better alternative to prodding a console!
> 
>> I think that'd be a lot easier.  If you want to maintain responsiveness of the GUI, when kicking off an evaluation that uses lots of time, you can use Haskell threads.
> 
> That might have issues under Gtk2Hs, see
> http://haskell.org/gtk2hs/archives/2005/07/24/writing-multi-threaded-guis/
> 
> Thanks
> 
> Neil