• Además de los ámbitos léxicos, existen también los llamados ámbitos dinámicos, que funcionan de otra forma y que no estudiaremos en este curso.

• La mayoría de los lenguajes de programación usan ámbitos léxicos, salvo excepciones (como LISP o los shell scripts) que usan ámbitos dinámicos.

• Por esa razón, a partir de ahora, cuando hablemos de «ámbitos» sin especificar de qué tipo, nos estaremos siempre refiriendo a «ámbitos léxicos».

• Por ejemplo: en el lenguaje de programación Java, los bloques son estructuras sintácticas delimitadas por llaves { y } que contienen instrucciones.

• Los bloques de Java determinan ámbitos léxicos; por tanto, si una instrucción está dentro de un bloque (es decir, si está situada entre las llaves { y } que delimitan el bloque), entonces esa instrucción se encuentra dentro del ámbito léxico que define el bloque.

• En Python, las expresiones lambda determinan ámbitos léxicos, así que, cada vez que creamos una expresión lambda, estamos introduciendo un nuevo ámbito en el código fuente de nuestro programa.

• En concreto, el ámbito que determina una expresión lambda viene delimitado por su cuerpo.

• Los ámbitos se pueden anidar recursivamente, o sea, que pueden estar contenidos unos dentro de otros.

• Por tanto, una instrucción puede estar en varios ámbitos al mismo tiempo (anidados unos dentro de otros).

• De todos ellos, el ámbito más interno es el que no contiene, a su vez, a ningún otro ámbito.

• Definimos el ámbito de una instrucción como el ámbito más interno en el que se encuentra dicha instrucción.

• Según lo anterior, en un momento dado, el ámbito actual es el ámbito de la instrucción actual, es decir, el ámbito más interno en el que se encuentra la instrucción que se está ejecutando actualmente.

• Decimos que los ámbitos léxicos cumplen la propiedad de la estructura.

• Una estructura es una construcción sintáctica que puede anidarse completamente dentro de otras estructuras, de forma que, dadas dos estructuras cualesquiera, o una está incluida completamente dentro de la otra, o no se tocan en absoluto.

• Por tanto, los bordes de dos ámbitos léxicos nunca pueden cruzarse:

• En este otro ejemplo más complicado, tenemos el siguiente script:

  w = 2
  f = lambda x, y: 5 + (lambda z: z + 3)(x + y)
  r = f(2, 4)
  m = (lambda x: x ** 2)(3)

  donde existen cuatro ámbitos:

• Por ejemplo, en el siguiente script se ejecutan cuatro definiciones:

• El ámbito de cada una de las instrucciones es el ámbito global, que es el único ámbito que existe en el script.

• En consecuencia:

  • Las cuatro definiciones tienen ámbito global (y son, por tanto, definiciones globales).

  • Cuando se ejecuten, esas definiciones crearán ligaduras globales.

• Como estamos usando un lenguaje de programación que trabaja con ámbitos léxicos, el ámbito de una instrucción siempre vendrá determinado por una construcción sintáctica del lenguaje.

• Por tanto:

  • Sus límites vienen marcados únicamente por la sintaxis de la construcción que determina el ámbito de esa definición.

  • El ámbito de la instrucción se puede determinar simplemente leyendo el código fuente del programa, observando dónde empieza y dónde acaba esa construcción, sin tener que ejecutarlo.

    Es decir, que se puede determinar de forma estática.

1. Si el identificador ligado es un atributo de un objeto, la ligadura sólo será visible dentro del objeto.

   En tal caso, decimos que la visibilidad de la ligadura (y del correspondiente atributo ligado) es local al objeto que contiene el atributo.

   Eso significa que debemos indicar (usando el operador punto (.)) el objeto que contiene a la ligadura para poder acceder a ella, lo que significa que también debemos tener acceso al propio objeto que la contiene.

2. Si el identificador ligado NO es un atributo de un objeto, la ligadura sólo será visible dentro del ámbito donde se definió la ligadura.

   Ese ámbito representa una «región» cuyas fronteras limitan la porción del código fuente en la que es visible esa ligadura.

   En tal caso, decimos que la visibilidad de la ligadura es local a su ámbito.

   Eso significa que no es posible acceder a esa ligadura fuera de su ámbito; sólo es visible dentro de él.

   En cambio, si el ámbito de la ligadura contiene dentro otro ámbito anidado, sí que podremos acceder a la ligadura dentro de ese ámbito más interno, ya que técnicamente seguiría estando dentro de su ámbito.

   Si el ámbito es el global, decimos que la ligadura tiene visibilidad global.

• Suponiendo que tenemos los siguientes cuatro ámbitos, identificados con las letras A, B, C y D:

  • A puede ver los nombres definidos en A, pero no los definidos en B, C o D.

  • B puede ver los nombres definidos en A y B, pero no los definidos en C o D.

  • C puede ver los nombres definidos en A, B y C, pero no los definidos en D.

  • D puede ver los nombres definidos en A y D, pero no los definidos en B o C.

• Por otra parte, el momento en que una ligadura deja de existir depende si el identificador ligado es un atributo de un objeto, o no:

  • Si el identificador ligado es un atributo de un objeto, la ligadura dejará de existir cuando se elimine el objeto de la memoria, o bien, cuando se elimine el propio atributo ligado.

  • En caso contrario, la ligadura dejará de existir allí donde termine el ámbito de la ligadura.

• Es importante hacer notar que, en un momento dado, una ligadura puede existir pero no ser visible.

• Por ejemplo, si una ligadura local y una global vinculan el mismo identificador, la local «hace sombra» a la global, cosa que estudiaremos con más profundidad posteriormente.

1. Cuando se crea una ligadura dentro de un objeto en Python usando el operador punto (.), el espacio de nombres será el propio objeto, ya que los objetos son espacios de nombres en Python.

   En tal caso, la ligadura asocia un valor con un atributo del objeto, y tanto el atributo como la ligadura se almacenan dentro del objeto.

   Por ejemplo, si en Python hacemos:

   import math
   math.x = 75

   estamos creando la ligadura x → 75 en el espacio de nombres que representa el módulo math, el cual es un objeto en Python y, por tanto, es quien almacena la ligadura.

   Así que el espacio de nombres ha sido seleccionado a través del operador punto (.) para resolver el atributo dentro del objeto, y no depende del ámbito donde se encuentre la sentencia math.x = 75.

   Diremos que la ligadura es local al objeto.

2. Si la ligadura no se crea dentro de un objeto usando el operador punto (.), entonces el espacio de nombres irá asociado al ámbito y, en este caso, ese espacio de nombres siempre será un marco.

   Ese marco será el que corresponda al ámbito actual, es decir, el ámbito más interno en el que se encuentra la instrucción que crea la ligadura.

   Cuando el ámbito es el ámbito global (y, por tanto, la ligadura se almacena en el marco global), se dice que la ligadura es global.

   En caso contrario, decimos que es local al ámbito, y se almacenará en el marco correspondiente a ese ámbito.

• Por otra parte, como esas ligaduras no se crean sobre atributos de objetos, empezarán a existir justo donde se crean, y terminarán de existir al final de su ámbito.

• Por ejemplo, la ligadura y → 99 empezará a existir en la línea 2 y terminará al final del script, que es donde termina su ámbito (que, en este ejemplo, es el ámbito global).

• En consecuencia, el tiempo de vida de la ligadura será el periodo comprendido desde su creación (en la línea 2) hasta el final de su ámbito.

• Cuando la ligadura se crea sobre un atributo de un objeto de Python, entonces ese objeto almacenará la ligadura y será, por tanto, su espacio de nombres.

• Recordemos que, por ejemplo, cuando importamos un módulo usando la sentencia import, podemos acceder al objeto que representa ese módulo usando su nombre, lo que nos permite acceder a sus atributos y crear otros nuevos.

• Esos atributos y sus ligaduras correspondientes sólo son visibles cuando accedemos a ellos usando el operador punto (.) a través del objeto que lo contiene.

• Por tanto, los atributos no son visibles fuera del objeto, y debemos usar el operador punto (.) para acceder a ellos (su visibilidad es local al objeto que los contiene).

• Por ejemplo:

  >>> import math
  >>> math.pi
  3.141592653589793     # El nombre 'pi' es visible dentro del objeto
  >>> pi                # El nombre 'pi' no es visible fuera del objeto
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  NameError: name 'pi' is not defined

• Igualmente, si creamos un nuevo atributo dentro del objeto, la ligadura entre el atributo y su valor sólo existirá en el propio objeto y, por tanto, sólo será visible cuando accedamos al atributo a través del objeto donde se ha creado.

  >>> import math
  >>> math.x = 95       # Creamos un nuevo atributo en el objeto
  >>> math.x            # El nombre 'x' es visible dentro del objeto
  95
  >>> x                 # El nombre 'x' no es visible fuera del objeto
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  NameError: name 'x' is not defined

• Resumiendo:

  • Para poder acceder a un atributo de un objeto, debemos acceder primero al objeto y usar el operador punto (.).

  • Por tanto, la visibilidad de su ligadura correspondiente no vendrá determinada por un ámbito, sino por el objeto que contiene al atributo (y que, por consiguiente, también contiene a su ligadura).

    En tal caso, diremos que la visibilidad es local al objeto que contiene el atributo.

  • Por otra parte, el tiempo de vida de la ligadura será el tiempo que permanezca el atributo en el objeto, ligado a algún valor.

• Pero hay que tener cuidado, ya que ese mismo identificador puede aparecer en ámbitos diferentes y, por tanto, ligarse en ámbitos diferentes.

• Así que no tendría sentido hablar del ámbito que tiene ese identificador (ya que podría tener varios) sino, más bien, del ámbito que tiene una aparición concreta de ese identificador.

• Por eso, sólo deberíamos hablar del ámbito de un identificador cuando no haya ninguna ambigüedad respecto a qué aparición concreta nos estamos refiriendo.

• Por ejemplo, en el siguiente script:

  x = 4
  suma = (lambda x, y: x + y)(2, 3)

  el identificador x que aparece en la línea 1 y el identificador x que aparece en la línea 2 pertenecen a ámbitos distintos (como veremos en breve) aunque sea el mismo identificador.

• En el ejemplo anterior, es como si el intérprete ejecutara las siguientes definiciones dentro del ámbito de la expresión lambda:

  x = 2
  y = 3

• Las ligaduras creadas por esas definiciones se almacenan en el marco de la llamada a la expresión lambda.

• Ese marco se eliminará de la memoria al salir del ámbito de la expresión lambda, es decir, cuando se termine de ejecutar el cuerpo de la expresión lambda al finalizar la llamada a la misma.

  Por tanto, las ligaduras se destruyen de la memoria al eliminarse el marco que las almacena.

• La próxima vez que se llame a la expresión lambda, se volverán a ligar sus parámetros, esta vez con los argumentos que haya en esa llamada.

• Por ejemplo, supongamos que tenemos esta situación:

  suma = lambda x, y: x + y
  a = suma(4, 3)
  b = suma(8, 9)

• En la primera llamada, se entrará en el ámbito determinado por el cuerpo de la expresión lambda, se creará el marco que representa a esa llamada, y se ejecutarán las siguientes definiciones dentro del ámbito:

  x = 4
  y = 3

  lo que creará las correspondientes ligaduras y las almacenará en el marco de esa llamada.

  Despues, evaluará el cuerpo de la expresión lambda y devolverá el resultado, saliendo del cuerpo de la expresión lambda y, por tanto, del ámbito que determina dicho cuerpo, lo que hará que se destruya el marco y, en consecuencia, las ligaduras que contiene.

• En la siguiente llamada ocurrirá lo mismo pero, esta vez, las definiciones que se ejecutarán serán las siguientes:

  x = 8
  y = 9

  lo que creará otras ligaduras, que serán destruidas luego cuando se destruya el marco que las contiene, al finalizar la ejecución del cuerpo de la expresión lambda.

• Es importante hacer notar que en ningún momento se está haciendo un rebinding de los parámetros, ya que cada vez que se llama de nuevo a la expresión lambda, se está creando una ligadura nueva sobre un identificador que no estaba ligado.

• En consecuencia, podemos decir que:

  • El ámbito de la ligadura entre un parámetro y su argumento es el cuerpo de la expresión lambda, así que la visibilidad del parámetro (y de la ligadura) es ese cuerpo.

  • Esa ligadura se crea justo después de entrar en ese ámbito, así que se puede acceder a ella en cualquier parte del cuerpo de la expresión lambda, por lo que su tiempo de vida va desde el principio hasta el final de la llamada.

  • El espacio de nombres que almacena las ligaduras entre parámetros y argumentos es el marco que se crea al llamar a la expresión lambda.

• Esto se resume diciendo que «el ámbito de un parámetro es el cuerpo de su expresión lambda».

• También se dice que el parámetro tiene un ámbito local y un almacenamiento local al cuerpo de la expresión lambda.

  Resumiendo: el parámetro es local a dicha expresión lambda.

• Por tanto, sólo podemos acceder al valor de un parámetro dentro del cuerpo de su expresión lambda.

• Por ejemplo, en el siguiente código:

  suma = lambda x, y: x + y

  el cuerpo de la expresión lambda ligada a suma determina su propio ámbito.

• Por tanto, en el siguiente código tenemos dos ámbitos: el ámbito global (más externo) y el ámbito del cuerpo de la expresión lambda (más interno y anidado dentro del ámbito global):

• Además, cada vez que se llama a suma, la ejecución del programa entra en su cuerpo, lo que crea un nuevo marco que almacena las ligaduras entre sus parámetros y los argumentos usados en esa llamada.

• Los ámbitos léxicos permiten ligaduras locales a ciertas construcciones sintácticas, lo cual nos permite programar definiendo partes suficientemente independientes entre sí.

• Esto es la base de la llamada programación modular.

• Por ejemplo, nos permite crear funciones sin preocuparnos de si los nombres de los parámetros ya han sido utilizados en otras partes del programa.

• Igualmente, nos permite crear programas sin preocuparnos de si estamos usando nombres que ya han sido usados en el interior de alguna de las funciones del programa.

• De lo contrario, se podría provocar lo que se conoce como name clash (conflicto de nombres o choque de nombres), que es el problema que se produce cuando usamos el mismo nombre para varias cosas diferentes y que impide que se puedan usar todas al mismo tiempo.

• Lo que impide el name clash son dos cosas:

  • Los ámbitos hacen que los nombres sólo sean visibles en ciertas zonas.

  • Los espacios de nombres permiten que un mismo nombre pueda ligarse a diferentes valores simultáneamente.

• O sea: con los identificadores cuantificados ocurre exactamente lo mismo que con los parámetros, ya que, de hecho, un parámetro y un identificador cuantificado son la misma cosa, como ya hemos visto.

• Durante la ejecución del programa, se van creando y destruyendo marcos a medida que se van entrando y saliendo de ciertos ámbitos; en concreto, a medida que se van ejecutando scripts, funciones o métodos.

• Asimismo, en esos marcos se van almacenando ligaduras.

• Según se van creando en memoria, esos marcos van enlazándose unos con otros creando una secuencia de marcos que se denomina entorno (del inglés, environment).

• En un momento dado, el entorno contendrá más o menos marcos dependiendo de por dónde haya pasado la ejecución del programa hasta ese momento.

• El entorno, por tanto, es un concepto dinámico que depende del momento en el que se calcule, es decir, de por dónde va la ejecución del programa.

• Por tanto, el entorno depende de qué partes del programa se han ido ejecutando hasta llegar a la instrucción actual.

• El entorno siempre contendrá, al menos, un marco: el marco global, que siempre será el último de la secuencia de marcos que forman el entorno.

• Asimismo, el primer marco del entorno se denomina el marco actual.

• Si el marco global es el único que existe, entonces el marco actual será el marco global.

• Gráficamente, representaremos los entornos como una lista enlazada de marcos conectados entre sí formando secuencias, de manera que:

  • Usaremos la letra E como un indicador que siempre apunta al primer marco de la lista.

    Ese primer marco es el marco actual.

  • El último marco siempre será el marco global.

• Si sólo hay un marco en el entorno, ése será necesariamente el marco global, el cual será también al mismo tiempo el marco actual:

• Por ejemplo:

  • Cuando entramos a ejecutar un script, se crea su marco global.

  • Si dentro de ese script llamamos a una expresión lambda, se creará un marco para esa ejecución concreta de la expresión lambda, por lo que en ese caso habrá dos marcos en la memoria: el global y el de esa llamada a la expresión lambda.

    El marco de la expresión lambda será el marco actual, que será el primer marco del entorno y apuntará a su vez al marco global.

  • El marco de la expresión lambda se eliminará de la memoria cuando termine esa ejecución de la expresión lambda.

  • A su vez, el marco global sólo se eliminará de la memoria cuando se finalice la ejecución del script.

• El cuerpo de una expresión lambda determina su propio ámbito, de forma que las ligaduras que ligan a los parámetros con los argumentos se crean dentro de ese ámbito y son, por tanto, locales a ese ámbito.

• Es decir: los parámetros (y las ligaduras entre los parámetros y los argumentos) tienen un ámbito local al cuerpo de la expresión lambda y sólo son visibles dentro de él.

• Además, esas ligaduras tienen un almacenamiento local al marco que se crea al llamar a la expresión lambda.

• Ese marco y ese ámbito van ligados:

  • Cuando se empieza a ejecutar el cuerpo de la expresión lambda, se entra en el ámbito y, por tanto, se crea el marco en la memoria.

  • Cuando se termina de ejecutar el cuerpo de la expresión lambda, se sale del ámbito y, por tanto, se elimina el marco de la memoria.

• Todo marco lleva asociado un ámbito (lo contrario no siempre es cierto).

• Cuando se crea el nuevo marco, éste se enlaza con el marco que hasta ese momento había sido el marco actual, en cadena.

• El último marco de la cadena es siempre el marco global.

• Se va formando así una secuencia de marcos que representa el entorno del programa allí donde se está ejecutando la instrucción actual.

• Así que no tendremos un único marco (el marco global) sino que tendremos, además, al menos uno más cada vez que se llame a una expresión lambda y mientras dure la ejecución de la misma.

• El ámbito es un concepto estático: es algo que existe y se reconoce simplemente leyendo el código del programa, sin tener que ejecutarlo.

• El marco es un concepto dinámico: es algo que se crea y se destruye a medida que se van ejecutando y terminando de ejecutar ciertas partes del programa: scripts, funciones y métodos.

  Un marco se crea cuando se entra en el ámbito de un script, función o método, y se destruye cuando se sale de ese ámbito.

• Por ejemplo, en el siguiente código:

  suma = lambda x, y: x + y

  el cuerpo de la función suma determina un ámbito.

• Por tanto, en el siguiente código tenemos dos ámbitos: el ámbito global (más externo) y el ámbito del cuerpo de la expresión lambda (más interno y anidado dentro del ámbito global):

• Además, cada vez que se llama a suma, la ejecución del programa entra en su cuerpo, lo que crea un nuevo marco que almacena las ligaduras entre sus parámetros y los argumentos usados en esa llamada.

• El concepto de entorno refleja el hecho de que los ámbitos se contienen unos a otros (están anidados unos dentro de otros).

  Si un marco A apunta a un marco B en el entorno, significa que el ámbito de A está contenido en el ámbito de B.

• El primer marco en la cadena del entorno siempre será el último marco que se ha creado y que todavía no se ha destruido.

  Ese marco es el marco actual, y se corresponde con el ámbito actual, es decir, con el ámbito más interno de la instrucción actual.

• Por otra parte, el último marco del entorno siempre es el marco global.

• Por ejemplo, si en cierto momento de la ejecución del programa anterior tenemos el siguiente entorno:

  Podemos afirmar que:

  • El marco de la función suma apunta al marco global en el entorno.

  • El ámbito de la expresión lambda a la que está ligado suma está contenido en el ámbito global.

  • El marco actual es el marco de la expresión lambda.

  • Por tanto, el programa se encuentra actualmente ejecutando el cuerpo de la expresión lambda.

  • De hecho, está ejecutando la llamada suma(3, 5).

• Por ejemplo:

  x = 4
  z = 1
  suma = (lambda x, y: x + y + z)(8, 12)
  y = 3
  w = 9

• A medida que vamos ejecutando cada línea del código, tendríamos los siguientes entornos:

• En cambio:

  >>> prueba = lambda x, y: x + y + z
  >>> z = 9
  >>> prueba(4, 3)
  16

  sí funciona (y devuelve 16) porque, en el momento de evaluar la aplicación de la expresión lambda (en la línea 3), el identificador z está ligado a un valor en el entorno (en este caso, 9).

• Observar que no es necesario que los identificadores que aparecen en el cuerpo estén ligados en el entorno cuando se crea la expresión lambda, sino cuando se evalúa el cuerpo de la expresión lambda, o sea, cuando se llama a la expresión lambda.

• Su ejecución, línea a línea, produce los siguientes entornos:

• La x que aparece en la línea 1 es distinta a las que aparecen en la 2:

  • La x de la línea 1 es un identificador ligado a un valor en el ámbito global (el ámbito de esa ligadura es el ámbito global). Esa ligadura, se almacena en el marco global, y por eso decimos que esa x es global.

    Por tanto, la aparición de la x en la línea 1 representa a la x cuya ligadura se encuentra almacenada en el marco global (es decir, la x global) y que está ligada al valor 4.

  • Las x de la línea 2 representan al parámetro de la expresión lambda. Ese parámetro está ligado al argumento de la llamada, el ámbito de esa ligadura es el cuerpo de la expresión lambda y esa ligadura se almacena en el marco de la llamada a la expresión lambda.

    En consecuencia, las apariciones de la x en la línea 2 representan a la x local a la expresión lambda, cuya ligadura se encuentra almacenada en el marco de la llamada a la expresión lambda y que está ligada a 3.

• Por tanto, la x que aparece en el cuerpo de la expresión lambda no se refiere al identificador x que está fuera de la expresión lambda (y que aquí está ligado al valor 4), sino al parámetro x que, en la llamada de la línea 2, está ligado al valor 3 (el argumento de la llamada).

• Es decir:

  • Dentro del cuerpo de la expresión lambda, x vale 3.

  • Fuera del cuerpo de la expresión lambda, x vale 4.

• Para determinar cuánto vale cada aparición de la x en ese código (es decir, para resolver la aparición de cada x), el intérprete de Python consulta el entorno.

• La x que está en la línea 1 y las x que están en la línea 2 son apariciones distintas que se corresponden con ligaduras distintas que tienen ámbitos distintos y se almacenan en espacios de nombres distintos.

• Por tanto, el identificador x podrá tener valores distintos dependiendo de qué aparición concreta de la x estamos evaluando.

• Cuando un mismo identificador está ligado dos veces en dos ámbitos anidados uno dentro del otro, decimos que:

  • El identificador que aparece en el ámbito más externo está sombreado (y su ligadura está sombreada) por el del ámbito más interno.

  • El identificador que aparece en el ámbito más interno hace sombra al identificador sombreado (y también se dice que su ligadura hace sombra a la ligadura sombreada) que aparece en el ámbito más externo.

• En nuestro ejemplo, podemos decir que el parámetro x de la expresión lambda hace sombra al identificador x que aparece en el ámbito global.

• Eso significa que no podemos acceder a ese identificador x global desde dentro del cuerpo de la expresión lambda, porque la x dentro del cuerpo siempre se referirá a la x local (el parámetro de la expresión lambda).

• Esto ocurre así porque, al buscar un valor para x, la primera ligadura que se encuentra el intérprete para el identificador x al recorrer la secuencia de marcos del entorno, es precisamente la que está en el marco de la expresión lambda, que es el marco actual cuando se está ejecutando su cuerpo.

• Si desde dentro de la expresión lambda necesitáramos acceder al valor de la x que está fuera de ese expresión lambda, lo que podríamos hacer es cambiarle el nombre al parámetro x. Por ejemplo:

  x = 4
  total = (lambda w: w * x)(3)  # Su valor es 12

  Así, en la expresión lambda tendríamos el parámetro w y el identificador libre x, éste último ligado en el ámbito global, y a cuyo valor ahora sí podemos acceder al no estar sombreado y encontrarse dentro del entorno.

Visualizar el script anterior en Pythontutor

• Concretamente, resolver el identificador pi en la expresión math.pi requerirá de los siguientes pasos:

  1. Se busca el valor de math en el entorno, que devuelve el objeto que representa al módulo math.

  2. Una vez que sabemos que el operando izquierdo del operador punto (.) es un objeto, procedemos a resolver el identificador pi, pero para ello sólo se considera el espacio de nombres asociado al objeto math.

     Es decir: buscamos el valor de pi en el espacio de nombres de math, y sólo ahí.

  3. Una vez localizado, se devolverá el valor ligado al nombre pi en el espacio de nombres de math, o se lanzará un error NameError en caso de que no haya ninguna ligadura para pi en math.

• Como se puede observar, en ningún momento se usa el entorno para resolver el identificador pi dentro de math.

• Cada vez que se hace una nueva llamada a una función:

  1. la ejecución actual se detiene,

  2. el marco correspondiente a esa llamada se almacena en la cima de la pila sobre los demás marcos que pudiera haber y

  3. se continúa la ejecución en la función llamada.

• Ese marco representa por dónde va la ejecución del programa en este momento.

• Según ésto, si un marco A está justo debajo de otro marco B, es porque el código correspondiente a A está esperando a que termine el código correspondiente a B (normalmente, una función).

• Ese marco además es el primero de la secuencia de marcos que forman el entorno de la función, que también estarán almacenados en la pila, más abajo.

• Los marcos se enlazan entre sí para representar los entornos que actúan en las distintas llamadas activas.

• El intérprete almacena en el marco cualquier información que necesite para gestionar las llamadas a funciones, incluyendo:

  • Las ligaduras entre los parámetros y sus valores (por supuesto).

  • La ligadura que apunta al valor de retorno de la función.

  • Cuál es el siguiente marco que le sigue en el entorno.

  • El punto de retorno, dentro del programa, al que debe devolverse el control cuando finalice la ejecución de la función.

• Un marco almacenado en la pila también se denomina registro de activación. Por tanto, también podemos decir que la pila de control almacena registros de activación.

• Cada llamada activa está representada por su correspondiente marco en la pila.

• En cuanto la llamada finaliza, su marco se saca de la pila y se transfiere el control a la llamada que está inmediatamente debajo (si es que hay alguna).

• Del análisis del diagrama del ejemplo anterior se pueden deducir las siguientes conclusiones:

  • En un momento dado, dentro del ámbito global se ha llamado a la función uno, la cual ha llamado a la función dos, la cual ha llamado a la función tres, la cual aún no ha terminado de ejecutarse.

  • El entorno en la función uno empieza por el marco de uno, el cual apunta al marco global.

  • El entorno en la función dos empieza por el marco de dos, el cual apunta al marco global.

  • El entorno en la función tres empieza por el marco de tres, el cual apunta al marco global.

• Si tenemos ámbitos anidados, los marcos se apuntarán entre sí en el entorno. Por ejemplo:

  g = 1
  uno = lambda x: dos(x - 1)
  dos = lambda y: 1 + (lambda z: z * 2)(y ** 3)
  r = uno(3)

• Hemos dicho que habrá un marco por cada nueva llamada que se realice a una función, y que ese marco se mantendrá en la pila hasta que la llamada finalice.

• Por tanto, en el caso de una función recursiva, tendremos un marco por cada llamada recursiva.

fact = lambda n: 1 if n == 0 else n * fact(n - 1)
r = fact(4)

• Los traductores que optimizan la recursividad final lo que hacen es sustituir cada llamada recursiva por la nueva llamada recursiva a la misma función.

• De esta forma, el marco que genera cada nueva llamada recursiva no se apila sobre los marcos anteriores en la pila, sino que sustituye al marco de la llamada que la ha llamado a ella.

• Por ejemplo, en el siguiente caso:

  fact_iter = lambda cont, acc: acc if cont == 0 else \
                                fact_iter(cont - 1, acc * cont)
  fact = lambda n: fact_iter(n, 1)

  tenemos lo siguiente:

  fact(5)
  = fact_iter(5, 1)
  = fact_iter(4, 5)
  = fact_iter(3, 20)
  = fact_iter(2, 60)
  = fact_iter(1, 120)
  = fact_iter(0, 120)
  = 120

• fact_iter(4, 5) llama a fact_iter(3, 20) y devuelve directamente el resultado de ésta.

• Es decir: fact_iter(4, 5) == fact_iter(3, 20), así que hacer fact_iter(4, 5) es lo mismo que hacer fact_iter(3, 20).

• Por tanto, la llamada a fact_iter(4, 5) se puede sustituir por la llamada a fact_iter(3, 20).

• Un intérprete que optimiza la recursividad final no apilaría el marco de la segunda llamada sobre el marco de la primera, sino que el marco de la segunda sustituiría al marco de la primera dentro de la pila.

• Así se haría también con las demás llamadas recursivas a fact_iter(2, 60), fact_iter(1, 120) y fact_iter(0, 120).

• De este modo, la pila no crecería con cada nueva llamada recursiva.

• Por ejemplo, si tenemos la siguiente función:

  cuadrado = lambda x: x * x

  según el orden aplicativo, la expresión cuadrado(3 + 4) se reduce así:

  cuadrado(3 + 4)               # definición de cuadrado
  = (lambda x: x * x)(3 + 4)    # evalúa 3 y devuelve 3
  = (lambda x: x * x)(3 + 4)    # evalúa 4 y devuelve 4
  = (lambda x: x * x)(3 + 4)    # evalúa 3 + 4 y devuelve 7
  = (lambda x: x * x)(7)        # aplicación a 7
  = (7 * 7)                     # evalúa (7 * 7) y devuelve 49
  = 49

• Por ejemplo, si tenemos la siguiente función:

  cuadrado = lambda x: x * x

  según el orden normal, la expresión cuadrado(3 + 4) se reduce así:

  cuadrado(3 + 4)               # definición de cuadrado
  = (lambda x: x * x)(3 + 4)    # aplicación a (3 + 4)
  = ((3 + 4) * (3 + 4))         # evalúa 3 y devuelve 3
  = ((3 + 4) * (3 + 4))         # evalúa 4 y devuelve 4
  = ((3 + 4) * (3 + 4))         # evalúa (3 + 4) y devuelve 7
  = 7 * (3 + 4)                 # evalúa 3 y devuelve 3
  = 7 * (3 + 4)                 # evalúa 4 y devuelve 4
  = 7 * (3 + 4)                 # evalúa (3 + 4) y devuelve 7
  = 7 * 7                       # evalúa 7 * 7 y devuelve 49
  = 49

• Sabiendo eso… ¿qué valor devolvería la siguiente expresión?

  primero(4, 1 / 0)

• Curiosamente, el resultado dependerá de si la evaluación es estricta o perezosa:

  • Si es estricta, el intérprete evaluará todos los argumentos de la expresión lambda aunque no se utilicen luego en su cuerpo. Por tanto, al evaluar 1 / 0 devolverá un error.

    Es lo que ocurre cuando se evalúa siguiendo el orden aplicativo.

  • En cambio, si es perezosa, el intérprete evaluará únicamente aquellos argumentos que se usen en el cuerpo de la expresión lambda, y en este caso sólo se usa el primero, así que dejará sin evaluar el segundo, no dará error y devolverá directamente 4.

    Es lo que ocurre cuando se evalúa siguiendo el orden normal:

    primero(4, 1 / 0) = (lambda x, y: x)(4, 1 / 0) = (4) = 4

• Hay un resultado teórico que avala lo que acabamos de observar:

  Teorema de estandarización:

  Si una expresión tiene forma normal, el orden normal de evaluación conduce seguro a la misma.

• En cambio, el orden aplicativo es posible que no encuentre la forma normal de la expresión.

• En Python la evaluación es estricta, salvo algunas excepciones:

  • El operador ternario:

    ⟨expr_condicional⟩ ::= ⟨valor_si_cierto⟩ if ⟨condición⟩ else ⟨valor_si_falso⟩

    evalúa perezosamente ⟨valor_si_cierto⟩ y ⟨valor_si_falso⟩ dependiendo del valor de la ⟨condición⟩.

  • Los operadores lógicos and y or también son perezosos (se dice que evalúan en cortocircuito):

    • True or  \;\underline{x}

      siempre es igual a True, valga lo que valga \underline{x}.

    • False and  \;\underline{x}

      siempre es igual a False, valga lo que valga \underline{x}.

    En ambos casos no es necesario evaluar \underline{x}.

• En Java también existe un operador ternario (? :) y unos operadores lógicos (|| y &&) que se evalúan de igual forma que en Python.

• La mayoría de los lenguajes de programación usan evaluación estricta y paso de argumentos por valor (siguen el orden aplicativo).

• Haskell, por ejemplo, es un lenguaje funcional puro que usa evaluación perezosa y sigue el orden normal.

• La evaluación perezosa en Haskell permite resultados muy interesantes, como la posibilidad de manipular estructuras de datos infinitas.