Data-Driven Evidence-Based Syntactic Sugar Design

First, let us consider the case where idioms consist only of the same kind of repeated statement. Such repetition could possibly be simplified by condensing it with a new syntactic sugar. As an example, consider the idiom consisting of multiple, successive assignment statements as shown on the left of Figure 2.

From mining thousands of repositories, our approach finds that this idiom is frequently implemented by Java developers. We call this the multiple assignments idiom and propose a Java syntactic sugar for it on the right side of Figure 2. Our approach aided in identifying the recurring pattern as a possibility for a new syntactic sugar. Afterward, we referred to other languages, e.g. Python’s tuple unpacking, for inspiration in suggesting the syntax for the new sugar. This sugar can provide a potentially more human-readable syntax to express this Java idiom.

As another example, consider when multiple increment operators (++) appear in succession, such as on the left of Figure 3. Our approach found this to be another frequently occurring idiom. To address this repetitive and potentially redundant code, we propose a new syntactic sugar, as shown on the right of Figure 3. This sugar allows developers to perform multiple increments with a single, concise operation. This sugar can provide syntax which is potentially easier to read and write for Java developers.

In addition to repeated statements, we mined several idioms involving if-statements. Here we present potential syntactic sugars motivated by our mined idioms. Instead of eliminating duplication like the sugars previously discussed, the sugars in this category aim to improve human readability by rephrasing the if-statements to better communicate their intended logic. The implementation of these syntactic sugars can potentially improve the readability and understandability of these frequent idioms.

Following the mining of over 166 million method bodies, we find a frequent idiom involving the negation of an if-statement’s condition. Taking inspiration from programming languages like Perl and Ruby which support an unless statement to invert an if-statement, we propose the introduction of such a construct in Java. Figure 4 portrays the design of the proposed unless-statement.

Additionally, if-statements with repeated conditional operators (&& and ||) are a frequent idiom, motivating the potential impact of a construct to better express them. Figure 5 exemplifies a separate syntactic sugar of any and all syntactic sugars to express || and && conditions respectively. These sugars can potentially viewed as easier to understand, despite requiring the same number of tokens to express as the original idiom.

Alongside previously discussed categories, our approach also extracts frequent idioms that handle null values. Therefore, frequent null-handling operations provide an impactful opportunity for simplification. In this section, we propose a Java null if null (?!) syntactic sugar to express the behavior shown in a mined frequent idiom shown on the left side of Figure 6.

The proposed null if null operator (?!) is similar to Kotlin’s not-null assertion operator (!!) but behaves differently. The proposed operator skips the body if the respective variable is null and always returns null if no other value is returned in the body. This could compress this frequent handling of null values in Java similar to how syntactic sugars of other languages provide null handlers such as null conditionals and null coalesces.

Handling errors is a frequent task performed by developers in many situations. Therefore, this category separates itself from previous sections by exploring syntactic sugars designed to express patterns of error-handling code such as throwing or catching errors.

A frequently recurring idiom found in our mining process is one that involves checking if a variable is an instance of a provided type and triggering an error if it does not meet this requirement. The left side of Figure 7 exemplifies such an instance.

To address the verbosity of this common pattern and convey its desired behavior, we propose the requireType syntactic sugar and exemplify its usage in Figure 7. This operator has the potential to effectively reduce the amount of code required to express such a frequently implemented idiom.

Continuing our examination, we find another syntactic sugar that can be motivated by a frequently occurring error-handling idiom. This second idiom is a catch block dedicated to rethrowing another error. This can assist when developers want to catch broad exception types, but omit catching specific ones.

Figure 8 demonstrates an instance of the mined idiom and the proposed syntactic sugar’s design. Accompanying the previously discussed requireType, the proposed rethrow syntactic sugar offers an alternative for simplifying error-catching and rethrowing operations by specifying which error is to be caught and which is to be thrown in response. Both syntactic sugars presented have the potential to advance the expression of error-handling idioms.

Although the sugars presented here are all new features, our approach can also motivate language features currently being developed by Java designers, such as the upcoming string templates being previewed in Java 21 (OpenJDK, 2023). Our approach mined idioms that involve the composition of string literals, which could have prompted designing a feature such as string templates.

In the context of a graph database, frequent subgraph mining (Aggarwal and Wang, 2010; Inokuchi et al., 2000; Kuramochi and Karypis, 2001; Yan and Han, 2002; Nijssen and Kok, 2004; Ranu and Singh, 2009; Saigo et al., 2008) is the process of identifying patterns and structures that appear frequently across a set of graphs. The task involves extracting subgraphs, which are subsets of the nodes and edges of a given graph, that appear in a number of separate graphs of the input database at least as many times as a user-defined minimum frequency threshold value. The subgraphs are then grouped based on their similarity, with two subgraphs being considered the same if they are isomorphic to each other. This means that the same subset of node and edge types are connected in the same way in separate graphs in the database. The frequency of a subgraph is determined by the percentage of graphs in which it appears, which must be greater than the user-defined minimum frequency threshold in order for it to be considered a frequent subgraph. This approach allows for the identification of common patterns, which can be used for further analysis and understanding of the underlying structure of the entire graph set.

We provide an example of a frequent subgraph mining task in Figure 9 where the graph database consists of 3 connected and directed graphs with a set of four node types (A, B, C, and D) and a user-defined minimum frequency threshold of 66%. To be considered frequent, a subgraph must appear in at least 2 out of the 3 graphs in the database. The graph database is depicted in the leftmost box, while the center box illustrates the set of all possible subgraphs as candidates for being frequent. It is important to note that in frequent subgraph mining, even the subgraph containing each individual node with no edges is considered a candidate subgraph, as well as the subgraph consisting of every node and edge. Finally, the rightmost box shows all subgraphs that have met the minimum frequency threshold of 66% and appeared in at least 2 out of the 3 graphs in the original database.

In this paper, we leverage the Boa infrastructure because of its proven capabilities in other works (Dyer et al., 2013, 2014; OBrien et al., 2024). Specifically, we use its provided capabilities to mine frequent subgraphs. Boa uses a scalable and deterministic candidate generation approach to gather and aggregate frequent subgraph candidates using Hadoop MapReduce, which enables the efficient handling of large graph sets.

In this paper, we leverage a large-scale public dataset provided in Boa. We choose to use this dataset since it is the largest dataset provided, excludes forked projects, and contains frequent subgraph mining capabilities. The dataset statistics are reported in Table 1.

We choose to mine the most recent snapshots of all Java methods in our dataset, totaling over 166 million methods. These methods are transformed to CFGs, which is a data structure that has been leveraged in previous studies (Zhang et al., 2018; Acharya et al., 2007; Nguyen et al., 2014; McMillan et al., 2011; Yamaguchi et al., 2014). We utilize Boa as a starting point to modify and analyze these CFGs, which provides capabilities for traversing and mining the information present.

Our goal in this paper is to identify opportunities for new syntactic sugars in a programming language by analyzing the current usage of language features to discover opportunities to advance the syntax. Previous work (Allamanis and Sutton, 2014) found that performing frequent subgraph mining on an unmodified tree structure of source code results in very small and meaningless idioms. This is because only small and meaningless subgraphs are frequent across multiple projects when all available information is involved in the mining process. To alleviate this, we propose a novel modification of control-flow graphs (CFG) designed for later frequent subgraph mining. CFGs are chosen to mine due to being a popular higher-level representation of source code. The mining of these modified CFGs enables the discovery of frequent code idioms and redundancies that could be simplified with the introduction of new syntactic sugars. We term these simplifiable subgraphs as being “sugarable”. This approach aims to identify sugarable subgraphs and promote language evolution.

We identify that syntactic sugars implemented in Java previously can be motivated by popular combinations of operations (e.g., +=) as well as compressing duplicate code (e.g., multiple variable declarations). Therefore, the subgraphs representing common idioms should express the broad operations and provide the context of duplication between neighboring expressions. During preliminary experimentation, we found that the broad similarities between CFG nodes contain noise that differentiates them from each other. This would cause them to be considered two different subgraphs during our later mining procedures. However, there is contextual information that certain subgraphs might require to contain enough information to confidently be considered as sugarable. Our technique generalizes the CFG nodes such that two CFG nodes that are broadly similar get mapped to the generalized same type to enable frequent subgraph mining of common idioms.

Therefore, our approach manipulates source code data across the CFG nodes and edges. Specifically, our generalization 1) removes project-specific information, 2) re-uses data of other CFG nodes to provide additional context, and 3) represents generalized neighboring data duplication across the CFG edges.

Figure 11 illustrates a CFG without generalization and a CFG with generalization for comparison and is discussed throughout the rest of this subsection.

Our technique innovates atop traditional CFGs by mapping similar programming language features through discarding specific information (e.g., variable names, user-defined types, and literal values other than null) as depicted in red in Figure 11. Discarding project-specific information is crucial in allowing similar subgraphs to be treated as the same during the frequent subgraph mining process. Discarding irrelevant information to increase analysis performance is an action also explored by (Upadhyaya and Rajan, 2018; Allen et al., 2015; Choi et al., 1991; Smaragdakis et al., 2013), but no works consider which pieces of information are relevant in the context of sugarable subgraph mining. As a result of our novel application of this process, frequent code idioms can be identified and considered frequent regardless of project-specific information.

For instance, in Figure 11 two integer assignments (result = 1 and result = -1) are originally represented as separate CFG nodes in the traditional CFG due to the difference in literal values getting assigned. However, these integer assignment nodes are considered the same type of node in our generalized representation after the removal of project-specific information from the original representation (variable name and assigned value). This allows for the detection of patterns such as the desugared usage of the ternary operator from this specific subgraph. This broad pattern would have been difficult to uncover through frequent subgraph mining with the original CFG representation which contained project-specific and subgraph-differentiating information. Therefore, such a subgraph is sugarable because of the duplicate operators in a control-flow structure and previous languages supplying a syntactic sugar atop this idiom. If this subgraph is found to be a frequently-occurring idiom, this would motivate the potential impact of supporting the ternary operator if it had not already been implemented in Java. Our process of removing project-specific information and generalizing CFG nodes thus helps identify sugarable subgraphs.

In Figure 11, the information introduced to new areas of a CFG during our generalization process is depicted in blue text. Our technique balances the need for generalization with the importance of context by reapplying information evident in other locations of a CFG. For instance, the original CFG representation involving result’s assignment in Figure 11 lacks the assigned variable’s type. However, our approach tracks this information from the variable declarations earlier in the CFG and reapplies it to generalized nodes whenever the variable is assigned a value, providing additional context for understanding potential type-specific syntactic sugars (e.g., string interpolation) which could simplify the assignment. Without this information, the generalized CFG nodes would simply be ASSIGN LITERAL, lacking potentially crucial details about the type of literal being assigned and introducing ambiguity which can prevent a subgraph from being viewed as sugarable. Thus, our approach strikes a balance between generalization and the provision of the context of extracted subgraphs.

Our approach extends the traditional CFG representation by generalizing neighboring variable definitions and usages. Conventionally, data dependence analysis forms edges to depict the dependence of a variable’s usage on its latest definition. However, this does not provide spatial information and can lead to edges connecting nodes far apart in the original source code. In this study, we aim to extract idioms consisting of neighboring CFG nodes to be considered as syntactic sugar opportunities. An example of a sugarable idiom consisting of neighboring information is the Elvis operator (?:) in Kotlin, where the syntactic sugar implicitly checks if a variable’s value is null, and if so, evaluates to a second specified value. Usage of this syntactic sugar in an assignment statement is shown in Figure 12. When considering the desugared equivalent of the Elvis operator, it’s crucial to know that the same variable is both used (checked against null) and redefined (assigned to provided value) in separate expressions. This highlights how syntactic sugars can simplify neighboring code idioms that involve the same data, which is not captured by traditional data dependence.

To address this, we modify the neighboring edges in the CFG to carry additional data context. Our approach introduces four types of edge modifiers: DEF-DEF, DEF-USE, USE-DEF, and USE-USE. These edge modifiers represent whether the source node defines or uses a variable defined or used in the destination node. By incorporating this generalized information, our approach captures important local relationships between expressions, making it easier to identify and motivate syntactic sugars with the applied context while still generalizing these cases to enable large-scale subgraph mining. One such data edge, USE-DEF, is shown in our generalized CFG of Kotlin’s Elvis operator’s desugared Java equivalent in Figure 12.

A weakness of frequent subgraph mining is the dependence on the user-defined threshold to determine whether a subgraph appears in enough graphs to be considered frequent. Therefore, we choose to leverage a different programming language’s established syntactic sugars to mine a threshold of potential syntactic sugar use cases: Kotlin, a programming language that compiles into the Java Virtual Machine (JVM) was created as an alternative to Java when creating Android applications and contains syntactic sugars that Java does not. We identify 4 syntactic sugars in Kotlin that do not have a Java equivalent (string interpolation, Elvis operator, getter and setter properties, and not-null assertion). Since Java does not contain these syntactic sugars, we consider what their desugared equivalents, the expanded form of the syntactic sugar, would appear as in Java. Following this, our Java dataset is mined for how often these desugared Kotlin syntactic sugars appear. Thus, any subgraph that appears at least as often as the least frequently appearing desugared syntactic sugar from Kotlin is viewed as a candidate for syntactic sugar.

Although mining Kotlin syntactic sugars may bias our results towards Kotlin-like syntactic sugars as opposed to Java-like syntactic sugars, the four chosen syntactic sugars, despite being selected from Kotlin, are not exclusive to Kotlin and are also present in multiple programming languages. For example, string interpolation, one of the selected syntactic sugars, is not unique to Kotlin and can also be found in other languages such as Python, Scala, and Swift, among others. Similarly, getter and setter properties, another selected sugar, are present in C#. Additionally, the not-null assertion appears in TypeScript, and null-handling syntactic sugars similar to Kotlin’s Elvis operator can be found in C# and Ruby, albeit under different names. In doing so, although the syntactic sugars were chosen from a similar language to Java, we aim to reduce bias by mining those syntactic sugars in Kotlin which are language agnostic.

The results of our experiment are shown in Table 2, with not-null assertion being the least frequent, appearing in 0.061% of methods. We use this as our threshold for frequent subgraph mining since any code idiom that appears more often would be at least as impactful on existing code as implementing the not-null assertion syntactic sugar from Kotlin. Although there might be other desugared syntactic sugars not mined that appear less often than the not-null assertion, using a lower threshold would only add more subgraphs to our results, but all subgraphs presented in this paper would still be considered frequent.