Consider a slight modification of a functional programming language like Haskell where local variables (e.g., let bindings) are optionally not named.
Instead, the language is no longer a purely textual, but includes graphical edges, joining the definitions of bindings to the locations of their use.
So, instead of let { foo = 7 + 2 * 3 } in bar foo, it would look like let { . 7 + 2 * 3 } in bar . , but with an edge drawn between the two periods. Then, graph layout (automatic or manual) lays out the code so that it looks pretty without too many intersecting edges.
Draw animated edges which "flow" from source to sink (from definition to use). Therefore, this language can only be viewed on a screen, not printed. Perhaps a different colored edge for type declarations.
Designing a UI to program in this language is left an open question. Mouse clicks are an obvious first thing to try, though I dislike dependence on mouse.
Inspired by the linear case, where one can string together a sequence of functions and infix operators such as $, ., or >>=, and never have to name intermediate results.
2 comments :
I have long used diagrams of this sort for informal code sketching, originally in APL. Expressions are written with an arrow-head where a variable name would be. Arrows run generally downward from an expression to its use(s) in expressions below. Annotations, as needed, are written beside the arrows.
These diagrams have become, for me, a standard personal tool when working with any programming language as well as math notation.
I haven't yet used the diagrams much with Haskell, which I am still learning, I expect to do so. Likely with some adaptions for its higher order aspects. Perhaps a second style arrow head for functions will be convenient.
Vaguely related, Perl 6 avoids naming parameters for simple functions by having special names for implied lambda parameters. Perl 6 "{ $^a + $^b }" is equivalent to Haskell "\a b -> a + b".
Post a Comment