El fijar en <a href=”file:backends/tupla/bootstrap.pd::fijar subclase a __CrearClase: {}”>~fijar subclase a~ está siendo compilado a un LSETC EACT, 0,
0, a pesar de que el OPNFRM del ~si~ está vacío. Esto es causado porque
la variable subclase está en el entorno ya que no es importada, no es
caturada, es local pero no es local directa (hay un ámbito de por medio
entre su uso y la función que la contiene).
El código aquí no la «agarra» porque no es una local inmediata (véase esta parte). Por eso no está siendo contada.
No tengo clara la solución. Claramente debo cambiar las reglas de cuando una
variable cuenta para el OPNFRM de su entorno. Los nodos si y mientras
deberían pasar las variables de sus ámbios como si fuesen
«inmediatas». ¿Quizás deba introducir un nuevo metadato?
localInmediataDelÁmbito: Si la local es usada en el ámbito en el que se
declaró (localInmediata solo toma en cuenta funciones, esta toma en cuenta
todos los ámbitos).
Nota: Creo que esto último es innecesario, las locales inmediatas de los
si y mientras deberían estarse incluyendo…
Esto es fundamental, debo agregarlo lo antes posible, quizán incluso antes
que las demás características de v3y.
Solo después de agregar continuaciones.
Existe en el backend de Lua, falta en el de C++.
Pensé que eran buena idea pero si ves a los objetos como funciones no tienen sentido.
Importantes, pero no tanto. Parte de abstraer el control de flujo con funciones (y por ende, objetos).
No estoy seguro de que sea buena idea, sobre todo teniendo en cuenta a los comportamientos.
Debo agregarlos.
Las interfaces pueden ser como en Racket, los comportamientos aún debo diseñarlos mejor.
No, mejor comportamientos.
Esto significa que los objetos deberían ser usados como un sistema distribuído.
- Similar a la filosofía UNIX.
- Ver el trabajo en OSH/Oil.
- Los objetos solo deben ser usados cuando hay invariantes que mantener.
- Objetos como
DatosDeVariableson cuestionables. - Objetos como
Ámbitoson mejores, aunque no perfectos. - Objetos como
CaminaNodosson horribles.
En vez de especificar manualmente en los distíntos pases del IR que argumenos son constantes, procedimientos, números, etc, cada opcode debería saber los tipos de sus argumentos de forma que, por ejemplo, obtener todas las constantes de una tupla séa tan sencillo como:
Mapear: (Filtrar: tupla#opcode#esquema, (MétodoComoFunción: {esConstante})), funcion: c
devolver tupla#en: c#índice
finfuncion
Usar el mismo AST en todos los pases ha resultado en complicaciones innecesarias. Por ejemplo, hacer que los ámbitos y bloques estuviesen representados por sus propios nodos simplificaría mucho el compilador.
Por ejemplo, en vez de tener arreglos de nodos (en NodoPrograma, NodoSi,
NodoMientras, NodoFunción, etc) sería mejor tener un solo atributo
cuerpo que es un NodoBloque, una secuencia de instrucciones. Igualmente,
en vez de que NodoFunción, NodoPrograma, NodoSi, etc tengan
implícitamente sus ámbitos como parte de ellos, sería mejor un NodoÁmbito
que explícitamente representa un ámbito.
En especial PuertoConPosiciónTextual.
Actualmente el parser es una de las partes más lentas del compilador.
Si crees que el parser es lento, espera a ver el parser de expresiones S.
Nota 2021-03-25: Aparentemente, al optimizar Diccionario el
lector/escritor de expresiones S se hizo como 2 veces más rápido, así que no
se si debería optimizarlo manualmente ahora.
Nota 2021-06-17: Nop, a pesar de que es 2 veces más rápido, aún es demasiado
lento para programar de forma cómoda. Mis pruebas al implementar una versión
en Lua no fueron exitosas y creo que tendré que hacer una implementación en
C o ir a un formato más eficiente (¿Quizás binario? ¿Con string.pack?).
Los diccionarios, Resultado y demás no están muy optimizados.
Solo usa _s si es necesario.
Solo pasa cuando la instrucción es una llamada a función/método.
Al cerrar un método fuera de clase con finfuncion en vez de finmetodo, el mensaje de error no tiene la ubicación del error en el archivo.
Lua solo permite llamadas a funciones como instrucciones, la solución es
compilar todas las expresiones en posición de instrucción a _ = expr.
¿Quizás bepd/x/cli?
Por ejemplo, si la variable X, que es un número, es exportada, fijar X a
otro valor dentro del módulo que la exportó debería cambiar el valor visto
por los demás módulos, sin embargo, esto no sucede. La solución es hacer que
rt.ns pida un rt.scope y la lista de nombres a exportar, en vez de los
valores mismos.
Por ejemplo, el texto "hola \\" mundo" erróneamente será parseado como
hola \" mundo en vez de hola \\.
Esto es debido a que faltan implementaciones de HashMap#...,
DiccionarioHashMap#... y DiccionarioAlist#....
Incluso así, Diccionario tendría que implementar sus propias operaciones.
Solo FALSO debe ser falso.
FIXME El mensaje de error de cuando una variable no existe no contiene el lugar del programa en el que se encontró el identificador.
FIXED No se puede cargar una base de datos de módulos que contenga un módulo que solo exporte un identificador.
No se está llevando registro que que llamadas están en posición tail y cuales no. Debido a esto nunca de emiten las instrucciones TMSG, TMSGV, TDYNMSG ni TDYNMSGV.
CLZ2OBJMK0CLZ
Es necesario usar el nuevo opcode DYNMSG. Hola: 1, ...2, 3 debería
compilar a algo como:
(1)
MKARR 1
(2)
(3)
(4)
MKARR 2
-- ([1], 2, [3, 4])
MSGDYN Cx, 3, 1
Si mal no recuerdo, la única parte actual que no permite un build
completamente reproducible es que Ámbito usa un Diccionario (que usa un
hash map) para almacenar los nombres y luego el prólogo de ámbito cuando
las variables se iteran en-órden para emitir las declaraciones de Lua, su
órden está indeterminado.
Nota 2021-06-18: Los nombres de los archivos de los módulos también están en el compilado, así que eso tampoco es reproducible.
La base de datos de módulos no es reproducible debido a que almacena información de los nombres de archivos y compilación (que no es reproducible).
Como mínimo, deberían indicar en que parte del programa sucedió el error.
Nota 2021-08-12: Ahora se pueden quitar con --sin-mensajes. Aún es un
sistema bastante feo, sin embargo.
Nota 2021-08-12: Parcial con PDTAGS.