[Haskell-cafe] Haskell for Accessibility

[Tom Hawkins]

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