Manuel M. T. Chakravarty wrote:
| I don't think that it makes much sense coding on the
| plain FFI unless there are reasons for avoiding an
| extra tool or the binding is very small.
Just my $0.02:
I have used the plain FFI for larger projects. The initial
reason I did this because my
Koen Claessen [EMAIL PROTECTED] writes:
| Does anyone have any better suggestions?
I think any solution that leaves it transparent as to if it
is a compiled or an interpreted module is fine.
But I have understood that this is hard to achieve...
How about using a different command for
I'd like to say thanks to everyone who responded.
At this point, I think I'll try each -- the FFI to get a feel for the
low-level goings-on, C-Haskell 'cause it looks interesting, and
H/Direct for it's power. After I've tried each, I'll have a better
understanding and be able to evaluate each
It turns out that, besides having a multithreaded process do
`forkProcess` and `executeFile` atomically, I also want to have a
multithreaded process do `forkProcess` (without `executeFile`) and
execute without any of the preexisting threads. This can be done by
having a lock that all threads
Writing .hi-boot files is a pain, and the works (allegedly) containing a compiler
which
does mutually recursive modules properly seem permanently gummed up. Therefore may I
suggest
a new .hs-boot suffix which compiles Haskell to produce just a .hi-boot file? I
already have
two .hs-boot
John Meacham [EMAIL PROTECTED] wrote,
don't forget one very big pro for hsc2hs, which is that it comes with
ghc so you can count on it working.
True.
I find it tricky to keep c2hs (and
hence gtk+hs) working with the latest ghc. no doubt the situation is
getting better, but it is still
