Para definir variables globales en nuestro código es recomendable utilizar la instrucción defvar, con el siguiente formato:

(defvar mi-variable 4
    "Esta variable se utiliza para almacenar un entero.")

En realidad, lo único necesario sería (defvar mi-variable). Eso solo ya reserva el espacio y nuestro programa ─y Emacs en general─, la reconocerá como válida. Sin embargo yo he utilizado la definición completa. ¿Por qué? La respuesta es obvia se después de evaluar el código anterior evaluamos (apropos "mi-variable"). ¿Lo ves?... ¡efectivamente! apropos nos mostrará la cadena de documentación que hayamos escrito.

Puedes seguir utilizando set, nada te lo impide, pero al escribir código será mucho más evidente que has querido crear una variable global ─si además documentas para qué la usas es ya de premio─ si utilizas la forma defvar.

También existe una forma defconst, que como su nombre indica implica el deseo de definir una constante, ─es decir, un valor que se mantendrá fijo durante la ejecución de nuestro programa─. Pero tiene un problema estructural básico: Sólo es un deseo, no es efectivo... sólo hay que comprobarlo con el siguiente código:

(defconst MI-CONSTANTE 3
  "Una constante cualquiera que quiero definir.")  ; ==> mi-constante = 3

(set 'MI-CONSTANTE 4)                              ; ==> mi-constante = 4

No hay ningún aviso de error ni nada que bloquee el que cambiemos el valor de una constante, lo cual no parece tener mucho sentido. En Emacs los símbolos mi-constante y MI-CONSTANTE son distintos. Yo suelo utilizar las constantes en mayúsculas para ver a simple vista que estoy intentando modificar algo que pensé como constante en el código y no se me crucen las cosas. También suelo utilizar defconst aún siendo de poca utilidad, porque cuando leo el código estoy seguro que quise definir algo como constante y mis motivos tenía ─los suelo escribir en la cadena de documentación de la definición─.

Para las ocasiones en las que sólo necesitamos las variables durante el tiempo que evaluamos el código y no lo necesitaremos fuera de él, podemos utilizar las formas let y let*, que como set y setq son primas-hermanas monocigóticas, para declarar variables. Tanto let como let* tienen una estructura similar:

(let (variables) (cuerpo))

Quizá con un ejemplo se vea más claro:

(let ((x 3)
      (y 5))    ; aquí se cierra el bloque de «variables»
  (+ x y))      ; aquí está el bloque «cuerpo» y se cierra la forma let

Si evaluamos el código anterior el resultado será 8. Vale, ¿y qué lo diferencia de let*? Vemos el siguiente ejemplo:

(let* ((x 3)
      (y (+ x 2)))
  (+ x y))

Prueba el código con el * y sin él. ¿Qué ocurre cuando no está? ¿Un error? ¿Qué error? ... algo así como «la variable x no existe». ¿Por qué con el asterisco sí existe? Pues básicamente, porque Lisp va evaluando el código de la definición de las variables según se las va encontrando, así, ha podido definir y en base al valor de x. En el caso de no utilizar asterisco, simplemente x no está disponible hasta que no se cierre el bloque de las variables.

Si evaluamos el símbolo x o y fuera de la forma let, elisp nos dirá que esa variable no existe, porque sólo existen dentro de la forma let.

Lo he traducido como formas, en Lisp se llama form a todo lo que se mete entre paréntesis con el fin de ser evaluado. Lo bueno de estas formas es que se pueden meter unas dentro de otras, como se puede intuir de los ejemplos anteriores. Es muy habitual que veamos cosas como por ejemplo:

(defun simbolo-funcion ...
  (let (variables)
    (cuerpo)))

Se puede ver cómo se van acumulando paréntesis en algunos sitios. Al principio te preocupa tanto paréntesis junto, temes olvidar alguno, sin embargo, con la práctica verás que es fácil de entender: sólo son formas dentro de formas que están dentro de formas y tu pensamiento se centrará en esas formas y no en los paréntesis.

La forma if es la más sencilla de todos los condicionales. Su estructura es muy fácil:

(if (condición)
    (bloque evaluado si es «t»)
  (bloque evaluado si es nil))

Vemos un ejemplo para ver cómo funciona:

(if (y-or-n-p "¿Tú que dices?")
    (message "¡¡¡Has dicho que síiii!!!")
  (message-box "Pues no, pues vale."))

He utilizado dos formas interactivas para mostrar un mensaje dentro de una if. La forma y-or-no-p muestra un mensaje en el minibuffer de emacs, el que le pasamos como cadena de caracteres, y espera a que el usuario pulse y si está de acuerdo o n si no lo está. Devolverá t en el primer caso y nil en el segundo. La forma message simplemente muestra un mensaje en el minibuffer. La forma message-box muestra el mensaje en un diálogo de ventana con su botón y todo.

Podríamos decir que when y unless son formas resumidas de if. La primera, when equivale a utilizar sólo el bloque cierto de la expresión. Dicho de otro modo, sólo se ejecutará el bloque de código si la condición es cierta. La forma unless, al contrario, sólo ejecutará el código si resulta la condición falsa.

Podríamos escribir when como:

(when (condición) (bloque de código))

; será completamente equivalente a

(if (condición)
    (bloque de código)
  nil)

Y también podríamos escribir unless como

(unless (condición) (bloque de código))

; será completamente equivalente a

(if (condición)
    nil
  (bloque de código))

Hemos visto que if evalúa sólo una condición para actuar en consecuencia. La forma cond lo que hace es evaluar una condición tras otra mientras y ejecuta sólo el cuerpo de la primera condición que se cumpla.

A ver, más despacio para no perdernos:

(cond (lista de condiciones))

donde cada condición tiene la forma:

(condición forma-código)

Vamos a poner un ejemplo a ver cómo funciona:

(cond ((numberp x) (message "x es un número"))
      ((stringp x) (message "x es una cadena"))
      (t           (message "x no es ni una cadena ni un número")))

Y para probarlo podemos ir evaluándolo con los siguientes valores:

(set 'x 4)
(set 'x "Hola")
(set 'x nil)

Bien, también aprovecho para contar que la tercera forma dentro de la lista de condiciones de cond que he puesto en el ejemplo, se evaluará siempre si ninguna de las anteriores es evaluada como cierta. Si no se pone, la forma cond devolverá un nil, que a veces no será un valor esperado.

Hay ocasiones en que las condiciones pueden ser más complejas que un sí o un no, sino una combinación de valores o cláusulas booleanas. Las funciones booleanas son and, or y not.

(not t)         ; ==> nil
(not nil)       ; ==> t

(and t   t)     ; ==> t
(and t   nil)   ; ==> nil
(and nil t)     ; ==> nil
(and nil nil)   ; ==> nil

(or t   t)      ; ==> t
(or t   nil)    ; ==> t
(or nil t)      ; ==> t
(or nil nil)    ; ==> nil

Vamos a evaluar un par de expresiones para ver cómo funcionan:

(and (message-box "Hola 1") (message-box "Hola 2") nil (message-box "Hola 3"))
(or (message-box "Hola 1") (message-box "Hola 2") nil (message-box "Hola 3"))

Si evaluamos la expresión and veremos que nos aparecen dos message-box y se detiene en tercer elemento, devolviendo nil. Sin embargo, en la expresión or sólo muestra el primero y devuelve la cadena "Hola 1" evaluando la expresión, por tanto como verdadera.