Movatterモバイル変換


[0]ホーム

URL:


Jump to content
WikipediaThe Free Encyclopedia
Search

Total functional programming

From Wikipedia, the free encyclopedia
Programming paradigm restricted to provably terminating programs

Total functional programming (also known asstrong functional programming,[1] to be contrasted with ordinary, orweakfunctional programming) is aprogramming paradigm that restricts the range of programs to those that areprovably terminating.[2]

Restrictions

[edit]

Termination is guaranteed by the following restrictions:

  1. A restricted form ofrecursion, which operates only upon 'reduced' forms of its arguments, such asWalther recursion,substructural recursion, or "strongly normalizing" as proven byabstract interpretation of code.[3]
  2. Every function must be a total (as opposed topartial) function. That is, it must have a definition for everything inside its domain.
    • There are several possible ways to extend commonly used partial functions such as division to be total: choosing an arbitrary result for inputs on which the function is normally undefined (such asxN.x÷0=0{\displaystyle \forall x\in \mathbb {N} .x\div 0=0} for division); adding another argument to specify the result for those inputs; or excluding them by use of type system features such asrefinement types.[2]

These restrictions mean that total functional programming is notTuring-complete. However, the set of algorithms that can be used is still huge. For example, any algorithm for which anasymptotic upper bound can be calculated (by a program that itself only uses Walther recursion) can be trivially transformed into a provably-terminating function by using the upper bound as an extra argument decremented on each iteration or recursion.

For example,quicksort is not trivially shown to be substructural recursive, but it only recurs to a maximum depth of the length of the vector (worst-case time complexityO(n2)). A quicksort implementation on lists (which would be rejected by a substructural recursive checker) is, using Haskell:

importData.List(partition)qsort[]=[]qsort[a]=[a]qsort(a:as)=let(lesser,greater)=partition(<a)asinqsortlesser++[a]++qsortgreater

To make it substructural recursive using the length of the vector as a limit, we could do:

importData.List(partition)qsortx=qsortSubxx-- minimum caseqsortSub[]as=as-- shows termination-- standard qsort casesqsortSub(l:ls)[]=[]-- nonrecursive, so acceptedqsortSub(l:ls)[a]=[a]-- nonrecursive, so acceptedqsortSub(l:ls)(a:as)=let(lesser,greater)=partition(<a)as-- recursive, but recurs on ls, which is a substructure of-- its first input.inqsortSublslesser++[a]++qsortSublsgreater

Some classes of algorithms have no theoretical upper bound but do have a practical upper bound (for example, some heuristic-based algorithms can be programmed to "give up" after so many recursions, also ensuring termination).

Another outcome of total functional programming is that bothstrict evaluation andlazy evaluation result in the same behaviour, in principle; however, one or the other may still be preferable (or even required) for performance reasons.[4]

In total functional programming, a distinction is made betweendata andcodata—the former isfinitary, while the latter is potentially infinite. Such potentially infinite data structures are used for applications such asI/O. Using codata entails the usage of such operations ascorecursion. However, it is possible to doI/O in a total functional programming language (withdependent types) also without codata.[5]

BothEpigram andCharity could be considered total functional programming languages, even though they do not work in the wayTurner specifies in his paper. So could programming directly in plainSystem F, inMartin-Löf type theory or theCalculus of Constructions.

See also

[edit]

References

[edit]
  1. ^This term is due to:Turner, D.A. (December 1995).Elementary Strong Functional Programming. First International Symposium on Functional Programming Languages in Education. Springer LNCS. Vol. 1022. pp. 1–13..
  2. ^abTurner, D.A. (2004-07-28),"Total Functional Programming",Journal of Universal Computer Science,10 (7):751–768,doi:10.3217/jucs-010-07-0751
  3. ^Turner, D. A. (2000-04-28),"Ensuring Termination in ESFP",Journal of Universal Computer Science,6 (4):474–488,doi:10.3217/jucs-006-04-0474
  4. ^The differences between lazy and eager evaluation are discussed in:Granström, J. G. (2011).Treatise on Intuitionistic Type Theory. Logic, Epistemology, and the Unity of Science. Vol. 7.ISBN 978-94-007-1735-0. See in particular pp. 86–91.
  5. ^Granström, J. G. (May 2012), "A New Paradigm for Component-based Development",Journal of Software,7 (5):1136–1148,doi:10.4304/jsw.7.5.1136-1148Archived copy
Imperative
Structured
Object-oriented
Declarative
Functional
Dataflow
Logic
Domain-
specific
language

(DSL)
Concurrent,
parallel
Metaprogramming
Separation
of concerns
Comparisons/Lists
Retrieved from "https://en.wikipedia.org/w/index.php?title=Total_functional_programming&oldid=1330547620"
Categories:
Hidden categories:

[8]ページ先頭

©2009-2026 Movatter.jp