
On 2015-05-21 at 18:02:57 +0200, Brandon Allbery wrote:
On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel
wrote:
Performance isn't (my) motivation for avoiding fork/exec (and the equivalent on Win32) but rather avoiding the added complexity of marshalling/IPC with fork/exec, as opposed to simply calling into a native Haskell function and crossing process boundaries and having to deal with the various things that can go wrong with the additional moving parts you encounter when controlling an external process. So this would IMO simplify code paths, and moreover I'd expect opportunities to actually make the Haskell cpphs API richer (in case it isn't already) and more tailored to GHC's lexer/parser pipeline and error-reporting.
Don't you still have to support -pgmF?
I guess so, unfortunately... so we'd have to keep a legacy code-path for external cpp processing around, at least in the short run...