abstract: Graph theory is a critical component of computer science and software engineering, with algorithms concerning graph traversal and comprehension powering much of the largest problems in both industry and research. Engineers and researchers often have an accurate view of their target graph, however they struggle to implement a correct, and efficient, search over that graph. To facilitate rapid, correct, efficient, and intuitive development of graph based solutions we propose a new programming language construct - the search statement. Given a supra-root node, a procedure which determines the children of a given parent node, and optional definitions of the fail-fast acceptance or rejection of a solution, the search statement can conduct a search over any graph or network. Structurally, this statement is modelled after the common switch statement and is put into a largely imperative/procedural context to allow for immediate and intuitive development by most programmers. The Go programming language has been used as a foundation and proof-of-concept of the search statement. A Go compiler is provided which implements this construct. / Dissertation/Thesis / Masters Thesis Software Engineering 2018

We analyse the semantics of aspect-oriented extensions to functional languages by presenting compositional translations of these primitives into languages with traditional notions of state and control. As a first step, we examine an existing semantic description of aspects which allows the labelling of program points. We show that a restriction of these semantics to aspects which do not preempt the execution of code can be fully abstractly translated into a functional calculus with higher order references, but that removing this restriction requires a notion of exception handling to be added to the target language in order to yield a sound semantics. Next, we proceed to show that abandoning the labelling technique, and consequently relaxing the so-called ``obliviousness'' property of aspectual languages, allows preemptive aspects to be included in the general references model without the need for exceptions. This means that the game model of general references is inherited by the aspect calculus. The net result is a clean semantic description of aspect-orientation, which mirrors recently published techniques for their implementation, and thereby provides theoretical justification for these systems. The practical validity of our semantics is demonstrated by implementing extensions to the basic calculus in Standard ML, and showing how a number of useful aspect-oriented features can be expressed using general references alone. Our theoretical methodology closely follows the proof structure that often appears in the game semantics literature, and therefore provides an operational perspective on notions such as ``bad variables'' and factorisation theorems.

Bugs in software is a very common problem, code reviews can help to catch bugs early on and detect which code is the most complex and may introduce bugs but when the code base is very large it can be costly to review all the code. Cyclomatic complexity can be used to give an indication of how complex the system source code is and help the developers to select which code they should review. But when measuring cyclomatic complexity on code written according to the functional paradigm, McCabe’s formula will not be sufficient since it is a formula most suitable for imperative code. Therefore we are making adaptations to a formula suited for pure functional languages in order to fit functional JavaScript. We are using an inductive empirical quantitative measurement method to calculate cyclomatic complexity on a directed graph implementation in order to define adaptations for functional JavaScript. Our results show a working adapted version of the formula. We have measured on a graph implemented in Haskell and on a corresponding functional JavaScript version which results in a cyclomatic complexity difference at only 0.375.

[pt] Se diz que uma linguagem de programação tem funções de primeira classe quando ela fornece a capacidade de manipular funções da mesma maneira que outros valores, isto é, guardar em variáveis, passar como parâmetros, etc.. Programar com funções de primeira classe abre o programadora novas formas de abstração e é o padrão em linguagens de programação funcionais. Porém, se tratando de linguagens imperativas (incluindo linguagens orientadas a objeto), cada linguagem tem semântica, propriedades e terminologia diferentes para funções—em grande parte graças a seu foco em mutabilidade, que as linguagens funcionais não têm. Para esclarecer essas diferenças, nós fizemos um levantamento sobre a especificação de funções como valores em linguagens de programação imperativas de várias disciplinas diferentes. Para cada linguagem, nós ilustramos, nos baseando em exemplos, as propriedades dos valores de funções nela,destacando onde ela difere de outras linguagens—tudo isso usando uma terminologia consistente em todas as linguagens. Nós esperamos oferecer uma referência para desenvolvedores compararem e contrastarem as diferentes versões de funções num só lugar. / [en] A programming language is said to have first-class functions when it provides the capability of manipulating functions in the same way as other values, i.e., storing in variables, passing as parameters, etc.. Programming with first-class functions opens the programmer to new forms of abstractions and it s the default in functional programming languages. However, in the realm of imperative languages (including object-oriented languages), each language has different semantics, properties, and terminology for functions—in great part, thanks to their focus on mutability, which isn t present in functional languages. To help shed light on these differences, we made a survey of the specifi-cation of function values in imperative programming languages from many different disciplines. For each language, we illustrate, based on examples,the properties of function values in it, highlighting where it differs from other languages—all this with a consistent terminology in all languages. We provide a reference that compares and contrasts different renditions offunctions in one single place and conclude that the design of functions in a language depends on the interaction of its features and constraints with its functions.