Funarg - abreviatura de "argumento funcional"; en informática, el problema de funargue se refiere a la dificultad de implementar funciones como objetos de primera clase en lenguajes de programación orientados a pila (en el sentido más amplio, incluidos todos los lenguajes en los que se pasan parámetros a funciones a través de la pila).
La complejidad surge si el cuerpo de la función se refiere directamente (por ejemplo, no a través del paso de parámetros) a identificadores definidos en el entorno en el que se define la función, y no en el entorno de su llamada [1] . Resumiendo el siguiente razonamiento, las dos soluciones estándar son prohibir tales referencias o crear cierres [2] .
Hay dos versiones del problema: el problema funarg ascendente ocurre cuando una función regresa de alguna función, el problema funarg descendente surge cuando una función se pasa como parámetro a alguna función.
Cuando una función llama a otra durante la ejecución normal del programa, el estado local de la función que llama (incluidos los parámetros y las variables locales) debe guardarse para que la ejecución pueda continuar después de que regrese la función llamada. En la mayoría de los programas compilados, este estado local se almacena en la pila de llamadas en una estructura de datos llamada marco de pila . Este marco de pila se coloca en la pila de llamadas cuando se llama a la función interna y se elimina de allí cuando regresa. El problema del funarg burbujeante ocurre cuando la persona que llama se refiere al estado de la persona que llama después de que la persona que llama ha regresado. Por lo tanto, el marco de pila que contiene el estado de la función llamada no se debe desasignar cuando regresa, lo que rompe el paradigma de llamada de función orientada a la pila.
La solución al problema de los funargs burbujeantes es colocar el marco de pila en el montón en lugar de la pila de llamadas, confiando en alguna forma de recolección de elementos no utilizados para garantizar que los recursos ocupados por los marcos de pila se liberen cuando ya no se necesiten. Trabajar con marcos de pila asignados en el montón es mucho menos eficiente que en la pila, por lo que esta estrategia puede reducir significativamente el rendimiento.
Si la cantidad de memoria ocupada por marcos de funciones envolventes es pequeña y los datos en estos marcos no cambian, entonces los marcos de funciones envolventes se pueden pasar como valores. Esta función está predefinida para algunos lenguajes (la mayoría de los lenguajes funcionales y Java para métodos de clases anónimas internas). Pero también para los lenguajes que le permiten cambiar los datos de las funciones adjuntas (por ejemplo, C# ), algunos compiladores efectivos implementan un enfoque híbrido en el que el marco de la pila de la función se coloca en la pila de llamadas si el compilador logra deducir por análisis de programa que la función no crea funargs ascendentes, y de lo contrario en el montón. Colocar el marco de pila en el montón generalmente degrada el rendimiento.
Un funarg descendente también puede referirse al estado de una función cuando no se está ejecutando. Sin embargo, dado que, por definición, la existencia de un funarg descendente está limitada por el tiempo de ejecución de la función que lo crea, se puede colocar un marco de pila en la pila de llamadas. Sin embargo, los funargs de arriba hacia abajo involucran una estructura de árbol de cierres y marcos que dificulta las inferencias humanas sobre el estado del programa.
El problema ocurre en programas en lenguajes que permiten pasar funciones como parámetros, como Pascal y Algol 68 .
El problema funarg de arriba hacia abajo hace que la recursión de cola y el código de paso de continuación sean más difíciles de compilar de manera eficiente .