Can Programming Be Liberated from the Functional Style?

This paper explores the theory and implementation of ray tracing in OCaml. We discuss the mathematical concepts and algorithms that drive the rendering process, followed by implementation using OCaml’s functional programming paradigm. Our analysis compares the merits and challenges of functional versus object-oriented (OO) approaches, highlighting the advantages of code clarity, static type safety, and ease of debugging in a functional style. With the development of functional programming module, it has been established that the debugging cost is higher in object oriented module. In this context the functional module can identify the errors at the time of compilation and we establish this fact with the development of code using OCaml. We also address performance considerations related to recursive function calls and state management complexities. Ultimately, we advocate for implementing a basic ray tracer in a functional style, demonstrating that this approach enhances code quality while aligning with the principles of immutability and strong typing.

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.

If you look at the examples and exercises presented so far in this book you can see that we fluctuate between two styles of programming: [statement1] // do something [statement2] // do something [statement3] // do something …

A functional data structure is a data structure that is suitable for implementation in a functional programming language, or for coding in an ordinary language like C or Java using a functional style. Functional data structures are closely related to persistent data structures and immutable data structures—in fact, the three terms are often used interchangeably. Howevber, there are subtle differences. The term persistent data structures refers to the general class of data structures in which an update does not destroy the previous version of the data structure, but rather creates a new version that co-exists with the previous version. See Chapter 33 for more details about persistent data structures. The term immutable data structures emphasizes a particular implementation technique for achieving persistence, in which memory devoted to a particular version of the data structure, once initialized, is never altered. The term functional data structures emphasizes the language or coding style in which persistent data structures are implemented. Functional data structures are always immutable, except in a technical sense discussed in Section 41.4.

In this paper, we discuss the cost of functional classes design style. Functional classes merge both object-oriented and functional programming paradigms; a functional class is a class without variables. Because of this, the methods in functional classes are true functions. Functional classes design style aims at improving reliability and program correctness. However, resulting program code is not optimal when considering the performance. As the main contribution, we analyze here the performance of functional classes in Java. We study especially the cost of recursive method calls. As the case study, we analyze an implementation of the cartesian product operation in a lightweight data mediator. The analysis confirms that functional classes design style leads to implementations that make poor use of HotSpot. However, the analysis also indicates how to restructure a functional class to improve the performance.

Lazy narrowing with simplification

In functional logic programs, rules are applicable independently of textual order, i.e., any rule can potentially be used to evaluate an expression. This is similar to logic languages and contrary to functional languages, e.g., Haskell enforces a strict sequential interpretation of rules. However, in some situations it is convenient to express alternatives by means of compact default rules. Although default rules are often used in functional programs, the non-deterministic nature of functional logic programs does not allow to directly transfer this concept from functional to functional logic languages in a meaningful way. In this paper we propose a new concept of default rules for Curry that supports a programming style similar to functional programming while preserving the core properties of functional logic programming, i.e., completeness, non-determinism, and logic-oriented uses of functions. We discuss the basic concept and sketch an initial implementation of it which exploits advanced features of functional logic languages.

In functional logic programs, rules are applicable independently of textual order, i.e., any rule can potentially be used to evaluate an expression. This is similar to logic languages and contrary to functional languages, e.g., Haskell enforces a strict sequential interpretation of rules. However, in some situations it is convenient to express alternatives by means of compact default rules. Although default rules are often used in functional programs, the non-deterministic nature of functional logic programs does not allow to directly transfer this concept from functional to functional logic languages in a meaningful way. In this paper, we propose a new concept of default rules for Curry that supports a programming style similar to functional programming while preserving the core properties of functional logic programming, i.e., completeness, non-determinism, and logic-oriented use of functions. We discuss the basic concept and propose an implementation which exploits advanced features of functional logic languages.

A major impediment to the wider proliferation of Single-Instruction, Multiple Datastream (SIMD) (3) architectures rests in the unsuitability of sequential, scalar, languages for programming data-parallel systems. Existing languages lack sufficient expressive power to describe data-parallel computation. A functional language, extended with data-parallel primitives, provides a powerful abstraction of the capabilities of SIMD architectures. Such a language conveys the following benefits: greater expressive power, a rich set of data-types, transparent access to data-parallelism, amenability to program transformation and consistency with the functional style. A compilation strategy onto an abstract SIMD architecture is presented. >

Polytypic Programming in Maude

Typing rule-based transformations over topological collections

article Free Access Share on Values and objects in programming languages Author: B. J. MacLennan Naval Postgraduate School, Monterey, CA Naval Postgraduate School, Monterey, CAView Profile Authors Info & Claims ACM SIGPLAN NoticesVolume 17Issue 12December 1982 pp 70–79https://doi.org/10.1145/988164.988172Online:01 December 1982Publication History 43citation121DownloadsMetricsTotal Citations43Total Downloads121Last 12 Months27Last 6 weeks14 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

SummaryThe C programming language is a foundational technology for modern computing with millions of lines of code implementing everything from hobby projects to commercial operating systems. This installation base and the programmers producing it represent a massive software engineering investment spanning decades and likely to continue for decades more. Nevertheless, C, which was first standardized almost 30 years ago, lacks many features that make programming in more modern languages safer and more productive. The goal of the C project (pronounced “C for all”) is to create an extension of C that provides modern safety and productivity features while still ensuring strong backward compatibility with C and its programmers. Prior projects have attempted similar goals but failed to honor the C programming style; for instance, adding object‐oriented or functional programming with garbage collection is a nonstarter for many C developers. Specifically, C is designed to have an orthogonal feature set based closely on the C programming paradigm, so that C features can be added incrementally to existing C code bases, and C programmers can learn C extensions on an as‐needed basis, preserving investment in existing code and programmers. This paper presents a quick tour of C features, showing how their design avoids shortcomings of similar features in C and other C‐like languages. Experimental results are presented to validate several of the new features.

This research aims to fully integrate logic programming into the programming language Scheme. We use a minimalist approach, based on the observation that the fundamental aspects of logic programming, nondeterminism and unification, are separable both in concept and in implementation. We have found that only two new primitive functions and one new special form need to be added to Scheme to achieve this integration. Using these primitives, we can write programs in the style of Scheme, Icon, Prolog, or any mixture thereof. We have found that a style of programming that uses both logical and functional techniques can be more powerful than the use of either technique alone. Because Scheme has side effects and continuations, this research addresses different problems and choices than previous research [2, 16, 19] on merging functional and logical languages.

We explore the design and implementation of Frank, a strict functional programming language with a bidirectional effect type system designed from the ground up around a novel variant of Plotkin and Pretnar's effect handler abstraction. Effect handlers provide an abstraction for modular effectful programming: a handler acts as an interpreter for a collection of commands whose interfaces are statically tracked by the type system. However, Frank eliminates the need for an additional effect handling construct by generalising the basic mechanism of functional abstraction itself. A function is simply the special case of a Frank operator that interprets no commands. Moreover, Frank's operators can be multihandlers which simultaneously interpret commands from several sources at once, without disturbing the direct style of functional programming with values. Effect typing in Frank employs a novel form of effect polymorphism which avoid mentioning effect variables in source code. This is achieved by propagating an ambient ability inwards, rather than accumulating unions of potential effects outwards. We introduce Frank by example, and then give a formal account of the Frank type system and its semantics. We introduce Core Frank by elaborating Frank operators into functions, case expressions, and unary handlers, and then give a sound small-step operational semantics for Core Frank. Programming with effects and handlers is in its infancy. We contribute an exploration of future possibilities, particularly in combination with other forms of rich type system.