As promised, here comes the summary of our survey results. Given the low number of responses, it is more anecdotical evidence than representative statistics, but thanks to the individual comments, it will be helpful for our project, and some of you may find the summary interesting. As everyone was invited to contribute, we'll assume that we've got the confessions of those Haskell hackers who care!-) Thanks to everyone who contributed, Claus "Refactoring Functional Programs" http://www.cs.ukc.ac.uk/research/groups/tcs/fp/Refactor/ ----------July 2002-----(summary)-------- SURVEY - Haskell editing In total, we got 45 responses. Not every response addressed all questions, and often there were several answers per response and question. So there's no summing up of sensible percentages, but the variety of answers (the questions only outlined possible answers, thus inviting keyword-style, but otherwise free-form responses), and some clear tendencies -amid the small selection of responses we got- are interesting. The following summary roughly lists each answer together with the number of times it was mentioned in different responses, sometimes accompanied by typical comments. Editor comments, based on summaries of the survey responses, follow in separate sections after each question/answer block (the editor's response is not included in the survey). [Proportional font won't be a good idea for the following] --------------------------------- 1. When developing Haskell programs, ----------------------------------- which OS-platforms do you work on? Linux: 43 (2.2/2.4,redhat 6.1/7.1/7.2, debian testing/unstable/woody, mandrake) Solaris: 17 SunOS: 3 Windows98: 1 Windows2000: 3 Win32: 2 Cygwin: 2 FreeBSD: 5 MacOS X: 3 IRIX: 1 --Comments Unix-style operating systems clearly dominate here, even more so since many of the non-unix entries stem from multi-OS developers, who use some variant of unix or windows as their main development platform, and several other OSs for production, to test portability / compatibility, or just because of their working environments. Given the small number of survey responses, one should keep in mind that this indicates a bias in the responses that may or may not reflect the overall situation of Haskell developers. --- which Haskell implementations are you using (please indicate rough --- version info: "whatever", "latest source release", "latest binary --- release", "latest CVS", "latest stable version", ..)? GHC: 40 (own experimental branch, latest stable, latest rpm, 5.02.2,5.02.3,5.04 binary, latest binary, latest CVS (occasionally), latest, latest source release, latest from debian unstable) Hugs98: 33 (dec 2001, nov 2001, feb 2001, may 1999, latest binary, latest stable, latest, latest source release, latest CVS, latest from debian testing/stable, whatever) nhc98: 12 (1.14, latest binary, latest stable, latest CVS, latest source release) hbc: 1 (0.99995b, 1999 apr 02) --Comments The distribution itself is not unexpected. A small number of programmers use only a single implementation (GHC or Hugs). The majority seems to combine two or even all three of the currently maintained implementations, mostly for specific advantages of Hugs or nhc. Although GHC seems to be catching up with its latest releases, trying to be the one tool for all purposes, advantages mentioned include: quick prototyping and scripting use via runhugs (Hugs), profiling, tracing, debugging (nhc). Depending on the quality and completeness of improvements in these areas in forthcoming GHC versions, a few programmers indicate that they might reduce their use of other implementations. Another advantage mentioned in favour of multiple implementations is security from redundancy and variety: getting alternative "opinions" and diagnostics on obscure errors and avoiding inadvertent use of non-portable features. However, the differences in supported features are also mentioned as a disadvantage, making it difficult or impossible to take advantage of other implementations and their strengths. Use of latest stable source/binary releases dominates over the use of latest experimental/CVS versions. ------ to what extent do you use (which?) features outside Haskell 98? None: 8 (plus several who only use FFI, or what external libraries require) Multiparameter type classes: 20 Existential types: 15 FFI: 10 Functional dependencies: 9 rank-n polymorphism: 7 (sometimes, just n=2) Hierarchical module system: 4 HsLibs: 2 Hierarchical libraries: 2 Overlapping instances: 5 Class/instance-restrictions: 4 GHC state threads: 3 Implicit parameters: 3 Undecidable instances: 3 Pattern guards: 2 Unboxed types: 2 Exceptions: 2 Concurrency: 3 Dynamic types: 1 Monad comprehensions: 1 TREX: 1 -fglasgow-exts: 1 unsafePerformIO: 1 --Comments A substantial part of respondents would favour programming within the limitations of Haskell 98, if only for being able to use all of the available implementations and the complementary tools they offer. The main exceptions are multiparameter type classes, explicit existential and universal quantification, functional dependencies, and the new foreign function interface (the latter now being an official addendum to the standard). Another frequent comment concerns the need to use libraries beyond the standard (hugs/ghc-libs, hslibs, now the hierarchical libraries), and thus whatever advanced features those might depend on, emphasizing the urgency of convergence of Haskell implementations in this matter. Other features are used (or mentioned?) less frequently, although this might be a matter of unnoticed use of non-standard features (e.g., the low number of responses mentioning lifted class/instance-restrictions seems to be at odds with the high numbers mentioning multiparameter classes and functional dependencies). One answer suggested that removing advanced features after prototyping would lead to production code that is easier to understand and hence easier to maintain and debug later. ------- what editors, IDEs or source-manipulation tools are you using? -------------------------------------------------------------- editors Emacs 21 XEmacs 11 Vim/GVim 8 Vi 3 NEdit 4 BBEdit 1 -------------------------------------------------- tag-file generators None 39 (didn't know about it, will check, xemacs menu) HaskTags 3 fptags 1 custom 2 (etags) --------------------------------------------- documentation generators None 30 (will use, can't use [CVS ident conflicts, browser dependency]) Haddock 7 hdoc 1 IDoc 1 literate prg 3 (haskell.sty, lhs2TeX) LambdaTeX 1 a2ps 1 custom 5 ------------------------------------ pre-processors/program generators None 28 (try to avoid) cpp 12 (debugging, porting) DrIFT 6 strafunski 1 PolyP 1 GreenCard 2 c2hs 2 hsc2hs 1 happy 1 utrecht AG 1 (attribute grammar system) HaXml 1 hat-trans 1 m4 1 custom 3 ----------------------------------------------------- revision control None 4 CVS 30 (better alternatives sought..) manual 9 RCS 4 PRCS 2 Subversion 2 VCS 1 ------------------------------------------------ dependency generation custom 1 (to avoid too frequent recompilations by standard Haskell make tools) --Comments The editors in use are not nearly as varied as expected (which might be another indication of a bias in the sample of responses). The indication of the top ranks (emacs variants, followed by vi variants) is not unlikely, however. The single most frequent comment regarding tag-file generators is roughly "now that I know about this, I'll check it out". The single most frequent comment regarding documentation generators is roughly "don't use them yet, will do in future", with a clear tendency (of planned and existing use) towards Haddock (one response mentioned problems with CVS identifiers and browser dependencies currently preventing use of this tool though). There seems to be a variety of custom-made solutions as well. The single most frequent comment regarding preprocessors is "I try to avoid them", and almost two third of the respondents seem to manage to do so. Unfortunately, the single most frequently used preprocessor is also the least favoured: cpp. The main reasons given are conditional compilation for debugging and porting - perhaps it is time to standardize Haskell-specific variants of these features? cpp is followed in frequency by tools supporting generic programming, an ongoing focus of research, and tools supporting the use of Haskell's FFI. Again, there are several custom-made tools in use, one respondent mentions an inhouse Haskell preprocessor hpp. As far as revision control is concerned, CVS is clearly the most used variant, but it is not necessarily the most loved one. Several answers commented on an ongoing search for better alternatives. --------------- 2. To what extent are your editors/IDEs Haskell-aware? ------------------- what Haskell-specific functionality do they offer? none/haven't tried/don't use it 9 syntax highlighting 34 (sometimes confused; lacks support for language extensions; some features could be different; also used for printouts) pretty-printing 18 (or simple auto-indenting; problems with different layout styles?; often sluggish) tag-files 12 haskell mode 11 (could be significantly improved, sometimes wrong when it tries to be smart) syntax-aware movements 9 display (declared) function types 5 (should not be limited to declared types, nor to fixed set only) inserting inferred types 1 (custom solution) GHCi integration 3 GHCi/Hugs session in separate window 3 scan declarations and put them in menu 1 editor integration in Hugs :find/:edit 1 (find definition, edit next error) keyboard shortcuts/mappings 1 --Comments It is slightly surprising that a substantial number of Haskellers don't use Haskell-specific functionality in their editors, especially since almost all editors mentioned offer support for language-specific customization. One reason might be that editor customization is an art in itself (both the emacs and vim manuals are already quite daunting in size and tend to grow faster than most users learn new features, and this is "only" the editor), but it takes only a few hackers to do the customization for each editor, so there have to be other factors. Specific factors mentioned include "haven't looked yet", "don't know what else it can do", "I use this or that haskell-mode, which probably does a lot of the things you mention, but I haven't used those yet" and also "I tried this or that haskell-mode, but wasn't happy with it, so I don't use [it | most of it's features]". There are definite gaps between features available, features known, and features used or wanted. Apart from releasing private customizations (emacs users are ahead in this), more documentation (how to find out about Haskell-specific editing functionality if you don't have the editor or Haskell-mode installed yet?) and communication (what is it you'd like to be able to? what do you think is wrong with the current Haskell-modes?) seem to be called for. The widely used syntax highlighting (note though that not everyone uses even this feature) shows that Haskellers are willing to use customised features, if they are easily available and easy to use, even though there are some problems even with this feature (mostly because it is typically not based on proper parsing). Many features are rather more basic than most users would like. Pretty-printing (semi-automatic layout) and language-sensitive movement/selection are the most often mentioned features, with semi-automatic layout seeming especially problematic. Not all that many Haskellers seem to count the typical "bug-spotting" integration (try to compile, then jump to first error position) as important, only one response mentioned the editor integration in Hugs. --------------- what non-Haskell-specific editing functionality do you --------------- find most helpful when developing Haskell programs? none/don't know 3 matching of parentheses 28 macro recording and playback 12 (small, repetitive tasks that don't warrant a script; adding fun args, creating large aggregate data structures; reformatting code; add/remove {- -}; consistently rename families of functions, or change constructor representations) integration with external tools 10 (ghci, hugs, make&jump to error, shell, directory editor, spell checkers, email, text filters, RCS, CVS) search&replace with reg.exprs 7 autocomplete 4 tags/jump to definition 2 editor scripting 2 insert/cut/paste rectangle 2 grep 1 justification of comments and text 1 line/column numbering and finding 1 abbreviations 1 filetype dependent key bindings 1 diff mode 1 syntax highlighting of LaTeX in .lhs 1 --Comments The small number of "don't know" entries in this section is slightly misleading as a large number of Haskellers seem to use little more than matching of parentheses, and a few find even this less useful than in C or Java (thanks to layout, and less noisy syntax), or don't think their editor supports this feature (IIRC, all editors mentioned here do). The emphasis on using external text-processing tools from within the editor is probably typical for the unix bias in the survey responses, but beyond macro recording&playback and search&replace, only limited use seems to be made of more advanced editor-internal features (which are, after all, what distinguishes the "programmer's editors" from your basic notepad, and are often supported across platforms). Again, that might be a consequence of the unix tool chain, but not all editing functions are conveniently replaced by delegating them to external tools (sed notwithstanding;-). ---- what Haskell-specific editing functionality do you you miss most? don't miss it (because I never had it in a form I'd want to use) 6 display type of function at cursor/ query type of things 7 (also show comments and :info) integration with Haddock, Haskell98/Lib report and haskell.org info 2 (extended :info) finding types in modules that don't type-check completely 2 incremental syntax/type checking 3 integration with TypeView 1 (http://www-users.cs.york.ac.uk/~olaf/PUBLICATIONS/typeview.html) better auto-indenting 10 (without explicit braces/ semicolons; maintain layout against changes of identifier lengths, both interactively and during search&replace; configurable to personal style; re-align at "=") switch between braces/semicolon-style and layout-style for marked block 2 (to maintain layout during complex edits: switch to explicit braces style, edit, switch back to layout style) editor support for layout rule 1 (colouring hints for potential layout problems?) better syntax highlighting 1 find callers to function/occurrences of identifiers/show call graphs 3 (custom scripts; avoid costs of compilation?) class browser 1 module browser/function finder 2 rename identifier and all uses, handling syntax, scopes, and kinds correctly 4 (likely to mess up formatting, and automatic indentation may not be what you want; should work for all kinds of identifiers) proper (haskell-based, not lisp-based) syntax-sensitive movement/selection 2 scope-aware tags function 1 (find the def that will be used, not just any global one) change order of parameters at definition and all call sites 1 change type of constructor and all uses 1 (http://cs.oregonstate.edu/~erwig/papers/{hula.pdf,uc.pdf}) extend data type and all uses 1 moving definitions between local and global scopes 1 splitting/joining modules 1 extract function and replace repeated bodies by calls to new function 1 (also for type synonyms) support for refactoring (either do it, or prove it correct) 1 autocomplete 1 "locate bug" feature 1 (really!-) debugger integration, breakpoints, .. 1 integration with profiling tools 1 "Proof General"-style interface 1 (http://www.proofgeneral.org) toolbar/sidebar for Haskell 1 writing editor modules in haskell 1 KDevelop Haskell mode 1 (kdevelop-devel@kdevelop.org) don't always treat identifiers as single words for editing operations 2 jump to definition/documentation 1 function folding 1 --Comments Again, there's a small number of "happy as it is?" users. Interestingly, most of these comment that they've tried the existing features and haven't found them convincing in their current form. And indeed, many wishes are about better versions of current features. Item number one on the wish list is easy access to more information about the items currently edited. For completeness, it should be mentioned here that (some of) the emacs Haskell-modes already support (limited) versions of this, which not all respondents seem to be aware of. However, most answers pointed out limitations in the existing systems (should work for functions without declarations, and not be limited to fixed set of functions; should work incrementally and in only partially type-correct modules), or opportunities for improvements (offer to show :info and comments as well; integration with documentation tools and with standards documents). Next on the list comes more useable support for semi-automatic layout. Finding uses of identifiers (as opposed to finding definitions) would be a popular feature, and extends to call graphs and class/instance- and module-hierarchy browsers. Renaming of identifiers (of all kinds) and their uses, properly respecting Haskell syntax and scoping, and without inadvertently messing up layout, is beyond simple search&replace, and the first refactoring on the list of suggestions. It is followed by a list of other typical refactoring-style editing operations proper support for which would require syntax-aware tools. Integration with other Haskell-specific tools, profilers, tracers and debuggers specifically, would be more interesting now that such tools actually exist. One response pointed out that between general text editing and Haskell-specific functionality there is a range of language-independent operations that could be supported by integration with AST-based tools, referring to www.program-transformation.org. ---------------- what interface options does your editor/IDE offer for ---------------- integration of external tools (brief explanations or ---------------- pointers to detailed documentations would be great)? --Comments This question was a last-minute addition to the survey, and while it caused a lot of confusion, it didn't actually produce any useable answers (beyond the answers to previous questions). The idea was not so much that I expected everyone to work on extending his/her favourite editor for day-to-day editing tasks. Rather, I was hoping for some pointers to information about how tools like our envisioned refactorers could be intergrated into your favourite editors. Given the surprisingly small spread in editors used, the lack of answers here isn't much of a problem - just making sure that our tools can be integrated into emacs and vim should be a good enough start.