Dimitry Golubovsky wrote:
John,
Thanks for the reply.
In this case, would the body of my function run in a separate thread via forkProcess (that's what is needed, maybe I didn't make it clear)?
No; at least not automatically. The idea is that a function that is Channel -> IO Channel should be very similar in concept to a String -> String - processing its input lazily.
In my previous project, I had to do like this (probably not very portable, at least requires System.Posix):
You are aware that HSH has built-in support for executing external commands, right? What is hssfigMain? Is it calling some other program or is it part of the current process? I would suggest that the appropriate idea is to make hsffigMain be some other executable. Then you could just: runIO $ ("hsffigMain", [args, args, ...]) -|- (fromJust $ gccPath dopt, ["-E", "-dD", ...])
where hscpid corresponds to a process that runs a Haskell function (hsffigMain :: a -> b -> c -> IO ()) defined within the same program, and gccpid runs an external program (gcc), and they are piped together. I am trying to avoid writing this mess using HSH.
OK, so I should have read more before starting to reply. But why are you writing to me about HSH if you're trying to *avoid* HSH? I'm confused.
I'm just trying to find out whether this was already done. If not, what is the best way to write the above to be integrated into HSH (I'd be glad to contribute).
Integraing hsffigMain into HSH directly will be difficult because it apparently already has its notions about where its input and output come from; the fact that its return type is IO () implies that its output either goes to stdout or to a file. This type of function cannot be generalized to pipes, because you can only dup2() your stdout once. (You couldn't have two functions like hsffigMain in your pipeline). Your best bet is to make this a separate executable. -- John