2.1 Structure of blocks

OCaml Blockly inherits the block structure of Google Blockly. There are two types of blocks: statement blocks and expression blocks. A statement block has connectors at the top and the bottom of the block. It is used to represent a declaration in OCaml Blockly, such as variable and function definition (a let block without in) and type declaration (a type block). For example, in Figure 1, a variable a is first defined and then used to define a function f. The variable test records whether f 1 evaluates to 8. Finally, a type link_t is defined as a record type that has three fields: two strings and a number.

Fig. 1.

Variable, function, and type declaration.

An expression block has a connector at the left of the block and optionally receives its arguments either in holes (inline arguments) or from the connector at the right of the block (external arguments). In Figure 1, all the blocks other than let and type blocks are expression blocks. Among them, + receives its arguments inline while * receives its arguments externally. As a whole, the function body represents 2 * (x + a). One can switch between inline/external arguments by right-clicking the block and selecting an appropriate option from the dropdown menu.

Each expression block has a type, reflected in the shape of its connector. An OCaml Blockly type may not only be a first-order type, such as int (the connector of numbers in Figure 1) or bool (the output connector of =), but it may also be a higher-order function type. The complex connector shape as observed in the let block for f in Figure 1 represents a function type consisting of its parameter and return types (in this case, both int). Note that when we use the function, as in the test block below, its output connector has the shape of the return type only, because the block receives its argument in the hole. The complex shape appears only when the function is used as an argument of a higher-order function (see Section 2.4).

Some blocks have a few dialog buttons on them. In Figure 1, the first blue button on let blocks configures the number of function parameters, while the one for the type block configures the number of record fields.

The second red button on the let blocks depicts the first Japanese Katakana character for “pattern” and lists possible patterns for parameters, such as variables, tuples, and previously defined records. Similarly, the second red button on the type block depicts a Chinese character for “type” and lists all the available types to be used for specifying types of fields.

Finally, by right-clicking a block, we can see more operations on the block, such as toggling arguments between external and inline, adding a rec keyword to let blocks, and folding blocks. Folding of blocks is particularly useful when building a large program.

As for all block-based programming environments, nesting structure of blocks naturally represents nesting structure of expressions. Since Blockly knows the operator precedence, parentheses are automatically inserted in the textual program when a low-precedence operator appears as an argument of a high-precedence operator.

2.2 Scope of variables, functions, and type declarations

As in OCaml, a variable or function definition has a scope: defined variables and functions can be used only at blocks that are connected below their definitions. In Figure 1, the use of f in test is legal, because the test block is connected below the definition of f. The same goes for parameters. The variable block x can be used only in the body of f (at the connector to the right of the = sign).

Variable blocks are created when a variable name in a let block is dragged. They can be dropped to a legal place, i.e., a place where the variable can be used in a scope- and type-safe manner. While a variable block is being dragged, the environment shows a warning saying that it cannot be dropped there. If a variable block is moved to a legal place, the warning disappears and the variable block can be dropped there. If it is dropped to an illegal place, it is automatically deleted.

To enforce the scoping rule of OCaml, OCaml Blockly maintains connections between definitions and uses of variables and functions. For example, when the user places the cursor at the variable a as in Figure 1, all the occurrences of a are highlighted. The user can also perform $\alpha$ -renaming of variables by clicking one of the variable blocks, selecting “Rename variable…” from the menu, and typing a new variable name. Illegal variable names are rejected. For instance, if one uses the name to (which is a reserved keyword in OCaml) instead of to’ for the second field of link_t, the environment tells the user that the name is invalid. Illegal cases include name clashes. As an example, if one tries to rename the variable a in Figure 1 to x, the environment yields an invalid name error, because the variable x is declared in the body of f and a is used within the scope of x.

The scoping rule applies to type declarations, too. A record block, which can be created by dragging the record name, can exist only below the declaration block. The $\alpha$ -renaming of field names is also supported.

2.3 Type checking

Since OCaml is a statically typed language with Hindley-Milner type inference (Pottier & Rémy, Reference Pottier and Rémy2004), all the blocks in OCaml Blockly are typed. The type information of a block is reflected in the shape of its connectors. Each base type has its own shape: a boolean-typed block has a triangle connector, whereas a string-typed block has a Bézier-curved hump connector. A structured type has a complex shape composed of the shapes of its constituent types. The shape of a pair type consists of the shapes of its two element types aligned vertically; the shape of ’a list consists of the shape of ’a with a bar below; and the shape of a function type consists of the shapes of its parameter types and return type.

OCaml Blockly supports the standard let-polymorphic type inference (Pierce, Reference Pierce2002). A polymorphic type has a general square-shaped connector with a color. In Figure 2, for example, the identity function id is assigned a polymorphic type. The two uses of id below show two different colors for id, expressing that it can be used for arguments of different types.

Fig. 2.

Polymorphic type checking for an identity function.

Type inference runs for every user action. During type inference, unconnected connectors are assumed to be of any type that satisfies the constraints coming from other blocks connected to them. When one tries to connect a block to a connector, type inference runs and checks if the types of the block and the connector can be unified. If not, a type error message appears as a pop-up message.

Since type information is necessary to connect blocks, one has to first specify types of fields in a record declaration before fields of a concrete record can be filled with blocks. Figure 3 shows a record declaration where the type of the third field is not specified yet. Accordingly, the connectors for the third field in the records below indicate that they are not active for connection at this point. If the block specifying the type of a field is removed, the corresponding connectors are disabled, resulting in the removal of blocks connected to that field. For example, if one removes string block for the first field in Figure 3, the two string blocks "Tokyo" and "Kanda" are removed because the connectors are disabled.

Fig. 3.

Connector is disabled when its type is not defined.

2.4 Higher-order functions

By dragging the name of a variable definition, one can construct a variable block. Similarly, by dragging the name of a function definition, one can construct a function call block having a hole for each of its arguments. Having holes for arguments is a nice default behavior for a function block. For the case when a function is used as a higher-order value, OCaml Blockly provides a way to create a function block without holes by option-dragging the function name, i.e., dragging the function name while pressing the option key.

For example, at test2 in Figure 4, the function add_a is mapped to a list of integers. Here, the function block add_a without a hole is passed to List.map. Notice that the complex connector of add_a shows a function type: it receives an integer and returns an integer. In contrast, when a function receives arguments in holes, the outermost connector shows only the type of the return value. For example, at test1 in Figure 4, the connector for add_a with a hole indicates that it returns an integer, given an integer as an argument in the hole.

Fig. 4.

Passing add_a to List.map.

When one wishes to apply a function partially, one can add or remove holes by right-clicking the block and selecting an appropriate option in the menu. The shape of the output connector of the function changes as the number of holes changes.

3.1 Scope playground

OCaml Blockly enforces that a variable can be placed only within its scope. This enforcement of the scoping rule impacts how users interact with the system. There are two ways to compose blocks: top down and bottom up. In the top-down approach, one places the outermost block first. For example, to create the expression 2 * (x + a), one first places the * block, and then constructs its arguments. This interaction is always possible in the main playground. However, one would also wish to compose blocks in a bottom-up way, by first constructing x + a and gradually forming the whole blocks by composing smaller blocks. Such an interaction is impossible at the main playground, because one cannot place the variables x and a in that area. To recover bottom-up composition of blocks, OCaml Blockly offers a scope playground as shown in Figure 7.

Fig. 7.

Scope playground.

A scope playground is a place where valid variables at that point may appear on their own. A scope playground is opened by clicking the scope button to the left of the body of a let block (or each branch of a match block). A scope playground is the same as the main playground except that variables (and records) in the scope may appear freely. For example, in the scope playground in Figure 7, one can use x and a, which appear in the menu of the scope playground. (If f were defined using let rec, f would have appeared in the scope playground, too.) Once blocks are constructed in a scope playground, they can be dragged to the main playground. The available variable blocks differ according to the place of a scope playground. For example, in the scope playground for test in Figure 7, one can use a and f.

The scope playground is also a good place to keep blocks with free variables temporarily. Suppose a user constructed the following function definition:

let a = 3

let f x = x + a

and wished to change the body of f to 2 * (x + a). To insert blocks for 2 *, the user first has to move the blocks for x + a somewhere else. However, since x + a contains free variables, they cannot be placed in the main playground. Instead, the user can keep them in the scope playground, construct blocks for 2 *, and then restore the blocks for x + a afterwards.

3.2 Type checking

In OCaml Blockly, type checking is performed for every user action, avoiding any ill-typed program to be constructed. Furthermore, the type information is shown as the shape of connectors.

Some students remember shapes of base types gradually and use them to avoid plugging a block having a different type. Even though it is unrealistic to parse the complex shape of a connector for a structured type, students recognize different shapes and can identify type mismatches quickly. In particular, the shapes are effective in helping students guess the order of arguments of higher-order functions such as List.map.

Since OCaml Blockly knows the field types of declared records, changing the definition of a record affects all the uses of that record. If one adds a new field in a record declaration, all the corresponding record blocks are extended with the new field. This is particularly useful when a record plays a central role in a program, such as world-passing programs for interactive games (Felleisen et al., Reference Felleisen, Findler, Flatt and Krishnamurthi2014), where the state of a game is typically represented as a record (called a world). When one extends a world record with a new field, one would naturally be urged to fill in the new fields for all the records that follow.

In the presence of on-the-fly type checking during editing, the program development based on the design recipe (Felleisen et al., Reference Felleisen, Findler, Flatt and Krishnamurthi2001) leads to an interesting user interaction. The design recipe advocates turning worked examples into tests before constructing the function definition. As an example, consider the program in Figure 8. The program has a header of the function discriminant that computes $b^2-4ac$ given three (integer) coefficients a, b, and c, as well as three test cases of that function. Since the student writes tests first, the type of the function is constrained. Although the connectors of parameters and the function body have square-shaped polymorphic types because of the let-polymorphic type inference, if one tries to connect a string block to the body of the function, it is rejected because the test cases require the return type to be an integer. By writing tests first, students obtain additional feedback when writing a body of a function.

Fig. 8.

Header and tests for a function discriminant. The type of discriminant is constrained by the test cases.

3.3 Functions

In OCaml Blockly, dragging the name of a function definition creates a function call block having one hole per argument. Having holes for arguments by default makes an obvious thing clear that is nonetheless important for beginning students: one needs to fill in arguments to call a function. Beginning students often forget to pass arguments to a function, especially when a function is called in another function. Figure 9 shows such an example: here, a function numRS returns the number of real solutions for a quadratic equation $ax^2+bx+c=0$ given the coefficients a, b, and c. To define the function, students use the discriminant function they have just defined. With a text editor, many students write the following incorrect program, forgetting the arguments to discriminant:

Fig. 9.

A function numRS that returns the number of real solutions, given coefficients a, b, and c. Students never forget to pass arguments to discriminant.

(* given a, b, and c, returns number of real solutions *)

(* numRS : int -> int -> int -> int *)

let numRS a b c =

if discriminant < 0 then 0

else if discriminant = 0 then 1

else 2

For this program, the OCaml interpreter reports a type error saying that the first 0 should have type int -> int -> int -> int, which is indecipherable for beginning students. With OCaml Blockly, students never forget to pass arguments to discriminant, because the block for calling discriminant has three holes waiting to be filled in.

3.4 Limitations

OCaml Blockly is designed to support static aspects of programming before execution. It has various limitations, too.

4.1 Course background

The functional programming course at Ochanomizu University was launched in 2002 and has been given every year ever since (except for 2004 when the author was on sabbatical). The purpose of the course is to learn how to write correct programs based on the design recipe (Felleisen et al., Reference Felleisen, Findler, Flatt and Krishnamurthi2001), to experience how the use of various data structures impact computational complexity of programs, and to write somewhat large and useful programs.

The course is targeted at second-year undergraduate studentsFootnote ² majoring in computer science. All students enter the course with experience using the C language, and most of them have no prior experience with functional languages. The course lasts 15 weeks, and in each week, there is a 90-minute lab-style class held in a computer room.

Table 1 shows the topics covered in the course, as well as students’ perspective of the course. In the first lecture, the author tells the students that they will eventually implement the shortest path problem for the TokyoFootnote ³ metro network. Showing such a goal (which might sound a bit ambitious to most students at this stage) gives them a stronger motivation to complete the course. It also helps them understand for what purpose each topic is taught.

Table 1.

Syllabus for the functional programming course in Ochanomizu University. The rightmost column shows students’ perception towards writing the shortest path problem for the Tokyo metro network

Although the course uses OCaml as the implementation language, learning the OCaml language itself is not the goal of the course. Rather, it emphasizes how to systematically construct a program following the design recipe, regardless of the programming language used. As such, a design recipe is introduced at an early stage (week 2) and is used throughout the course.

4.2 How OCaml Blockly was introduced

Since its initial inception in 2002, we have invested considerable amount of efforts into the course.

5.1 When students stop using OCaml Blockly

At the beginning of each iteration of the course, we announced that students were free to use either OCaml Blockly or a text editor (Emacs equipped with the type debugger and the stepper) and that they would have to switch to a text editor at week 10 because OCaml Blockly does not support user-defined data types (trees). Table 3 shows when students stopped using OCaml Blockly. The choices are at an early stage (around week 1), in the middle of the course when programs became gradually larger (around week 6), when students wrote the first version of the shortest path problem (around week 8), when trees (which are not supported in OCaml Blockly) were introduced (around week 10), and even after week 10. (The response for the “other” row said that the student did not use OCaml Blockly at first but started to use it in the middle of the course only to find a text editor was easier to use when she already got used to the syntax of OCaml.)

Table 3.

Questionnaire 1: when did you stop using OCaml Blockly?

The table shows that students’ responses vary. Some students did not use OCaml Blockly at all or abandoned it at an early stage. According to the free-text responses to the questionnaire, they were already familiar with text-based editing (which they did in the first year programming courses) and thought that they could write programs in a text editor. One of them stated that once she understood syntax, text-based editing was faster. Another reason some students did not use OCaml Blockly is that the textbook and the video assumed a text-based environment. One student wrote (and stated in the interview) that she wanted to use the same environment as in the textbook and the video. She also said in the interview that although instructor’s explanation using OCaml Blockly was easier to understand than using text-based environment, she wanted to compare the resulting textual code with what she wrote by herself.

Even though all the students had experienced text-based editing already, most of them gave OCaml Blockly a try. Among them, roughly one-third of them stopped using OCaml Blockly as programs became larger. They wrote that at that point, they began to understand the syntactic structure of OCaml programs, and as a result, text-based editing was faster. On the other hand, one student wrote that she switched to text-based editing at this stage because she found she had trouble writing the same program in a text editor and thought she needed training on using a text editor.

Rather surprisingly, a certain number of students used OCaml Blockly all the way to complete the first version of the shortest path problem. Since they did not report how much effort it took to write such a large program in OCaml Blockly, we asked them during the interviews. One of the students responded that the size of a program did not matter; it was hard to read a program when its block representation became large, but it would be the same for textual programs since they also became long; then, the structure of programs was clearer with a block interface. Another student said she did not remember the precise syntax—because she did not have to—and thus continued using OCaml Blockly as long as she could. Yet another student responded that she could understand code in blocks visually, while she was confused when looking at textual code. Students who came that far appeared to acquire their own way of understanding programs in blocks regardless of the size.

Even after week 10, some students used OCaml Blockly. From the comments in the questionnaire, they used it to see how complex constructs, such as nested local variable definitions, were written in OCaml. In the interview, one student said she used OCaml Blockly to construct parts of a program that were still supported by OCaml Blockly and wrote remaining parts of the program in a text editor, thus confirming the supported parts were type checked.

5.2 Whether students found OCaml Blockly useful

Table 4 shows whether students thought the block interface was useful in general, compared to text-based editing. As with the previous question, some students responded they did not use OCaml Blockly at all. Among those who used OCaml Blockly, some students found OCaml Blockly not (very) useful, saying that it was good only for very small programs. Still, one student in this group said it was easier to recognize the structure of programs with OCaml Blockly.

Table 4.

Questionnaire 2: was block interface useful?

A majority of students who used OCaml Blockly found it was useful. The free-text responses typically mentioned the low barrier for beginning students, such as:Footnote ⁶ “It was easy to use,” “At the beginning, it was not realistic for me to write programs in a text editor,” “I could write programs without remembering syntax,” “I could see/understand the structure of programs,” and “OCaml Blockly supported understanding of basics (for those who are not good at programming).” There were deeper comments, too. One student wrote that she could concentrate on programming without being bothered by syntax. Another student wrote that once she was used to OCaml Blockly, she could write programs in a text editor more easily.

Rather unexpectedly, a fair number of students said OCaml Blockly was useful for detecting type errors, in addition to syntax errors. Typical responses said that they could notice type mismatches intuitively when a block did not connect. Another use of the type information was to guess the ordering of arguments of higher-order functions, such as List.map, according to the shape of the arguments’ connectors. One student went even further and wrote that she could be more aware of types when programming in a text editor after using OCaml Blockly.

To further assess the effect of connector shapes, we tested whether students remembered the shape of connectors in the interviews. We showed to students connectors for integers, floats, strings, booleans, pairs, lists, functions, and records and asked them what these connectors were for. From the interviews, it turned out that (1) a student who abandoned OCaml Blockly early (naturally) did not remember connector shapes very well, (2) for students who used OCaml Blockly until later, the results were diverse: some of them remembered very little, some of them remembered the shapes for base types, and some of them could answer most of the connector shapes. One student who remembered most of the connector shapes said she might have recognized simple shapes during programming, but she did not see the structured types carefully. Rather, she tried to connect a block to see if type matched. One factor that affected this behavior could be polymorphic types. Since the shape for polymorphic types is the same (although they have different colors), she said she tried to connect a block even if connector shapes were different.

These responses suggest that the shapes for simple types are somewhat useful while shapes for complex types are not very important. Even if shapes do not match, students often try to connect a block and discover type mismatch when the program is rejected. This behavior could lead to a trial-and-error programming where students try to connect a block until it fits without thinking about type mismatch very much. In fact, one student wrote in the free-text responses that she could often go through without thinking deeply. Although we think it should not be a serious problem (because the student also wrote that the type mismatch did trigger thinking about types), we think it is important to encourage students to reflect on what they are doing.

One unexpected finding from the interviews was that almost all of them recognized types of blocks by their colors. Students unanimously mentioned colors, one of them even saying she felt the ‘atmosphere’ of blocks from their colors. Although colors in OCaml Blockly are assigned mostly based on types, it is not strictly so. For example, when an integer block is connected to a then branch of an if block, the connectors of both the then and else branches change their shapes to the one for integers, but the color remains the same as before. Similarly, the int_of_float block has the same color as an integer block (because it returns an integer), even though it receives a float argument. This observation suggests it might be effective to assign not only the same shape but also the same color to both the male connector and female connector of the same type.

5.3 Whether programming became easier in OCaml Blockly than in a text editor

Table 5 shows whether students thought programming became easier by using OCaml Blockly than using a text editor. There were some “strongly no” and “no” responses. Most of them were from those who did not use OCaml Blockly at all. One student wrote that the programming did not become easier because she wrote programs in a text editor anyway even when she used OCaml Blockly, thus doubling the time for programming. (Apparently, she did not copy textual programs OCaml Blockly produced.) Another student wrote that she understood what she was doing only when she wrote programs in a text editor.

Table 5.

Questionnaire 3: do you feel the programming became easier (e.g., for understanding syntactic structure, typing) by using block interface?

30 students (21%) among 142 students who participated in the questionnaire stayed neutral to this question. Most of them did not provide free-text comments, but submitted comments showed that they found OCaml Blockly useful but were not sure if it led to (easier programming with) deeper understanding. One student wrote OCaml Blockly may have enabled her to understand the syntactic structure and typing of programs. Another student wrote she sometimes stopped thinking because OCaml Blockly was too useful and she could write programs without much thought.

Most other students found OCaml Blockly made programming easier for understanding syntactic structure and typing. The free-text comments can be classified into two categories: rule enforcement and empowerment. The first category is further divided into two groups: syntactic structure and typing.

Students appreciated the syntactic support for complex constructs, such as (nested) conditionals, pattern matching, records, and local variable definitions. They also mentioned that they never passed wrong number of arguments to a function. The syntactic structure of programs becomes obvious once students get used to the language. Nonetheless, the responses indicate that it is important especially in the early stages of programming. For instance, at first, they do not know how to write a simple conditional, where it can appear, and how it connects to other constructs.

The vast majority of free-text comments were about typing. OCaml Blockly does not allow composition of blocks having incompatible types. Whenever a block is rejected for connection, students are forced to think why it is rejected. Students wrote: “I learned all branches of conditionals/pattern matching must have the same type,” “I could avoid making type errors,” “I could see/understand types visually in OCaml Blockly,” and “I became used to think about types in general.” The original motivation for designing OCaml Blockly was to support syntax, but it turned out pleasantly that the support for typing (and scoping) was also quite effective.

The second category of students’ responses is empowerment. Beginning students who are not confident in their ability to program are particularly empowered and encouraged to go forward. Students wrote: “I thought programming was difficult for me, but I could think about it positively,” “The way only the syntactically legal and well-typed blocks could be connected made me learn especially in early stages how to write a program,” “I could avoid thinking about inessential details such as matching parentheses,” and “I became able to structure a program in my mind more easily.”

5.4 Whether OCaml Blockly had negative effects on text-based programming

Table 6 shows whether students thought they were spoiled by the use of OCaml Blockly. Around 72% of students thought OCaml Blockly did not have negative effects (“strongly no” or “no”). Some of them did feel confused when they switched to text-based programming, but they became used to it very quickly. Overall, the benefits of having easier introduction and syntax/typing support exceeded a small struggle at transition time.

Table 6.

Questionnaire 4: do you feel your programming ability decreased (e.g., cannot live without block interface, cannot program in a text editor) because of the block interface?

There were many positive and also fundamental comments: “I could get used to OCaml quickly via the block interface,” “Because of OCaml Blockly, I could catch up with the class,” “There were more benefits than drawbacks,” “By using OCaml Blockly, I learned how to write programs in a text editor,” “Since it was the structure of programs that was important, the interface did not matter,” “The flow of thought is the same in both the interfaces,” and “I became able to program in other programming languages, too.”

On the other hand, there were a few “strongly yes” and “yes” responses as well as a certain number of “neutral” responses. The students who responded “yes” wrote they did not remember how to write programs (even if they remembered typing rules), especially for complex constructs such as pattern matching and records. The student who responded “strongly yes” did not leave any written comments, but in the interview, she made the same point: because she did not write textual programs with the block interface, she simply could not write any programs in a text editor and needed some practice when she switched the interface. On the contrary, students who responded “(strongly) no” typically wrote they learned concrete syntax from the textual programs produced by OCaml Blockly. Students did have to handle programs in text files to send them to the check system provided by the author or to submit them as part of assignments. During this process, they had the opportunities to see text-based programs. Still, the above responses indicate that it would be important to urge students to look into text-based programs from time to time. In fact, one of the students said in the interview that she found it important to be able to see textual programs in the OCaml Blockly window.

The “neutral” responses expressed concerns on the possibility of using OCaml Blockly without deep understanding. That is, OCaml Blockly could be too useful for them so that they could rely on it too much. Although many students among them wrote they could transition to text-based programming rather smoothly possibly with some struggle, it would be important to remind them to reflect on what they have been doing in each assignment.

5.5 Threats to validity and limitations

To begin with, the sample size is small, around 40 students per year over five years. Thus, the results in the paper might reflect these particular students rather than general students. The fact that all students are female could also have affected the results. Furthermore, the students knew that OCaml Blockly was developed by the author’s research group, hence they might have answered the questions in a more positive way than necessary.

Although we would ultimately want to see if the use of OCaml Blockly has any positive impacts on students’ programming ability, what the questionnaire asked is students’ perception of OCaml Blockly. One way to assess students’ programming ability is to see whether students perform better in the follow-up courses. We have not done this for two reasons. First, we think it is not ethical to force the use of either OCaml Blockly or a text editor to students. Second, the follow-up course (a programming language course on either an interpreter or a compiler depending on the year of the course) is one year away, and the number of enrollments of the course is very small (typically three to five) to do comparison experiments.

6.1 Blockly and related environments

The original Blockly (Fraser, Reference Fraser2015) developed by Google is an extensible framework for realizing block-based environments for various imperative languages. It supports all the basic features required for block-based environments, including statement and expression blocks, dialog buttons, and conversion to text programs. OCaml Blockly was forked from Google Blockly in April 2018 and inherited all the features of Google Blockly. We added OCaml-specific features, in particular, the scope playground and let-polymorphic type inference. Since the added features required substantial changes to Google Blockly, however, it became unrealistic to merge the upstream changes into OCaml Blockly. As such, OCaml Blockly is now an isolated branch missing features recently added to Google Blockly, such as shadowed blocks.

HenBlocks (Boey & Adams, Reference Boey and Adams2022) is a Blockly-based structured editor for the Coq proof assistant. It provides syntactic support for writing proof scripts in Coq, including inductive datatype definitions, function definitions, theorems, and proofs. Being block based, it naturally prevents syntax errors. It also supports $\alpha$ -renaming of variables and names of assumptions, respecting the scope rules of Coq. Since Coq supports function definitions, one can write functional programs in Coq. However, type checking is deferred to proof checking time. Thus, one can construct syntactically correct but ill-typed programs that result in a type error at proof checking time.

BlockPy (Bart et al., Reference Bart, Tibau, Kafura, Shaffer and Tilevich2020) is a block-based programming and execution environment for Python. It features a dual text/block interface, and it has been shown that the block interface is helpful for novice learners in a computational thinking class for non-CS major students. Being a block-based environment for Python, it does not have functionalities equivalent to OCaml Blockly’s scope playground or type checking. BlockPy uses a block language that is suitable for novice learners (e.g., for each) instead of strict Python syntax (e.g., for), while OCaml Blockly uses original keywords so that program texts on blocks are identical to the textual programs (except for the automatic insertion of parentheses).

6.2 Connectors as representation of types

The idea of representing precise type information as shapes of connectors is considered in TypeBlocks (Vasek, Reference Vasek2012). In TypeBlocks, a connector shape of a composite type consists of the shapes of the constituent types. OCaml Blockly, developed independently of TypeBlocks, employs the same approach for pair, list, and function types, but not for record types. On one hand, precisely representing types of fields of a record requires a large connector. Even a connector for a simple pair of integers requires the height more than twice the size of an integer connector. On the other hand, using a single shape for all the records prevents us from distinguishing different record types by looking at the connector shape. The design choice to use a fixed connector for records and complex connectors for other data in OCaml Blockly came from the ease of implementation. It is yet to be seen whether students benefit from more information on the record connectors.

Another approach to showing type information is proposed by Poole (Reference Poole2019). He presents a block design for Haskell in which type information including type classes is shown to users. He uses labels and colors for types and black hatch patterns for polymorphic types. Types for lists, tuples, and functions are represented as a white base on which component types are shown. Because labels are used instead of connector shapes, the type information does not take too much vertical space for complex nested types.

6.3 Integrated development environment

There are a number of integrated development environments (IDEs) for various languages. They allow various degrees of spell checking, selection of bound variables and library functions, showing type information and documentation, and even suggesting interpolation of programs. Notably, Visual Studio Code (VS Code)Footnote ⁷ supports many programming languages including OCaml. The language server for OCaml used in VS Code (and also other text-based editors, such as Emacs and Vim) is Merlin (Bour et al., Reference Bour, Refis and Scherer2018). It provides services such as signaling syntax errors, typing errors and warnings, or making auto-completion suggestions as well as more advanced features such as asking the type of a variable under the cursor or going to the definition. Merlin provides them in response to every user action by implementing incremental lexing, parsing, and type checking for an incomplete program.

VS Code with Merlin would be ideal once one gets used to the basic structure of OCaml programs. However, VS Code is not necessarily friendly to beginners and those who are not confident in their programming ability. OCaml Blockly offers an introduction to programming for those beginning students by showing what constructs are available in a menu, how complex constructs are built, how the use of a variable is restricted within its scope, and how type checking is performed.

6.4 Structured editors

The idea of a structured editor was first proposed by the Cornell Program Synthesizer (Teitelbaum & Reps, Reference Teitelbaum and Reps1981). It was intended not necessarily for beginners but also for experts.

More recently, Omar et al. (Reference Omar, Voysey, Hilton, Sunshine, Goues, Aldrich and Hammer2017) designed Hazel, a web-based live programming environment for an ML-like functional programming language. It is equipped with a structural editor that understands the syntax and typing rules of the language. One of the unique features of Hazel is it assigns abstract syntax trees (ASTs) to any programs including incomplete ones (and even allows us to run them). Hazel does not exclude syntactically incorrect or ill-typed programs. The internal ASTs are built according to the textual representation of programs. In contrast, OCaml Blockly does not allow syntactically incorrect or ill-typed programs. Textual representation of programs is derived only when there are corresponding internal ASTs (possibly with holes).

Whether the main representation is textual or structural affects user experience. Consider a function add1 that adds 1 to its argument.

let add1 x = let y = 1 in x + y

In Hazel, renaming the first y to x results in

let add1 x = let x = 1 in x + y

where x in x + y is rebound to the new let-bound x, and y becomes unbound. This is because the AST is built according to the textual representation of the program. In OCaml Blockly, renaming of y to x is prohibited, because it shadows x that is used in x + y. (If x is not used in the body of the let expression, the renaming is allowed because it does not shadow any binding.) In OCaml Blockly, the binding is at the AST level, and it cannot be broken by renaming. If one wants to change the binding, one has to delete the variable and create a new variable by dragging from its declaration.

Racket (Felleisen et al., Reference Felleisen, Findler, Flatt, Krishnamurthi, Barzilay, McCarthy and Tobin-Hochstadt2018) has the integrated development environment DrRacket (Findler et al., Reference Findler, Clements, Flanagan, Flatt, Krishnamurthi, Steckler and Felleisen2002) that is text based but has a “Check Syntax” button (and a stepper among others). After checking syntax and scoping, DrRacket analyzes declarations and uses of variables and shows arrows between them when a user hovers a mouse on a variable. By properly setting #lang directive, the checking of syntax can be done continuously in the background. It also allows renaming of bound variables. If we try to replace y to x in the add1 function (rewritten in Racket), DrRacket warns that the renaming conflicts with an existing variable name.

The enforcement of all the static rules (scoping rules in particular) employed by OCaml Blockly inhibits users from constructing ill-formed programs temporarily. However, to edit a well-formed program into another well-formed program, one often needs to go through ill-formed programs. Such editing is not permitted in OCaml Blockly. For more flexible uses of variables without violating scoping rules, OCaml Blockly supports the scope playground. There appears to be no similar mechanisms in block-only environments, but there are some work on allowing intermediate ill-formed programs in hybrid environments and structured (projectional) editors.

Frame-based editing (Kölling et al., Reference Kölling, Brown and Altadmri2015) takes a hybrid approach. Statement blocks (called frames) are structured enforcing scoping rules, while expressions are input as texts, allowing users to write temporally ill-formed expressions. MPS (Voelter et al., Reference Voelter, Siegmund, Berger and Kolb2014) is a projectional editor for expert programmers. MPS operates on program texts which are actually projections of the internal ASTs and users can directly manipulate the ASTs by editing programs represented as texts. Gradual structure editing (Moon et al., Reference Moon, Blinn and Omar2023) follows MPS in that a program text is always a projection of the internal AST. It avoids unexpected editing behavior of MPS by introducing obligations that have to be satisfied for the currently input program text to be structurally correct.