This study explores the use of Code Churn and Pattern Size (PSIZ) metrics to identify bug-prone areas in Haskell codebases. The primary research questions addressed are whether these metrics can effectively predict areas of code instability and potential bugs. Our contributions include a comprehensive analysis of these metrics across three large Haskell projects, examining the correlation between high metric values and documented bugs. Our findings reveal that Code Churn is a significant indicator of potential bugs, with ’buggy’ files showing markedly higher mean code churn values. However, the PSIZ metric proved ineffective in predicting bug-prone areas, as the mean and median values for both projects and ’buggy’ files were similar and low. These results suggest that while Code Churn is a useful metric for identifying unstable code areas, PSIZ does not offer the same predictive value. Future research should expand the dataset and consider additional metrics to enhance the reliability of these findings.

The classification of bugs in functional languages is an understudied area, as opposed to imperative counterparts, such as Java. This paper acts as an initial step to cover this gap into two complementary directions. First, a dataset of 142 bugs from 10 Haskell FOSS repositories have been classified according to two taxonomies from literature in order to assess how well they handle the differences in programming paradigms. Based on our bug classifications, the first taxonomy has very little variance in types of bugs, with 86% of bugs being classified in the same category. On the other hand, the second taxonomy showed more potential as the bugs were more balanced between categories, but with occasional difficulties in classification, as some bugs fitted more than one type. Second, we performed interviews with four Haskell developers about their experience with bugs and the usefulness of these taxonomies in practice. They argued that while such taxonomies can prove useful, the context in which it is being used is more important. Thus, circumstances such as the size of the project and team, and stages of development need to be taken in consideration before trying to apply any taxonomy.

Haskell programming language has a long history of extensions which extend and
modify its syntax and semantics. They range from small quality-of-life syntax im-
provements, to complete overhauls of the type system. Such extensions are commonly
implemented directly as a part of Glasgow Haskell Compiler (GHC) or as plugins for
GHC through its plugin API. This paper looks at the present ecosystem of such lan-
guage extensions, identifying the key categories into which extensions can be separated,
based on how often and in which ways they are used, and their functionality.
We analysed which extensions are used in packages uploaded to Hackage, a central
open-source Haskell archive. We further extracted the metadata about the packages,
including the user-submitted tags and maintainer lists, to ascertain how and when are
language extensions used.
The result of our research is a combination of several proposed potential taxonomies,
that can be used by academics and practitioners alike.

Various studies already exist about the lifecycle of software programs written in languages like Java, C and C++, but this is an under-reported area for the pure, functional programming language Haskell. This report explores steps in the development of Haskell programs, and particularly, of their bugs. By gaining more knowledge about a bug’s development and its different stages, possible patterns or trends can be found. Using these insights, developers could get a better understanding of the development process, and optimise it. The main question of the research is formulated as ‘What are the different stages of bugs in Haskell programs?’. We consider three different stages: bug introduction, bug detection and bug fixing. To gain more knowledge about these stages, different open-source Haskell repositories, and their bugs were analysed. We found the median time between the bug introduction and detection is 381 days. The median time between the bug detection and fixing turned out to be 3 days. Most bugs were detected and fixed at similar rates regardless of their complexity, except for bugs that were detected by the same developer who introduced the bug. In this case, the time it takes to detect the bug is 30% of the global median. These results motivate developers to check their code more extensively, as they detect bugs quicker than other developers would. It also motivates developers to work with shared code ownership, as having more developers familiar with the code should reduce bug-detection time. Moreover, this study shows that single-statement bugs, which needed a simple fix, occur 2.5 times more often in code when no test is written, which argues for developers to write more test code. Lastly, we recommend repository owners to be more strict with developers working structured and precisely so that they follow Git’s and the repository’s standards and write test code.

Machine learning models are increasingly being used within software engineering for their predictions. Research shows that these models’ performance is increasing with new research. This thesis focuses on models for method name prediction, for which the goal is to have a model that can accurately predict method names. With this thesis, we could create a tool that can suggest method names to software developers, which would assist in improving the quality of the projects.
This research aims to get insight into the robustness vulnerabilities of a method name prediction model. We use a genetic search algorithm that looks for these robustness problems. The main question this thesis tries to answer is to what extent the performance metrics are affected by applying metamorphic transformations to the test set of a trained code2vec model. Besides this, this thesis also proposes an alternative metric called percentage MRR, which might better reflect the robustness of a model. The main idea behind this metric is that it penalizes the prediction certainty of a model instead of penalizing the prediction rank.
To answer this research question, a tool is created that runs a genetic algorithm applying these metamorphic transformations to a dataset that a trained model is then evaluating. With this tool, we conducted 22 genetic search experiments on primary metrics and combinations of metrics to see the trade-offs in the Pareto fronts. The guided search of applying metamorphic transformations on the test set results in an average performance decrease of around 19%. This thesis also compares this drop in performance to the performance decrease a random search algorithm would create. Notably, for every transformer added, the average decrease in performance becomes smaller, and there are transformations, e.g., the if-false-else transformation, that have a bigger effect than others. This thesis concludes that the trained model is not robust against metamorphic transformations and has a significant performance drop.

Machine learning (ML) algorithms have been used frequently in the past years for Software Engineering tasks.
One of the popular tasks researchers use is method name prediction, which helps them generate an identifier for methods with ML models such as Code2Seq.
This model represents code snippets as Abstract Syntax Trees (AST) and includes all code elements except comments.
This paper introduces a novel approach to incorporating comments in Code2Seq.
The reimplemented models integrate comments into the AST when preprocessing the data.
We filtered comments to reduce the noise introduced in the model and improve the predictions using techniques such as TF-IDF and stopword removal.
We implement several models for each filtering technique and one for raw comments.
These models are trained and evaluated using the dataset java-small, provided by Code2Seq, with 700K examples and the following metrics: precision, recall, and F1.
The results obtained from the evaluation of our model with raw comments show an improvement of 3.62% and 2.36% in precision and F1, respectively, on method name prediction compared to the original model.
Furthermore, the model with stopword removal has a 6% and 3.52% gain in recall and F1. These improvements suggest that adding comments to Code2Seq is valuable for better method name predictions since they contain additional information about the methods.

AI-assisted development tools use Machine Learning models to help developers achieve tasks such as Method Name Generation, Code Captioning, Smart Bug Finding and others. A common practice among data scientists training these models is to omit inline code comments from training data. We hypothesize that including inline comments in the training code will provide more information to the model and improve the model's performance for natural-language related tasks, specifically Code Captioning. We adjust one of these models, code2seq, to include inline comments in its data processing, then train and compare it to a commentless version. We find that including inline comments tends to increase the performance of the model by making it faster and producing more verbose results, and then reflect on the results of this work to formulate suggestions on how to improve upon this body of research.

A number of Machine Learning models utilize source code as training data for automating software development tasks. A common trend is to omit inline comments from source code in order to unify and standardize the examples, even though the additional information can capture important aspects and better explain algorithms. We claim that models, utilizing the supplementary data, are able to produce more fluent translations for Automatic Documentation Generation task. We test this by creating two datasets and measuring the performance difference. The results show that there is a slight improvement in translation accuracy when a dataset contains inline comments, with stop words removed. Further research needs to be done to optimize the preprocessing of data and to more accurately detect the scope of inline comments.