SURVEY - Haskell editing (summary)
Claus Reinke
claus.reinke@talk21.com
Tue, 6 Aug 2002 22:47:41 +0100
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.