I love programming in Haskell, yet even its concise expressions have not saved my tendons from chronic RSI. Has anyone put any thought into building an accessible Haskell development interface for those who may not be able to use a keyboard? One inspirational program is Dasher (http://www.inference.phy.cam.ac.uk/dasher/). Not only is it godsend for people with a wide range of disabilities, Dasher is also a lot of fun to use. Though Dasher is good at general text entry, it's not well suited for programming. However, combining Dasher's statistical inference with Haskell's type inference might yield a graphical, cursor driven interface even more efficient than the conventional keyboard. Is there interested in such a project? I don't have the expertise or typing strength (pun intended) to go it alone, but I could lend a hand. Here are a few random ideas: - A tree viewer to navigate and manage directories, modules, module declarations, and expressions. Similar to a directory explorer, nodes in the tree can be collapsed and expanded. Collapsed module definitions would display the type annotation, while hiding the definition. - Another interface for composing expressions. This interface could be similar to Dasher, but use both statistical inference and type inference to weight and prune the decision tree. The expression composer interface could directly assemble the abstract syntax tree, thus eliminating the need for whitespace and ()s. Of course, the tree viewer would pretty print all expressions in the familiar Haskell layout. - The development environment could be hosted as a web server, delivering SVG and minimal JavaScript for the client-side interface, allowing Haskell program development from any web browser with a 2 button mouse -- head mounted or eye tracked, of course. The client-server architecture would allow developers to concurrently work from the same source code. -

From the tree viewer, click any expression to view the compiler's inferred type, with the ability to turn any inferred type into a concrete type annotation. And the ability to compare inferred types to type annotations. Type violations highlighted in red.

- Variable references would not have to be explicitly spelled out. Instead, variables could be selected from either the tree viewer or expression composer, forming a hard link. When a variable's name changes, all references could be automatically updated. When an expression is either moved or copied into a new lexical scope, the variable references could be automatically rebound to variable definitions in the new scope. Unmatched referenced names and ambiguous names would be highlighted in red. -Tom