For my capstone project, I intend to continue with my Interactive project on visualizing lambda calculus and actually make an interactive lambda calculus editor. To that end, I have researched a few approaches to code visualization.

To Dissect a Mockingbird – David C. Keenan

Keenan is one of the few people who have also undertaken the project of visualizing lambda calculus; however, the representations he has created become overly complex very quickly. Because of his adherence to the most pedantic definition of lambda calculus syntax (in which all abstractions take only one argument), the graphics become cluttered with containing lines. Additionally, the structure of his diagrams do not differ significantly from textual representations: they evaluate horizontally, largely sequentially, when in fact the strength of a graphical representation is that it frees us to engage with the lambda calculus in a nonlinear manner.

Blockly – Google

Blockly is a tool developed by Google to make programming similar to fitting together pieces of a puzzle. This seems to be a common approach to visual programming, which frequently has drawbacks. The usefulness of the tool is constrained by the fact that the blocks all have to be defined, and this requires writing text-based code, and it also induces a jarring switch between the visual programming environment and the textual. Because of these limitations, the plug-together style is one that I intend to avoid for the most part. However, these projects to strike at the necessity of abstraction in a visual programming language. It will be important to be able to collapse elements within the lambda calculus editor, to avoid being overwhelmed in a complex program. Block-based visual editors are often designed from this standpoint, and incorporating that use pattern should improve the quality of my user experience.

Visual Lambda – Viktor Massalogin

Visual Lambda is another take on the problem of creating a graphical lambda calculus environment. Like Keenan, Massalogin focuses in his work more on evaluation of lambda expressions and less on composition. Visual Lambda also appears to prefer a left-to-right orientation and does not compress abstractions for simplicity. It also does not seem clear how the user should interpret the diagram to understand the lambda expressions. Thus I can see that presenting information clearly, particularly to those who have never worked with lambda calculus before, will likely be a challenge in future work with graphical lambda calculus.