From HaskellWiki
Revision as of 09:06, 23 May 2006 by Sjw (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Yi ideas

This page is meant to gather ideas people have for Yi, an extensible editor written in Haskell.

Coming from an Emacs background, the current version of Yi lacks a few things I think are essential, mainly the introspection capabilities of Emacs. On of the main problems is that Yi is based on purely compiled code --- there is little or no interaction with the run-time system.

Ideally, the next version of Yi would be based on a (modified?) version of GHCi, maybe taking advantage of package GHC.

Emacs goodness

The following are things I like about Emacs, as an extensible environment:

Really good online documentation
Emacs can tell you a lot about a function or variable with a
keypress--- the current value, where it is declared, and a hypertext
information string
All (good) apps allow users to extend, through, e.g., hooks --- a
list of functions that are run before/after some event (like saving
a file)
It is really easy in Emacs to have one package interact with
another. Thus, I can, e.g., insert a new appointment from my mail app into
the diary.
Everything is Lisp
Ignoring the actual language, everything is handled in a uniform
language --- from binding keys to writing apps.
Easy to start hacking
I can start playing with the system from the second I start up, and
things pretty much work as expected. I.e., I can type a bit of code
in, execute it, and the result is displayed in the minibuffer. The
good docs help immeasurably.
Written for the frequent user
Lots of key shortcuts (and famous for it). There are still menus,
for those who like em, but you aren't forced to pretend you just
started using it.
A tonne of code
Well, Haskell has this to some degree. Haskell is (IMHO) much
easier to write than ELisp, so maybe people will be encouraged to contribute.

Emacs badness

So, why replace it?:

Dynamically scoped, Dynamically typed, ugly, old. 'Nuff said
What's a Parser?
A lot of apps in emacs do stuff with text, usually text that is in
some language. There is no standard parser (like, e.g. parsec), so
a lot of it is ugly handwritten spaghetti. This also means that
adding analysis tools isn't really done (or done nicely).
ELisp again
Haskell is a lot cleaner to write, especially because of the large
number of libraries.

Emacs maybeness (?)

Some things that are sometimes bad, sometimes good:

Everything is a buffer
Makes some sense, but sometimes doesn't. It is nice to have uniform
key bindings do the right thing (e.g., C-Space sets the mark, and
the region can then be used, e.g. to delete a sequence of emails in Wl)
Sometimes, however, you just want some sort of GUI widget.
OTOH, having the minibuffer be a special kind of buffer is a good idea.
It is possible to associate arbitrary properties with symbols. This
means you can annotate a symbol and then use that information at a
later date


An extension to GHCi to support documentation of symbols.

Intermixed compiled/interpreted code (for speed/hacking)

GUI abstraction --- want it to work on terminals as well as X

Remote attach so I can work from home, but still use a remote machine

Haddock documentation (no brainer), maybe associate with .hi files for binaries.

A class MiniBufferRead (or PromptingRead) which allows the user to invoke a function similar to M-x in Emacs, but without requiring (interactive)


Sjw 09:06, 23 May 2006 (UTC)