[haskell-llvm] Thoughts on llvm-base package structure

[Benjamin Scarlet]

There is a notable potential obstacle to using the llvm-general FFI code for an llvm-ffi package: it is dependent on the AST in llvm-general-pure, through use of template Haskell.

For example: rather than duplicate long lists of instructions in several places, the instruction constructors are used as data, joined (in the relational sense) with the information provided by LLVM in the Instruction.def meta-header, and used to generate the FFI declarations for all of the corresponding builder functions.

Of the various places I could have chosen to use as the written-out, "master" version of the instruction data, I chose to use the AST in order to make reading the code and haddock clearer for a user who is not an implementor.

There is no technical reason that the AST could not be a dependency of a hypothetical unified FFI library, but such a dependency might be unpalatable to those of you who do not wish to use the AST.

Thinking briefly, I don't immediately see a way to eliminate the dependency which would not either require significant code duplication or make the haddock of the AST much less useful. I'm open to suggestions.

-Ben Scarlet

On Aug 13, 2013, at 3:49 AM, Scott West <scott.west at inf.ethz.ch> wrote:

> I have actually looked at the llvm-general code, it's quite nice,
> although it does raise the barrier to contributing (one must grok the
> TH, which isn't the most common skill).
> 
> I would actually be pretty happy to have this better foundation living
> in llvm-base/llvm-ffi! What I'm actually asking is: is there a reason
> not to have the FFI by itself, separate from the higher-level wrappers
> like ST/llvm-general/etc?
> 
> Regards,
> Scott
> 
> On 08/13/2013 09:34 AM, Carter Schonwald wrote:
>> Please actually take a look at the llvm-general code, there really isn't
>> a compelling reason for it to use the ffi machinery in llvm-base, it's
>> own ffi work is much nicer.   
>> 
>> Cheers. 
>> 
>> On Tuesday, August 13, 2013, Scott West wrote:
>> 
>>    The recent (and previous) discussions seem to indicate that the package
>>    structure of LLVM on Haskell might need to be rethought.
>> 
>>    I'll refer to the nice justification given in the bug report:
>>    https://github.com/bos/llvm/issues/61
>> 
>>    The general proposal was to have llvm-ffi, llvm-wrapper (how much
>>    wrapping should be here I don't know), and then the higher level
>>    interfaces building on top of one or the other.
>> 
>>    Now that we have another high-level interface (llvm-general), it seems
>>    that it might be a good time to actually implement some of these ideas.
>> 
>>    Would there be any strong objection to splitting llvm-base into two,
>>    hoping to make it easier for all the upper levels to consume?
>> 
>>    Regards,
>> 
>>    _______________________________________________
>>    Haskell-llvm mailing list
>>    Haskell-llvm at projects.haskell.org <javascript:;>
>>    http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-llvm
>> 
> 
> 
> _______________________________________________
> Haskell-llvm mailing list
> Haskell-llvm at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-llvm