Sobre tipos de variables y bolas de cristal

En PSeInt siempre tuve un dilema interesante, y aún hoy no tengo certezas sobre cual es la mejor solución. El problema es cómo determinar el tipo de una variable. En este lenguaje, no es necesario declarar las variables y decir de que tipo son, pero sin embargo cada variable tiene un tipo asociado. Es decir, hay variables para guardar texto, otras para números, y otras para valores de verdad. El usuario casi nunca dice explícitamente de qué tipo son las variables que usa en su algoritmo (en realidad a veces sí, se puede configurar, pero en la mayoría de los perfiles no). Entonces, el interprete debe "adivinarlo", y para ello debe analizar qué se hace con estas variables, o qué datos se guardan. O sea, en realidad debe tratar de deducirlo. Pero no siempre se puede, y el problema es ¿qué hacer cuando no?.

Por ejemplo, tomando el siguiente fragmento de pseudocódigo:
    Leer A
    Escribir "Usted ingreso: ",A
La variable A podría ser de cualquier tipo, según qué ingrese el usuario. Si analizamos qué ingresa el usuario para determinar el tipo, en cualquier caso el algoritmo funciona. Pero este otro fragmento:
    Leer Clave
    Si Clave="123" entonces ...
funcionaría mal, ya que al leer 123 el interprete deduciría que es numérica, pero al querer comparar con la cadena de texto "123" generaría un error.
Estaría bien que se tome como cadena de texto, ya que una clave, en general, puede ser alfanumérica. Entonces, hay que ver qué ingresó el usuario para acortar las posibilidades (si ingresó 123 claramente no es un valor de verdad), y ver con qué operadores y operandos interactúa esa variable para terminar de definirlo (al ver que se compara con una cadena literal, sabemos que es de texto). Pasamos entonces al tercer ejemplo:
    Leer A, B
    Si A<B entonces ...
En este caso, si el usuario ingresa 123 y 45, siguiendo la lógica del párrafo anterior, diremos que A y B pueden ser numéricas o de texto. Analizando los operadores, todavía podrían ser numéricas o de texto, pero a la hora de comparar, si fueran numéricas 123 es mayor que 45, pero si fueran cadenas, por el orden lexicográfico el resultado es el opuesto. Entonces, aquí no tenemos herramientas suficientes para deducirlo, y debemos efectivamente adivinar. A la hora de adivinar, yo diría que lo mejor sería tratarlas como numéricas, pero supongamos que más adelante dice:
    Leer C
    Si C>A entonces ...
y resulta que el usuario ingresa "Hola" en C. En este punto está claro que son de texto, pues sino "Hola" no es una entrada válida, pero ya es tarde, ya "adivinamos" que serían numéricas, y se genera una confusión. ¿Hay que marcar un error por querer comparar "Hola" con 123, o seguir interpretando a pesar de la inconsistencia?.

Internamente, PSeInt deduce de qué tipo es una variable por descarte: según qué ingresan en ella o qué operadores y operandos interactúan con ella en las expresiones, se van descartando potenciales tipos de variables hasta que solo queda uno. Antes de comenzar a interpretar el algoritmo se analizan todas las expresiones, pero aún sin saber qué contendrán las variables. Luego, mientras se interpreta, se va completando la información. Sin embargo, a veces el intérprete debe tomar una decisión antes de que las opciones posibles se reduzcan a solo una. El problema ocurre siempre con la entrada por teclado, ya que el usuario ingresa de igual forma el número 123 que la cadena "123" (en el código, como constantes en una asignación, se distinguirían por la presencia o ausencia de comillas). Estos casos son para mi inevitables en un pseudolenguaje no tipado y donde la misma sintaxis de lectura se utiliza para todas las variables, y si bien son poco frecuentes, pueden confundir al alumno; y lo peor que puede hacer PSeInt es interpretar mal un pseudocódigo correcto. Esto será muy contraproducente, ya que si el alumno está usando PSeInt es porque está aprendiendo y aún no tiene la confianza suficiente como para dudar del intérprete. Tal vez, si una persona lee el algoritmo, el nombre de la variable o el enunciado del problema le aclare la duda, pero el intérprete no considera estas cosas, y así va por la vida, cometiendo pequeños errores en situaciones rebuscadas.