[haskell-llvm] llvm-general FFI dependencies

[Scott West]

On 08/20/2013 10:26 AM, Henning Thielemann wrote:
> Am 20.08.2013 10:06, schrieb Scott West:
> 
>>> Btw. if the FFI package should be used widely I prefer it would not
>>> depend on so many GHC extensions like TemplateHaskell.
>>
>> The use of TemplateHaskell here automates much of the process that
>> should it easier to keep the maintenance burden down. For example
>> definitions from the LLVM headers are used to generate some of the FFI.
>>
>> This helps reduce the situations where LLVM changes and we have to
>> manually tweak the FFI.
> 
> I thought llvm-base also has some support for converting C headers to
> FFI definitions in llvm/base/tools. 

There's something there. The documentation doesn't say that its for FFI
generation, but that could be a functionality as well (there does appear
to be some "foreign" generation).

> Is Template Haskell used for parsing
> the C stuff? It sounds crazy to me. So far I have used HSC for
> interfacing from Haskell to C. However I have no experience with
> automatic generation of FFI declarations using HSC.
> 

No it doesn't parse the C stuff.

The LLVM headers include a Instruction.def file that allows a caller to
#define some macros to help generate structures. TH is used from there
to generate some Haskell foreign declarations.

I suppose (although am not 100% sure) this could be done without TH, but
TH is also used to translate hand written Haskell datatype definitions
into foreign declarations.

> I guess that the Template Haskell code is something that could be run
> without Template Haskell. It could be a stand-alone C->FFI converter,
> right?

I can't comment on that definitively, Ben Scarlet would probably be more
suited.

> 
>> Did you have a use case that may help us understand why TH is
>> undesirable?
> 
> I am generally nervous about lots of GHC extensions because every one
> makes it harder to port code to another compiler and to port from one
> GHC version to another one. Especially Template Haskell breaks regularly
> from release to release. Although I do not plan to use llvm with a
> compiler other than GHC today, it would be great to keep this option.
> There are some other interesting compiler projects like JHC and UHC and
> they can hardly catch up with all GHC extensions. If you invest much
> time in a Template Haskell solution now you will certainly not change
> this later to another tool.
> 

I admit that this is not a huge concern for me. In particular, the time
is already invested in the TH solution, so switching away from it will
cost now or later, probably about the same. Given that so far there
isn't a great call to get it working on the other compilers, its hard to
justify putting in the effort.


Regards,
Scott