Core FOBS: A hybrid functional and object-oriented language

Abstract. At a fundamental level, functional and object-oriented programming languages are all ‘higher-order’, in the sense that they support computing with values that are themselves pieces of program code encapsulated with a local environment. In functional languages these ‘active’ values are functions, while in object-oriented languages they are objects. Both styles of higher-order language claim to provide good support for writing adaptable programs, but functional and object-oriented languages achieve this adaptability in different ways: functional programs rely on parameterisation at the value, type and module level, while object-oriented languages rely primarily on subtyping and implementation inheritance. Here we compare these two approaches, mainly in terms of the features and properties of their type systems, and consider the benefits and disadvantages of unifying (or merging) the two paradigms by adding object-oriented features to ML as a base language. We argue that while some of the simpler aspects of object-oriented languages are compatible with ML, adding a full- edged class-based object system to ML leads to an excessively complex type system and relatively little expressive gain, especially if we aim to preserve that mostly functional style of programming that is a major advantage of ML.

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.

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.

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.

A language FOBS-X (Extensible FOBS) is described.This language is an interpreted language, intended as a universal scripting language.An interesting feature of the language is its ability to be extended, allowing it to be adapted to new scripting environments.The interpretation process is structured as a core-language parser back-end, and a macro processor frontend.The macro processor allows the language syntax to be modified.A configurable library is used to help modify the semantics of the language, adding the required capabilities for interacting in a new scripting environment.This paper focuses on the macro capability of the language.A macro extension to the language has been developed, called the standard extension, that gives FOBS-X a friendlier syntax.It also serves as a convenient tool for demonstrating the macro expansion process.

Lua is a scripting language used in many industrial applications, with an emphasis on embedded systems and games. Two key points in the design of the language that led to its widely adoption are flexibility and small size. To achieve these two conflicting goals, the design emphasizes the use of few but powerful mechanisms, such as first-class functions, associative arrays, coroutines, and reflexive capabilities. As a consequence of this design, although Lua is primarily a procedural language, it is frequently used in several different programming paradigms, such as functional, object-oriented, goal-oriented, and concurrent programming, and also for data description.In this paper we discuss what mechanisms Lua features to achieve its flexibility and how programmers use them for different paradigms.KeywordsFunctional ProgrammingConcurrent ProgrammingTuple SpaceAlternative GoalProcedural LanguageThese 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.

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.

The students' over reliance upon formulas and routine use of technique in problem solving too often lead to poor performance in advanced courses and a high attrition rate in the engineering, technology, and science programs. The students' lack of comprehension of mathematical concepts results in time wastage during laboratory experiments, misinterpretations of lab data and underachievement in standardized science and engineering tests that stress the fundamentals. This problem can be effectively addressed by improving the student's conceptual understanding and comprehension of the topics covered in introductory science and technology courses. One way to achieve this is through interactive learning and teaching and upgrading the existing laboratories with modern equipment. This will require increased funding and resources. But in recent years there is a decrease in resource allocation making it increasingly difficult to modernize the laboratories to provide adequate levels of laboratory and course work and universities are under pressure to look for alternative cost effective methods. One way to achieve this is through interactive learning and teaching through the use of software packages like LabVIEW (Virtual Instruments) and Java/Visual Basic (Object Oriented Programming).LabVIEW and Java/Visual Basic are currently used in a number of engineering schools and industries for simulation and analysis. By introducing virtual instrumentation (LabVIEW) and object oriented programming (Java/Visual Basic) to the existing laboratory facilities and course(s) the students can be well trained with the latest design techniques and computer aided instrumentation, design and process control used throughout industry. This will also allow the students greater interaction with the subject matter and improve his/her skills in the use of number of applied engineering software packages.LabVIEW is based on graphical programming and easy to use. It is an interactive problem-solving environment, where the students can analyze, visualize, and document real-world science and engineering problems. A number of books are available covering the use and application of LabVIEW.LabVIEW also provides an extensive library of virtual instruments and functions to help in programming. It also contains application specific libraries for data acquisition, GPIB and serial instrument control, data analysis, and file input/output with conventional program debugging tools that can be used to set breakpoints, single-step through the program, and animate the execution so that the flow of data can be observed.At South Carolina State University (SCSU), the PC and VI based system concept is used to design and develop a laboratory called Computer Based Virtual Engineering Laboratory (CBVEL). The CBVEL consists of IBM compatible computers with appropriate software and hardware from National Instruments (NI), Simulation software such as C++, Visual Basic, Java, PSPICE, etc., and is connected to School of Engineering Technology and Sciences (SETS) network and existing equipment. Virtual Instrument (VI) and Object Oriented Programming modules for different courses and research areas are currently developed and used to teach various courses. Examples of some of these VIs are Circuit Analysis, Electronics, Communications, Digital Signal processing, Networking, and Digital Filters.This paper discusses design and development of some of the modules such as Number Systems, Internet Protocol Addresses, Address Classes, Subnet Masks, and Sub-netting using LabVIEW and Visual Basic/Java.

MultiJava is a conservative extension of the Java programming language that adds symmetric multiple dispatch and open classes. Among other benefits, multiple dispatch provides a solution to the binary method problem. Open classes provide a solution to the extensibility problem of object-oriented programming languages, allowing the modular addition of both new types and new operations to an existing type hierarchy. This article illustrates and motivates the design of MultiJava and describes its modular static typechecking and modular compilation strategies. Although MultiJava extends Java, the key ideas of the language design are applicable to other object-oriented languages, such as C# and C++, and even, with some modifications, to functional languages such as ML.This article also discusses the variety of application domains in which MultiJava has been successfully used by others, including pervasive computing, graphical user interfaces, and compilers. MultiJava allows users to express desired programming idioms in a way that is declarative and supports static typechecking, in contrast to the tedious and type-unsafe workarounds required in Java. MultiJava also provides opportunities for new kinds of extensibility that are not easily available in Java.

General Information Quick Overview This chapter is not a comprehensive manual of Python. Its sole aim is to provide sufficient information to give you a good start if you are unfamiliar with Python. If you know another computer language, and presumably you do, it is not difficult to pick up the rest as you go. Python is an object-oriented language that was developed in late 1980s as a scripting language (the name is derived from the British television show Monty Python's Flying Circus). Although Python is not as well known in engineering circles as some other languages, it has a considerable following in the programming community—in fact, Python is considerably more widespread than Fortran. Python may be viewed as an emerging language, since it is still being developed and refined. In the current state, it is an excellent language for developing engineering applications—it possesses a simple elegance that other programming languages cannot match. Python programs are not compiled into machine code, but are run by an interpreter . The great advantage of an interpreted language is that programs can be tested and debugged quickly, allowing the user to concentrate more on the principles behind the program and less on programming itself. Since there is no need to compile, link and execute after each correction, Python programs can be developed in a much shorter time than equivalent Fortran or C programs.

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.

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.

Scala is a new programming language bringing together object-oriented and functional programming. Its defining features are uniformity and extensibility. Scala offers great flexibility for programmers, allowing them to grow the language through libraries. Oftentimes what seems like a language feature is in fact implemented in a library, effectively giving programmers the power of language designers. The downside of this flexibility is that familiar looking code may hide unexpected performance costs. It is important for Scala compilers to bring down this cost as much as possible. We identify several areas of impact for Scala performance: higher-order functions and closures, and generic containers used with primitive types. We present two complementary approaches for improving performance in these areas: optimizations and specialization. Compiler optimization can bring down the cost through a combination of aggressive inlining of higher-order functions, an extended version of copy-propagation and dead-code elimination. Both anonymous functions and boxing can be eliminated by this approach. We show on a number of benchmarks that these language features can be up to 5 times faster when properly optimized, on current day JVMs. We propose a new approach to compiling parametric polymorphism for performance at primitive types. We mix a homogeneous translation scheme with user-directed specialization for primitive types. Type parameters may be annotated to require specialization of code depending on them. We propose definition-site specialization for primitive types, achieving separate compilation and no boxing when both the definition and call site are specialized. Specialized classes are compatible with unspecialized code, and specialization agnostic code can work with specialized instances, meaning that specialization is opportunistic. We present a formalism of a small subset of Scala with specialization and prove that specialization preserves types. We implemented this translation in the Scala compiler and report on improvements on a set of benchmarks, showing that specialization can make programs more than two times faster.