[haskell-llvm] Maintainership still ongoing?

[Benjamin Saunders]

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.

If all that you want to use is the FFI, I suggest reconsidering your usecase in light of the llvm-general API. 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'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.

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.

----- 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