Hubbry Logo
search
logo
Purely functional programming avatar
Purely functional programming
Purely functional programming
current hub
P

Purely functional programming

logo
Community Hub0 Subscribers
Read side by side
Purely functional programming
View on Wikipedia
from Wikipedia

In computer science, purely functional programming usually designates a programming paradigm—a style of building the structure and elements of computer programs—that treats all computation as the evaluation of mathematical functions.

Program state and mutable objects are usually modeled with temporal logic, as explicit variables that represent the program state at each step of a program execution: a variable state is passed as an input parameter of a state-transforming function, which returns the updated state as part of its return value. This style handles state changes without losing the referential transparency of the program expressions.

Purely functional programming consists of ensuring that functions, inside the functional paradigm, will only depend on their arguments, regardless of any global or local state. A pure functional subroutine only has visibility of changes of state represented by state variables included in its scope.

Difference between pure and impure functional programming

[edit]

The exact difference between pure and impure functional programming is a matter of controversy. Sabry's proposed definition of purity is that all common evaluation strategies (call-by-name, call-by-value, and call-by-need) produce the same result, ignoring strategies that error or diverge.[1]

A program is usually said to be functional when it uses some concepts of functional programming, such as first-class functions and higher-order functions.[2] However, a first-class function need not be purely functional, as it may use techniques from the imperative paradigm, such as arrays or input/output methods that use mutable cells, which update their state as side effects. In fact, the earliest programming languages cited as being functional, IPL and Lisp,[3][4] are both "impure" functional languages by Sabry's definition.

Properties of purely functional programming

[edit]

Strict versus non-strict evaluation

[edit]
Main article: Evaluation strategy

Each evaluation strategy which ends on a purely functional program returns the same result. In particular, it ensures that the programmer does not have to consider in which order programs are evaluated, since eager evaluation will return the same result as lazy evaluation. However, it is still possible that an eager evaluation may not terminate while the lazy evaluation of the same program halts. An advantage of this is that lazy evaluation can be implemented much more easily; as all expressions will return the same result at any moment (regardless of program state), their evaluation can be delayed as much as necessary.

Parallel computing

[edit]

In a purely functional language, the only dependencies between computations are data dependencies, and computations are deterministic. Therefore, to program in parallel, the programmer need only specify the pieces that should be computed in parallel, and the runtime can handle all other details such as distributing tasks to processors, managing synchronization and communication, and collecting garbage in parallel. This style of programming avoids common issues such as race conditions and deadlocks, but has less control than an imperative language.[5]

To ensure a speedup, the granularity of tasks must be carefully chosen to be neither too big nor too small. In theory, it is possible to use runtime profiling and compile-time analysis to judge whether introducing parallelism will speed up the program, and thus automatically parallelize purely functional programs. In practice, this has not been terribly successful, and fully automatic parallelization is not practical.[5]

Data structures

[edit]
Main article: Purely functional data structure

Purely functional data structures are persistent. Persistency is required for functional programming; without it, the same computation could return different results. Functional programming may use persistent non-purely functional data structures, while those data structures may not be used in purely functional programs.

Purely functional data structures are often represented in a different way than their imperative counterparts.[6] For example, array with constant-time access and update is a basic component of most imperative languages and many imperative data-structures, such as hash table and binary heap, are based on arrays. Arrays can be replaced by map or random access list, which admits purely functional implementation, but the access and update time is logarithmic. Therefore, purely functional data structures can be used in languages which are non-functional, but they may not be the most efficient tool available, especially if persistency is not required.

In general, conversion of an imperative program to a purely functional one also requires ensuring that the formerly-mutable structures are now explicitly returned from functions that update them, a program structure called store-passing style.

Purely functional language

[edit]
For a more comprehensive list, see List of programming languages by type § Pure.

A purely functional language is a language which only admits purely functional programming. Purely functional programs can however be written in languages which are not purely functional.

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Purely functional programming

View on Grokipedia
from Grokipedia
Purely functional programming is a programming paradigm that treats all computation as the evaluation of mathematical functions, emphasizing the construction of programs through the composition and application of pure functions without mutable state or side effects.[1] In this approach, functions are deterministic, producing identical outputs for identical inputs regardless of execution context, and they avoid interactions with external state such as global variables or input/output operations.[2] This strict adherence to purity distinguishes it from impure functional programming, where side effects may be permitted under controlled conditions.[3] Key principles of purely functional programming include referential transparency, which allows any expression to be replaced by its evaluated value without changing the program's meaning, enabling easier reasoning and optimization.[1] Data immutability is fundamental, as values once created cannot be altered, promoting safer concurrency and reducing errors from unintended modifications.[4] Iteration is achieved through recursion rather than mutable loops, and functions are typically higher-order, capable of accepting other functions as arguments or returning them, which facilitates abstraction and code reuse.[3] Many implementations incorporate lazy evaluation, deferring computation until a value is required, which supports infinite data structures and enhances modularity by decoupling expression evaluation from order of execution.[1] Exemplary languages include Haskell, a standardized, lazy, purely functional language developed in the 1990s that enforces purity through its type system and monadic structures for handling effects; Miranda, an earlier lazy functional language influential in academic settings; and Clean, which pioneered uniqueness typing for efficient I/O in a pure context.[5][4] These languages demonstrate the paradigm's roots in lambda calculus and its evolution from earlier systems like Lisp and Scheme, which are functional but impure. The paradigm yields significant advantages, including enhanced modularity through higher-order functions and composition, which often results in more concise and reusable code compared to imperative alternatives.[1] It simplifies program verification, testing, and debugging by eliminating side-effect-related bugs and enabling formal proofs akin to mathematical derivations.[2] Additionally, the absence of shared mutable state facilitates parallelism and concurrency, making it suitable for modern multicore and distributed systems, while reducing overall development time on complex applications.[6]

Fundamentals

Definition of Purity

In purely functional programming, a pure function is defined as one that, for any given input, always produces the same output and has no observable side effects, such as input/output operations, mutation of state, or interactions with external environments.[7][8] This ensures that the function's behavior is deterministic and solely dependent on its arguments, mirroring the properties of mathematical functions.[9] At its core, purely functional programming treats computations as the evaluation of mathematical functions, where programs are constructed as compositions of expressions rather than sequences of imperative commands that alter state.[4] This approach emphasizes immutability and the absence of hidden dependencies, allowing programs to be reasoned about equationally, much like algebraic manipulations.[7] The foundational principles of purity trace their origins to the lambda calculus, developed by Alonzo Church in the 1930s as a formal system for expressing computation through function abstraction and application without any mutable state.[10][11] Church's work provided a theoretical basis for modeling all computable functions in a purely applicative manner, influencing the design of modern purely functional languages.[10] For instance, a simple arithmetic operation like addition exemplifies a pure function: given inputs 2 and 3, it invariably returns 5, with no alteration to external variables or generation of side effects.[7] In contrast, a random number generator is impure, as it may yield different results for the same input due to reliance on internal or external state, violating purity.[12] Purity in functions also enables referential transparency, where an expression can be substituted with its value without altering the program's meaning.[7]

Referential Transparency

Referential transparency is a fundamental property in purely functional programming, where an expression can be replaced by its evaluated value at any point in the program without altering the overall behavior or meaning. This substitutability ensures that the value of an expression depends solely on its subexpressions and not on external factors such as mutable state or execution context. As defined in early programming language theory, referential transparency means that to evaluate an expression containing a subexpression, only the value of the subexpression is needed, preserving mathematical-like predictability.[13] Purity in functional programming, characterized by the absence of side effects and deterministic evaluation given the same inputs, directly implies referential transparency, since expressions remain consistent under substitution. Formally, in the lambda calculus, this is illustrated by the equivalence (λx.x+1)5≡6(\lambda x. x + 1) 5 \equiv 6, where the application can be substituted by its result without affecting the program's semantics, demonstrating how pure functions enable such equational substitutions.[14][13] The benefits of referential transparency are profound for program analysis and optimization. It facilitates techniques like common subexpression elimination, where repeated computations of the same expression are computed only once, improving efficiency without changing results. Moreover, it supports equational reasoning, treating programs as algebraic expressions that can be manipulated and proven correct using mathematical laws, as seen in the algebra of functional programs where combining forms allow transformations like [f,g]∘h=[f∘h,g∘h][f, g] \circ h = [f \circ h, g \circ h]. This equational approach contrasts with imperative styles by enabling formal verification and optimization at a high level.[14][15] In practical terms, referential transparency simplifies debugging and testing by ensuring functions produce predictable outputs solely from their inputs, independent of order or context, thereby reducing errors from hidden dependencies and allowing modular composition with confidence.[14]

Differences from Impure Functional Programming

Side Effects and Impurity

In purely functional programming, functions produce no observable changes beyond their return values, but side effects introduce modifications to the external environment that violate this principle. Common types of side effects include input/output (I/O) operations, such as reading from or writing to files or consoles; modifications to global variables, which alter shared state across function invocations; throwing exceptions, which abruptly terminate normal execution flow; and non-local control flow mechanisms, like continuations or gotos, that jump execution to arbitrary points in the program. These effects make function behavior dependent on context, execution order, or external state, contrasting sharply with the deterministic nature of pure functions.[16][17] Impure functional programming languages, such as Lisp and Scala, permit side effects alongside functional constructs like higher-order functions and recursion, fostering hybrid imperative-functional styles that blend purity with practicality. In Lisp, for instance, primitives like rplaca and rplacd enable mutation of list structures, allowing destructive updates within otherwise applicative code. Similarly, Scala integrates functional features with object-oriented elements, supporting mutable variables and I/O directly in functional expressions, which enables efficient real-world applications but compromises strict purity. This impurity allows developers to leverage functional abstractions for expressiveness while incorporating imperative idioms for performance-critical tasks.[18] (Chapter 23 on effects) The introduction of side effects leads to several consequences that undermine the benefits of functional programming, including loss of predictability due to non-deterministic outcomes from timing or order dependencies, increased difficulty in debugging because effects can propagate unpredictably across modules, and reduced composability as functions become harder to reuse without considering their environmental impact. For example, consider an impure function that computes a sum and prints it to the console: 
def impureSum(a: Int, b: Int): Int = {
  val result = a + b
  println(s"Sum is: $result")  // Side effect: I/O
  result
}
This function's behavior changes based on when it is called, potentially interleaving output with other prints, whereas a pure equivalent simply returns the value without external interaction: 
def pureSum(a: Int, b: Int): Int = a + b
The pure version maintains referential transparency—replacing calls with their results does not alter program behavior—while the impure one breaks it, complicating reasoning and testing. Side effects thus introduce bugs related to execution order and state interference, which pure functions avoid entirely.[19] To mitigate impurity in such languages, monads serve as a conceptual technique to encapsulate side effects, structuring computations so that effects like I/O or state changes are isolated within a composable wrapper, preserving much of the pure style's modularity without eliminating impurity outright. This approach, originally developed for pure languages but adaptable to impure ones, sequences effects predictably while allowing controlled interaction with the environment.[20]

Mutable State Management

In impure functional programming, mutable state is managed through mechanisms like reference cells and arrays that allow in-place modifications, enabling imperative-style updates within a largely functional framework. For instance, in languages such as Standard ML (SML), reference cells of type 'a ref are created using the ref constructor, dereferenced with the ! operator, and updated via the := assignment operator, permitting variables to change over time unlike immutable values in pure paradigms. Arrays, provided via the Array structure, similarly support mutable operations like Array.update, which alters elements at specific indices without creating new structures. These features extend functional languages with imperative capabilities, as seen in SML's design where such primitives integrate seamlessly with higher-order functions but introduce observable changes to program state. A key challenge of mutable state in impure functional programming is the introduction of aliasing, where multiple identifiers can refer to the same underlying storage location, leading to unexpected interactions during updates. For example, consider a counter implemented with a shared reference: val counter = ref 0; fun increment () = (counter := !counter + 1; !counter);, where calling increment() twice yields 1 and then 2, but if another alias val alias = counter is used to set alias := 0 midway, subsequent increments start from the reset value, complicating reasoning about the program's behavior. This aliasing breaks referential transparency, as the meaning of an expression can depend on external mutations rather than solely on its subexpressions, making equational reasoning difficult and increasing the risk of subtle bugs. In concurrent settings, mutable state exacerbates issues like race conditions, where unsynchronized access to shared references can produce nondeterministic outcomes, though SML itself lacks built-in concurrency primitives to mitigate this. To address these challenges while retaining some functional benefits, impure functional languages employ workarounds such as state-passing patterns, where state is explicitly threaded through function arguments to avoid hidden mutations, or closures that encapsulate mutable references for localized control. In state-passing, a function might take the current state as input and return an updated state alongside the result, simulating purity by making dependencies explicit, though this incurs overhead from repeated copying or allocation compared to direct mutation. Closures can capture references in their environment, allowing incremental updates within a scoped context, but they still risk aliasing if the captured state is shared externally. These techniques aim to localize impurity but often require careful discipline to prevent proliferation of side effects, which encompass broader external interactions beyond internal state changes. The trade-offs of mutable state in impure functional programming favor efficiency for algorithms benefiting from in-place updates, such as certain graph traversals or accumulators, where avoiding data duplication reduces time and space complexity. However, this comes at the cost of reliability, as aliasing and loss of transparency hinder debugging, testing, and parallelization, potentially leading to programs that are harder to verify than their immutable counterparts.

Core Properties

Evaluation Strategies

In strictly evaluated purely functional languages, such as PureScript, function arguments are evaluated to values prior to function application, a strategy known as call-by-value.[21] This approach simplifies the operational semantics by ensuring predictable evaluation order and avoiding redundant computations of arguments used multiple times, unlike call-by-name where arguments may be re-evaluated. Consequently, it can prevent divergence in cases where an argument expression would loop indefinitely if re-evaluated, promoting more straightforward debugging and implementation. In contrast, non-strict or lazy evaluation defers the computation of arguments until their values are actually demanded by the function body, typically implemented via call-by-need to share results and avoid recomputation.[22] This strategy, central to Haskell, enables the construction and manipulation of infinite data structures, such as lazy lists, without immediate resource exhaustion, as only the required portions are computed on demand.[19] Additionally, it supports natural short-circuiting in control structures like conditionals, where unevaluated branches are discarded if not selected.[22] To illustrate the difference, consider a conditional expression if cond then expr1 else expr2. In a strict evaluator, both expr1 and expr2 are computed regardless of cond's value, potentially wasting effort if, for example, expr2 is an expensive or non-terminating computation. In a lazy evaluator, only the selected branch is evaluated, mirroring logical short-circuiting and aligning with referential transparency to facilitate optimizations without altering program meaning. Comparatively, strict evaluation may perform unnecessary work on discarded arguments, reducing efficiency for higher-order functions where arguments might go unused, while lazy evaluation excels in compositional settings but can incur higher memory overhead from thunk storage and sharing mechanisms.[19] Referential transparency in purely functional programs further aids lazy strategies by allowing safe reordering and common subexpression elimination during optimization.[23] Lazy evaluation was popularized in the 1990s through Haskell, where it became a defining feature to support modular, declarative programming with infinite structures and higher-order combinators.[23] Its theoretical foundations trace to denotational semantics, as explored in natural semantics models that separate evaluation from sharing to capture lazy behavior precisely.[24]

Parallelism and Concurrency

In purely functional programming, the absence of shared mutable state significantly simplifies parallelism and concurrency by eliminating race conditions and data races that plague imperative programs. Since all data is immutable and functions are referentially transparent, computations on disjoint parts of the data can proceed independently without synchronization overhead, enabling straightforward parallel execution of independent subcomputations. This purity allows developers to focus on algorithmic structure rather than low-level thread safety mechanisms.[25] Key mechanisms for achieving parallelism leverage the functional paradigm's recursive and compositional nature. Divide-and-conquer patterns, common in functional recursion, naturally decompose problems into independent subproblems that can be evaluated in parallel; for instance, mergesort can split lists and process halves concurrently, yielding logarithmic depth on parallel architectures. Additionally, lazy evaluation integrates well with asynchronous constructs like futures and promises, where unevaluated expressions (thunks) serve as deferred computations that can be sparked in parallel contexts. A representative example is a parallel map operation over an immutable list, where each element's transformation is executed concurrently using sparks, ensuring deterministic results due to the lack of side effects.[25][26] Despite these advantages, challenges arise from immutability, particularly the potential overhead of creating new data copies for each update, which can increase memory usage and slow parallel performance in data-intensive tasks. Solutions include libraries that optimize evaluation without altering purity, such as Haskell's Strategies library, which modularizes parallelism by specifying how to traverse and evaluate data structures in parallel while preserving determinism. This approach separates algorithmic logic from execution strategy, mitigating overhead through selective sparking and deep evaluation.[26] Research from the 2000s highlighted the real-world benefits of these properties, demonstrating that purely functional programs scale more easily on multicore systems compared to imperative counterparts, with parallel extensions achieving near-linear speedups on commodity hardware by exploiting inherent independence. For example, early implementations in Haskell showed effective utilization of multiple cores for divide-and-conquer algorithms, paving the way for broader adoption in scalable computing.[27]

Persistent Data Structures

In purely functional programming, data structures adhere to the principle of immutability, meaning that once created, they cannot be modified in place; instead, any update operation produces a new structure while leaving the original intact.[28] This approach ensures referential transparency and avoids side effects, allowing values to be safely shared across computations.[29] Persistence in these data structures refers to the ability to maintain multiple versions of the data over time, where unchanged portions are shared between versions to achieve efficiency. A key technique is path-copying, used in tree-based structures, where only the path from the root to the modified node is copied during an update, enabling the rest of the structure to be reused without duplication.[28] For example, in linked lists constructed via cons cells—pairs consisting of a value and a pointer to the next cell—appending an element creates a new cons cell that shares the entire tail of the original list, resulting in O(1) time for sharing and construction.[29] Common persistent data structures include balanced binary search trees, such as AVL trees adapted for sets, which maintain balance to support efficient operations, and tries (prefix trees) for storing and retrieving strings or sequences.[28] These structures typically achieve O(log n) time complexity for insertions, deletions, and lookups, where n is the number of elements, by leveraging the logarithmic height of balanced trees and the prefix-sharing properties of tries.[29] The benefits of persistent data structures include inherent thread-safety, as immutability eliminates race conditions without requiring locks, and support for versioning, which allows efficient checkpointing and backtracking in computations.[28] Historically, persistent data structures emerged in the 1970s and 1980s within functional programming research, with early contributions like Dobkin and Lipton's 1976 work on slab partitioning for planar point location and Sarnak and Tarjan's 1986 development of persistent binary search trees using fat nodes for O(log n) operations.[29] Okasaki's 1990s advancements, including techniques for real-time queues and catenable lists that reconcile amortization with strict persistence via lazy evaluation, built on this foundation to enable more practical implementations.[28]

Languages and Implementations

Notable Purely Functional Languages

Haskell, a standardized purely functional programming language, was developed in the late 1980s by a committee of researchers seeking a common platform for non-strict functional programming research, with the first report published in 1990.[23] It features lazy evaluation by default and enforces purity through its type system and semantics, making it suitable for applications requiring referential transparency.[30] Haskell has found extensive use in academia for teaching and research in areas like type theory and program verification, as well as in industry for web development—exemplified by frameworks like Yesod—and financial systems where reliability and parallelism are critical.[31] Miranda, developed by David Turner in the early 1980s, served as a key precursor to Haskell, introducing lazy evaluation and a clean syntax for purely functional programming in a non-strict semantics.[32] Released commercially in 1985, it influenced the design of subsequent languages by demonstrating practical implementation of higher-order functions and polymorphism without side effects.[33] Miranda found early adoption in academic settings for algorithm development and as a stepping stone toward more comprehensive standards like Haskell. Clean, introduced in the late 1980s by researchers at Radboud University Nijmegen, is a purely functional language that combines strict evaluation with uniqueness typing to manage state in a referentially transparent manner, enabling efficient I/O without impurity.[34] Designed for high-performance applications, it has been particularly utilized in graphics and multimedia processing, where its graph reduction model supports parallel execution and persistent data structures.[35] In the 2000s, purely functional languages transitioned from primarily academic tools to practical implementations, driven by advancements in compilers and libraries that addressed performance concerns, enabling adoption in web development and beyond.[36] A notable example is Elm, released in 2012 by Evan Czaplicki, which applies purely functional principles to front-end web applications through a domain-specific type system that compiles to JavaScript, emphasizing immutability and no runtime exceptions for reliable user interfaces.[37] Another example is PureScript, created in 2013 by Phil Freeman, a purely functional language strongly inspired by Haskell that compiles to JavaScript. It features advanced type system capabilities like row polymorphism and supports effect systems for handling side effects in a pure manner, making it suitable for full-stack web development with libraries like Halogen for UI and backend integration via Node.js. As of 2025, PureScript remains actively maintained with a vibrant ecosystem for browser-based applications.[21]

Key Features and Paradigms

In purely functional programming, higher-order functions treat functions as first-class citizens, allowing them to be passed as arguments, returned as results, and composed to form more abstract computations. This enables powerful patterns such as mapping a function over a collection to transform each element uniformly or filtering elements based on a predicate function, promoting reusable and modular code structures.[38] Strong static type systems with polymorphism form a cornerstone of purely functional languages, inferring types automatically to catch errors at compile time and ensuring program correctness without runtime overhead. The Hindley-Milner type system, featuring principal type schemes and unification via Algorithm W, supports parametric polymorphism, allowing generic functions to work across types while guaranteeing type safety. Pattern matching serves as the primary mechanism for control flow, deconstructing data structures to bind variables and select behaviors based on structural shapes, thereby replacing imperative conditionals and loops with declarative expressions. Recursion replaces iteration as the standard for repetitive tasks, with tail recursion optimization transforming qualifying recursive calls into efficient loops that prevent stack overflow and maintain constant space usage.[39][40] Advanced paradigms extend these foundations for more expressive abstractions. Type classes enable ad-hoc polymorphism by associating operations with types through overloaded instances, allowing flexible definitions of behaviors like equality or ordering without subclassing. Monads abstract over sequenced computations, encapsulating effects such as state or failure in a composable manner while preserving purity through their bind and return operations. Modern extensions, such as linear types introduced in post-2010 research, track resource usage by requiring values to be consumed exactly once, facilitating safe memory management and preventing leaks in performance-critical applications.[41][20][42] Despite these strengths, purely functional programming presents challenges, including a steep learning curve due to its departure from imperative idioms, requiring developers to rethink control flow and state. Performance tuning also demands expertise, as lazy evaluation and higher-order constructs can introduce overhead in real-time or resource-constrained environments, necessitating optimizations like strictness analysis.[43]

References

  1. [PDF] Why Functional Programming Matters
  2. Functional Programming HOWTO — Python 3.14.0 documentation
  3. [PDF] Functional Programming Languages (FPL)
  4. Functional Programming — ORIE 6125
  5. [PDF] Functional Programming Languages - Computer Science
  6. Why Functional Programming Should Be the Future of Software ...
  7. Introduction to Functional Programming
  8. Stat 8054 Lecture Notes: R as a Functional Programming Language
  9. ICS 33 Fall 2025, Notes and Examples: Functional Programming
  10. Functional Programming - Johns Hopkins Computer Science
  11. Lambda calculus - Computer Science
  12. [PDF] LABORATORY FOR COMPUTER SCIENCE - DSpace@MIT
  13. [PDF] Fundamental Concepts in Programming Languages
  14. [PDF] Why Functional Programming Matters 1 Introduction
  15. [PDF] Can Programming Be Liberated from the von Neumann Style? A ...
  16. Side Effects - Functional Programming and Software Engineering
  17. Why is the raising of an exception a side effect? - Stack Overflow
  18. https://dl.acm.org/doi/10.1145/244795.244798
  19. [PDF] Why Functional Programming Matters
  20. [PDF] Monads for functional programming - The University of Edinburgh
  21. [PDF] The Definition of Standard ML
  22. [PDF] Haskell 98 Language and Libraries The Revised Report
  23. [PDF] A History of Haskell: Being Lazy With Class - Microsoft
  24. A natural semantics for lazy evaluation - ACM Digital Library
  25. [PDF] Parallelism in Sequential Functional Languages
  26. [PDF] Seq no more: Better Strategies for Parallel Haskell - Simon Marlow
  27. Seq no more: Better Strategies for Parallel Haskell - ResearchGate
  28. [PDF] Purely Functional Data Structures - CMU School of Computer Science
  29. [PDF] introduction to persistent data structures - Xavier Leroy
  30. Introduction - HaskellWiki - Haskell.org
  31. (PDF) A history of Haskell: Being lazy with class - ResearchGate
  32. The Scheme Programming Language
  33. [PDF] Appendix B FUNCTIONAL PROGRAMMING WITH SCHEME
  34. [PDF] The History of Standard ML
  35. [PDF] Standard ML
  36. [PDF] Programming in Standard ML - CMU School of Computer Science
  37. Miranda homepage
  38. 3.8 Haskell and Miranda
  39. Language features - Clean
  40. [PDF] Functional Programming in CLEAN
  41. The history of Functional Programming - Ada Beat
  42. Elm - delightful language for reliable web applications
  43. How functional programming mattered | National Science Review
  44. [PDF] Derivation of a Pattern-Matching Compiler
  45. Proper tail recursion and space efficiency - ACM Digital Library
  46. Type classes in Haskell - ACM Digital Library
  47. The best of both worlds: linear functional programming without ...
  48. [PDF] If Functional Programming Is So Great, Why Isn't Everyone Using It ...
User Avatar
No comments yet.