[haskell-llvm] Maintainership still ongoing?

[Scott West]

On 8/12/2013 8:51 PM, Benjamin Saunders wrote:
> I've moved my projects over to llvm-general and do not expect to be
> doing further work on llvm and llvm-base.
>
> llvm-general in fact exposes far more FFI-based functionality than
> llvm-base (see the LLVM.General.* modules at
> http://bscarlet.github.io/llvm-general/3.3.7.0/doc/html/llvm-general/index.html
> ), and provides a very nice interface for them. There's no direct
> exposure of the FFI, in part because it includes many custom wrappers
> for functionality available only through C++, rather than just
> providing access to the LLVM C API.Speaking as someone who has
> worked on both, llvm-general's FFI story is also much cleaner and far
> more maintainable than that of llvm-base, thanks in part to extensive
> use of template haskell, and in general benefits massively from the
> relative absence of cruft, to the point that the most plausible way
> to port llvm-general's FFI stuff to llvm-base would be to rename to
> llvm-base.

Great! More maintainable sounds super, and getting the benefits of this 
greater maintainability out to more people (through llvm-base) is even 
better.

> If all that you want to use is the FFI, I suggest reconsidering your
> usecase in light of the llvm-general API.

My usecase is to maintain the working code I have now with a minimum 
amount of time spent. llvm-general does not help me there :) The code 
already uses the FFI and switching away is pretty unappealing, as its 
working code. I just don't want to see duplicated effort where there's a 
possibility for cooperation.

Is there a large underlying API difference between your Internal.FFI and 
what we could have under llvm-base?

 > It provides access to all
> of the functionality exposed by FFI in llvm-base plus much more in
> cleaner and more idiomatic Haskell interfaces, and generating
> Haskell-side ASTs is a far nicer experience than calling out to the
> IR builder directly, or even working with elaborate low-level
> wrappers as I was experimenting with.

I think there are 3 main reasons to maintain an FFI separately:

1) people have existing FFI code and don't want to rewrite it
2) people may just prefer their FFI code over an AST approach
3) people may have another approach different from llvm-proper or 
llvm-general and need the FFI anyway to try it out.

In any case, updates/improvements to the FFI saves the most amount of 
people the most amount of time if all the FFI code is in one place.

> I'm not sure what you're doing,
> but I have a hard time imagining a situation where redoing all of the
> extensive binding and wrapping work that transforms a raw C FFI into
> something nice to use is the most efficient solution.

I'm actually pretty happy with a fairly thin wrapper around the C FFI. 
If llvm-general was around when I started I probably would have used 
that, but I have code on the FFI now that's not too bad so I'm happy to 
just maintain it.

> Another idea that's been bounced around a little is to write a legacy
> layer that ports the typesafe API of the Haskell llvm package onto
> llvm-general.

Thank you very much for taking the time to respond, I've found it very 
enlightening!

Regards,
Scott

> ----- Original Message ----- From: "Scott West"
> <scott.west at inf.ethz.ch> To: "Carter Schonwald"
> <carter.schonwald at gmail.com> Cc: haskell-llvm at projects.haskell.org
> Sent: Monday, August 12, 2013 8:51:42 AM Subject: Re: [haskell-llvm]
> Maintainership still ongoing?
>
> Hi Carter,
>> Llvm-general has a better ffi story than llvm/llvm-base.  And
>> provides a nice way to map  back and forth between the Haskell AST
>> and the llvm c++ in memory AST.  It's really a markedly better
>> substrate. And there's no cruft in its build scripting!
>
> Well, I'd be happy to have a better FFI story in llvm-base! Is there
> something fundamental in the FFI bindings that makes it so the
> improvements cannot be shifted to llvm-base under the same/similar
> interface?
>
> It seems that the FFI isn't even exposed in llvm-general, what if
> that's all I want to use?
>
> I think you're going to face a hard sell telling people to switch to
> llvm-general; it's not exactly a replacement for llvm-base.
>
> I think the optimal solution would be to find a way for llvm-general
> to use llvm-base for its FFI (not the AST part of course). I'd be
> willing to help integrate the improvements on the FFI side into
> llvm-base, if they are portable. If we can find a way to cooperate
> here I think it will benefit everyone in the long run :).
>
> Thanks for chiming in on the llvm-general side!
>
> Regards, Scott
>
> _______________________________________________ Haskell-llvm mailing
> list Haskell-llvm at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-llvm
>