[Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.

[Thomas Schilling]

On 18 jun 2007, at 16.01, Pasqualino 'Titto' Assini wrote:

> Having just presented a case for the possible rationality of the  
> irrational
> decision of creating an Emacs-like IDE in Haskell, I wonder if we  
> should not
> be even more irrational and contemplate the possibility of using  
> Haskell to
> create a radically different kind of IDE.

I agree, that just duplicating Emacs in Haskell is a rather useless  
endeavor.  If you want any chance of building up sufficient momentum  
to be superseded by a good-enough emacs module you have to provide  
killer-features that are hard to do in emacs.

Here are some ideas I've been collecting over the years.

* Structural (optionally Type-Directed) Editing

Structural editing means that your code is always (mostly)  
syntactically correct, and in case of haskell maybe also type- 
checked.  This also implies that edit operations have syntactic  
awareness.  paredit[1] emulates this quite nicely for lisp, Proxima  
does something like this in Haskell for Haskell and XML-based  
languages.  This also needs some way of incremental parsing, for  
which good techniques already exist[3].


* Choose a more flexible editor model

Emacs (and probably Vi too) has a really old-fashioned editor model.   
It represents the complete file as a flat array (gap-buffer) of  
characters.  The Dylan-editor Deuce[2] wisely chose to use  
polymorphic lines, which requires greater storage overhead but is far  
more flexible.  It allows for easy embedding of different fonts,  
graphical and interactive objects, folding, and automatically  
generated objects (like callers, callees, etc.)


* Micro-versioned documents

With a little care, you can support lightweight, because incremental,  
tools and you get undo for free.  (You don't need redo, since that's  
just undoing an undo.)  This also should be pretty functional.   
Coupling this with an easy-to-use version-control goes without saying.


* No hardcoded editing model

Support Emacs-, Vim- or Mac/Windows-style usage.  This is important  
for adoption.


* Don't optimize for a console-based interface

And there so many more things to do, but I think if you have these  
much just falls off naturally.  Yi is still young, so it's not too  
late to get on the right track :)

I intend to help, as soon as I can find some time for this.


[1] .. http://www.emacswiki.org/cgi-bin/wiki/ParEdit

[2] .. http://wiki.opendylan.org/wiki/view.dsp? 
title=AppleDylanScreenshots

   The Deuce source code is available online as part of the  
functional developer source code:
   http://www.opendylan.org/cgi-bin/viewcvs.cgi/trunk/fundev/sources/ 
deuce/

[3] .. http://harmonia.cs.berkeley.edu/papers/twagner-parsing.pdf