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
[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
Subject: RE: communication with ghci from haskell
To: "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]>, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
Subject: Re: communication with ghci from haskell
To: "Simon Peyton-Jones" <[EMAIL PROTECTED]>
Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]"
<[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
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
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
