Un mal día, mi jefe llegó preguntando por un forma de analizar unos
logs de un programa que utilizamos. Primero una cosa sencilla, y
mi tonta cabeza pensó:
Procesamiento de texto + Algoritmo simple = Perl
No lo vuelvo a hacer.
En ese momento pareció y fue buena idea, detectar un patrón de texto
en un archivo, organizar un poco el texto y limpiarlo, parecía y fue
factible, cuestión de minutos, más tiempo en recordar Perl, afinar la
expresión regular, ver unos cuantos ejemplos sobre arreglos (pero se
veía que llegaba a cosas oscuras) y listo.
Luego al ver el resultado y que había áreas de oportunidad, el
requerimiento creció considerablemente; se encontró un error y
seguimos para adelante.
El error fue resuelto, no sin sus problemas. En mi cabeza rondaban
distintas formas de resolverlo, alguien con idea en el problema del
análisis de texto podrá recordar estos problemas alguna vez:
Teoricamente el archivo tiene la forma:
[Una linea]
[Una linea]
...
Pero en realidad tenía la forma:
[Una linea]
[Una linea][Una linea]
[Una linea][Una mentirosa linea][Una linea]
[Una
linea]
[Una
linea][Una linea]
...
Y combinaciones peores que esa. Así que como opciones encontré:
- Considerar que el salto de linea no fuera mi separador de cadenas.
- Que mis expresiones regulares fueran multi-lineas.
- Otro par que afortunadamente ya no recuerdo.
Al final, después de pensarle un poco dí con una solución
correcta. Pero recae muy poco en el poder de Perl de manejar
expresiones regulares, tanto que podría haberlo escrito en Python
sin ningún contratiempo, al menos no hubiera sido peor que lo que
había hecho en Perl.
Pero hasta ese momento puedo presumir de que Perl había realizado su
tarea sin muchos problemas. El problema fue cuando quise implementar
los requerimientos extras.
En cuanto a mis requisitos para el lenguaje, una vez diseñada mi
solución (y que decidí limpiar un poco el código) son:
- Arreglos de Hash.
- Arreglos de Arreglos de Hash.
- Funciones que reciben valores por referencia.
- Referencia a elementos de arreglos o de Hash.
Estas cosas suenan de lo más natural e inocencentes y han probado ser
una desgracia infinita para mí. No por que no pueda resolver mi
problema, sino por que no encuentro la forma correcta de
hacerlo. Me centraré en el problema de las referencias para
ejemplificar. Tengo un archivo de pruebas que voy generando mientras
voy aprendiendo gramática nuevas (Sí, mientras voy aprendiendo formas
nuevas de hacer lo mismo sigh).
Al inicio del archivo declaro mis buenas intenciones, la prueba es
clásica, declaro una variable ($a) luego hago una referencia a ella
$b y modifico el valor de la variable via su referencia. No me voy a
meter en lo feo que se ve \$, yo creo que esto aceptable en un
lenguaje como Perl:
# Trying to learn how to use references in perl
# Lesson 1: Make reference with \$ and dereference with $$
$a = "pp";
$b = \$a;
$$b = "qq";
print "\$a changed via \$\$b $a\n";
Después intento hacer lo mismo via referencias, tomo la referencia de
$a via \$a sin variables intermedias, está todo bien, cuando
declaro la variable con my, no pongo $$, sólo en el resto de los
casos. Esto es coherente, puedo pasar de mi lección 1 a la lección 2
sin problemas:
# Lesson 2: This works for functions too in the same way \$ and $$
sub t {
my $p = shift;
$$p = "rr";
}
t(\$a);
print "\$a changed via t(\\\$a) $a\n";
Por alguna extraña razón en mi script de trabajo, necesito utilizar
prototipos (que por cierto no pudieron ser más feos) así que me pongo
a probar como hacer prototipos. Y aquí es donde surge la duda, ¿qué
recibe la función? Siendo coherente con la lección 2, una referencia a
escalar (\$), no un escalar realmente, pero aparentemente las
referencias a escalaras son... escalares. Así que yo no me fuí con el
ejemplo anterior y jugué un poco, después de esto obtuve este código
funcional:
# Lesson 3a: with prototypes
sub u ($);
u(\$a);
sub u ($) {
my $p = shift;
$$p = "ss";
}
print "\$a changed via u(\\\$a) $a, with prototype u(\$)\n";
Poniendo atención a la linea de asignación en la función `$$p =
"ss"`. Por que aquí viene el momento en que decimos
Bienvenido a Perl:
# Lesson 3b: same to the one above but using declaring the reference
# in the function no in the call
sub v (\$);
v($a);
sub v (\$) {
my $p = shift;
$$p = "tt";
}
print "\$a changed via v(\$a) $a, with prototype v(\\\$)\n";
Veamos, utilizando una referencia ahora sí, entonces, resulta que $p
tiene una referencia que con $$p se puede "desreferenciar". Bien
entonces si \$a es una referencia y $a es un escalar, ambos
enviados a una función, $$p, sirve para acceder al mismo valor
en ambos casos? ¿\$a y $a son sinónimos? No, pero me dan el mismo
resultado, ¿cómo se supone que debo hacerlo? Buscando esta respuesta
se me ocurrió otra combinación:
# Lesson 3c: same to the others, not declaring reference in the call
# nor the declaration, just use it via $$
sub w ($);
w($a);
sub w ($) {
my $p = shift;
$$p = "tt";
}
print "\$a changed via w(\$a) $a, with prototype w(\$)\n";
Aquí es donde nos paramos de la mesa y mejor nos vamos a otra cosa. La
función espera un scalar, recibe un scalar, y mágicamente, con la
soberana autoridad de hacer lo que se le da la gana "desreferencia"
un scalar ¿? Sí. Eso hizo y tengo un nuevo valor para $a.
¿Cuál es la forma correcta de hacerlo?
En este momento me parecía que la última, ya que aunque no era
explicita -ni mucho menos- era la menos fea (la \ es horrible). Aunque
es la peor en términos de su significado (no dice nada al respecto de
que se esta haciendo). Pero cuando intenté extender esto a arreglos me
dí cuenta que esa era mi peor opción.
Eso lo pondré en otro episodio más de: No importa cuanto procesamiento
de texto te prometan, si un lenguaje programación no es capaz de
mantener una sintaxis estable y elegante para estructuras de datos
complejas gira la página y vete al siguiente.
