Haskell Programming Environment

[C.Reinke]

> One of the emacs modes for Haskell gives the type of the identifier
> the cursor is in in the modeline.  It does this by examining the type
> signatures in the current file, and having the prelude type signatures
> built-in.  This is quite helpful, if incomplete, and fairly easy to
> implement.

Similar shortcuts are possible for other aspects, and might help
to produce something useful within the constraints of an MSc project.
Finding a reasonable compromise between producing something for an
MSc and producing something that will remain in use and that others
could build on later would be the first challenge, I think.

Personally, I couldn't care less about yet another non-portable
IDE demo bound to one specific, non-standard, smallish editor 
and one specific graphics library with one specific OS. It might 
get a small user base, but is likely to be out of date before it 
can grow to a functionality that could attract more users. But 
that's just my personal opinion..

The results of this survey and your own thoughts about what
the specific issues in a Haskell Programming Environment might
be, what functionality should be provided, and how, have a 
greater likelihood to be of lasting value.

If you want to produce anything "real", you will want to reuse
the language knowledge built into existing implementations. If you
then want to remain portable, a good route would be to define an
interface between the HPE and some Haskell implementation, 
specifying exactly which functionality the HPE would want to 
access, and how.

Examples:

 - syntax-awareness. Experience with syntax-directed editors shows
   that users don't like to be locked into the syntax, they want
   some leeway for errors in intermediate stages. Also, many 
   programmers don't want to drop their favourite, productive, 
   proven and portable editor for the ones built into IDEs. Still, 
   the editor should be aware of the syntax of the current language
   (those regular-expression-based syntax-highlighters are nothing
   but a stop-gap measure). Having a standard interface to the
   implementation's parser (where is the next subexpression?
   where is next enclosing context? where and what is the next
   syntax error?..).

 - scope&type awareness. A natural extension of the above with 
   an interface to the implementation's symbol table (where is
   the binding occurence for this variable? what the type of
   this expression? what are the constructors/class instances
   for this type? which identifiers with which types are exported 
   from this module?..)

 - other language-specific interactions. (evaluate current 
   expression in current environment; browse module graph; 
   browse class graph; compile&run; instrument for debugging;..)

Have a look at the functionality provided in Hugs and try to
define an interface that could support that functionality from
within a standard editor, without being dependent on Hugs. 

There used to be an idea of having a more modular Haskell 
implementation with interfaces between all parts, including an 
interface between Hugs-like frontend and background compiler 
and runtime system (part of the Haskell Execution Platform, HEP;-). 
That got rescheduled to low priority, but might still be a useful 
starting point (http://www.haskell.org/ghc/docs/papers/hep.ps.gz).

Of course, that would be only one side of a modular HPE. The
other half would be to make sure that standard programmer
editors (Emacs, VIM, ..) get the necessary stub functionality
to make use of the interfaces. And finally, both Haskell 
implementers and Editor developers would need to be convinced
to support those interfaces.. After that, implementing and
adding functionality using the editor and implementation 
interfaces would be the lesser problem.

The really good IDEs are either built on meta-programming and 
reflective facilities in the underlying programming language
or integrated into one particular implementation. 

Trying to guess types and syntax is either a lot of work 
(duplicating what has gone into existing implementations) or 
just a hack.

Claus