<div dir="ltr">I agree that preprocessing code shouldn&#39;t be hsc2hs specific.  I prefer c2hs myself.  But hsc2hs is distributed with ghc, which makes it as official as a good many other parts of &quot;modern Haskell&quot;.<div>
<br></div><div style>I also agree that making cabal-ghci work nicely would be ideal, but I don&#39;t think it can be done without either adding hooks into ghci or wrapping stdin.  As Roman points out, if you use :r in ghci, cabal-ghci wouldn&#39;t pick up changes in the source file.  Using ghc&#39;s support for custom preprocessors seems like a very straightforward solution: it already exists, can be used today, and isn&#39;t tied to hsc2hs.</div>
<div style><br></div><div style>Not that this should stop anyone from working on cabal-ghci of course.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 6, 2013 at 11:43 AM, Jeremy Shaw <span dir="ltr">&lt;<a href="mailto:jeremy@n-heptane.com" target="_blank">jeremy@n-heptane.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While hsc2hs is a popular FFI preprocessor, it is not the only one.<br>
There is also greencard and a few others.<br>
<br>
While hsc2hs can usually get the job done -- it&#39;s not clear that it is<br>
really the best choice. I think the Haskell FFI got to the point that<br>
it was &#39;just good enough&#39; and then people lost interest in doing<br>
anything more. Let&#39;s face it -- working on the FFI is just not that<br>
exciting :)<br>
<br>
So, basically, we are stuck with stuff that is &#39;good enough&#39; but no so<br>
great that we want to make it official.<br>
<br>
We can bind to C fairly easily, but for C++, Python, Ruby, Javascript,<br>
Java, etc, we have never really made much headway.<br>
<br>
I think the efforts to make cabal-ghci work nicely could really be the<br>
best solution for now. That is more extensible, and makes it easy to<br>
solve the problem you actually care about (being able to easily<br>
load/compile .hs files) with out giving priority to any particular FFI<br>
system.<br>
<span class="HOEnZb"><font color="#888888"><br>
- jeremy<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Jun 4, 2013 at 9:02 PM, silly8888 &lt;<a href="mailto:silly8888@gmail.com">silly8888@gmail.com</a>&gt; wrote:<br>
&gt; I was wondering today, why hasn&#39;t hsc2hs been merged with ghc so that<br>
&gt; it would be possible to add a<br>
&gt;<br>
&gt; {-# LANGUAGE ForeignFunctionInterface #-}<br>
&gt;<br>
&gt; at the top of a source file and then load it with ghci or compile it,<br>
&gt; without the intermediate step of calling hsc2hs? This would be exactly<br>
&gt; like the CPP extension. I don&#39;t have to call cpp manually. All I have<br>
&gt; to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of<br>
&gt; the rest. This would also mean that there would be no need to have a<br>
&gt; separate file extension. Surely I must not be the first person to have<br>
&gt; that thought, so there must be a good reason why this hasn&#39;t happen<br>
&gt; yet, but what is it?<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Haskell-Cafe mailing list<br>
&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>