RE: Modification to foreign import/export
If we want to rule cpp as out of bounds (a very worthwhile but difficult goal), then we need to think about how to avoid conditional compilation too.
I think the goal is not to avoid the use of cpp, but rather to avoid mentioning it in the spec. In practice, many people will be using cpp (one way or another) when they write a C-library binding. Conditional compilation is a fact of life, I don't think it's worth trying to avoid - but at least there's no need to mention it in the FFI spec. Cheers, Simon
While on the subject of preprocessors, I thought I'd mention a need I've found in distributing tools like Knit where the intended audience isn't expected to: 1) Care either way about it being implemented in Haskell 2) Have any desire to spend half a day installing lots of Haskell-related tools (greencard, c2hs, happy, etc.) on their machine before they can try out my tool. Getting them to install a GHC binary is about the limit of what I can reasonably expect. In this case, it is very useful to be able to distribute the output of all those useful support tools (greencard, c2hs, happy, etc.). But now the problem: if I achieve portability by running the input to these tools through cpp (or any other tool providing conditional compilation), then I end up with 2^N different files to distribute and complicated instructions for building the system. What would (perhaps) be nice is for the support tools to implement conditional compilation themselves and for the output file to use conditional compilation too. Alastair ps Or maybe I should just hack up a perl script that runs greencard and friends 2^N times and then packs the results (using diff, etc as appropriate) into a convenient file for shipping to users.
Thu, 22 Feb 2001 11:41:20 -0700, Alastair Reid <reid@cs.utah.edu> pisze:
2) Have any desire to spend half a day installing lots of Haskell-related tools (greencard, c2hs, happy, etc.) on their machine before they can try out my tool. Getting them to install a GHC binary is about the limit of what I can reasonably expect.
hsc2hs is in ghc-4.11.
In this case, it is very useful to be able to distribute the output of all those useful support tools (greencard, c2hs, happy, etc.).
The output can depend on versions of C libraries they have installed and other details of their system which are detected at configure time. You would lock the distributed package to a concrete binary-compatible environment.
What would (perhaps) be nice is for the support tools to implement conditional compilation themselves and for the output file to use conditional compilation too.
Sorry, I don't understand this. For example hsc2hs transforms a .hsc file with #ifdefs and other things into a .hs file and sometimes also .h and .c files. The .hs file has conditional compilation resolved; the .h and .c files contain #ifdefs which mirror the #ifdef structure of the source. hsc2hs doesn't implement #ifdefs itself, but uses cpp to compile a C program which outputs the Haskell source. What would you like to obtain?
ps Or maybe I should just hack up a perl script that runs greencard and friends 2^N times and then packs the results (using diff, etc as appropriate) into a convenient file for shipping to users.
Do you mean considering every possible combination of #ifdefed expressions? Sorry, it won't work. One of my modules contains 98 #ifdefs in a row (generated by macros), which check availability of errno constants. I will not distribute 316912650057057350374175801344 variants of this file. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
hsc2hs is in ghc-4.11.
Did I miss the last 3 releases? I'm still stuck with something between 4.08.1 and 4.08.2 waiting for a debian package and freebsd port to appear for 4.08.2. :-) [Serious content of which is that I'm absolutely _not_ interested in subjecting users of my tools to the bleeding edge of Haskell tools. For example, we don't even tell people how to build Knit from source because the current instructions include installing 4.04 then using that to bootstrap 4.08.2 then building Knit.]
What would you like to obtain?
An output file or files which can be used as input to cc/ghc/Hugs/etc. (i.e., which doesn't require greencard, c2hs, hsc2hs, etc.) and which contains ifdefs to handle any portability issues.
Do you mean considering every possible combination of #ifdefed expressions? Sorry, it won't work. One of my modules contains 98 #ifdefs in a row (generated by macros), which check availability of errno constants. I will not distribute 316912650057057350374175801344 variants of this file.
Which is why it'd be nice if the output of the tools contained the ifdefs - a tool can often (but not always) do a more intelligent job of generating ifdefs. -- Alastair
Thu, 22 Feb 2001 14:07:04 -0700, Alastair Reid <reid@cs.utah.edu> pisze:
An output file or files which can be used as input to cc/ghc/Hugs/etc. (i.e., which doesn't require greencard, c2hs, hsc2hs, etc.) and which contains ifdefs to handle any portability issues.
Ah, now I see. hsc2hs could have an option to not delete the source of the C program which outputs the Haskell source. In this case it would be possible to make a distributable source package which doesn't require hsc2hs to compile. I will add this option. (Except that I pass some file through hsc2hs twice, because C macros can't expand to preprocessor directives. For this case the scheme would not help. But it's very rare.) -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
"Alastair Reid" <reid@cs.utah.edu> wrote,
While on the subject of preprocessors, I thought I'd mention a need I've found in distributing tools like Knit where the intended audience isn't expected to:
1) Care either way about it being implemented in Haskell
2) Have any desire to spend half a day installing lots of Haskell-related tools (greencard, c2hs, happy, etc.) on their machine before they can try out my tool. Getting them to install a GHC binary is about the limit of what I can reasonably expect.
In this case, it is very useful to be able to distribute the output of all those useful support tools (greencard, c2hs, happy, etc.).
But now the problem: if I achieve portability by running the input to these tools through cpp (or any other tool providing conditional compilation), then I end up with 2^N different files to distribute and complicated instructions for building the system.
Yes, a nasty problem.
What would (perhaps) be nice is for the support tools to implement conditional compilation themselves and for the output file to use conditional compilation too.
Due to my dislike of mixing cpp and Haskell, c2hs actually doesn't use conditional compilation at all. I gather some information with autoconf, but much of this won't be necessary with the latest version of the FFI libraries. So, it might actually be feasible to delay the inclusion of system dependent information until the generated files are compiled, which is what you want. Good point - I will put it on the todo list. Cheers, Manuel
On 22-Feb-2001, Alastair Reid <reid@cs.utah.edu> wrote:
While on the subject of preprocessors, I thought I'd mention a need I've found in distributing tools like Knit where the intended audience isn't expected to:
What's Knit?
1) Care either way about it being implemented in Haskell
2) Have any desire to spend half a day installing lots of Haskell-related tools (greencard, c2hs, happy, etc.) on their machine before they can try out my tool.
Why not just distribute binaries for the platforms of interest? Or runhugs scripts? I must be missing something. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
What's Knit?
A component language for C. Announcement attached.
Why not just distribute binaries for the platforms of interest?
People feel uncomfortable if they can't build from source themselves. Generating binaries for a decent range of platforms is a bunch of work (especially given the current mess in the Linux library system).
Or runhugs scripts?
Using Hugs is attractive because it is really easy to install and very portable. It's also too slow to use for compiling large systems or when doing cross-component inlining. But even if we stick with Hugs, there's a little ffi'd C code in the system - so they still have to compile some of the code themselves. -- Alastair
participants (5)
-
Alastair Reid -
Fergus Henderson -
Manuel M. T. Chakravarty -
qrczak＠knm.org.pl -
Simon Marlow