I didn't mention it on my presentation of the project, but being this a project that tries to enhace the tools available to Haskell developers, and ease the work for coding in that language, I would really like to hear suggestions or critiques from Haskell developers who have used EclipseFP or any other environment to make a better work.
I think the best place to write the suggestions would be in the comment section of this entry. Thank you very much in advance :D
domingo, 29 de mayo de 2011
Week #1
In my last post I just introduced a bit the project I will be working on this summer. Of all the features I proposed, I decided to start with the Browser, because it seemed the most orthogonal to the rest of EclipseFP, and a good way to learn about Scion and Eclipse APIs.
I started with a parser for Hoogle files written in Parsec. The information was saved using several custom data types for each kind of element in the database, and serialized to disk using binary. Here I already faced some problems, mostly due to laziness in the parsing, which created a very large memory footprint, so I decided to move to cereal to make the parsing.
After that, my mentor Thomas suggested some improvements for the code. One of it was to use the haskell-src-exts (since now, HSE) package to save information about elements. That turned to be a great idea, because HSE has special datatypes for annotated syntax elements and comes with parsers for some parts of the syntax I could reuse. In that way I could rewrite the parsing of Hoogle files, getting a neater code.
I was still having some problems with memory consumption, so I've been learning about the text and bytestring packages for better string handling. I also changed from automatic derivation of Data.Serialize instances using derive to manual writing of it, in order to implement a lookup tables for common names. That cut the memory footprint a lot, because Haskell type signatures tend to reuse names (such as "a" or "b" for type variables) and a lot was gained by not creating a new instance of Type each time one appeared.
That's all for this week. Until now, I've been making the changes into a separate repository from Scion, but next week I plan to merge my work on it.
I started with a parser for Hoogle files written in Parsec. The information was saved using several custom data types for each kind of element in the database, and serialized to disk using binary. Here I already faced some problems, mostly due to laziness in the parsing, which created a very large memory footprint, so I decided to move to cereal to make the parsing.
After that, my mentor Thomas suggested some improvements for the code. One of it was to use the haskell-src-exts (since now, HSE) package to save information about elements. That turned to be a great idea, because HSE has special datatypes for annotated syntax elements and comes with parsers for some parts of the syntax I could reuse. In that way I could rewrite the parsing of Hoogle files, getting a neater code.
I was still having some problems with memory consumption, so I've been learning about the text and bytestring packages for better string handling. I also changed from automatic derivation of Data.Serialize instances using derive to manual writing of it, in order to implement a lookup tables for common names. That cut the memory footprint a lot, because Haskell type signatures tend to reuse names (such as "a" or "b" for type variables) and a lot was gained by not creating a new instance of Type each time one appeared.
That's all for this week. Until now, I've been making the changes into a separate repository from Scion, but next week I plan to merge my work on it.
Presentation
This is my first post about my Summer of Code working on EclipseFP, adding new features so that Haskell users can have a comfortable working environment inside Eclipse. I've been using EclipseFP for more than a year now (mainly for my University assignments), and I would really like it to have some of the advanced tools that Eclipse gives for Java or C. However, "adding features to EclipseFP" is a very vague statement. So in my proposal and after some mails with my mentor Thomas, I decided to work in 3 more concrete areas.
The first one, and the one I'm currently working on, is to create a Browser similar to the Java one. At least for me, that would mean an increase in productivity, because most of my Haskell programming time is spent changing from the editor to a web browser with Hackage open. With this view, I could browse the list of functions and types in a package or module from inside the environment.
When I was looking for ways to approach this, I found Hoogle. And more importantly, Hoogle maintains a complete index of the documentation of the latest version of every package in Hackage. So I'm going to use that information to provide developers a way to browse, inside the environment, the entire world of Haskell. That also means that when providing some interface for adding dependencies to Cabal projects (see below), we can also show the list of available Hackage packages.
The second feature to implement is some way to run unit tests, and show the statistics about passing and failure, much alike to JUnit tests in Java. The interface is going to be indeed very close to JUnit's integration in Eclipse, but I still have some open problems on getting the list of tests to run. The best option now seems to use Cabal's Test Suite support, although I was not able to find the "connectors" for QuickCheck and HUnit in Hackage.
The third feature I have in mind is to enhace the visual editor for Cabal files. Currently, it allows to change author, name and some other package metadata, but does not handle dependencies, build options or targets. My idea is to create something similar to the Cabal editor of Leksah, but as I said before, enhaced with metainformation I could get from Hackage.
Apart from this, there are lots of places to work. For example, having a database of function names allows to create "automatic imports" as the Java editor does, or provide better autocompletion. Refactoring support would be a great addition to the IDE. But all of this is just to much for a single summer...
The first one, and the one I'm currently working on, is to create a Browser similar to the Java one. At least for me, that would mean an increase in productivity, because most of my Haskell programming time is spent changing from the editor to a web browser with Hackage open. With this view, I could browse the list of functions and types in a package or module from inside the environment.
When I was looking for ways to approach this, I found Hoogle. And more importantly, Hoogle maintains a complete index of the documentation of the latest version of every package in Hackage. So I'm going to use that information to provide developers a way to browse, inside the environment, the entire world of Haskell. That also means that when providing some interface for adding dependencies to Cabal projects (see below), we can also show the list of available Hackage packages.
The second feature to implement is some way to run unit tests, and show the statistics about passing and failure, much alike to JUnit tests in Java. The interface is going to be indeed very close to JUnit's integration in Eclipse, but I still have some open problems on getting the list of tests to run. The best option now seems to use Cabal's Test Suite support, although I was not able to find the "connectors" for QuickCheck and HUnit in Hackage.
The third feature I have in mind is to enhace the visual editor for Cabal files. Currently, it allows to change author, name and some other package metadata, but does not handle dependencies, build options or targets. My idea is to create something similar to the Cabal editor of Leksah, but as I said before, enhaced with metainformation I could get from Hackage.
Apart from this, there are lots of places to work. For example, having a database of function names allows to create "automatic imports" as the Java editor does, or provide better autocompletion. Refactoring support would be a great addition to the IDE. But all of this is just to much for a single summer...
Suscribirse a:
Entradas (Atom)