• Es importante hacer notar que el cuerpo de una expresión lambda sólo se evalúa cuando se lleva a cabo una β-reducción (es decir, cuando se aplica la expresión lambda a unos argumentos), y no antes.

• Por tanto, el cuerpo de la expresión lambda no se evalúa cuando se define la expresión.

• Por ejemplo, al evaluar la expresión:

  lambda x, y: x + y

  el intérprete no evalúa la expresión del cuerpo (x + y), sino que crea un valor de tipo «función» pero sin entrar a ver «qué hay» en el cuerpo.

  Sólo se mira lo que hay en el cuerpo cuando se aplica la expresión lambda a unos argumentos.

• En particular, podemos tener una expresión lambda como la siguiente, que sólo dará error cuando se aplique a un argumento, no antes:

  lambda x: x + 1/0

• La evaluación de la llamada a suma(4, 3) implicará realizar los siguientes tres pasos y en este orden:

  1. Sustituir el nombre de la función suma por su definición, es decir, por la expresión lambda a la cual está ligado.

  2. Evaluar los argumentos que aparecen en la llamada.

  3. Aplicar la expresión lambda a sus argumentos (β-reducción).

• Esto implica la siguiente secuencia de reescrituras:

  suma(4, 3)                    # evalúa suma y devuelve su definición
  = (lambda x, y: x + y)(4, 3)  # evalúa 4 y devuelve 4
  = (lambda x, y: x + y)(4, 3)  # evalúa 3 y devuelve 3
  = (lambda x, y: x + y)(4, 3)  # aplica la expresión lambda sus argumentos
  = (4 + 3)                     # evalúa 4 + 3 y devuelve 7
  = 7

• Como una expresión lambda es una función, aplicar una expresión lambda a unos argumentos es como llamar a una función pasándole dichos argumentos.

• Por tanto, también podemos decir que llamamos o invocamos una expresión lambda, pasándole unos argumentos durante esa llamada.

• En consecuencia, ampliamos ahora nuestra gramática de las expresiones en Python incorporando las expresiones lambda como un tipo de función:

  ⟨llamada_función⟩ ::= ⟨función⟩([⟨lista_argumentos⟩])
  ⟨función⟩ ::= identificador
                           | (⟨expresión_lambda⟩)
  ⟨expresión_lambda⟩ ::= lambda [⟨lista_parámetros⟩]: ⟨expresión⟩
  ⟨lista_parámetros⟩ ::= identificador(, identificador)*
  ⟨lista_argumentos⟩ ::= ⟨expresión⟩(, ⟨expresión⟩)*

• En realidad, un identificador cuantificado y un parámetro están vinculados, hasta el punto en que podemos considerar que son la misma cosa.

• Tan sólo cambia su denominación dependiendo del lugar donde aparece su identificador en la expresión lambda:

  • Cuando aparece antes del «:», le llamamos «parámetro».

  • Cuando aparece después del «:», le llamamos «identificador cuantificado».

• Por ejemplo: en la siguiente expresión lambda:

  lambda x, y: x + y
         ┬     ┬
         │     └────── identificador cuantificado
         └── parámetro

  el identificador x aparece dos veces, pero en los dos casos representa la misma cosa. Tan sólo se llama de distinta forma («parámetro» o «identificador cuantificado») dependiendo de dónde aparece.

• A los identificadores cuantificados se les llama así porque sus posibles valores están cuantificados o restringidos a los posibles valores que puedan tomar los parámetros de la expresión lambda en cada llamada a la misma.

• Dicho valor además vendrá determinado automáticamente por la ligadura que crea el intérprete durante la llamada a la expresión lambda.

  Es decir: el intérprete liga automáticamente el identificador cuantificado al valor del correspondiente argumento durante la llamada a la expresión lambda.

• En cambio, el valor al que esté ligado un identificador libre de una expresión lambda no viene determinado por ninguna característica propia de dicha expresión lambda.

• 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.

• 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».

• 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.

• El concepto de ámbito no es nada trivial y, a medida que vayamos incorporando nuevos elementos al lenguaje, tendremos que ir adaptándolo para tener en cuenta más condicionantes.

• Hasta ahora sólo hemos tenido un ámbito, llamado ámbito global:

  • Si se está ejecutando un script en el intérprete por lotes (con python script.py), el ámbito global abarca todo el script, desde la primera instrucción hasta la última.

  • Si estamos en el intérprete interactivo (con python o ipython3), el ámbito global abarca toda nuestra sesión con el intérprete, desde que arrancamos la sesión hasta que finalizamos la misma.

• Por tanto:

  • En el momento en que se empieza a ejecutar un script o se arranca una sesión con el intérprete interactivo, se entra en el ámbito global.

  • Del ámbito global sólo se sale cuando se finaliza la ejecución del script o se cierra el intérprete interactivo.

• 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 definició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 definició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. 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.

   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.

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.

• Por otra parte, el momento en que una ligadura deja de existir depende su almacenamiento:

  • Si se almacena en un objeto, es porque la ligadura está ligando un atributo de ese objeto a un determinado valor. En tal caso, la ligadura dejará de existir cuando se elimine el objeto de la memoria, o bien, cuando se elimine el atributo ligado.

  • En caso contrario, la ligadura estará almacenada en un marco y, por tanto, 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.

• 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 que crean 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 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 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 usadas 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 acceder a 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 nombres 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.

• Por ejemplo: f(n) = n + f(n + 1)

• Esta función matemática es recursiva porque aparece ella misma en su propia definición.

  Para calcular el valor de f(n) tenemos que volver a utilizar la propia función f.

• Por ejemplo: f(1) = 1 + f(2) = 1 + 2 + f(3) = 1 + 2 + 3 + f(4) = \ldots

• Cada vez que una función se llama a sí misma decimos que se realiza una llamada recursiva o paso recursivo.

• Ese punto en el que la función recursiva no se llama a sí misma, se denomina caso base, y puede haber más de uno.

• Los casos base, por tanto, determinan bajo qué condiciones la función no se llamará a sí misma, o dicho de otra forma, con qué valores de sus argumentos la función devolverá directamente un valor y no provocará una nueva llamada recursiva.

• Los demás casos, que sí provocan llamadas recursivas, se denominan casos recursivos.

• Tenemos el caso recursivo, pero necesitamos al menos un caso base para evitar que la recursión se haga infinita.

• El caso base del factorial se obtiene sabiendo que el factorial de 0 es directamente 1 (no hay que llamar al factorial recursivamente): 0! = 1

• Combinando ambos casos tendríamos:

  n! = \begin{cases} 1 & \text{si } n = 0 \text{\quad(caso base)} \\ n\cdot(n-1)! & \text{si } n > 0 \text{\quad(caso recursivo)} \end{cases}

• La especificación de una función que calcule el factorial de un número sería:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & n \geq 0 \\[0.5em] & \texttt{factorial(\(n\):\,int)\;->\;int} \\[0.5em] \text{\textbf{Post}}: & \texttt{factorial(\(n\))} = n! \end{array}\right.

• Y su implementación en Python podría ser la siguiente:

  factorial = lambda n: 1 if n == 0 else n * factorial(n - 1)

  que sería prácticamente una traducción literal de la definición recursiva de factorial que acabamos de obtener.

• En el ejemplo del factorial:

  • El caso base es fact(0), es decir, el caso en el que queremos calcular el factorial de 0, que ya vimos que es directamente 1 (sin necesidad de llamadas recursivas).

  • Si queremos resolver el problema de calcular, por ejemplo, el factorial de 5, podríamos intentar reducir el problema a calcular el factorial de 4, que es un número que está más cerca del caso base (que es 0).

  • A su vez, para calcular el factorial de 4, reduciríamos el problema a calcular el factorial de 3, y así sucesivamente.

  • De esta forma, podemos reducir el problema de calcular el factorial de n a calcular el factorial de (n - 1), que es un número que está más cerca del 0. Así, cada vez estaremos más cerca del caso base y, al final, siempre lo acabaremos alcanzando.

• En el ejemplo del factorial:

  • Supongamos que queremos calcular, por ejemplo, el factorial de 6.

  • Aún no sabemos calcular el factorial de 6, pero suponemos (por hipótesis inductiva) que sí sabemos calcular el factorial de 5.

    En ese caso, ¿cómo puedo aprovechar que sé resolver el factorial de 5 para lograr calcular el factorial de 6?

  • Analizando el problema, observo que se cumple esta propiedad: 6! = 6\cdot\overbrace{5\cdot4\cdot3\cdot2\cdot1}^{5!}=6\cdot 5!

    Por tanto, he deducido un método para resolver el problema de calcular el factorial de 6 a partir del factorial de 5: para calcular el factorial de 6 basta con calcular primero el factorial de 5 y luego multiplicar el resultado por 6.

    Dicho de otro modo: si yo supiera calcular el factorial de 5, me bastaría con multiplicarlo por 6 para obtener el factorial de 6.

• Generalizando para cualquier número, no sólo para el 6:

  • Si queremos diseñar una función fact(n) que calcule el factorial de n, supondremos que esa función ya existe pero que aún no sabe calcular el factorial de n, aunque sí sabe calcular el factorial de \pmb{(n - 1)}.

    Tenemos que creer en que es así y actuar como si fuera así, aunque ahora mismo no sea verdad. Ésta es nuestra hipótesis inductiva.

  • Por otra parte, sabemos que: n! = n\cdot\overbrace{(n-1)\cdot(n-2)\cdot(n-3)\cdot2\cdot1}^{(n-1)!}=n\cdot(n-1)!

    Por tanto, si sabemos calcular el factorial de (n - 1) llamando a fact(n - 1), para calcular fact(n) sólo necesito multiplicar n por el resultado de fact(n - 1).

    Resumiendo: si yo supiera calcular el factorial de \pmb{(n - 1)}, me bastaría con multiplicarlo por \pmb{n} para obtener el factorial de \pmb{n}.

  • Así obtengo el caso recursivo de la función fact, que sería: fact(n) = n\cdot fact(n-1)

• Combinando todos los pasos, obtenemos la solución general:

fact(n) = \begin{cases} 1 & \text{si } n = 0 \text{\quad(caso base)} \\ n\cdot fact(n-1) & \text{si } n > 0 \text{\quad(caso recursivo)} \end{cases}

• Podemos observar un perfil de expansión seguido de una contracción:

  • La expansión ocurre conforme el proceso construye una secuencia de operaciones a realizar posteriormente (en este caso, una secuencia de multiplicaciones).

  • La contracción se realiza conforme se van ejecutando realmente las multiplicaciones.

• Llamaremos proceso recursivo a este tipo de proceso caracterizado por una secuencia de operaciones pendientes de completar.

• Para poder ejecutar este proceso, el intérprete necesita memorizar, en algún lugar, un registro de las multiplicaciones que se han dejado para más adelante.

• En el cálculo de n!, la longitud de la secuencia de operaciones pendientes (y, por tanto, la información que necesita almacenar el intérprete), crece linealmente con n, al igual que el número de pasos de reducción.

  A este tipo de procesos lo llamaremos proceso recursivo lineal.

• Al igual que antes, usaremos el modelo de sustitución para visualizar el proceso del cálculo de 6!:

  factorial(6)
  = fact_iter(6, 1)
  = fact_iter(5, 6)
  = fact_iter(4, 30)
  = fact_iter(3, 120)
  = fact_iter(2, 360)
  = fact_iter(1, 720)
  = fact_iter(0, 720)
  = 720

• Este proceso no tiene expansiones ni contracciones ya que, en cada instante, toda la información que se necesita almacenar es el valor actual de los parámetros cont y acc, por lo que el tamaño de la memoria necesaria es constante.

• A este tipo de procesos lo llamaremos proceso iterativo.

• El número de pasos necesarios para calcular n! usando esta función crece linealmente con n.

  A este tipo de procesos lo llamaremos proceso iterativo lineal.

* * *

• En general, un proceso iterativo es aquel que está definido por una serie de coordenadas de estado junto con una regla fija que describe cómo actualizar dichas coordenadas conforme cambia el proceso de un estado al siguiente.

• La diferencia entre los procesos recursivo e iterativo se puede describir de esta otra manera:

  • En el proceso iterativo, los parámetros dan una descripción completa del estado del proceso en cada instante.

    Así, si parásemos el cálculo entre dos pasos, lo único que necesitaríamos hacer para seguir con el cálculo es darle al intérprete el valor de los dos parámetros.

  • En el proceso recursivo, el intérprete tiene que mantener cierta información oculta que no está almacenada en ningún parámetro y que indica qué operaciones ha realizado hasta ahora y cuáles quedan pendientes por hacer.

• No debe confundirse un proceso recursivo con una función recursiva:

  • Cuando hablamos de función recursiva nos referimos al hecho de que la función se llama a sí misma (directa o indirectamente).

  • Cuando hablamos de proceso recursivo nos referimos a la forma en como se desenvuelve la ejecución de la función (con una expansión más una contracción).

• Puede parecer extraño que digamos que una función recursiva (por ejemplo, fact_iter) genera un proceso iterativo.

  Sin embargo, el proceso es realmente iterativo porque su estado está definido completamente por dos parámetros, y para ejecutar el proceso sólo se necesita almacenar el valor de esos dos parámetros.

• Aquí hemos visto un ejemplo donde se aprecia claramente que una función sólo puede tener una especificación pero puede tener varias implementaciones distintas.

• Eso sí: todas las implementaciones de una función deben satisfacer su especificación.

• En este caso, las dos implementaciones son:

  factorial = lambda n: 1 if n == 0 else n * factorial(n - 1)

  y

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

• Y aunque las dos satisfacen la misma especificación (y, por tanto, calculan exactamente los mismos valores), lo hacen de una forma muy diferente, generando incluso procesos de distinto tipo.

• Podemos definir una función recursiva que devuelva el n-ésimo término de la sucesión de Fibonacci:

  fib(n) = \begin{cases} 0 & \text{si } n = 0 \text{\quad (caso base)} \\ 1 & \text{si } n = 1 \text{\quad (caso base)} \\ fib(n - 1) + fib(n - 2) & \text{si } n > 1 \text{\quad (caso recursivo)} \end{cases}

• La especificación de una función que devuelva el n-ésimo término de la sucesión de Fibonacci sería:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & n \geq 0 \\[0.5em] & \texttt{fib(\(n\):\,int)\;->\;int} \\[0.5em] \text{\textbf{Post}}: & \texttt{fib(\(n\))} = \text{el \(n\)-ésimo término de la sucesión de Fibonacci} \end{array}\right.

• Y su implementación en Python podría ser:

  fib = lambda n: 0 if n == 0 else 1 if n == 1 else fib(n - 1) + fib(n - 2)

  o bien, separando la definición en varias líneas:

  fib = lambda n: 0 if n == 0 else \
                  1 if n == 1 else \
                  fib(n - 1) + fib(n - 2)

• Si vemos el perfil de ejecución de fib(5), vemos que:

  • Para calcular fib(5), antes debemos calcular fib(4) y fib(3).

  • Para calcular fib(4), antes debemos calcular fib(3) y fib(2).

  • Así sucesivamente hasta poner todo en función de fib(0) y fib(1), que se pueden calcular directamente (son los casos base).

• En general, el proceso resultante tiene forma de árbol.

• Por eso decimos que las funciones con recursividad múltiple generan procesos recursivos en árbol.

• La función anterior es un buen ejemplo de recursión en árbol, pero desde luego es un método horrible para calcular los números de Fibonacci, por la cantidad de operaciones redundantes que efectúa.

• Para tener una idea de lo malo que es, se puede observar que fib(n) crece exponencialmente en función de n.

• Por lo tanto, el proceso necesita una cantidad de tiempo que crece exponencialmente con n.

• Por otro lado, el espacio necesario sólo crece linealmente con n, porque en un cierto momento del cálculo sólo hay que memorizar los nodos que hay por encima.

• En general, en un proceso recursivo en árbol el tiempo de ejecución crece con el número de nodos del árbol mientras que el espacio necesario crece con la altura máxima del árbol.

• Se puede construir un proceso iterativo para calcular los números de Fibonacci.

• La idea consiste en usar dos coordenadas de estado a y b (con valores iniciales 0 y 1, respectivamente) y aplicar repetidamente la siguiente transformación:

  \begin{array}{l} a_{nuevo} = b_{viejo} \\[0.5em] b_{nuevo} = b_{viejo} + a_{viejo} \end{array}

• Después de n pasos, a y b contendrán fib(n) y fib(n + 1), respectivamente.

• En Python sería:

  fib_iter = lambda cont, a, b: a if cont == 0 else fib_iter(cont - 1, b, a + b)
  fib = lambda n: fib_iter(n, 0, 1)

• Esta función genera un proceso iterativo lineal, por lo que es mucho más eficiente.

• Es decir:

  • fact_iter(cont, acc) simplemente llama a:

    fact_iter(cont - 1, acc * cont)

    y luego devuelve directamente el valor que le entrega ésta llamada, sin hacer ninguna otra operación posterior antes de terminar.

  • En cambio, factorial(n) hace:

    n * factorial(n - 1)

    o sea, se llama a sí misma pero el resultado de la llamada recursiva tiene que multiplicarlo luego por n antes de devolver el resultado final.

• Por tanto, lo último que hace fact_iter es llamarse a sí misma. En cambio, lo último que hace factorial no es llamarse a sí misma, porque tiene que hacer más operaciones (en este caso, la multiplicación) antes de devolver el resultado.

• Cuando lo último que hace una función recursiva es llamarse a sí misma y devolver directamente el valor devuelto por esa llamada recursiva, decimos que la función es recursiva final o que tiene recursividad final.

• En caso contrario, decimos que la función es recursiva no final o que tiene recursividad no final.

• Las funciones recursivas finales generan procesos iterativos.

• La función fact_iter es recursiva final, y por eso genera un proceso iterativo.

• En cambio, la función factorial es recursiva no final, y por eso genera un proceso recursivo.

• En la práctica, para que un proceso iterativo consuma realmente una cantidad constante de memoria, es necesario que el traductor optimice la recursividad final.

• Ese tipo de optimización se denomina tail-call optimization (TCO).

• No muchos traductores optimizan la recursividad final.

• De hecho, ni el intérprete de Python ni la máquina virtual de Java optimizan la recursividad final.

• Por tanto, en estos dos lenguajes, las funciones recursivas finales consumen tanta memoria como las no finales.

• De hecho, por lo que respecta a area, cuadrado no representa una definición concreta de función, sino más bien la abstracción de una función, lo que se denomina una abstracción funcional, ya que a area le sirve igual de bien cualquier función que calcule el cuadrado de un número.

• Por tanto, si consideramos únicamente los valores que devuelven, las tres funciones siguientes son indistinguibles e igual de válidas para area. Ambas reciben un argumento numérico y devuelven el cuadrado de ese número:

  cuadrado = lambda x: x * x
  cuadrado = lambda x: x ** 2
  cuadrado = lambda x: x * (x - 1) + x

• En otras palabras: la definición de una función debe ser capaz de ocultar sus detalles internos de funcionamiento, ya que para usar la función no debe ser necesario conocer esos detalles.

• «Abstraer» es centrarse en lo importante en un determinado momento e ignorar lo que en ese momento no resulta importante.

• «Crear una abstracción» es meter un mecanismo más o menos complejo dentro de una caja negra y darle un nombre, de forma que podamos referirnos a todo el conjunto simplemente usando su nombre y sin tener que conocer su composición interna ni sus detalles internos de funcionamiento.

• Por tanto, para usar la abstracción nos bastará con conocer su nombre y lo que hace, sin necesidad de saber cómo lo hace ni de qué elementos está formada internamente.

• La abstracción es el principal instrumento de control de la complejidad, ya que nos permite ocultar detrás de un nombre los detalles que componen una parte del programa, haciendo que esa parte actúe (a ojos del programador que la utilice) como si fuera un elemento predefinido del lenguaje.

• Las funciones son, por tanto, abstracciones porque nos permiten usarlas sin tener que conocer los detalles internos del procesamiento que realizan.

• Por ejemplo, si queremos usar la función cubo (que calcula el cubo de un número), nos da igual que dicha función esté implementada de cualquiera de las siguientes maneras:

  cubo = lambda x: x * x * x
  cubo = lambda x: x ** 3
  cubo = lambda x: x * x ** 2

• Para usar la función, nos basta con saber que calcula el cubo de un número, sin necesidad de saber qué cálculo concreto realiza para obtener el resultado.

• Los detalles de implementación quedan ocultos y por eso también decimos que cubo es una abstracción.

• Las funciones también son abstracciones porque describen operaciones compuestas a realizar sobre ciertos valores sin importar cuáles sean esos valores en concreto (son generalizaciones de casos particulares).

• Por ejemplo, cuando definimos:

  cubo = lambda x: x * x * x

  no estamos hablando del cubo de un número en particular, sino más bien de un método para calcular el cubo de cualquier número.

• Por supuesto, nos las podemos arreglar sin definir el concepto de cubo, escribiendo siempre expresiones explícitas (como 3*3*3, y*y*y, etc.) sin usar la palabra «cubo», pero eso nos obligaría siempre a expresarnos usando las operaciones primitivas de nuestro lenguaje (como *), en vez de poder usar términos de más alto nivel.

  Es decir: nuestros programas podrían calcular el cubo de un número, pero no tendrían la habilidad de expresar el concepto de elevar al cubo.

• Una de las habilidades que deberíamos pedir a un lenguaje potente es la posibilidad de construir abstracciones asignando nombres a los patrones más comunes, y luego trabajar directamente usando dichas abstracciones.

• Las funciones nos permiten esta habilidad, y esa es la razón de que todos los lenguajes (salvo los más primitivos) incluyan mecanismos para definir funciones.

• Por ejemplo: en el caso anterior, vemos que hay un patrón (multiplicar algo por sí mismo tres veces) que se repite con frecuencia, y a partir de él construimos una abstracción que asigna un nombre a ese patrón (elevar al cubo).

• Esa abstracción la definimos como una función que describe la regla necesaria para elevar algo al cubo.

• Por tanto, algunas veces, analizando ciertos casos particulares, observamos que se repite el mismo patrón en todos ellos, y de ahí extraemos un caso general que agrupa a todos los posibles casos particulares que cumplen el mismo patrón.

• A ese caso general le damos un nombre y ocultamos sus detalles internos en una «caja negra».

• Eso es una abstracción.

• En resumen, creamos abstracciones:

  • Cuando creamos casos generales a partir de patrones que se repiten en varios casos particulares.

  • Cuando queremos reducir la complejidad, dándole un nombre a un mecanismo complejo para poder referirnos a todo el conjunto a través de su nombre sin tener que recordar continuamente qué piezas contiene el mecanismo o cómo funciona éste por dentro.

  • Cuando queremos que nuestro programa pueda expresar un concepto abstracto, como el de «elevar al cubo».

• Por ejemplo, cuando vemos que en nuestros programas es frecuente tener que multiplicar una cosa por sí misma tres veces, deducimos que ahí hay un patrón común que se repite en todos los casos.

• De ahí, creamos la abstracción que describe ese patrón general y le llamamos «elevar al cubo»:

• La especificación de una función es la descripción de qué hace la función sin entrar a detallar cómo lo hace.

• La implementación de una función es la descripción de cómo hace lo que hace, es decir, los detalles de su algoritmo interno.

• Para poder usar una función, un programador no debe necesitar saber cómo está implementada.

• Eso es lo que ocurre, por ejemplo, con las funciones predefinidas del lenguaje (como max, abs o len): sabemos qué hacen pero no necesitamos saber cómo lo hacen.

• Incluso puede que el usuario de una función no sea el mismo que la ha escrito, sino que la puede haber recibido de otro programador como una «caja negra», que tiene unas entradas y una salida pero no se sabe cómo funciona por dentro.

• Hasta ahora, al especificar programas, hemos llamado «entrada» al dominio, y hemos agrupado el rango y el propósito en una sola propiedad que llamamos «salida».

• Por ejemplo, cualquier función cuadrado que usemos para implementar area debe satisfacer esta especificación:

  \begin{cases} \text{\textbf{Entrada}}: n \in \mathbb{R} \\ \texttt{cuadrado} \\ \text{\textbf{Salida}}: n^2 \end{cases}

• La especificación no concreta cómo se debe llevar a cabo el propósito. Esos son detalles de implementación que se abstraen a este nivel.

• Este esquema es el que hemos usado hasta ahora para especificar programas, y se podría seguir usando para especificar funciones, ya que éstas son consideradas subprogramas (programas que forman parte de otros programas más grandes).

• Pero para especificar funciones resulta más adecuado usar el siguiente esquema, al que llamaremos especificación funcional:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & \texttt{True} \\[0.5em] & \texttt{cuadrado(\(n\):\,float)\;->\;float} \\[0.5em] \text{\textbf{Post}}: & \texttt{cuadrado(\(n\))} = n^2 \end{array}\right.

• «Pre» representa la precondición: la propiedad que debe cumplirse justo en el momento de llamar a la función.

• «Post» representa la postcondición: la propiedad que debe cumplirse justo después de que la función haya terminado de ejecutarse.

• Lo que hay en medio es la signatura: el nombre de la función, el nombre y tipo de sus parámetros y el tipo del valor de retorno.

• La especificación se lee así: «Si se llama a la función respetando su signatura y cumpliendo su precondición, la llamada termina cumpliendo su postcondición».

• En este caso, la precondición es True, que equivale a decir que cualquier condición de entrada es buena para usar la función.

• Dicho de otra forma: no hace falta que se dé ninguna condición especial para usar la función. Siempre que la llamada respete la signatura de la función, el parámetro n puede tomar cualquier valor de tipo float y no hay ninguna restricción adicional.

• Por otro lado, la postcondición dice que al llamar a la función cuadrado con el argumento n se debe devolver n^2.

• Tanto la precondición como la postcondición son predicados, es decir, expresiones lógicas que se escriben usando el lenguaje de las matemáticas y la lógica.

• La signatura se escribe usando la sintaxis del lenguaje de programación que se vaya a usar para implementar la función (Python, en este caso).

• Recordemos la diferencia entre:

  • Dominio y conjunto origen de una función.

  • Rango (o codominio) y conjunto imagen de una función.

• ¿Cómo recoge la especificación esas cuatro características de la función?

  • La signatura expresa el conjunto origen y el conjunto imagen de la función.

  • El dominio viene determinado por los valores del conjunto origen que cumplen la precondición.

  • El codominio viene determinado por los valores del conjunto imagen que cumplen la postcondición.

• En el caso de la función cuadrado tenemos que:

  • El conjunto origen es float, ya que su parámetro n está declarado de tipo float en la signatura de la función.

    Por tanto, los datos de entrada a la función deberán pertenecer al tipo float.

  • El dominio coincide con el conjunto origen, ya que su precondición es True. Eso quiere decir que cualquier dato de entrada es válido siempre que pertenezca al dominio (en este caso, el tipo float).

  • El conjunto imagen también es float, ya que así está declarado el tipo de retorno de la función.

• Las pre y postcondiciones no es necesario escribirlas de una manera formal y rigurosa, usando el lenguaje de las Matemáticas o la Lógica.

• Si la especificación se escribe en lenguaje natural y se entiende bien, completamente y sin ambigüedades, no hay problema.

• El motivo de usar un lenguaje formal es que, normalmente, resulta mucho más conciso y preciso que el lenguaje natural.

• El lenguaje natural suele ser:

  • Más prolijo: necesita más palabras para decir lo mismo que diríamos matemáticamente usando menos caracteres.

  • Más ambiguo: lo que se dice en lenguaje natural se puede interpretar de distintas formas.

  • Menos completo: quedan flecos y situaciones especiales que no se tienen en cuenta.

• En este otro ejemplo, más completo, se especifica una función llamada cuenta:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & car \mathrel{\char`≠} \text{\texttt{""}} \land \texttt{len(}car\texttt{)} = 1 \\[0.5em] & \texttt{cuenta(\(cadena\):\,str,\;\(car\):\,str)\;->\;int} \\[0.5em] \text{\textbf{Post}}: & \texttt{cuenta(\(cadena\),\;\(car\))} \geq 0\ \land\\[0.1em] & \texttt{cuenta(\(cadena\),\;\(car\))} = cadena\texttt{.count(\(car\))} \end{array}\right.

• Con esta especificación, estamos diciendo que cuenta es una función que recibe una cadena y un carácter (otra cadena con un único carácter dentro).

• Ahora bien: esa cadena y ese carácter no pueden ser cualesquiera, sino que tienen que cumplir la precondición.

• Eso significa, entre otras cosas, que aquí el dominio y el conjunto origen de la función no coinciden (no todos los valores pertenecientes al conjunto origen sirven como datos de entrada válidos para la función).

• En esta especificación, count se usa como un método auxiliar.

  Las operaciones auxiliares se puede usar en una especificación siempre que estén perfectamente especificadas, aunque no estén implementadas.

• En este caso, se usa en la postcondición para decir que la función cuenta, la que se está especificando, debe devolver el mismo resultado que devuelve el método count (el cual ya conocemos perfectamente y sabemos qué hace, puesto que es un método que ya existe en Python).

• Es decir: la especificación anterior describe con total precisión que la función cuenta cuenta el número de veces que el carácter \underline{\textbf{\textit{car}}} aparece en la cadena \underline{\textbf{\textit{cadena}}}.

• En realidad, las condiciones de la especificación anterior se podrían simplificar aprovechando las propiedades de las expresiones lógicas, quedando así:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & \texttt{len(\(car\))} = 1 \\[0.5em] & \texttt{cuenta(\(cadena\):\,str,\;\(car\):\,str)\;->\;int} \\[0.5em] \text{\textbf{Post}}: & \texttt{cuenta(\(cadena\),\;\(car\))} = cadena\texttt{.count(\(car\))} \end{array}\right.

• Finalmente, podríamos escribir la misma especificación en lenguaje natural:

  \left\{\begin{array}{ll} \text{\textbf{Pre}}: & car \text{ debe ser un único carácter} \\[0.5em] & \texttt{cuenta(\(cadena\):\,str,\;\(car\):\,str)\;->\;int} \\[0.5em] \text{\textbf{Post}}: & \texttt{cuenta(\(cadena\),\;\(car\))} \text{ devuelve el número de veces}\\[0.1em] & \text{que aparece el carácter } car \text{ en la cadena } cadena.\\[0.1em] & \text{Si } cadena \text{ es vacía o } car \text{ no aparece nunca en la}\\[0.1em] & \text{cadena } cadena \text{, debe devolver } 0. \end{array}\right.

• Probablemente resulta más fácil de leer (sobre todo para los novatos), pero también es más largo y prolijo.

• Es como un contrato escrito por un abogado en lenguaje jurídico.