2011/4/1 Gershom Bazerman :

On Apr 1, 2011, at 7:52 AM, Gábor Lehel wrote:

The two projects I've been able to think of which seem like they *might* be appropriate are: integrating the standard 'deriving' mechanism with Template Haskell to support deriving custom classes; and adding native FFI support for passing C structs / tuples (arbitrary products?) of FFI-able types by value, as discussed in [1]. Would either of these be not-too-big / would anyone be willing to mentor them? Alternately, I'd be very happy to receive suggestions about other GHC-related work which would be considered appropriate. (Or, heck, any other compiler.)

The former project is now outdated, I suspect. My understanding is that work has already been underway to implement Generic Deriving [1] in GHC. Even prior to then, the template haskell approach was supported by the derive [2] tool.

As far as I can tell from skimming the paper, the Generic Deriving approach is more structured, disciplined, and less flexible than what I had in mind. Using TH to generate instances is all over the place: all that I have in mind is being able to take a function with a type along the lines of 'Name -> Q (Either String Dec)' and register it with GHC for a given class somehow (a pragma?), and thenceforth being able to list that class in a deriving clause and have the provided function be used to (attempt to) derive it, instead of having to do a top-level TH splice explicitly (which is rather ugly, to my taste). So just syntactic sugar, more or less, but to me it feels like important sugar. I can imagine this being both too small or too large for a summer project, depending on how GHC works. (The staging restriction seems like it's going to be either the fly in the ointment or the cherry on top: if using TH-backed deriving causes the file to be staged into pieces that almost entirely defeats the purpose; whereas if it can be made so that TH-backed deriving *doesn't* cause staging, unlike a vanilla top-level TH splice, that would be, well, pretty great.)

On the latter count, there's plenty of work to be done for c2hs, that seems very related to the work you've done on the C++-to-Haskell generator. C2hs is already in wide use across the Haskell community, and improvements to it would benefit a wide swath of developers, either directly or indirectly. I've been told that the c2hs project is quite open to a SoC student. I'm ccing Duncan and Manuel, because they're much more able to speak to the "big picture" than I am. As I recall, one task I heard described is an overhaul of marshalling -- although, again, Duncan and Manuel could explain what that actually entails.  Along with that, I'd very much like to see extensible declaration of default marshalling, and extension of default marshalling support to get and set hooks as well. Another task is to implement "enum define" hooks as described in the paper. I'm sure there's plenty else too.

I'm actually not overly familiar with c2hs :) and (correct me if I'm wrong, but) I'm not sure C++ and c2hs are as relevant to each other as one might think. c2hs seems to be mainly concerned with C structs and marshalling thereof, along with functions involving them; in contrast, while C++ is (almost) a superset of C, C++ types are by convention nearly always opaque, so one just passes around pointers to them and is done with it, and the interesting parts are elsewhere. (And the two seem to work on a different level: c2hs seems mainly to be an aid for binding libraries manually, whereas the point of the generator I'm working on is that it would generate bindings semi-automatically; and once you're doing that it seems easier to just skip the intermediate step and generate the foreign import/exports and other code directly.) Another idea I had earlier, but discarded, was adding FFI support for the Itanium C++ ABI (which seems to have been adopted as more-or-less the standard across Unix-like systems). I discarded it because it seemed like you'd have to essentially implement a C++ compiler as part of GHC to make it work. Thinking about it more, though, I'm not sure if a useful subset would necessarily be unreasonable (no templates, for starters). One foreseeable difficulty is that while reference and const-reference parameters are in practice passed the same way as pointers, one would still need to somehow tell GHC which one it is in order to generate the correct mangling (or correct stub-C-wrapper-to-be-compiled-with-g++, if going that route). In any case, this very much would build on my experience with the bindings generator in a pretty big way, maybe even bringing it into the scope of a summer project (though obviously iffy). (The wildcard from my point of view is still GHC, about whose internals I don't know so much -- how easy/hard it is to muck around with the FFI implementation, for example.)

And while I'm at it, I should mention another SoC project that I think would be quite important -- improvements/rewrites to the HDBC database backends. [3] Cheers, Gershom [1] http://www.dreixel.net/research/pdf/gdmh_nocolor.pdf [2] http://hackage.haskell.org/package/derive [3] http://hackage.haskell.org/trac/summer-of-code/ticket/1598

-- Work is punishment for failing to procrastinate effectively.

2011/4/1 Johan Tibell :

Hi Gábor,

There are a few non-Cabal projects on the ideas list (http://hackage.haskell.org/trac/summer-of-code/report/1). Just thought I mentioned it in case you missed it.

I saw it :)

2011/4/1 Gábor Lehel :

...

Alternately, I'd be very happy to receive suggestions about other GHC-related work which would be considered appropriate. (Or, heck, any other compiler.)

Perhaps you could send an email to the GHC mailing list and ask if they have any good GSoC projects? I'm not sure the Simons are reading every post on this list.

Oh, hmm. Good idea. Should've cross-posted from the beginning :|. What's the accepted etiquette here? Forward the original message? Send a short heads-up with a link to this thread in the archives?

...

A related problem is that, having done only minimal GHC hacking so far, drawing up a detailed plan / design in advance as part of the proposal would be difficult. If this is considered necessary and there is someone willing to mentor the project I'd be happy to research the problem in advance of the submission deadline so I can submit a more detailed proposal. Alternately, if it's deemed acceptable to learn the ropes / come up to speed as part of the SoC itself that's fine by me as well. (Wasn't this sort of the point originally?)

It's not required but it helps. Us mentors need to figure out if you're likely to finish your project or not. Showing that you understand what needs to be done is a good sign. If you're not sure what needs to be done there's still a chance you'll get accepted if people who already know GHC thinks one summer is enough time to both get familiar with GHC and add something worthwhile.

...

Background info: I've taken part in the SoC once before, back in 2006 (when I applied to KDE to work on Krita). I don't yet have any Hackage packages to my name, however I'm working on a C++-to-Haskell bindings generator for my bachelor's thesis (the primary target being Qt*) which is likely to spawn quite a few. (I've avoided making any noise about this because I didn't want to put the cart before the horse: the plan was (and still is) to announce something once there is something worth announcing, and it's not at that point quite yet.)

How about adding Haskell support for SWIG? Being able to call C++ libraries from Haskell would be very useful.

Maybe I have a case of NIH, but I'm not very familiar with SWIG either :). None of the other Qt/KDE bindings for other languages use it, and as far as I can remember the rationale was that it's too limited. Based on this assumption I never felt the inclination to learn about it, either. That said, "being able to call C++ from Haskell" is pretty much what the bindings generator I'm working on aims to accomplish. (For certain kinds of libraries -- object-oriented ones which make only limited use of templates, essentially.) Adding C++ support to the FFI (per my previous message) would still have considerable value-added in comparison to this -- not having to call a generator is always a plus, and it would also be somewhat orthogonal and lower-level (parts of the generated bindings could be switched over to use it internally, for example).

Cheers, Johan

-- Work is punishment for failing to procrastinate effectively.

2011/4/1 Johan Tibell :

2011/4/1 Gábor Lehel :

...

Oh, hmm. Good idea. Should've cross-posted from the beginning :|. What's the accepted etiquette here? Forward the original message? Send a short heads-up with a link to this thread in the archives?

I'd send a new message with only the parts relevant for the GHC devs (i.e. asking if they have some good GSoC project).

OK, thanks.

Johan

-- Work is punishment for failing to procrastinate effectively.