EclipseFP (Haskell IDE) 0.9.1 released

EclipseFP 0.9.1 has been released since last Friday. It is an open-source development environment for Haskell code. EclipseFP integrates GHC with an Haskell-aware code editor and also supports quick file browsing through an outline view, automatic building/compiling and quick one-button code execution. Downloads and more information are available on the project home page http://eclipsefp.sourceforge.net/ We are open for comments and general discussion. Actually we would really appreciate comments from both newbie and veteran Haskell programmers. This is open-source development and everyone on the Haskell community is welcome to participate. Cheers, Thiago Arrais

Thiago Arrais wrote:
EclipseFP 0.9.1 has been released since last Friday. It is an open-source development environment for Haskell code.
EclipseFP integrates GHC with an Haskell-aware code editor and also supports quick file browsing through an outline view, automatic building/compiling and quick one-button code execution. Downloads and more information are available on the project home page
http://eclipsefp.sourceforge.net/
We are open for comments and general discussion. Actually we would really appreciate comments from both newbie and veteran Haskell programmers. This is open-source development and everyone on the Haskell community is welcome to participate.
More of a meta-comment than a comment... [I should say that I haven't yet actually tried this software, though I'd like to do so when I get some time.] One of the features of Haskell that I like is that it doesn't require lots of IDE support to write complex programs... the compact syntax and clean separation of concerns that can be achieved make it iasy enough to program using nothing more than a regular text editor, and no long wait for the development environment to start up. I can imagine programming Haskell on a palm-top device. So is there a compelling feature in this Eclipse plugin that isn't easily achieved using simpler tools? (Please don't take this as a negative response to your efforts -- I can imagine things that would really help Haskell development based on this kind of framework, such as features in quickly inspect intermediate results in complex programs without visible recompilation, and instrumentation of intermediate results for creating regression tests, though I don't know how such might be provided.) #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact

On Wed, 2006-02-01 at 13:21 +0000, Graham Klyne wrote:
Thiago Arrais wrote:
EclipseFP 0.9.1 has been released since last Friday. It is an open-source development environment for Haskell code.
EclipseFP integrates GHC with an Haskell-aware code editor and also supports quick file browsing through an outline view, automatic building/compiling and quick one-button code execution. Downloads and more information are available on the project home page
http://eclipsefp.sourceforge.net/
We are open for comments and general discussion. Actually we would really appreciate comments from both newbie and veteran Haskell programmers. This is open-source development and everyone on the Haskell community is welcome to participate.
More of a meta-comment than a comment...
[I should say that I haven't yet actually tried this software, though I'd like to do so when I get some time.]
One of the features of Haskell that I like is that it doesn't require lots of IDE support to write complex programs... the compact syntax and clean separation of concerns that can be achieved make it iasy enough to program using nothing more than a regular text editor, and no long wait for the development environment to start up. I can imagine programming Haskell on a palm-top device.
Indeed, this is probably why there has not been so much demand for an IDE for Haskell as there is for other languages. It's not so hard coding in Haskell that we really need lots of tool support. Our motivation in starting the hIDE project (not the same as this EclipseFP) is not to create new tools but to tie existing tools together to make the way we program now that bit quicker. We're not trying to tie you down with auto-generated code or non-standard build tools. Apart from the basics of an editor with accurate syntax highlighting we can get integrated syntax and type errors. We can automate building with cabal. We can get jump to definition, jump to documentation. Such an IDE would also be ideal to plug in existing refactoring and debugging tools. Then there is the fact that not all Haskell programmers are comfortable with editors like emacs or vim. Fortunately using an IDE is optional. Duncan

2006/2/1, Graham Klyne
[I should say that I haven't yet actually tried this software, though I'd like to do so when I get some time.]
I really hope you find the time to do so. We would be glad to be hearing from you again.
One of the features of Haskell that I like is that it doesn't require lots of IDE support to write complex programs... the compact syntax and clean separation of concerns that can be achieved make it iasy enough to program using nothing more than a regular text editor, and no long wait for the development environment to start up. I can imagine programming Haskell on a palm-top device.
Very interesting idea. One that I have thought of some time ago. I wasn't thinking of Haskell, but Ruby instead. The idea is the same, but that's another thread. Every language experiences kind of a wave. At the time it is created, there aren't many tools. The early adopters work most of the time using a compiler/interpreter and a text editor. Then the wave starts to form. This is the time the second generation of tools start to flock. They are the test frameworks, the build automation tools and others. At some point of the wave, the integrated environments appear. They come, as the name says, to integrate the previous tools in an easy to use and productive environment. Not that the previous tools were hard to use or counter-productive, it is just that by integrating them much time is saved from the details and the programmer can spend more time on the creative and useful things only he can do.
So is there a compelling feature in this Eclipse plugin that isn't easily achieved using simpler tools?
When we write an Eclipse plugin, we get a lot of things for free. Just
to cite one, there is already CVS integration support within every
Eclipse installation, which includes a very neat diff viewer. Adding
support for other version control systems isn't very hard. There are
plugins, for example, for Darcs and Subversion too.
Another very nice feature of the Eclipse platform is the refactoring
support. Wouldn't you like to refactor your Haskell code as easily as
selecting some context-menu item? Not to mention code assistance and
'go to declaration support' (click a module/function/whatever
reference and open its corresponding declaration). This has saved me a
lot of time when browsing code.
Of course, you need to write the code to tell the platform about your
language. That's what the EclipseFP team is trying to do.
There is one issue, though, that touches a lot of sensitive areas. The
Eclipse platform runs inside a Java Virtual Machine. Unfortunately,
there isn't currently a way to compile Haskell to the JVM (at least I
don't know of any, if someone knows, please let me know). This means
the IDE has to be written in Java, not in Haskell. That's the price we
are paying now. Writing a tool for a language in a different language.
2006/2/1, Duncan Coutts
Fortunately using an IDE is optional.
And should always be. An IDE should never be the only way to build things in any language. And the existing IDEs should always be backward compatible with the previous tools. They should not, for example, generate unreadable code or use any vendor-specific format. Cheers, Thiago Arrais

Thiago Arrais wrote:
There is one issue, though, that touches a lot of sensitive areas. The Eclipse platform runs inside a Java Virtual Machine. Unfortunately, there isn't currently a way to compile Haskell to the JVM (at least I don't know of any, if someone knows, please let me know). This means the IDE has to be written in Java, not in Haskell. That's the price we are paying now. Writing a tool for a language in a different language.
Ah, now there's a thing! I don't have any good answers, but I have a friend who is interested in such things, and may even be looking for a project in this area. In our discussions, a number of links came up, but I'm not sure if I can find them all. Here's an attempt: http://www.xoltar.org/languages/nice.html http://www.pugscode.org/ http://scala.epfl.ch/index.html Nothing very specific to your ideas goal, but there's some work on compiling functional code to JVM. I was also talking to someone from Cambridge Comlab the other week who has an FP-like system (for web service/portal creation) that uses JVM bytecode modification. maybe some useful experience to draw upon there? I'm also reminded of a project I was in discussion about some time ago, which was to explore use of Haskell program transformation techniques (hopefully adapting some ideas from BMF/Squiggol) for implementing aspects of a JIT runtime for JVM. Unfortunately, that never took off (and was maybe too ambitious for the effort contemplated). There is some related work at the kestrel Institute [http://www.kestrel.edu/home/projects/] #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact

Hello, I stumbled upon your discussion on haskell-cafe and this theme seems to pop up one time or another. If someone is interested, I have some Java code for compiling Haskell98 to bytecode that I would be more than willing to share. It is not in the best shape and does not implement all of haskell but most low-level work to generate classes and bytecode from haskell code is implemented (patternmatching, data constructors, lazy functions, ...). This is a project I started some years ago and used for specification of simple functional behaviour (without complex type system) in Java. Regards, -- Arnaud Bailly, Dr. - Ingénieur de Recherche NORSYS 1, rue de la Cense des Raines ZAC du Moulin 59710 ENNEVELIN Tel : (33) 3 28 76 56 76 Mob : (33) 6 17 12 19 78 Fax : (33) 3 28 76 57 00 Web : http://www.norsys.fr

Hi,
up one time or another. If someone is interested, I have some Java code for compiling Haskell98 to bytecode that I would be more than willing to share. It is not in the best shape and does not implement
You might also be interested in: http://www.brianweb.net/personal/blog/entry.php?id=18 Currently this is only a runtime, which allows running full Haskell in a JVM. A bytecode translator was being worked on, although I don't know the progress that has been made recently. Thanks Neil

Questions about Haskell for JVM or .NET was asked quite often and it
is really interesting question. Since the JVM and .NET machines have a
lot of common if there was a compiler for one of them then it can
retargeted to the other quite easily. The major problem with such
compilers is the performance. Many attempts exists but no one has
managed to build a complete solution. There are several major
problems:
- How to represent the G/STG machine stack in JVM/.NET? The naive
solution is to use an array but it is proven to be inefficient.
- How to minimize the runtime typecasts? They are necessary because
the JVM/.NET type system is a lot weaker than the Haskell's one.
- How to efficiently represent the IO monad and exceptions?
- How to make the integration of Haskell with Java/C# easier?
Since usually the performance of all VM languages is worse than those
of the native compiled (C/C++), I think that it is acceptable for
Haskell for JVM/.NET to be slower than GHC for example. Even that if
the performance isn't so worse then it will be usable since it can be
used in existing Java/.NET projects.
Cheers,
Krasimir
2006/2/2, Arnaud Bailly
Hello, I stumbled upon your discussion on haskell-cafe and this theme seems to pop up one time or another. If someone is interested, I have some Java code for compiling Haskell98 to bytecode that I would be more than willing to share. It is not in the best shape and does not implement all of haskell but most low-level work to generate classes and bytecode from haskell code is implemented (patternmatching, data constructors, lazy functions, ...). This is a project I started some years ago and used for specification of simple functional behaviour (without complex type system) in Java.
Regards,
-- Arnaud Bailly, Dr. - Ingénieur de Recherche NORSYS 1, rue de la Cense des Raines ZAC du Moulin 59710 ENNEVELIN Tel : (33) 3 28 76 56 76 Mob : (33) 6 17 12 19 78 Fax : (33) 3 28 76 57 00 Web : http://www.norsys.fr
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hello Graham, Wednesday, February 01, 2006, 4:21:02 PM, you wrote: GK> So is there a compelling feature in this Eclipse plugin that isn't easily GK> achieved using simpler tools? it's a list of what-i-want-from-the-IDE: * autogeneration of prototypes * auto-adding import statements * adding/removing function from the export list * background compilation with parsing error messages * switchable compilation types (optimized, profiled...) * context help * expression evaluation in context of my program's definitions * "sjow me the Core for this function" * project support (i.e. show list of all files in this project) * type-based function hierarchy browsing * auto-indenting * syntax colouring, folding, brackets matching, jumping to function definition (these things are already in vim) -- Best regards, Bulat mailto:bulatz@HotPOP.com

Bulat Ziganshin
it's a list of what-i-want-from-the-IDE:
I already use an environment that integrates Xemacs, GHC, GHCi, and Make, and it's called /bin/zsh. I've used it (or something very similar) for over ten years, so anything else would take some getting used to. I could be convinced to switch, though.
* auto-adding import statements * adding/removing function from the export list
Automatic import/export management would be nice. Similar with type signatures; I often modify some code, and forget to update the signature and/or export/imports. A good IDE could at least highlight any issues. And while the compiler will catch these, it often has problems pinpointing the problem (it could be an error in the function, it's type signature, or the type signature of some called function, etc) - and IDE will know which function you're editing, and flag the error the moment it is introduced. Also, the IDE could display the inferred types, of course.
* autogeneration of prototypes
It would be nice to have undefined function defined to be undefined :-) I.e. you can run the code, and have it halt when a missing function is required. Ideally, you should supply the code at that point, and move on (one less bragging point for the Lisp crowd), but I can live with a restart.
* context help * type-based function hierarchy browsing
Some integrated (library) search facility would be good, using types and Haddock. I would like to write (e.g.) quickcheck tests, without having them clutter up the code proper. I'd also like to have call-graph analysis, from simple "show me callers of this function", to suggestions about moving functions across modules. * "show me the Core for this function" Optimization support would be really nice, displaying the strictness and boxedness of function parameters, for instance. Or profiling integration that highlights functions/call points that consume much time and/or space. And, one final thing, I need Emacs-type key bindings. This is the only thing that is entirely non-negotiable. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants

Bulat Ziganshin wrote:
Hello Graham,
Wednesday, February 01, 2006, 4:21:02 PM, you wrote:
GK> So is there a compelling feature in this Eclipse plugin that isn't easily GK> achieved using simpler tools?
it's a list of what-i-want-from-the-IDE:
Aha, thanks. By way of feedback, here are my personal reactions to these features:
* autogeneration of prototypes
I don't know what you mean by this.
* auto-adding import statements
Handy (i.e. I like the feature, but I'm not sure I'd fire up Eclipse to get it)
* adding/removing function from the export list
Handy
* background compilation with parsing error messages
Handy
* switchable compilation types (optimized, profiled...)
Useful - in preparing production systems, I probably would use Eclipse for this
* context help
Very nice - might persuade me to use Eclipse routinely (I assume you mean things like getting help about functions, esp. prelude and standard libraries)
* expression evaluation in context of my program's definitions
Very nice.
* "sjow me the Core for this function"
Not something I'd use often, but I can see its value.
* project support (i.e. show list of all files in this project)
Hmmm... I sort-of get that with my text editor. But I agree that exploiting the Eclipse file hierarchy browser would be handy.
* type-based function hierarchy browsing
Very nice. I assume this allows functions to be located from type signatures, including prelude and standard libraries.
* auto-indenting * syntax colouring, folding, brackets matching, jumping to function definition (these things are already in vim)
These are handy to have, but as you indicate don't need a full IDE support. ... In summary, I think there's enough there to make me think seriously about using Eclipse for Haskell development, at least some of the time. Something I'd also like is in-editor warnings of features that are not supported uniformly across different implementations -- my (rough) criteria for "portable Haskell" has been to check that code runs with GHC and Hugs. Also, some form of integrated testing support would be nice. There was brief discussion here some time ago about something like assert statements that could be checked at compile time -- if you have in-context expression evaluation then this wouldn't be a great leap: e.g. scan the code for identifiable expressions that are expected to be true, and report warnings if they are not. When I get back to some Haskell coding, I must try out your package. Thanks! #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact

Hello Graham, Thursday, February 02, 2006, 1:15:44 PM, you wrote:
GK> So is there a compelling feature in this Eclipse plugin that isn't easily GK> achieved using simpler tools?
it's a list of what-i-want-from-the-IDE:
* autogeneration of prototypes GK> I don't know what you mean by this.
adding type signatures of functions to module. this can be done by loading module into the hugs/ghci and using ":t"; or by the programmatica tools, afair
* context help GK> Very nice - might persuade me to use Eclipse routinely (I assume you mean things GK> like getting help about functions, esp. prelude and standard libraries)
yes. btw, if you need it, you can use hasktags with a vim/emacs. it allows you to jump right to the fucntion definition, which is more informative and anyway typically contains text for the haddock. vim even can show this function definition in the supplementary window without jumping to it
* type-based function hierarchy browsing GK> Very nice. I assume this allows functions to be located from type signatures, GK> including prelude and standard libraries.
seems that we say about different things. IDEs for OOP languages show program hierarchy around the defined classes, that is unuseful for Haskell. nevertheless, many functions typically grouped around types they "support". so, a "module->type->function" view and "type->function" view should be handy GK> In summary, I think there's enough there to make me think seriously about using GK> Eclipse for Haskell development, at least some of the time. sorry, i said about ideal IDE, not about Eclipse (what i never seen, after all). and of course i'm not the author of this package. sorry :))) GK> Something I'd also like is in-editor warnings of features that are not supported GK> uniformly across different implementations -- my (rough) criteria for "portable GK> Haskell" has been to check that code runs with GHC and Hugs. one thing that i skipped in my dream list is on-the-fly syntax checking GK> Also, some form of integrated testing support would be nice. There was brief GK> discussion here some time ago about something like assert statements that could GK> be checked at compile time -- if you have in-context expression evaluation then GK> this wouldn't be a great leap: e.g. scan the code for identifiable expressions GK> that are expected to be true, and report warnings if they are not. good idea. i think that i should place all our stuff at the "IDE/Ideal" wiki -- Best regards, Bulat mailto:bulatz@HotPOP.com

"Graham Klyne"
One of the features of Haskell that I like is that it doesn't require lots of IDE support to write complex programs... the compact syntax and clean separation of concerns that can be achieved make it iasy enough to program using nothing more than a regular text editor, and no long wait for the development environment to start up. I can imagine programming Haskell on a palm-top device.
I do that on my PDA phone sometimes, usually when I'm having a coffee with some buddy discussing this or that algorithm :) Thanks to whoever ported Hugs for Windows CE (I don't remember the url now)
participants (9)
-
Arnaud Bailly
-
Bulat Ziganshin
-
Duncan Coutts
-
Graham Klyne
-
Ketil Malde
-
Krasimir Angelov
-
Neil Mitchell
-
Pepe iborra
-
Thiago Arrais