I am writing some code in haskell that has to be callable from C. Is there a tool or library in Haskell that simplifies writing FFI wrapper code for haskell functions that needs to be exported.
For example the tool given a haskell function to be exported would take care(generate the wrapper code) of mapping haskell types to the correct Foreign.C types etc. as required. It would also take care of generating the correct pointers when mapping [Int] types etc. Like what the questioner is attempting here Automatic conversion of types for FFI calls in Haskell. But only is it available like a library?
I wrote a tool called Hs2lib to do this. If you're on windows you're in luck, it'll do everything including compiling the code to a dll and generating c/c++ or c# wrappers. If you're on linux, I'm afraid I haven't gotten the compilation step to work yet, but it still produces the required marshalling information and stubs. You can tell it to keep those by using the -T flag.
Related
I am pretty much 90% sure that the title of this question is wrong however I have no idea what the right title would be (I will gladly edit the title if suggestions come along!).
When reading up on Haskell and the core principles of the language you always find that it is a language "based on lambda expressions". I remember reading somewhere that this means that at the end, the main function just gets "proprocessed" into one big lambda, everything gets inlined, basically your entire code becomes one single, huge, lambda expression.
My questions are:
Is what I said above true?
If the answer to question 1 is "yes", is there any... decompiler/partial compiler/preprocessor? I know about this that lets you see the assembly code behind languages like C/++ and Haskell but is there anything I could use to explore the generated lambda expression?
This question is asked from a purely educational standpoint and not intended to seek a solution to a particular problem. I simply wish to learn more about a language I find extremely fascinating.
Let's make a distinction between the semantics of Haskell and the implementation of GHC. Mostly because we use different terms for language semantics than for assembly, but also because some other compiler might do things differently than GHC.
Every Haskell program defines main, which is an expression of type IO (). I don't like to call it a "lambda expression" because the type shows that it's not a function. The definition of main is some nested tree of function calls. Even the sequential lines in a do block are defined as calls to the functions (>>) and (>>=).
GHC uses heuristics to decide what to inline, to get the best runtime performance. It will usually inline small expressions that aren't recursive. I believe the runtime system maintains a callstack of functions currently being evaluated, not unlike the runtime result of compiling function calls in C or other imperative languages.
GHC provides many options for printing intermediate stages of compilation. I'm not sure which you will find interesting. Core is the lowest-level representation that feels like Haskell. Cmm (also called C--) is the highest-level representation that feels like assembly.
I'm trying to dump type information of all identifiers in an Haskell project, basically it's the same as traversing the typed abstract syntax tree.
From another question, OCaml exposes its internal APIs through a library called compiler-libs. I'm wondering how is Haskell's support for similar task?
GHC-as-a-library gives you a TypecheckedModule, and getNamesInScope, which includes the type of each name.
I have some Haskell code, and would like a Fay script to be able to access it. The problem is the Haskell code uses monads. Fay doesn't support arbitrary monads. How do I get my Haskell code to work with Fay? Namely, the Fay script needs to be able to access functions from the Haskell script. What do I do?
I may not quite understand what you are asking.
You have some Haskell that isn't valid Fay, so if you want to run it as Fay code you would need to replace unsupported features, for example by using monomorphic functions to replace the missing Monad instances (note that you can use RebindableSyntax here)
If you compile the Haskell code with GHC there is no reasonable way to interface with the functions from Fay. You would need to invoke an external process from Fay inside node.js or similar.
Does Haskell erase types, and if so, in what ways is this similar/dissimilar to the type erasure that occurs in Java?
Warning: experience+inference. Consult someone who works on both compilers for The Truth.
In the sense that type checking is done at compile time, and several complex features of the type system are reduced to much simpler language constructs, yes, but in a rather different way to Java.
A type signature creates no runtime overhead. The Haskell compiler is good at program transformation (it has more leeway, because the running order is in many cases not specified by the programmer), and automatically inlines appropriate definitions and specialises haskell-polymorhpic (=java-generic) functions to a particular type etc, as it sees fit, if it helps. That's a similar to Java type erasure, but more-so aspect.
There are in essence no type casts needed in Haskell to ensure type safety, because Haskell is designed to be type-safe from the ground up. We don't resort to turning everything into an Object, and we don't cast them back, because a polymorphic(generic) function genuinely does work on any data type, no matter what, pointer types or unboxed integers, it just works, without trickery. So unlike Java, casting is not a feature of compiling polymorphic(generic) code. Haskell folk tend to feel that if you're doing type casting, you said goodbye to type safety anyway.
For a lovely example of how ensuring the code's static type-correctness at compile time can avoid runtime overhead, there's a newtype construct in Haskell which is a type-safe wrapper for an existing type, and it's completely compiled away - all the construction and destruction simply doesn't happen at runtime. The type system ensures at compile time it's used correctly, it can't be got at at runtime except using (type-checked) accessor functions.
Polymorphic(generic) functions don't have polymorphic overheads. Haskell-overloaded functions (Java-interface-instance methods) have a data overhead in the sense that there's an implicit dictionary of functions used for what appears to be late binding to Java programmers, but is in fact, again, determined at compile time.
Summary: yes, even more so than in Java, and no, they were never there at runtime to erase anyway.
C and Pascal have type erasure. Java lets you inspect classes at run-time - even dynamically loaded ones!
What Haskell does is much closer to Pascal than to Java.
What is the difference between hsc2hs and c2hs?
I know what hsc2hs is a preprocessor but what does it exactly do?
And c2hs can make Haskell modules from C-code, but do I need hsc2hs for this?
They both have the same function: make it easier to write FFI bindings. You don't need to know about hsc2hs if you chose to use c2hs; they are independent. C2hs is more powerful, but also more complicated: Edward Z. Yang illustrates this point with a nice diagram in his c2hs tutorial:
When should I use c2hs? There are many
Haskell pre-processors; which one
should you use? A short (and somewhat
inaccurate) way to characterize the
above hierarchy is the further down
you go, the less boilerplate you have
to write and the more documentation
you have to read; I have thus heard
advice that hsc2hs is what you should
use for small FFI projects, while c2hs
is more appropriate for the larger
ones.
Things that c2hs supports that hsc2hs
does not:
Automatic generation of foreign import based on the contents of the C
header file
Semi-automatic marshalling to and from function calls, and
Translation of pointer types and hierarchies into Haskell types.
Mikhail's answer is good, but there's another side. There are also things that hsc2hs provides that c2hs does not, and it may be necessary to use both in conjunction.
Notably, hsc2hs operates by producing a C executable that is run to generate Haskell code, while c2hs parses header files directly. Therefore hsc2hs allows you to access #defines, etc. So while I've found c2hs better for generating bindings and wrappers to bindings as well as "deep" peeks and pokes into complex C structures, it is not good for accessing constants and enumerations, and it only automates mildly the boilerplate for Storable instances. I've found hsc2hs necessary as well, in conjunction with the bindings-dsl package [1], in particular in my case for predefined constants. In one instance, I have one hsc file for an enormous amount of constants, and one chs file for wrapping the functions that use these constants.
[1] http://hackage.haskell.org/package/bindings-DSL