About

This blog is about a Google Summer of Code project that aims to improve EclipseFP, the Haskell plugin for Eclipse. Read more about the blog, the author and the project in a series of three introductional posts.

Client/server communication

June 3, 2009 — Thomas ten Cate

Because of other obligations (mainly my Master’s thesis) I had a late start with this Summer of Code, but now it has really begun. Below are the first results, but first some background information.

To make Eclipse understand your Haskell source, a lot of parsing and processing code is needed. Fortunately, this code has already been written, in the form of the GHC compiler. Unfortunately, this code is written in Haskell, whereas Eclipse is written in Java. Part of the purpose of Scion is to overcome this problem. On one side, it communicates with the GHC API; on the other side, it communicates with whatever program is interested. This used to mean Emacs only, but now it also includes Eclipse!

There are essentially two ways to make Scion communicate with a non-Haskell program. One is through an intermediary C program. Haskell can call into C using FFI, and Java can call into C using JNI, so this is technically possible. However, it would be very painful and cumbersome.

The alternative is to communicate through some kind of intermediary format that is sent over a stream (say, a pipe or a socket). This is how Scion’s current Emacs frontend is implemented. When needed, Emacs launches a separate process (scion_server) that listens on a local TCP socket. Emacs connects to the socket and sends a command; the server responds in a similar, Lisp-like format. (In fact, the returned value is sent straight into the Lisp interpreter.)

To do a similar thing with Eclipse, I could either make the server speak another language that is easily parsed from Java (XML-RPC comes to mind), or make Eclipse parse the Lisp code. To get quick results, my mentor nominolo and I chose the latter route, so I hacked together some code to parse a small number of specific responses. The full Lisp parser will have to wait a day or two.

Add some code to start the server, connect to its socket, send and receive commands, and we’re all set. The screenshot below shows one of the many things that are now within reach: automatic type inference, in a tooltip, straight from Eclipse!

The current code is still full of TODO comments, lousy error handling and hard-coded configuration, but it works. At the moment it is necessary to save the file before the type information gets updated, but I hope that it will be possible to send changes to the server incrementally.

Over the next few days, I will replace my quick hacks by something better, improve the error handling, and make the whole thing more robust. And I should also really, really do something about the hard-coded absolute path that points to the Scion server in my home directory…

Like this:

Related

3 Responses to “Client/server communication”

Interesting post. In my work on the ECF remote services, I’ve been thinking about a remote ‘type inference’ service…and this sounds very similar to what you are doing.

You might be interested in the work we’ve been doing on adding support for RFC119-based distributed services to ECF 3.0/Galileo. At least you don’t have to hardcode socket code (if you don’t want to). In any event, see Getting Started with ECF’s RFC 119 Implementation

Scott, thanks for the pointer. Am I correct in deducing that this requires the server to bind to a particular port, which might conflict with other services? Also, the wiki page you link to does not mention the protocol that is used in host-consumer communication, but browsing around, I get the impression that it’s serialized Java objects. Does that mean that Java serialization will have to be implemented in Haskell…?