Home » Guías » Guía básica de Swift REPL, otra forma de probar y trabajar
Swift REPL

Guía básica de Swift REPL, otra forma de probar y trabajar

No hace mucho iniciamos un Guía de uso de los Playground, una nueva funcionalidad que Apple estrenó junto a su nuevo lenguaje y que permite a cualquiera probar código en Swift, en tiempo real y sin la necesidad de crear un proyecto completo y ejecutar en simuladores ni nada parecido. Simplemente escribir con la enorme ventaja de una serie de herramientas que nos permiten valorar y testear nuestro código para probar su eficiencia.

Pero para aquellos que hemos crecido con los interfaces de línea de comando como el MSDOS o el magnífico SQL*Plus de Oracle, y que aun hoy disfrutamos con terminales, Apple ha creado una herramienta más a nuestra medida: Swift REPL (Read-Eval-Print Loop) o lo que es lo mismo ciclo de lectura, evaluación e impresión.

En realidad, el REPL existe desde hace mucho y el mencionado SQL Plus es un buen de ejemplo de este. REPL se conoce también como el shell del lenguaje o interfaz más básico. Es la herramienta más básica de testeo y prueba, más rápida y práctica que el clásico ciclo de edición, compilación, ejecución y debug.

Si trabajar con un Playground es rápido y práctico, usar REPL en línea de comandos lo es más aún. Si hemos trabajado con los Playground sabremos que su dinámica se basa en compilar el código cada vez que detecta un cambio en el mismo desde el editor, lo que no deja de ser un paso intermedio entre el ciclo clásico y el de REPL. El REPL, sin embargo, lo que hace es ejecutar directamente las instrucciones dando la salida directa de su ejecución.

Usando REPL

REPL requiere que usemos el terminal de comandos del sistema, así que vamos a nuestra carpeta de aplicaciones, buscamos la carpeta Utilidades y ejecutamos la app Terminal (también podemos usar Spotlight, que para el caso es más rápido). Una vez abierto el terminal lo único que hemos de hacer es escribir:

Nada más. Al hacerlo, la primera vez tardará un poco pues compilará algunos elementos necesarios y nos aparecerá el mensaje:

Ya podemos empezar a escribir nuestro código para probarlo y veremos que este se va ejecutando línea a línea, dándonos por cada línea una salida que nos muestra qué se ha realizado. Por ejemplo, creamos un array de películas que se llame films:

Al ejecutar la instrucción superior, veremos la respuesta que nos da diciendo que ha creado un array de cadenas, un [String], con 4 valores y nos informa de la posición que tiene cada uno de los valores que hemos dado.

Si queremos hacer un código más complejo que nos requiera más de una línea, por ejemplo una enumeración de los valores de dicho array, podremos hacerlo ya que el intérprete detecta que las sentencias no están completas y nos permite seguir añadiendo código.

Vemos que al pulsar ENTER tras el primer corchete en la línea 2, la línea 3 ya no comienza por un ángulo > sino que empieza por un punto y el sistema nos tabula para que escribamos. Ponemos lo que queramos hacer, pulsamos ENTER y al escribir el corchete de cierre, el propio editor lo pone en su sitio y ejecuta la instrucción dándonos el resultado.

Una instrucción ya ejecutada no puede ser editada (como es lógico) pero una conjunción de instrucciones que estemos escribiendo y que aun no hayamos ejecutado sí se puede. Aunque ya hayamos dado a ENTER para escribir en una nueva línea, podemos subir con el cursor y editar sin problema el código hasta que el intérprete detecte que hemos cerrado un flujo, y entonces lo ejecute.

Podemos escribir una función que nos muestre el ganador que queramos y editarla en tiempo real antes de cerrar su correspondiente ciclo:

Si subimos el cursor, podemos escribir para que en vez de imprimir una cadena, nos devuelva una.

Vemos que podemos movernos libremente por cualquier línea y editar con precisión, ya que el cursor estará en modo edición. En el caso de esta función, al terminarla vemos que la línea 8 vuelve a tener un > que indica que es comienzo de línea de ejecución y no obtenemos salida.

No obstante, podemos invocar la función que acabamos de crear pues esta queda almacenada en la memoria junto al resto de variables o constantes que hayamos usado hasta entonces. Si simplemente llamamos a la función invocándola, veremos que nos da una salida del tipo:

$R0 corresponde al valor de retorno de índice 0 (el primero) dándonos el tipo de variable y su valor. Si ejecutamos sin embargo haciendo un println, obtendremos otro resultado:

Como vemos, mientras el $R0 se nos muestra en gris claro, el resultado del println va en color negro indicando que es una salida real mientras que el anterior era información interna. Esa es la principal diferencia de colores: el gris siempre representa el resultado interno de unas instrucciones y el negro la salida de un proceso.

Hemos de ser coherentes en la introducción de instrucciones porque si usamos una variable o función aun no declarada en un conjunto de instrucciones que aun no hemos procesado, dará error.

Otra cosa a tener en cuenta es que si estamos editando múltiples líneas, solo el ENTER en la última de ellas cuando cerremos el flujo con su correspondiente corchete provocará la ejecución del mismo. Si estamos en cualquier otra línea estaremos en modo edición y el ENTER provocará un salto de línea. Deberemos ir abajo del todo o en su defecto usar la secuencia de teclas ESC y luego el ángulo de cierre > para desplazarnos al último carácter de la última línea y así cerrar convenientemente el flujo con su corchete de cierre.

Los comandos de control de REPL siempre se anteceden por el símbolo :. De esta forma el intérprete diferencia el código de nuestro programa de la instrucciones de control del mismo. Por ejemplo, si queremos salir y cerrar el intérprete, solo hay que escribir:

Si escribimos :help, obtendremos una amplia ayuda que nos dará una idea de cómo el intérprete REPL sirve para mucho más pues nos permite evaluar expresiones, hacer debug del código, evaluar expresiones de C, Objective-C o C++ dentro del contexto del programa…

Os invitamos a probar, experimentar y sacar el máximo provecho de esta nueva e interesante forma de probar y trabajar con Swift. Y si tenéis cualquier duda, ya sabéis como siempre que estamos a vuestra disposición. Hasta la próxima y Good Apple Coding.

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

ARKit

Analizando ARKit

Realizamos un análisis de ARKit, sus posibilidades, cómo funciona y lo comparamos con las Microsoft Hololens para ver el alcance de sus posibilidades. Un análisis en detalle incluyendo algunas pruebas en vídeo que hemos realizado mientras preparamos el curso de ARKit en Apple Coding Academy que verá la luz en septiembre, una vez tengamos versión final de esta interesante plataforma.