as mentioned earlier, I'd like to discuss the future relationship
between Cohatoe and EclipseFP with you. As you know, I started Cohatoe
at the end of last year mainly as an experiment to see if I could build
a framework that allows to implement Eclipse plugins in Haskell. The
background was of course that this would allow to re-use existing
Haskell code and libs (such as the Haskell Refactorer, or the GHC API)
and to motivate potential contributors who would contribute if they
could do it in Haskell.
Looking back, I'd say the experiment was successful: we have now such a
framework, which can run Haskell code in the form of source code or
compiled object code, and which can easily be extended to run Java
bytecode that was compiled from Haskell sources (once there is a
compiler that can do it). I've also got some enthusiastic feedback at
the Haskell in Leipzig meeting two weeks ago from people who would like
to implement extensions to EclipseFP in Haskell.
So I think we should now think about how to organize this. There are
basically two possibilities:
A - merge the Cohatoe codebase back into EclipseFP
B - leave Cohatoe separate (would need to create a new sf project or
Google code project) and use it as a dependency in EclipseFP, or at
least in some plugins in EclipseFP.
There are some pros and cons for both possibilities. Version A would
make it easier to focus users of the new Cohatoe APIs in the place where
they are probably mostly used, namely for extending EclipseFP. On the
other hand, I see some potential for Cohatoe to be useful in other areas
than IDEs, too. For instance, I have just built a user interface for a
command line app written in Haskell, which also uses Cohatoe (and the
Cohatoe examples include a sudoku solver frontend, which is also not
strictly an IDE feature ;-) So there is a good reason to have Cohatoe
small and generic and separately available.
Both possibilities involve some work effort (A - we would need some
importing and renaming, B - need to set up a new project). But these
efforts are not very big and seem no problem to me.
One question regards the project facilities (such as mailing list, issue
tracker etc.). Should we have a
- separate sf (or Google code, or whatever) project for Cohatoe, with
its own mailing list, tracker etc.
- separate Cohatoe mailing list, tracker category etc. at eclipsefp.sf.net
- just use the eclipsefp mailing list and issue tracker?
In any case, I think the best approach would be to introduce
Cohatoe-based new features to the IDE first as an independent plugin, or
perhaps in a new development milestone. As a good start we could try the
mark-occurrences implementation that I have done as a demo for the
Haskell in Leipzig meeting (however, that requires changes to
EclipseFP's Haskell editor, which must call the Mark-Occ-code).
Thanks && ciao,