[Haskell-cafe] To yi or not to yi,
is this really the question? A plea for a cooperative,
ubiquitous, distributed integrated development system.
nominolo at googlemail.com
Tue Jun 19 14:27:12 EDT 2007
On 18 jun 2007, at 16.01, Pasqualino 'Titto' Assini wrote:
> Having just presented a case for the possible rationality of the
> 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 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.
* 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 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
* 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.
 .. http://www.emacswiki.org/cgi-bin/wiki/ParEdit
 .. http://wiki.opendylan.org/wiki/view.dsp?
The Deuce source code is available online as part of the
functional developer source code:
 .. http://harmonia.cs.berkeley.edu/papers/twagner-parsing.pdf
More information about the Haskell-Cafe