Funarg problem: Difference between revisions

Revision as of 16:24, 26 March 2024

Latest revision as of 08:02, 9 August 2025

(3 intermediate revisions by 3 users not shown)

Line 1:

{{Short description|Programming language implementation problem}}

In [[computer science]], the '''funarg problem''' ''(function argument problem)'' refers to the difficulty in implementing [[first-class function]]s ([[function (programming)|function]]s as [[first-class object]]s) in programming language implementations so as to use [[stack-based memory allocation]] of the functions.

Line 6 ⟶ 7:

==Upwards funarg problem==

When one function calls another during a typical program's execution, the local state of the caller (including [[parameter (computer science)|parameters]] and [[local variable]]s) must be preserved in order for execution to proceed after the callee returns. In most compiled programs, this local state is stored on the [[call stack]] in a [[data structure]] called a ''[[Call stack#Structure|stack frame]]'' or ''activation record''. This stack frame is pushed, or allocated, as prelude to calling another function, and is popped, or deallocated, when the other function returns to the function that did the call. The upwards funarg problem arises when the calling function refers to the called/exited function's state after that function has returned. Therefore, the stack frame containing the called function's state variables must not be deallocated when the function returns, violating the [[stack-based memory allocation|stack-based function call paradigm]].

One solution to the upwards funarg problem is to simply allocate all activation records from the [[Heap (data structure)|heap]] instead of the stack and rely on some form of [[Garbage collection (computer science)|garbage collection]] or [[reference counting]] to deallocate them when they are no longer needed. Managing activation records on the heap has historically been perceived to be less efficient than on the stack (although this is partially contradicted<ref>[[Andrew Appel|Andrew W. Appel]], Zhong Shao. [https://www.cambridge.org/core/services/aop-cambridge-core/content/view/30303C7D7A9ACCC12AAA130855B7E6CF/S095679680000157Xa.pdf/empirical_and_analytic_study_of_stack_versus_heap_cost_for_languages_with_closures.pdf An Empirical and Analytic Study of Stack vs. Heap Cost for Languages with Closures]. [ftphttps://ftpwww.cs.princeton.edu/techreportsresearch/1994techreps/450.ps.gz 150 Princeton CS Tech Report TR-450-94], 1994.</ref>) and has been perceived to impose significant implementation complexity. Most functions in typical programs (less so for programs in [[functional programming languages]]) do not create upwards funargs, adding to concerns about potential overhead associated with their implementation. Furthermore, this approach is genuinely difficult in languages that do not support garbage collection.

Some efficiency-minded compilers employ a hybrid approach in which the activation records for a function are allocated from the stack if the [[compiler]] is able to deduce, through [[static program analysis]], that the function creates no upwards funargs. Otherwise, the activation records are allocated from the heap.

Another solution is to simply copy the value of the variables into the closure at the time the closure is created. This will cause a different behavior in the case of mutable variables, because the state will no longer be shared between closures. But if it is known that the variables are constant, then this approach will be equivalent. The [[ML (programming language)|ML]] languages take this approach, since variables in those languages are bound to values—i.e. variables cannot be changed. [[Java_(programming_language)|Java]] also takes this approach with respect to anonymous classes (and lambdas since Java 8), in that it only allows one to refer to variables in the enclosing scope that are effectively <code>final</code> (i.e. constant).

Line 18 ⟶ 19:

===Example===

The following [[Haskell (programming language)|Haskell]]-like [[pseudocode]] defines [[Function_composition_(computer_science)|function composition]]:

{{sxhl|2=haskell|1=compose f g = λx → f (g x)}}

<code>[[Lambda calculus|λ]]</code> is the operator for constructing a new function, which in this case has one argument, <code>x</code>, and returns the result of first applying <code>g</code> to <code>x</code>, then applying <code>f</code> to that. This λ function carries the functions <code>f</code> and <code>g</code> (or pointers to them) as internal state.

Line 29 ⟶ 30:

==Practical implications==

Historically, the upwards funarg problem has proven to be more difficult. For example, the [[Pascal programming language]] allows functions to be passed as arguments but not returned as results; thus implementations of Pascal are required to address the downwards funarg problem but not the upwards one. The [[Modula-2]] and [[Oberon (programming language)|Oberon]] programming languages (descendants of Pascal) allow functions both as parameters and return values, but the assigned function may not be a nested function. The [[C (programming language)|C programming language]] historically avoids the main difficulty of the funarg problem by not allowing function definitions to be nested; because the environment of every function is the same, containing just the statically allocated global variables and functions, a pointer to a function's code describes the function completely. [[Apple, Inc.|Apple]] has proposed and implemented a [[Blocks (C language extension)|closure syntax for C]] that solves the upwards funarg problem by dynamically moving closures from the stack to the heap as necessary.{{citation needed|date=November 2012}} The [[Java programming language]] deals with it by requiring that context used by nested functions in anonymous inner and local classes be declared <code>[[Final (Java)|final]]</code>, and context used by [[Anonymous function#Java|lambda expressions]] be effectively final. [[C Sharp (programming language)|C#]] and [[D (programming language)|D]] have lambdas (closures) that encapsulate a [[function pointer]] and related variables.

In [[functional language]]s, functions are first-class values that can be passed anywhere. Thus, implementations of [[Scheme (programming language)|Scheme]] or [[Standard ML]] must address both the upwards and downwards funarg problems. This is usually accomplished by representing function values as [[Dynamic memory allocation|heap-allocated]] closures, as previously described. The [[OCaml]] compiler employs a hybrid technique (based on [[static program analysis]]) to maximize efficiency.{{Citation needed|date=April 2011}}