Should ML be Object-Oriented?

This thesis proposes a novel way of performing type checking, whose results are incremental, depending on the provided local information. This new way of type checking is called co-contextual, where all context information of expressions, methods, classes, etc., is removed. Instead, we introduce corresponding structures using requirements. Standard type systems are translated to the co-contextual ones systematically using dualism as technique. Type systems play an important role to prevent execution errors from occurring during runtime. They are used to check programs statically for potential errors. Programs are type checked against a given set of rules. Depending on these rules programs are well-typed or not. The set of these rules is called typing rules. Each type rule associates types to the constructs of a program given a certain context. There can be different forms of contexts, depending on the features of the typed programming language. Functional languages use a typing context of variables and their types; object-oriented (OO) languages use additional class tables. Class tables are used for example to ensure that method and class declarations are well-typed. Type checking is performed top-down. While traversing the syntax tree of a program, typing contexts are extended with information on the expressions and their types. In case of OO, class tables are extended with clauses from class declarations, including the class members, i.e., fields, methods, or constructors. Contexts are passed through the nodes of the syntax tree in order to coordinate type checking between them. Therefore, while traversing the syntax tree top-down, the type checker creates dependencies between otherwise independent subexpressions. This way, it inhibits incrementalization and parallelization of type checking. That is, a change to a node of the syntax tree would require to redo the type check of the whole syntax tree. In this thesis a novel formulation of type systems is proposed, in order to remove dependencies between subexpressions. We propose a co-contextual formulation of typing rules that depends only on the local program constructs, e.g., expressions, methods, classes. The co-contextual typing rules have as conclusion a type and sets of requirements. That is, contexts and class tables are replaced by the dual concept of context and class table requirements. In addition, operations on contexts and class tables are replaced by new dual operations on requirements. The co-contextual type checker traverses a syntax tree bottom-up and merges context requirements of independently checked subexpressions. We describe a method for systematically constructing a co-contextual formulation of type rules from a regular context-based formulation and we show how co-contextual type rules give rise to incremental type checking. We derive co-contextual type checkers for functional and OO languages. As a representative of functional languages we consider PCF and extensions of it: records, parametric polymorphism, structural subtyping and let-polymorphism. Also, we investigate featherweight java (FJ) as the basis of OO languages and extensions of it: method overloading and generics. We build a1 co-contextual type checker for FJ enabling key features of OO languages: subtype polymorphism, nominal typing and implementation inheritance. The dualism between the co-contextual and contextual type systems preserves the correctness of the contextual calculus. That is, we prove the correctness of the co-contextual calculus via the equivalence between contextual type rules and their co-contextual formulations. We implemented an incremental type checker for PCF along with a performance evaluation showing that co-contextual type checking has performance comparable to standard context-based type checking, and incrementalization can improve performance significantly. Regarding FJ, we implemented a co-contextual type checker with incrementalization and compared its performance against javac on a number of realistic programs. Our performance evaluation shows significant speedups for the co-contextual type checker with incrementalization in comparison to javac.

Object-oriented programming languages are suitable for describing real-world objects, functional programming languages for algebraic values. In this paper we propose an object-oriented functional programming language, called TOFL, which combines many desired properties of the two paradigms. In particular, TOFL unifies object classes, inheritance, (method) redefinitions and late binding as in object-oriented languages, algebraic data types, higher-order functions, type classes and type inference (without type reconstruction in this paper) as in functional languages. We translate TOFL into a stratified and explicitly typed λ-calculus T with overloaded functions, where redefinitions and late binding become late binding of overloaded functions. The operational semantics of T gives a semantics and a simple prototyping implementation of TOFL.

Functional programming languages are well-suited for developing compilers, and compilers for functional languages are often themselves written in a functional language. Functional abstractions, such as monads, allow abstracting away some of the repetitive structure of a compiler, removing boilerplate code and making extensions simpler. Even so, functional languages are rarely used to implement compilers for languages of other paradigms.

Concurrency has been with us almost from the beginning of computing. Managing and programming for concurrency is a difficult problem and various solutions have been suggested over the years. Debates on message passing vs. remote procedure call, synchronous vs. asynchronous message passing, bounded vs. unbounded buffers, active vs. passive objects etc. still continue. No solution is entirely satisfactory. Concurrent programming usually depends heavily on the nature of the problem at hand and the architecture of the target machine.

The generic programming approach is popular in functional languages (for example, OCaml, Haskell). In essence, it is a compile-time generation of code that performs transformations of user-defined data types. The generated code can carry out various kinds of transformations of the values. Usually, transformations are represented as functions that implement algorithms of transformation. New transformations could be built from these transformation functions and user-defined ones. The representation based on functions has a downside: functions behave as final representations, and hence it is not possible to modify the behavior of the already built function. If the current set of transformations does not suit well, software developers are obliged to write a completely distinct transformation, even in the case when the new transformation is almost identical to the existing one. This work proposes to build transformations that are extensible after construction. The object-oriented programming paradigm will be followed, transformations will be represented not as functions but as objects. Instead of calling a transformation function, one of the object’s methods will be called. The transformation itself will be split into methods. The extensibility is supported by adding new methods and overriding existing ones. In this paper, the authors propose an approach to represent transformations as objects in the OCaml functional programming language. Every alternative in data type definition has a corresponding object method. This design allows the construction of many distinct transformations. The cases where too many methods are not desirable are also discussed. The method is applicable to represent extensible transformations for polymorphic variant data types in OCaml when other methods fail to do it. The method is not bound to any particular domain. It allows the creation of extensible transformations in OCaml. It could be ported to other functional languages supporting object-oriented programming.

The Second International Workshop on Trends in Functional Programming in Education, TFPIE 2013, was held on May 13, 2013 at Brigham Young University in Provo, Utah, USA. The goal of TFPIE is to gather researchers, professors, teachers, and all professionals interested in functional programming in education. Submissions were vetted by the TFPIE 2013 program committee using prevailing academic standards. The 2 articles in this volume were selected for publication as the result of this process. Tobin-Hochstadt and Van Horn report on their solution to the difficult transition between the first semester course in functional programming (using languages, programming environment, etc. intended for teaching) to the second semester course in object-oriented programming (with a production-oriented language, environment, etc.). Finding that this confusing circumstance made the key concepts hard to grasp for students, the authors present and evaluate a new introduction to the second semester course, based on the environment and languages the students used before, that focusses on key object-oriented concepts. Caldwell lays out an education narrative that focusses on reasoning about programs, using structural induction principles. He argues that more such formal reasoning should get more emphasis in programming education and demonstrates the feasibility thereof by reporting on his experiences using this narrative in the functional programming course at the University of Wyoming.

Dynamic type-checking and object-oriented programming often go hand-in-hand; scripting languages such as Python, Ruby, and JavaScript all embrace object-oriented (OO) programming. When scripts written in such languages grow and evolve into large programs, the lack of a static type discipline reduces maintainability. A programmer may thus wish to migrate parts of such scripts to a sister language with a static type system. Unfortunately, existing type systems neither support the flexible OO composition mechanisms found in scripting languages nor accommodate sound interoperation with untyped code. In this paper, we present the design of a gradual typing system that supports sound interaction between statically- and dynamically-typed units of class-based code. The type system uses row polymorphism for classes and thus supports mixin-based OO composition. To protect migration of mixins from typed to untyped components, the system employs a novel form of contracts that partially seal classes. The design comes with a theorem that guarantees the soundness of the type system even in the presence of untyped components.

Current (heterogeneous) multi-core environments such as gpGPU architectures are hard to program with normal imperative and object-oriented (OO) languages. There are two basic problems to tackle: (1) it is too easy to program race conditions and dead-locks with the available synchronization primitives, and (2) these environments do not support (or support inefficiently) the instructions required for efficient execution of OO programs, e.g., because function pointers and pointer arithmetic are lacking. We address both problems with a new language that comprises both Functional Programming (FP) and OO programming. We solve problem (1) by auto-parallelization in the functional core where all loops and non-dependent calls can be executed in parallel. FP is to be used to write computational intensive code with safe concurrent memory access. An alternative object model that does neither use pointer arithmetic nor function pointers but smart pointers/proxies (to implement polymorphism) as well as mixins and templates (to implement OO like code reuse) solves problem (2). To cleanly integrate the two language cores, we propose a new integration model that even grants some restricted ways to access state from within FP mode. With the new language and prototype compiler we can transparently parallelize code to target both Cuda and multi-core machines (without annotations from the programmer) and obtain good speedups.

Functional programming (FP) is regularly touted as the way forward for bringing parallel, concurrent, and distributed programming to the mainstream. The popularity of the rationale behind this viewpoint has even led to a number of object-oriented (OO) programming languages outside the Smalltalk tradition adopting functional features such as lambdas and thereby function closures. However, despite this established viewpoint of FP as an enabler, reliably distributing function closures over a network, or using them in concurrent environments nonetheless remains a challenge across FP and OO languages. This paper takes a step towards more principled distributed and concurrent programming by introducing a new closure-like abstraction and type system, called spores, that can guarantee closures to be serializable, thread-safe, or even have custom user-defined properties. Crucially, our system is based on the principle of encoding type information corresponding to captured variables in the type of a spore. We prove our type system sound, implement our approach for Scala, evaluate its practicality through a small empirical study, and show the power of these guarantees through a case analysis of real-world distributed and concurrent frameworks that this safe foundation for closures facilitates.

Hosting functional languages in object-oriented environments, such as the Java Virtual Machine and Microsoft's Common Language Infrastructure, so that they inter-operate well with other languages presents a number of problems. In the paper the authors introduce Mondrian, a functional language specifically designed for such environments, and describe the decisions and trade-offs in its design. The paper concentrates on the high-level design decisions made for Mondrian. The authors cover the design of a type system which is part-way between the traditional parametric polymorphism and sum type models of functional languages and the sub-type models used by the virtual machines. Next they discuss how function values and nonstrict evaluation can be provided while supporting easy inter-working with strict object-oriented languages. They briefly comment on the low-level implementation of Mondrian and conclude with a multi-language example using Mondrian and C#. The work shows that, with appropriate design, it is possible to combine functional and object-oriented programming without losing the unique benefits of each.

Automation software systems usually implement the IEC 61131-3 and IEC 61499 standards. Nowadays, these applications request, among others, reusability, flexibility, reliability, and modularity via both standards. These characteristics can be achieved by a traditional paradigm called Object-Oriented Programming (OOP). OOP is an older method that applied with various programming languages to generate a replicable style of programming, i.e., code composed by Functions, Methods, etc. A well-defined programming method makes the code understandable for programmers. OOP defines the reusability, accessibility, adaptability, and robustness of software programs. It means that using gradual methods gained experience improves the quality of programs and simplifies their organization. OOP also increases the security of applications from its core features, i.e., Abstraction, Instantiation, Encapsulation, Polymorphism, and others. Therefore, OOP has been applied and discussed for both standards; however, OOP’s complexity and implementation using these IEC standards have not been compared yet. This work proposes the typical application of the Function Block (FB) to define classes and objects for industrial automation systems based on OOP. We implement one particular case of study for both standards. The FB employments are evaluated in order to compare OOP applicability and advantages of each standard. Adapting automation software regarding new industry requirements implies greater modularity. Code programmed by OOP generates abstractions levels which improve the design and make the software application in maintenance more comfortable to read and more adaptable to future extensions. This research shows how both standards (their latest updates) address OOP. Object-oriented programs in the field of automation engineering face another paradigm shift that impacts the methods used to program control systems. OOP would facilitate the design patterns implementations, which are a reusable understanding of common problems.

Many languages offer different ways to model using structures to represent the solution to a particular problem in the real world. With Scala, you can use two methods of modelling: object-oriented programming (OOP) and functional programming (FP). They share some structures with different meanings but the idea is to define attributes and behavior. As you read in the previous chapter, languages like Java, JavaScript, Python, C++, C#, Ruby, and PHP use OOP as the default modelling option or paradigm.

Swift is Apple’s new programming language intended to be the future replacement of Objective-C for Mac and iOS development. Some people are referring to it as a functional programming language, but it is actually an object-oriented programming language with a healthy dose of generic programming.

In this paper we investigate the addition of first-class relationships to a prototypical object-oriented programming language (a “middleweight” fragment of Java). We provide language-level constructs to declare relationships between classes and to manipulate relationship instances. We allow relationships to have attributes and provide a novel notion of relationship inheritance. We formalize our language giving both the type system and operational semantics and prove certain key safety properties.KeywordsOperational SemanticType SoundnessMethod BodyRelationship InheritanceSubject ReductionThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Developing a general component system for a statically typed, object-oriented language is a challenging design problem for two reasons. First, mutually recursive references across components are common in object-oriented programs-an issue that has proven troublesome in the context of component systems for functional and procedural languages. Second, inheritance across component boundaries can cause accidental method overrides. Our recent research shows that a component framework can be constructed for a nominally typed object-oriented language supporting first-class generic types simply by adding appropriate annotations, syntactic sugar, and component-level type-checking. The fundamental semantic building blocks for constructing, type-checking and manipulating components are provided by the underlying first-class generic type system. To demonstrate the simplicity and utility of this approach we have designed and implemented an extension of Java called Component NEXTGEN (CGEN). CGEN, which is based on the Sun Java 5.0 javac compiler, is backwards compatible with existing Java binary code and runs on current Java Virtual Machines. The primary contribution of this paper is a technical analysis of the subtle design issues involved in building a component framework for a nominally typed object-oriented language supporting first-class generics. In contrast to component systems for structurally typed languages, mutual recursion among components is accommodated in the type system and semantics without incorporating any special machinery. Our analysis includes a presentation of Core CGEN (CCG), a small, core language modeling the CGEN framework. It is based on Featherweight GJ and incorporates some ideas from MIXGEN. CCG adds the essential features to support components, but nothing more. Our discussion includes the type rules and semantics for CCG, as well as a proof of type safety.