Hello Thiago, Monday, July 3, 2006, 4:18:01 PM, you wrote:
- background compilation with errors highlighting
There is already some support for background compilation using GHC. Error highlighting doesn't still work as I'd like to, but is there too.
now i'm using editor with just syntax highlighting and therefore i wrote about things those lacking are most important for me. first is the compilation. after i've compiled program i don't like to find files, go to specified line just because i'm not Ceasar and can't think about files/lines and program bugs simultaneously. why the error highlighting is a problem? GHC even supports -ferror-spans option in which emacs-style error message is printed (i.e. it includes the exact range of lines/chars what contain error) the next problem is slowness of GHC compilation. There are whole range of methods to deal with it: 1) background compilation, as you already implemented 2) fast "precompilation" with hugs and reporting bugs it encountered and then "true" compilation with ghc - of course, for this sort of scenario the program should be compatible with both compilers 3) "wide" compilation scheme - on first step compile all modules just searching for syntax errors (which should be much faster) and on the second step perform full compilation 4) using GHCi - it's a 2-3 times faster than GHC and moreover you will drop the startup time and the linking time. This also can be combined with GHC compilation - after module has been successfully compiled with GHCi and programmer continues to further develop his code, GHC can be invoked in background to recompile the modules and make them faster work / faster load in next GHCi session 5) using the GHC library to find simple errors just while editing so compilation in most cases will be successful this list contains all ideas i can recall. i personally like the last variant. of course, the compilation should still be performed in background, it just be called much less often and programmer will not wait for its completion. on the other side, for debugging, 4th variant will be more interesting i also mentioned tight integration with WinHugs. are you seen WinHugs 2006 version? are you able to see it? look at least at http://haskell.org/haskellwiki/WinHugs (Win)Hugs remains the fastest way to debug haskell programs and new WinHugs adds new pretty look and usability features to this story. one especially important one is ability to position editor just at the line containing error. It's already supported for Vim and i will be glad to see the same support for Eclipse. May be it just need adding instructions about setting up editor's call (for Vim it is "gvim.exe --remote-silent +%d %s") The almost complete support for WinHugs should include just two facilities: 1) save all, run modified files through the CPP, load module specified 2) same as above plus run the function specified (running modules through C preprocessor required because WinHugs can't preprocess modules and developing any serious program as compatible both with Hugs and GHC is impossible without conditional compilation)
- syntax highlighting, including highlighting of bracket's pair
There is already some of this too, although it may not be exactly what you have in mind.
i'm spoiled with vim-like one in FAR :)
- ability to "fall in" definition of identifier under cursor
Being worked on. Should be one of the leading features on the next release, together with some more code completion.
i does it on Vim, using modified hasktags (original one finds only functions with explicit signatures). if Eclipse supports 'tags' file, it should be relatively easy, at least for global identifiers (although field names and class methods will be out of luck in this case). what set of indexed identifiers you are plan to support?
- automatic management of import lists
Being worked on, together with code completion. I would like some more detail here, though.
if compiler complains about missing identifiers, the plugin should find module where it defined and add this module name (or this identifier if module already imported with just some identifiers) to import list. i personally keep import list splitted into two parts - global and local modules of current project, each list sorted alphabetically it will be also great to delete from import list unused modules/identifiers, but that is very low on my priority list
- auto-indenting with user-tuned style
This one seems very challenging and interesting, not a must-have for me but a very attractive feature.
You can start with indenting after lines with "special" words (such as if, when and so on). The catch is what in Haskell many "control structures" are finished on the same line they are started or just partially applied and passed as parameters to some other functions :) I personally want to see as "control structures" many functions i defined myself. It's also true for syntax highlighting - my current syntax file contains as "reserved words" the "return", "when", "forever", "block" and many other function names also i should mention that Emacs haskell mode, afaik, already does it. you can try to borrow their experience?
I have purposely left some items behind, just because resources are limited and we need to focus on some more valuable features. Do you think the ones I selected are the most valuable ones?
i tried to sort them in the importance order and for me the first 4 are most important (i often need them in my development process): - background compilation with errors highlighting - integration with WinHugs - syntax highlighting, including highlighting of bracket's pair - ability to "fall in" definition of identifier under cursor
Would you mind to delve into some more detail on the topics above on the EclipseFP mailing list? I am particularly interested on these four (in order of priority):
- ability to "fall in" definition of identifier under cursor - automatic management of import lists - syntax highlighting - auto-indenting with user-tuned style
i've said about everything except for syntax highlighting. there is no
much to say - editor i use has vim-like features, which means that
it's really great in this area. may be there is some Eclipse package
that does the same?
one feature i forgot to mention is code navigation. The structured
code navigation should, imho, include files in the project mirroring
the directory structure and on the next level each file should be
splitted to "sections". In the absence of classes splitting to
sections is widely used for the Haskell source files. For example, GHC
library sources contains the following section headings:
-- -----------------------------------------------------------------------------
-- Handy IOErrors
-- -----------------------------------------------------------------------------
-- Handle Finalizers
and so on. I personally adopted this headings style but it will be
great to just allow to use regexp to define it. And inside each
section one can see the identifiers it define
Another, unstructured view should just list all identifiers in project
and type in several chars from the identifier name to locate it in
list. It's an explanation of this very helpful feature:
my shell (FAR manager) saves all the
commands i use (now this list contains ~5000 ones!) and when i open
this list and start to type some word, it just filers whole list and
show only commands which contains this sequence of letters. that is
damn useful. just for example i open this window and typed "hugs" -
FAR filters out 146 commands which includes this word:
---------------------------- Commands history *[hugs](146/5144) --------------------------
t C:\Base\Compiler\Hugs\runhugs.exe +st.qkoOuI -98 nocmt.hs You can subscribe to our mailing list on
http://lists.sourceforge.net/mailman/listinfo/eclipsefp-develop done Are you use GHC library? Not yet, but it may turn to be a very wise decision to make in the
future. Simon said in his paper that many great features of Visual Haskell
would be impossible without GHC running in background EclipseFP is being written in Java, I wonder how the GHC
library would be accessed on such a environment. Need to take a look
at the paper. http://haskell.org/haskellwiki/InterfacingOtherLanguages#Java
--
Best regards,
Bulat mailto:Bulat.Ziganshin@gmail.com