Content deleted Content added
m typo |
|||
Line 29:
==Practical implications==
Historically, the upwards funarg problem has proven to be the 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 [[Oberon programming language]] (a descendant of Pascal) allows 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 closure syntax for C that solves the upwards funarg problem by dynamically moving closures from the stack to the heap as necessary. The [[Java programming language]] deals with it by requiring that context used by nested functions in anonymous inner classes be declared [[Final (Java)|final]].
In [[functional language]]s, functions are first-class values and can be passed anywhere. Thus, implementations of [[Scheme (programming language)|Scheme]] or [[SML programming language|SML]] 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|Objective Caml]] compiler employs a hybrid technique (based on [[program analysis (computer science)|program analysis]]) to maximize efficiency.
| |||