Skip to content

Overview

Rahul Arya edited this page Mar 22, 2019 · 4 revisions

The following is an image of a typical session in the editor (full size): image

Windows and Tabs

The editor uses a tabbed interface (using https://golden-layout.com/) within a web browser, that can be rearranged arbitrarily by the user. Many tab panes (referred to as components) have a toolbar at the top, which allows us to access all the functionality of the component. For instance, the editor component allows us to save, reformat, debug, test, and run the program. In addition, there is a header at the top of the window (referred to as the global header) with functionality for creating and opening new files, changing settings, and viewing documentation.

Consoles

Multiple files can be open simultaneously, and that it is easy to simultaneously interact with them in consoles directly from the GUI (rather than requiring students to run scheme in a new terminal). For instance, a test case could be open alongside the program, to allow for intuitive test-driven development and debugging. These consoles will evaluate code as it is written, in order to quickly highlight syntax / runtime errors, but will never make irreversible changes unless Enter is pressed.

Debugging

In addition to an environment diagram visualizer, there is a new "Debugger" visualizer, that allows students to step forward and backwards through the execution of their code. scheme_eval and scheme_apply calls are illustrated using color coding, and an option in the debugging toolbar can display the tree-recursive structure of Scheme evaluation explicitly. Both these tools handle tail recursion in a hidden manner, meaning that even deeply recursive programs can be debugged with no confusion.

Unlike Python Tutor and https://scheme.cs61a.org, these debugging tools introduce only a constant factor performance penalty (for the most part), and automatically deactivate for long-running programs. Just like Python Tutor, the user must first run their program (to generate an execution trace) before starting to debug.

A timestep within an execution trace is known as an index. The index of each execution trace is kept in sync across debugging tools, so the environment diagram and the debugger will always be in sync.

Auto-formatting

Readability is an issue with student Scheme code, due to its significant differences from Python. The "Reformat" button in the editor toolbar is a strongly opinionated auto-formatting tool, that can handle comments but will place student code in a canonical form. In particular, trailing close-parentheses on a new line are banned under all circumstances, with alignment used to avoid having to count parentheses. The editor (https://ace.c9.io) used also offers some automatic help with indentation, but the auto-formatting tool should be viewed as the canonical way of presenting code in a uniform manner.

Documentation

The 61A Scheme spec and primitive reference is available using the search functionality in the global header. The search is fast (since the spec and reference are stored locally) and does not disrupt the workflow, making it easier for students understand the behavior of Scheme special forms.

Clone this wiki locally