I seem to get this question quite a lot, so I think it might be a good idea to address it globally instead of on a per individual basis like I’ve been doing up till now.
for those who don’t know Scion it is a service that provides common functionality that editors for Haskell might need. It’s a wrapper around the GHC-API and provides a much more simplified interface to it all than the ghc-api. It implements a state for things like caching etc and works in the form of a out of process server (it runs as a separate process). It’s mode of communication with the outside world is Serialization.
Now Visual Haskell (the original ones) were written using H/Direct and FFI to communicate via a COM bridge with Visual Studio. When I first thought of this project I was planning on “just” updating the original code to the new COM interfaces of Visual Studio (2008) 2010 while also updating the GHC from the 6.6/6.8 used to 6.10/6.12 . However there were a couple of problems with this, First off it relied on internal GHC structures which have changed a lot in time and some even completely removed (the changelog mentions “this seems to not be used by anything”).
The second major problem was that Visual Studio itself evolved rather rapidly and the new interfaces were quite different. (If you want to use the new features). So I decided to rewrite it all. Start from scratch with the aim to rely less on the compiler internals but more on the interfaces it provides. I used the original paper on Visual Haskell to get started on this, In their approach they used Marshalling to read/write information directly from and to Haskell land, so I took the same route. At this point I did not know about Scion at all, and even If I did, I would have been following the route the original authors made with marshalling since I can directly pass the result of the call to visual studio by making sure the datatypes visual studio want be generated from the Haskell code.
So therein lies the first problem, Scion uses XML serialization (afaik) and I wanted Marshalling. The second problem was that the datatypes I have were tailored specifically to visual studio. Eventually I decided to drop using the COM interfaces and moved to the managed interface using C#. Because C# can handle unsafe code I didn’t have to change anything (even though I eventually did).
Then comes that whenever I add new features (while some overlap with Scion). I generate specific datatypes that I need, and that I don’t know if they would be useful to the rest of the world, hence that’s my reason for not “expanding” Scion to my needs. It needs to stay generic afteral.
Now here people say that EclipseFP uses it just fine, but their site states
EclipseFP uses Scion, the Haskell IDE library. See http://code.google.com/p/scion-lib/ for more information.
You cannot use the version from Hackage (0.1.0.2) since commands have been added for eclipsefp. From version 1.111, eclipsefp includes a modified source distribution of scion, that is built and used by eclipsefp if the use built-in server preferences option is checked. Since it is by default, eclipse might be a bit slow to start the first time scion is built. Otherwise, you’ll need to build Scion from source (git clone git://github.com/JPMoresmau/scion.git,runhaskell Setup.hs configure/build/install)
Which means that EclipseFP also uses a modified version of Scion. (which wasn’t merged back presumably for the same reasons I’m hesitant to change it).
Also when I took a look at Scion later on, I noticed that it really had one contributor, (nominolo). Now nominolo has been pretty helpful in helping me out, he seems like a pretty busy guy. So at the time I figured Scion wasn’t an active project (at least not very active). And I was not in the mood to have to contribute to another project (I already have enough as is). The last commit was somewhere in mid 2009, and it seems to have been just minor tweaks and bug fixes in 2009.
And Finally the last argument is that I wanted to learn about GHC as well. Having to write all this was a great way to learn how it does things, and that alone I think is a big enough reason for why I have not used Scion. It was also a lot of fun running into problems and having to find fixes for it. This post was not meant to be arrogant or condescending in anyway, who knows, I might back peddle one day and switch to Scion. But at this point it’s very difficult. But in order to foster the community effort behind it, I might one day commit the stuff in Visual Haskell that make sense back into Scion.
Tamar's Blog 