sugiero lo siguiente la versión de PSEINT actual sería la casi final, solo se actualizaría BUGs críticos e iniciar PSEINT-II porque pienso que incorporar la biblioteca de interpretación puede generar problemas de acople y a muchos docentes no les gustaría que la aplicación les falle en sus salones de clase. Ó agregar una nueva versión BETA (para ir depurándola) dejando la versión actual como versión estable.
Ahora sobre la creación de la biblioteca de interpretación, he leído que convirtiendo las sentencias a NOTACIÓN POLACA (PN) también conocida como NOTACIÓN PREFIJA, y la NOTACIÓN POLACA INVERSA (RPN) también conocida como NOTACION PREFIJA, con PN y RPN se pueden crear muy poderosos y completos intérpretes y compiladores, creo que LIPS está implementado en PN, cuando se habla de PODEROSOS Y COMPLETOS se refiere a que por ejemplo en el actual PSEINT una expresión aritmética solo muestra el resultado final de la evaluación, con RPN tu puedes mostrar todos los pasos o pasos intermedios de la evaluación, esto permite ver mejor el comportamiento y seguimiento de una expresión o sentencia.
Hay algunos programas convertidores de sentencias en NOTACIÓN NORMAL, mal llamada NOTACIÓN INFIJA a NOTACIÓN POSFIJA O PREFIJA.
Yo escribí un artículo donde demuestro que la notación INFIJA O NOTACIÓN ESTÁNDAR que aprendemos en la escuela al escribir expresiones algebraicas o sentencias de programación no es 100% notación infija, es decir los operadores aritméticos o funciones de programación no siempre están en el medio de los operandos
Ejemplos donde sí se cumplen
A + B, el operador suma esta infijo entre los operandos o argumentos A, B
Igual para A-B, 3*4, 5/2, 5 modulo 2,
Pero no se cumple para
Factorial
A! o 5!, el operador factorial esta después del operando, es decir 5! está en notación postfija.
El negativo de un numero o mejor el operador cambio de signo
-A, -4 está en notación prefija, el operador (-) esta antes del operando
SIMILARMENTE LAS FUNCIONES TRIGONOMÉTRICAS ESTÁN EN MODO PREFIJO
SEN A, COS B, SEN 90, así que escribimos sin darnos cuenta en PN, RPN
Existe aún otra notación la llamada notación exofija el operador esta por fuera del operando, como es el caso de valor absoluto, norma de un vector etc
|x|, la función techo, la función piso, la raíz cuadrada
las notaciones funcionales de tipo NOMBREDEFUNCION(ARGUMENTOS) también se consideran en notación prefija
SEN(a), CEIL(x), FLOOR(X), miFuncion(a,b,c) etc
Finalmente, la NOTACIÓN 2D es muy poco frecuente en IDE o SDK de programación, conozco muy pocos lenguajes que la soportan, uno de ellos es el TI-BASIC.
Para pSEINT debería también incorporarse en el editor un motor de edición 2D de expresiones, hay uno muy bueno en JAVA, ahora busco su nombre.
La NOTACIÓN 2D hace uso de índices, superíndices, guiones o líneas intermedias por ejemplo la sumatoria, la productora, integral, la división, potenciación
Un IDE o SKD o editor de programas que no soporta NOTACIÓN 2D, obliga a digitar o escribir en notación funcional lineal de paréntesis o de caracteres lineales, la seudonotacion debe ser lo más real a la que escribimos en el papel, y en ella lo hacemos en 2D(bidimensional) y no lineal
Ejemplos
La división ente a y b se escribe en un editor que no soporta notación 2D como a/b y no como lo vemos en la mayoría de los libros, entre una línea horizontal.
|x|, se codifica como abs(x) en notación lineal, la sumatoria se codifica como SUM(EXPRESION, INDICE, VALOR INICIAL, VALOR FINAL)
Y después de esta nota introductorio sobre NOTACIONES, el ejemplo que muestra PABLO
EscRibIR A+ b, 42;
Se codifica en RPN como …, pero antes una forma de ver una expresión en RPN es imaginar la suma de dos números, como la enseñan en el cole. Un numero debajo del otro luego una rayita y sumamos
Asi que A+B es:
A
B
+
RESULTA C
Entonces “A+B” en RPN ver en forma lineal el ejemplo anterior “A B +”
Una anécdota, yo aprendí RPN cuando compre mi HP48GX y desde ahí no he dejado de usarlo, un proyecto nuevo que usa RPN y su lenguaje RPL es NEWRPL mas info en https://sourceforge.net/p/newrpl/
regresando a la interpretación de
EscRibIR A+ b, 42;
En RPN es:
42 A B + ESCRIBIR
O en PN
ESCRIBIR + A B 42
En mi caso me gusta más en RPN, es más lógico y fácil de operar, para otros es total mente confuso, por eso odian las calculadoras HP48, HP50 y similares
42 A B + ESCRIBIR;
Se puede ver en forma de pila (stack) o niveles de entrada como:
1: 42
2: A
3: B
4: +
5: ESCRIBIR
6: ;
Ejecutado de arriba hacia abajo
Lee el primer nivel y lo evalúa, coloca el número 42, luego lee el segundo nivel A y lo evalúa, suponiendo que sea A=9, coloca 9, luego lee el tercer nivel, coloca B y si va vale 8. entonces la salida o nuevo stack sería
1: 42
2: 9
3: 8
4: +
5: ESCRIBIR
6;
Luego lee el nivel 4 que es un operador (suma) lo ejecuta es decir suma el nivel 2 con el nivel 3, ya que la suma requiere de dos argumentos y retorna una sola salida o resultado, por esta razón los niveles 2, 3 y 4 se convierten en uno solo, el nuevo stack es
1: 42
2: 17
3: ESCRIBIR
4;
Luego lee el nivel 3, donde encuentra el operador ESCRIBIR y como esta requiere al menos un argumento o n si los hay entonces imprime el valor de 42 y 17 concatenados
Salida final 4217, con un espacio EscRibIR A+ b, “ “, 42; la salida hubiera sido
42 17
El nivel 4: con punto y coma o nueva linea, limpia el stack para preparar el análisis de la próxima sentencia
Se mostró como se evaluaría la expresión estándar “EscRibIR A+ b, 42;” en RPN, dejo esta nueva motivación a Pablo para que se interese en el RPN y tal vez lo incorpore en PSEINT, no como notación de seudocódigo sino como interpretación,
Con el PSEINT actual cuando llega a la expresión A+B, solo nos muestra el resultado de 17, mas no como lo obtuvo, así que no hubo un verdadero y detallado paso a paso, claro está que en la expresión A+B es obvio, pero en expresiones más complejas, nos interesa ver como se llegó a ese resultado, para corroborar que la expresión fue bien escrita, y esto se hace mostrando las evaluaciones intermedias.
Si se usa el RPN como interpretación cada código se convertiría a RPN pero como un archivo independiente, dejando el “CÓDIGO FUENTE” intacto, así al convertirlo a gráfica y devolverse no hay perdida de información.
En RPN
Algoritmo sin_titulo
9 a :=;
8 b :=;
42 A B + ESCRIBIR;
“Hi” ESCRIBIR;
FinAlgoritmo
O visto en forma de stack
Algoritmo sin_titulo
9
a
:=
;
8
B
:=
;
42
A
B
+
ESCRIBIR;
“Hi”
ESCRIBIR;
FinAlgoritmo
La interpretación se basa en ejecución de línea por línea en lugar de INTERPRETAR CADENAS HACIA LA DERECHA, por esta razón la interpretación en RPN es mucho más veloz y fácil de implementar
Gracias por su atención
Jaime
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hola en el blog de Pablo, no me deja colocar un texto largo, asi que lo agrego aca
http://cucarachasracing.blogspot.com.co/2017/02/rehaciendo-pseint-parte-1-motivacion.html
sugiero lo siguiente la versión de PSEINT actual sería la casi final, solo se actualizaría BUGs críticos e iniciar PSEINT-II porque pienso que incorporar la biblioteca de interpretación puede generar problemas de acople y a muchos docentes no les gustaría que la aplicación les falle en sus salones de clase. Ó agregar una nueva versión BETA (para ir depurándola) dejando la versión actual como versión estable.
Ahora sobre la creación de la biblioteca de interpretación, he leído que convirtiendo las sentencias a NOTACIÓN POLACA (PN) también conocida como NOTACIÓN PREFIJA, y la NOTACIÓN POLACA INVERSA (RPN) también conocida como NOTACION PREFIJA, con PN y RPN se pueden crear muy poderosos y completos intérpretes y compiladores, creo que LIPS está implementado en PN, cuando se habla de PODEROSOS Y COMPLETOS se refiere a que por ejemplo en el actual PSEINT una expresión aritmética solo muestra el resultado final de la evaluación, con RPN tu puedes mostrar todos los pasos o pasos intermedios de la evaluación, esto permite ver mejor el comportamiento y seguimiento de una expresión o sentencia.
Hay algunos programas convertidores de sentencias en NOTACIÓN NORMAL, mal llamada NOTACIÓN INFIJA a NOTACIÓN POSFIJA O PREFIJA.
Yo escribí un artículo donde demuestro que la notación INFIJA O NOTACIÓN ESTÁNDAR que aprendemos en la escuela al escribir expresiones algebraicas o sentencias de programación no es 100% notación infija, es decir los operadores aritméticos o funciones de programación no siempre están en el medio de los operandos
Ejemplos donde sí se cumplen
A + B, el operador suma esta infijo entre los operandos o argumentos A, B
Igual para A-B, 3*4, 5/2, 5 modulo 2,
Pero no se cumple para
Factorial
A! o 5!, el operador factorial esta después del operando, es decir 5! está en notación postfija.
El negativo de un numero o mejor el operador cambio de signo
-A, -4 está en notación prefija, el operador (-) esta antes del operando
SIMILARMENTE LAS FUNCIONES TRIGONOMÉTRICAS ESTÁN EN MODO PREFIJO
SEN A, COS B, SEN 90, así que escribimos sin darnos cuenta en PN, RPN
Existe aún otra notación la llamada notación exofija el operador esta por fuera del operando, como es el caso de valor absoluto, norma de un vector etc
|x|, la función techo, la función piso, la raíz cuadrada
las notaciones funcionales de tipo NOMBREDEFUNCION(ARGUMENTOS) también se consideran en notación prefija
SEN(a), CEIL(x), FLOOR(X), miFuncion(a,b,c) etc
Finalmente, la NOTACIÓN 2D es muy poco frecuente en IDE o SDK de programación, conozco muy pocos lenguajes que la soportan, uno de ellos es el TI-BASIC.
Para pSEINT debería también incorporarse en el editor un motor de edición 2D de expresiones, hay uno muy bueno en JAVA, ahora busco su nombre.
La NOTACIÓN 2D hace uso de índices, superíndices, guiones o líneas intermedias por ejemplo la sumatoria, la productora, integral, la división, potenciación
Un IDE o SKD o editor de programas que no soporta NOTACIÓN 2D, obliga a digitar o escribir en notación funcional lineal de paréntesis o de caracteres lineales, la seudonotacion debe ser lo más real a la que escribimos en el papel, y en ella lo hacemos en 2D(bidimensional) y no lineal
Ejemplos
La división ente a y b se escribe en un editor que no soporta notación 2D como a/b y no como lo vemos en la mayoría de los libros, entre una línea horizontal.
|x|, se codifica como abs(x) en notación lineal, la sumatoria se codifica como SUM(EXPRESION, INDICE, VALOR INICIAL, VALOR FINAL)
Y después de esta nota introductorio sobre NOTACIONES, el ejemplo que muestra PABLO
EscRibIR A+ b, 42;
Se codifica en RPN como …, pero antes una forma de ver una expresión en RPN es imaginar la suma de dos números, como la enseñan en el cole. Un numero debajo del otro luego una rayita y sumamos
Asi que A+B es:
A
B
+
RESULTA C
Entonces “A+B” en RPN ver en forma lineal el ejemplo anterior “A B +”
Una anécdota, yo aprendí RPN cuando compre mi HP48GX y desde ahí no he dejado de usarlo, un proyecto nuevo que usa RPN y su lenguaje RPL es NEWRPL mas info en
https://sourceforge.net/p/newrpl/
regresando a la interpretación de
EscRibIR A+ b, 42;
En RPN es:
42 A B + ESCRIBIR
O en PN
ESCRIBIR + A B 42
En mi caso me gusta más en RPN, es más lógico y fácil de operar, para otros es total mente confuso, por eso odian las calculadoras HP48, HP50 y similares
42 A B + ESCRIBIR;
Se puede ver en forma de pila (stack) o niveles de entrada como:
1: 42
2: A
3: B
4: +
5: ESCRIBIR
6: ;
Ejecutado de arriba hacia abajo
Lee el primer nivel y lo evalúa, coloca el número 42, luego lee el segundo nivel A y lo evalúa, suponiendo que sea A=9, coloca 9, luego lee el tercer nivel, coloca B y si va vale 8. entonces la salida o nuevo stack sería
1: 42
2: 9
3: 8
4: +
5: ESCRIBIR
6;
Luego lee el nivel 4 que es un operador (suma) lo ejecuta es decir suma el nivel 2 con el nivel 3, ya que la suma requiere de dos argumentos y retorna una sola salida o resultado, por esta razón los niveles 2, 3 y 4 se convierten en uno solo, el nuevo stack es
1: 42
2: 17
3: ESCRIBIR
4;
Luego lee el nivel 3, donde encuentra el operador ESCRIBIR y como esta requiere al menos un argumento o n si los hay entonces imprime el valor de 42 y 17 concatenados
Salida final 4217, con un espacio EscRibIR A+ b, “ “, 42; la salida hubiera sido
42 17
El nivel 4: con punto y coma o nueva linea, limpia el stack para preparar el análisis de la próxima sentencia
Se mostró como se evaluaría la expresión estándar “EscRibIR A+ b, 42;” en RPN, dejo esta nueva motivación a Pablo para que se interese en el RPN y tal vez lo incorpore en PSEINT, no como notación de seudocódigo sino como interpretación,
Algoritmo sin_titulo
a:=9;
b:=8;
EscRibIR A+ b, 42;
EscRibIR “Hi”;
FinAlgoritmo
Con el PSEINT actual cuando llega a la expresión A+B, solo nos muestra el resultado de 17, mas no como lo obtuvo, así que no hubo un verdadero y detallado paso a paso, claro está que en la expresión A+B es obvio, pero en expresiones más complejas, nos interesa ver como se llegó a ese resultado, para corroborar que la expresión fue bien escrita, y esto se hace mostrando las evaluaciones intermedias.
Si se usa el RPN como interpretación cada código se convertiría a RPN pero como un archivo independiente, dejando el “CÓDIGO FUENTE” intacto, así al convertirlo a gráfica y devolverse no hay perdida de información.
En RPN
Algoritmo sin_titulo
9 a :=;
8 b :=;
42 A B + ESCRIBIR;
“Hi” ESCRIBIR;
FinAlgoritmo
O visto en forma de stack
Algoritmo sin_titulo
9
a
:=
;
8
B
:=
;
42
A
B
+
ESCRIBIR;
“Hi”
ESCRIBIR;
FinAlgoritmo
La interpretación se basa en ejecución de línea por línea en lugar de INTERPRETAR CADENAS HACIA LA DERECHA, por esta razón la interpretación en RPN es mucho más veloz y fácil de implementar
Gracias por su atención
Jaime