-
Notifications
You must be signed in to change notification settings - Fork 1
Helium Editor
A source editor has been implemented for a significant subset of the functional language Helium, which is a Haskell dialect designed for education. In order to provide type information during editing, the editor is integrated with the Helium type checker. Not counting the Helium compiler, the editor is written in about 1800 lines of code.
[
In the screenshot (click to enlarge), we see an editable view of a program source, with the focus the expression x+1
in the definition of f
. The right-hand side of large
has been hidden and may be expanded by clicking on the dots. The definition of f
shows that program constructs may have a graphical presentation.
The type signatures for the top-level declarations have been automatically derived, and furthermore, the editor provides type information for local expressions as well. At the top of the window we see the type for the expression focused on (if it has a type). At the bottom, the variables that are in scope at the focus are listed together with their types.
To the right of each type signature is a comment that shows the value of the declared identifier. The value changes dynamically when the source is being edited. Although not very useful in a source editor, since most declarations are functions, these computations provide an example of spreadsheet-like behavior; parts of the document that represent computations are interpreted dynamically, and the results are displayed in the presentation.
Expressions can be edited structurally (or document-oriented) based on the Helium abstract syntax. Below is an example that shows how structure editing facilitates editing a list. When the 3*5
element is cut, the comma to the right of it automatically disappears. When the element is pasted at the end, a comma appears at the left.
![]() | |
=> {document cut} | |
![]() | |
=> {document paste at beginning of list} | |
![]() |
The editor also supports structure building with placeholders. By selecting constructs from a menu, an expression may be constructed:
![]() | |
=> {insert DivExp} | |
![]() | |
=> {insert PowerExp} | |
![]() |
Similar structure editing is supported by conventional syntax-directed editors, but Proxima has the advantage that the presentation can still be edited textually as well. Program fragments can be entered or modified textually without having to switch to a different view or mode. Below is a screenshot that shows a presentation-oriented cut operation. Although the selection that is cut does not make sense at document level, the cut is a valid edit operation at the presentation level.
![]() |
|
=> {cut \*5, 1+} | |
![]() |
The editor shows type errors by displaying an error message at the bottom and marking the location with a squiggly line in the source. This mechanism also works in the graphically presented parts of the program, as is shown by the screenshot fragment below.

The Helium type compiler is an interesting candidate for integration with Proxima because it has a sophisticated type checker. Besides the location of the error, the type checker can provide additional information about the other parts of the program that contribute to the error. Such information would be hard to show on a command-line, but can be displayed in a clear way by highlighting the relevant parts of the source code.
A simple reduction engine can be applied to a term in the source. The screen-shots below show two steps in the reduction of the application f 3
. First, the function f
is replaced by its definition (see screenshot at the top of this page). Then, a beta-reduction step is performed, and the argument 3
is substituted for all free occurrences of x
in the fraction. The process can be continued by reducing the mathematical operators until we get the final value 16
.
![]() | |
=> {replace f by definition} | |
![]() |
|
=> {reduce lambda expression} | |
![]() |
The reduction engine is implemented by an attribute grammar of about 150 lines, which can be reduced further to about 100 lines once the underlying attribute-grammar system supports default attribute declarations.
The evaluation layer has not been completely implemented yet, but nevertheless a few experimental evaluation-layer features have been implemented. The list of top-level identifiers at the top of of the editor window is similar to an editable table of contents. Editing a name in the list causes an update to the identifier in the corresponding declaration, and moving an identifier moves the declaration. The screenshot shows how editing list
in the identifier list results in an update to the declaration of list
as well.
![]() |
|
=> {type '1'} | |
![]() |
Integrated with the Helium editor is a very basic slide editor in the style of Microsoft's PowerPoint. A slide presentation is a list of slides, each of which consists of a title and a list of items. An item can be either a string, a Helium expression, or a nested item list:
[
The screenshot shows the slide editor for a slide presentation of two slides. An item list may choose from several display styles (bulleted, numbered, or enumerated with letters) and nested lists get a smaller font size. The entire slide editor is specified in about 200 lines of sheet code.
[
Because a WYSIWYG view is not always convenient, the editor also provides an XML source view, which is shown in below. The source view is only partially editable, but it is straightforward to turn it into a fully editable view.
The slide editor is fully integrated with the Helium editor: the list of slides is part of the program source, and, more interestingly, a slide may contain Helium code (which may again contain a list of slides, and so on). The Helium code may refer to declarations elsewhere in the source. Moreover, the edit functionality for Helium code in a slide is exactly the same as for code in the source editor. As an example, consider the slide below, in which a Helium expression refers to a non-existent identifier increaze
.
