[haskell-llvm] llvm-general FFI dependencies

[Benjamin Scarlet]

The transform code we're talking about is pure Haskell listing the various transform passes as constructors of a data type. It's used both at compile time, as input to the template haskell code which produces the FFI declarations of the corresponding methods, and at runtime as input to the exposed API for using the same.

It's okay to put the data type into llvm-general-pure, as it's pure Haskell - not dependent on any FFI.
It's weird to put it in llvm-general-pure, because it's not of much external use at runtime except to pass to code in llvm-general.
It's weird to put it in llvm-general-ffi, because it's not FFI code.

These are not at all necessarily equivalent weirdnesses. I, for one, am still staring at them deciding what's most sensible.

-Ben Scarlet

On Aug 19, 2013, at 5:21 PM, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> ok, makes sense.
> 
> 
> On Mon, Aug 19, 2013 at 7:10 PM, Scott West <scott.west at inf.ethz.ch> wrote:
> Hello Carter,
> 
> There are two main reasons:
> 
> 1) It reduces the maintenance burden for all projects. With a single FFI as the base of all the LLVM packages it gives it more testing/users. This in the end will increase the quality of the FFI binding which benefits everyone.
> 
> 2) It's also more future-proof: an independent FFI package makes it easier for any future independent experimentation.
> 
> Regards,
> Scott
> 
> 
> On 8/19/2013 10:27 PM, Carter Schonwald wrote:
> whats the motivation for either choice over the current approach?
> 
> 
> On Mon, Aug 19, 2013 at 4:16 PM, Dr. Benjamin S. Scarlet
> <roll10 at greynode.net <mailto:roll10 at greynode.net>> wrote:
> 
>     Scott,
> 
>     You asked on IRC about putting the Transforms into the -ffi package. I
>     replied that yes, that option would be weird.
> 
>     This option of putting them into the -pure package is also weird.
> 
>     I'm torn between the two. Neither one is unacceptable; neither is
>     particularly nice.
> 
>     I'm pondering the two, and would welcome arguments in either direction.
> 
>     -Ben Scarlet
> 
>     On Mon, 2013-08-19 at 09:33 +0200, Scott West wrote:
>      > Hello all,
>      >
>      > I've been looking a bit in the past week at the llvm-general bindings
>      > trying to figure out how to tweeze the FFI part away from the rest.
>      >
>      > As Ben Scarlet indicated, the dependency of the FFI part is
>     largely on
>      > llvm-general-pure. However, there are two other small dependencies on
>      > the llvm-general:
>      >
>      > - LLVM.General.Internal.InstructionDefs and
>      > - LLVM.General.Transforms
>      >
>      > It seems that the dependency on Internal.InstructionDefs is
>     mostly just
>      > code-sharing, and there is probably a not too difficult solution
>     there.
>      >
>      > For Transforms however, I'm less sure what to do.
>      >
>      > I think a better option is to move it into llvm-general-pure, as it
>      > certainly pure, although it's not really part of the AST (which
>      > llvm-general-pure mostly contains). This would make it that
>      > llvm-general-pure is a dependency for all llvm packages in the
>     future,
>      > allowing us to share a single FFI implementation (the currently
>     hidden
>      > llvm-general one).
>      >
>      > Thoughts?
>      >
>      > Thanks!
>      >
>      > Regards,
>      > Scott
>      >
>      > _______________________________________________
>      > Haskell-llvm mailing list
>      > Haskell-llvm at projects.haskell.org
>     <mailto:Haskell-llvm at projects.haskell.org>
> 
>      > http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-llvm
> 
> 
> 
>     _______________________________________________
>     Haskell-llvm mailing list
>     Haskell-llvm at projects.haskell.org
>     <mailto:Haskell-llvm at projects.haskell.org>
>     http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-llvm
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-llvm/attachments/20130819/eb525b66/attachment.htm>