Especificación Técnica Oficial: Metsu Programming Language (MPL)

Versión de la Especificación: 1.0.0-draft
Autor: Metsuke
Ecosistema de Referencia: MetsuOS

MPL Runtime

1. Visión General de la Arquitectura MPL

El lenguaje MPL (Metsu Programming Language) es un lenguaje de especificación y programación estructurado en capas jerárquicas de abstracción. Su objetivo principal es permitir la representación continua de sistemas software desde su descripción declarativa orientada a requisitos de usuario hasta su ejecución lógica e imperativa.

graph TD
    classDef urd fill:#2b4c7e,stroke:#4a90e2,stroke-width:2px,color:#ffffff;
    classDef capa3 fill:#1e5128,stroke:#4e9f3d,stroke-width:2px,color:#ffffff;
    classDef capa2 fill:#7b4b94,stroke:#b873d9,stroke-width:2px,color:#ffffff;
    classDef capa1 fill:#9e472a,stroke:#e67e22,stroke-width:2px,color:#ffffff;

    URD["Capa URD (User Requirements Definition)
Definición narrativa en lenguaje natural formalizado (es-ES)
Requisitos, historias de usuario, vistas narrativas"]:::urd

    Capa3["Capa 3: Pseudocódigo de Alto Nivel (Human-Centric / DSL)
Gramática declarativa en es-ES para flujos, vistas y transiciones"]:::capa3

    Capa2["Capa 2: Pseudocódigo Orientado a Objetos Conceptuales e Interacciones
Entidades, estados, señales, buses de eventos y canalización de datos"]:::capa2

    Capa1["Capa 1: Pseudocódigo Estructurado Imperativo (Base Formal)
Primitivas de control, tipos básicos, rutinas y E/S de bajo nivel"]:::capa1

    URD -->|Abstracción declarativa| Capa3
    Capa3 -->|Binding estructural| Capa2
    Capa2 -->|Implementación lógica| Capa1

2. Definición Formal de las Capas de Abstracción

2.1. Capa URD (User Requirements Definition)

• Definición: Especificación semántica formalizada en castellano (es-ES) sin construcciones sintácticas rígidas de código.
• Propósito: Capturar la intención del dominio, reglas de negocio, flujos de experiencia de usuario (UX) y estados globales del sistema.

2.2. Capa 3: Pseudocódigo de Alto Nivel (Human-Centric DSL)

• Definición: DSL declarativo con lexemas formales en español.
• Construcciones Principales: PANTALLA, VISTA, OPCION, CUANDO, TRANSICIONAR_A, MOSTRAR, SOLICITAR.
• Propósito: Mapear directamente la topología de la aplicación, las decisiones del usuario y las transiciones de estado.

2.3. Capa 2: Objetos Conceptuales e Interacciones

• Definición: Capa orientada a entidades de dominio, modelos de datos, máquinas de estado y buses de comunicación.
• Construcciones Principales: OBJETO_CONCEPTUAL, ESTADO, EVENTO, PROPAGAR, SUSCRIBIR, CONEXION.
• Propósito: Formalizar los modelos de información y el desacoplamiento mediante patrones de eventos/señales.

2.4. Capa 1: Pseudocódigo Formal Imperativo

• Definición: Lenguaje estructurado de control de flujo imperativo, tipos de datos fuertemente tipados y funciones primitivas.
• Construcciones Principales: FUNCION, VARIABLE, SI...SINO, MIENTRAS, PARA, RETORNAR, INCAPSULAR.
• Propósito: Proporcionar la base ejecutable determinista subyacente.

3. Gramática y Léxico Reservado de MPL

4. Flujo de Ejecución e Interacción entre Capas

El siguiente diagrama de secuencia ilustra cómo interactúan las capas de MPL durante el ciclo de vida de una acción del sistema, desde la intención del usuario hasta la resolución lógica imperativa.

sequenceDiagram
    autonumber
    participant URD as Capa URD (Requisito)
    participant C3 as Capa 3 (DSL Declarativo)
    participant C2 as Capa 2 (Objeto / Evento)
    participant C1 as Capa 1 (Imperativo)

    Note over URD: "El usuario selecciona procesar una entrada"
    URD->>C3: Dispara evento de UI

    Note over C3: PANTALLA Principal
OPCION "Procesar" CON_ACCION AccionProcesar
    C3->>C2: AccionProcesar(origen)

    Note over C2: OBJETO_CONCEPTUAL GestorProceso
METODO procesar_solicitud()
    C2->>C1: EjecutarRutinaProcesamiento(datos: Cadena)

    Note over C1: FUNCION EjecutarRutinaProcesamiento(...)
Validación, iteración y retorno
    C1-->>C2: Retorna EstadoResultado

    C2-->>C3: Notifica cambio de estado / Evento
    C3-->>URD: Renderiza nueva vista de usuario

5. Especificación Sintáctica por Capas (Sintaxis Canónica)

5.1. Ejemplo Sintáctico: Capa 3 (DSL Declarativo)

PANTALLA VistaPrincipal:
    ENCABEZADO: "MetsuOS Terminal v1.0"

    COMPONENTE MenuOpciones:
        OPCION "1. Cargar Recurso" CON_ACCION CargarRecurso
        OPCION "2. Consultar Estado" CON_ACCION ConsultarEstado
        OPCION "3. Finalizar" CON_ACCION Salir

    CUANDO AL_PULSAR_TECLA(Escape):
        TRANSICIONAR_A VistaSalida

5.2. Ejemplo Sintáctico: Capa 2 (Objetos y Eventos)

OBJETO_CONCEPTUAL GestorRecursos:
    PROPIEDADES:
        identificador: Cadena
        activo: Booleano
        metadatos: Diccionario[Cadena, Cadena]

    EVENTOS:
        EventoRecursoCargado(id: Cadena)

    INTERACCIONES:
        METODO inicializar(id: Cadena):
            ESTADO.activo = Verdadero
            DISPARAR EventoRecursoCargado(id)

5.3. Ejemplo Sintáctico: Capa 1 (Imperativo Formal)

FUNCION ValidarYProcesarEntrada(entrada: cadena) -> booleano:
    VARIABLE es_valida: booleano
    es_valida = Falso

    SI Longitud(entrada) > 0 ENTONCES:
        VARIABLE i: entero
        PARA i = 0 HASTA Longitud(entrada) - 1 HACER:
            SI CaracterEn(entrada, i) == ' ' ENTONCES:
                RETORNAR Falso
            FIN_SI
        FIN_PARA
        es_valida = Verdadero
    SINO:
        es_valida = Falso
    FIN_SI

    RETORNAR es_valida
FIN_FUNCION

6. Gramática Formal EBNF (Extended Backus-Naur Form)

Esta sección establece las reglas sintácticas estrictas para el análisis léxico y sintáctico (parsing) de MPL en sus tres capas de pseudocódigo.

graph TD
    classDef lexer fill:#2b4c7e,stroke:#4a90e2,stroke-width:2px,color:#ffffff;
    classDef c3 fill:#1e5128,stroke:#4e9f3d,stroke-width:2px,color:#ffffff;
    classDef c2 fill:#7b4b94,stroke:#b873d9,stroke-width:2px,color:#ffffff;
    classDef c1 fill:#9e472a,stroke:#e67e22,stroke-width:2px,color:#ffffff;

    subgraph Pipeline_Gramatica ["Pipeline del Parser MPL"]
        Tokens["Analizador Léxico (Lexer)
Identificadores, Literales, Palabras Reservadas"]:::lexer
        ParserC3["Parser Capa 3 (DSL UI)
Gramática de Pantallas y Menús"]:::c3
        ParserC2["Parser Capa 2 (Modelos)
Gramática de Objetos y Eventos"]:::c2
        ParserC1["Parser Capa 1 (Imperativo)
Gramática de Control de Flujo"]:::c1
    end

    Tokens --> ParserC3
    Tokens --> ParserC2
    Tokens --> ParserC1

6.1. Reglas EBNF: Capa 3 (DSL Declarativo de Interfaz y Flujo)

ProgramaC3         ::= { DefinicionPantalla | DefinicionVista } ;

DefinicionPantalla ::= "PANTALLA" Identificador ":" [ SeccionEncabezado ] { SeccionComponente } { SeccionEventoUI } ;
DefinicionVista    ::= "VISTA" Identificador ":" { SeccionComponente } ;

SeccionEncabezado  ::= "ENCABEZADO" ":" Cadena ;
SeccionComponente  ::= "COMPONENTE" Identificador ":" { DefinicionOpcion } ;
DefinicionOpcion   ::= "OPCION" Cadena "CON_ACCION" Identificador ;

SeccionEventoUI    ::= "CUANDO" TriggerUI ":" AccionUI ;
TriggerUI          ::= "AL_PULSAR_TECLA" "(" Identificador ")" | "AL_SELECCIONAR" "(" Identificador ")" ;
AccionUI           ::= "TRANSICIONAR_A" Identificador | "EJECUTAR" Identificador ;

6.2. Reglas EBNF: Capa 2 (Objetos Conceptuales y Bus de Eventos)

ProgramaC2            ::= { DefinicionObjeto } ;

DefinicionObjeto      ::= "OBJETO_CONCEPTUAL" Identificador ":" [ BloquePropiedades ] [ BloqueEventos ] [ BloqueInteracciones ] ;

BloquePropiedades     ::= "PROPIEDADES" ":" { DeclaracionPropiedad } ;
DeclaracionPropiedad  ::= Identificador ":" TipoDatoC2 ;

BloqueEventos         ::= "EVENTOS" ":" { DeclaracionEvento } ;
DeclaracionEvento     ::= Identificador "(" [ ListaParametrosC2 ] ")" ;

BloqueInteracciones   ::= "INTERACCIONES" ":" { DefinicionMetodo } ;
DefinicionMetodo      ::= "METODO" Identificador "(" [ ListaParametrosC2 ] ")" ":" { SentenciaC2 } ;

SentenciaC2           ::= AsignacionEstado | DisparoEvento | InvocacionC1 ;
AsignacionEstado      ::= "ESTADO" "." Identificador "=" Expresion ;
DisparoEvento         ::= "DISPARAR" Identificador "(" [ ListaArgumentos ] ")" ;
InvocacionC1          ::= Identificador "(" [ ListaArgumentos ] ")" ;

TipoDatoC2            ::= "Texto" | "Numero" | "Booleano" | "Coleccion" | "Diccionario" "[" TipoDatoC2 "," TipoDatoC2 "]" ;

6.3. Reglas EBNF: Capa 1 (Imperativo Formal)

ProgramaC1          ::= { DefinicionFuncion | DeclaracionGlobal } ;

DefinicionFuncion   ::= "FUNCION" Identificador "(" [ ListaParametrosC1 ] ")" [ "->" TipoDatoC1 ] ":" BloqueSentencias "FIN_FUNCION" ;

ListaParametrosC1   ::= ParametroC1 { "," ParametroC1 } ;
ParametroC1         ::= Identificador ":" TipoDatoC1 ;

BloqueSentencias    ::= { SentenciaC1 } ;

SentenciaC1         ::= DeclaracionVariable
                      | Asignacion
                      | Condicional
                      | BucleMientras
                      | BuclePara
                      | Retorno ;

DeclaracionVariable ::= "VARIABLE" Identificador ":" TipoDatoC1 [ "=" Expresion ] ;
Asignacion          ::= Identificador "=" Expresion ;

Condicional         ::= "SI" Expresion "ENTONCES" ":" BloqueSentencias [ "SINO" ":" BloqueSentencias ] "FIN_SI" ;
BucleMientras       ::= "MIENTRAS" Expresion "HACER" ":" BloqueSentencias "FIN_MIENTRAS" ;
BuclePara           ::= "PARA" Identificador "=" Expresion "HASTA" Expresion "HACER" ":" BloqueSentencias "FIN_PARA" ;

Retorno             ::= "RETORNAR" Expresion ;

TipoDatoC1          ::= "cadena" | "entero" | "decimal" | "booleano" | "arreglo" "[" TipoDatoC1 "]" ;

7. Sistema de Tipos e Inferencia Cruzada entre Capas

MPL implementa un sistema de verificación de tipos dinámico-estático escalar. A medida que una entidad desciende de la Capa 3 a la Capa 1, las restricciones de tipo se vuelven más estrictas y deterministas.

graph LR
    classDef c3 fill:#1e5128,stroke:#4e9f3d,stroke-width:2px,color:#ffffff;
    classDef c2 fill:#7b4b94,stroke:#b873d9,stroke-width:2px,color:#ffffff;
    classDef c1 fill:#9e472a,stroke:#e67e22,stroke-width:2px,color:#ffffff;

    subgraph Inferencia_Tipos ["Mapeo y Coerción de Tipos MPL"]
        C3_Types["Capa 3 (Tipos Implícitos)
Etiquetas, Entradas, Comandos"]:::c3
        C2_Types["Capa 2 (Tipos Conceptuales)
Texto, Numero, Booleano, Coleccion"]:::c2
        C1_Types["Capa 1 (Tipos Primitivos)
cadena, entero, decimal, booleano, arreglo"]:::c1
    end

    C3_Types -->|Asignación semántica| C2_Types
    C2_Types -->|Binding estricto| C1_Types

7.1. Tabla de Mapeo Equivalente de Tipos

8. Mecanismo de Transpilación y Semántica de Compilación

El proceso de compilación en MPL no genera directamente lenguaje máquina; transforma las representaciones de alto nivel mediante pasadas de análisis semántico hasta consolidar un AST (Abstract Syntax Tree) ejecutable de Capa 1.

sequenceDiagram
    autonumber
    participant Parser as Analizador Sintáctico
    participant Semantico as Chequeador Semántico
    participant Transpiler as Generador AST MPL
    participant Target as Target de Ejecución

    Parser->>Semantico: Entrega Árbol Sintáctico C3 / C2 / C1
    Note over Semantico: Valida referencias cruzadas entre
Acciones de UI y Métodos C2
    Semantico->>Transpiler: Árbol Validado + Tabla de Símbolos
    Note over Transpiler: Reduce abstracciones de C3 y C2
a bloques de control imperativo C1
    Transpiler->>Target: Emite AST Consolidado Capa 1

8.1. Pasadas del Compilador MPL

1. Pasada 1 (Lexing y Parsing): Convierte el código fuente escrito en cualquier capa de MPL en nodos del AST correspondiente.
2. Pasada 2 (Resolución de Símbolos): Mapea los identificadores de UI en Capa 3 con sus correspondientes métodos/eventos en Capa 2, y las invocaciones de Capa 2 con funciones de Capa 1.
3. Pasada 3 (Lowering / Descenso de Capa): Traduce de forma autómata las estructuras declarativas (PANTALLA, OBJETO_CONCEPTUAL) a bucles de eventos imperativos y estructuras de datos en Capa 1.
4. Pasada 4 (Emisión): Generación del ejecutable final o representación intermedia para el runtime objetivo de MetsuOS.

9. Especificación del Runtime y Event Loop (Motor de Ejecución)

El runtime de MPL opera bajo una arquitectura de ejecución híbrida impulsada por eventos (Event-Driven Loop). Las construcciones declarativas de la Capa 3 y los eventos de la Capa 2 se traducen en un ciclo de eventos no bloqueante en la Capa 1.

graph TD
    classDef loop fill:#2b4c7e,stroke:#4a90e2,stroke-width:2px,color:#ffffff;
    classDef queue fill:#7b4b94,stroke:#b873d9,stroke-width:2px,color:#ffffff;
    classDef exec fill:#1e5128,stroke:#4e9f3d,stroke-width:2px,color:#ffffff;

    subgraph Runtime_MetsuOS ["Motor de Ejecución MPL (Event Loop)"]
        EventQueue["Cola de Eventos (FIFO)
Señales UI, Temporizadores, I/O, Mensajes C2"]:::queue
        Loop["Bucle Principal (Event Loop)
Despachador de Eventos"]:::loop
        Handler["Manejador de Contexto / Pila
Ejecución de Rutinas Imperativas C1"]:::exec
    end

    EventQueue -->|Desencola Siguiente Evento| Loop
    Loop -->|Sincrónico / Asincrónico| Handler
    Handler -->|Modifica Estado / Semiactivo| EventQueue

11.1. Modelo de Concurrencia y Asincronía

• Aislamiento de Estado: Los objetos conceptuales (Capa 2) gestionan su estado de forma aislada.
• Canales de Comunicación: La interacción entre entidades se realiza mediante el paso de mensajes asincrónicos o el disparo directo de eventos (DISPARAR).
• Primitivas Asincrónicas (Capa 1):
• ESPERAR: Pausa la ejecución de la rutina actual cediendo el control al Event Loop hasta que se resuelva una promesa o evento.
• EN_SEGUNDO_PLANO: Ejecuta un bloque imperativo sin bloquear el hilo principal.

10. Manejo de Excepciones y Propagación Cruzada de Errores

El sistema de errores de MPL es uniforme a través de todas las capas, permitiendo capturar fallos técnicos de bajo nivel (Capa 1) o errores de estado/dominio (Capa 2) y representarlos de forma amigable en la interfaz (Capa 3).

sequenceDiagram
    autonumber
    participant C1 as Capa 1 (Imperativo)
    participant C2 as Capa 2 (Objeto / Estado)
    participant C3 as Capa 3 (DSL UI)

    Note over C1: Error I/O o Condición Inválida
    C1->>C1: LANZAR_ERROR ExcepcionLectura
    C1-->>C2: Propaga Excepción no capturada

    Note over C2: Intercepta error en Método
    C2->>C2: PROPAGAR_ERROR ErrorDominio
    C2-->>C3: Notifica fallo de acción

    Note over C3: Captura evento en UI
    C3->>C3: MOSTRAR_AVISO "Error de Procesamiento"

10.1. Sintaxis Canónica de Manejo de Errores

Capa 1: Captura Técnica Imperativa

INTENTAR:
    VARIABLE resultado: cadena
    resultado = LeerArchivo(ruta)
CAPTURAR ExcepcionArchivoNoEncontrado COMO error:
    Imprimir("Error de lectura: " + error.mensaje)
    RETORNAR Falso
FIN_INTENTAR

Capa 2: Propagación Semántica de Dominio

OBJETO_CONCEPTUAL GestorArchivos:
    INTERACCIONES:
        METODO procesar_documento(ruta: Texto):
            INTENTAR:
                EjecutarLectura(ruta)
            CAPTURAR ErrorTecnico COMO e:
                PROPAGAR_ERROR ErrorNegocio("El documento no se pudo validar.")

11. Catálogo de la Librería Estándar (StdLib)

La Librería Estándar de MPL provee el conjunto de rutinas nativas indispensables en la Capa 1 para la interacción con el sistema operativo base, almacenamiento y red.

graph LR
    classDef std fill:#9e472a,stroke:#e67e22,stroke-width:2px,color:#ffffff;

    StdLib["Librería Estándar (StdLib MPL)"]:::std

    IO["Módulo Sistema.IO
Archivo.leer(), Archivo.escribir()"]:::std
    TextoMod["Módulo Texto.Utils
Concatenar(), Reemplazar()"]:::std
    RedMod["Módulo Red.HTTP
Peticion.obtener(), Peticion.enviar()"]:::std
    MathMod["Módulo Mate.Base
Redondear(), Aleatorio()"]:::std

    StdLib --> IO
    StdLib --> TextoMod
    StdLib --> RedMod
    StdLib --> MathMod

11.1. Funciones Nativas Primitivas (Capa 1)

12. Modelo de Memoria y Ciclo de Vida de Objetos

MPL adopta un esquema de gestión de memoria basado en Conteo de Referencias con Recolector de Ciclos (ARC/Garbage Collector híbrido) en la Capa 1, completamente transparente para el desarrollador en las Capas 2 y 3.

• Creación de Instancias: Ocurre automáticamente al entrar en un estado de la Capa 3 o al invocar un OBJETO_CONCEPTUAL en la Capa 2.
• Destrucción de Instancias: Cuando un objeto o vista deja de estar activo o referenciado en el árbol de contexto, el runtime libera de forma determinista sus recursos e invoca su destructor implícito AL_DESTRUIR.

OBJETO_CONCEPTUAL SesionUsuario:
    PROPIEDADES:
        token: Texto

    INTERACCIONES:
        METODO AL_CREAR():
            ESTADO.token = GenerarToken()

        METODO AL_DESTRUIR():
            LimpiarMesaTrabajo()

13. Sistema de Pruebas Unitarias e Integración Integrado (Nativo)

MPL integra el marco de pruebas directamente en la sintaxis del lenguaje. Esto permite validar formalmente los componentes de las tres capas (pantallas y flujos en Capa 3, reglas de negocio y eventos en Capa 2, y algoritmos/rutinas en Capa 1) sin recurrir a herramientas externas.

graph TD
    classDef test3 fill:#1e5128,stroke:#4e9f3d,stroke-width:2px,color:#ffffff;
    classDef test2 fill:#7b4b94,stroke:#b873d9,stroke-width:2px,color:#ffffff;
    classDef test1 fill:#9e472a,stroke:#e67e22,stroke-width:2px,color:#ffffff;
    classDef runner fill:#2b4c7e,stroke:#4a90e2,stroke-width:2px,color:#ffffff;

    Runner["Ejecutor Nativode Pruebas (MPL Test Runner)"]:::runner

    subgraph Suite_Pruebas ["Niveles de Pruebas Integradas"]
        PruebaC3["Pruebas de Flujo UI (Capa 3)
SIMULAR_PULSACION, AFIRMAR_PANTALLA"]:::test3
        PruebaC2["Pruebas de Estado y Eventos (Capa 2)
AFIRMAR_EVENTO, AFIRMAR_ESTADO"]:::test2
        PruebaC1["Pruebas Unitarias Formales (Capa 1)
AFIRMAR_IGUAL, AFIRMAR_VERDADERO"]:::test1
    end

    Runner --> PruebaC3
    Runner --> PruebaC2
    Runner --> PruebaC1

13.1. Pruebas Unitarias en Capa 1 (Imperativo Formal)

Las pruebas de Capa 1 verifican la corrección determinista de las funciones y algoritmos puros mediante aserciones estrictas.

PRUEBA "Validación de formato de cadena no vacía":
    VARIABLE entrada: cadena
    entrada = "MetsuOS"

    VARIABLE resultado: booleano
    resultado = ValidarYProcesarEntrada(entrada)

    AFIRMAR_VERDADERO(resultado)
    AFIRMAR_IGUAL(Longitud(entrada), 7)
FIN_PRUEBA

13.2. Pruebas de Integración y Estado en Capa 2 (Objetos y Eventos)

Las pruebas de Capa 2 verifican la mutación de propiedades de un OBJETO_CONCEPTUAL, la correcta emisión de eventos y el manejo de excepciones de dominio.

PRUEBA "Ciclo de vida y emisión de eventos en GestorRecursos":
    VARIABLE gestor: GestorRecursos

    ESCUCHAR_EVENTO gestor.EventoRecursoCargado COMO evento_capturado

    gestor.inicializar("RES-001")

    AFIRMAR_VERDADERO(gestor.PROPIEDADES.activo)
    AFIRMAR_IGUAL(gestor.PROPIEDADES.identificador, "RES-001")
    AFIRMAR_EVENTO_DISPARADO(evento_capturado)
FIN_PRUEBA

13.3. Pruebas de Interfaz y Flujo de Usuario en Capa 3 (DSL Declarativo)

Las pruebas de Capa 3 simulan la interacción del usuario sobre pantallas y componentes para verificar el comportamiento de la experiencia de usuario (UX).

PRUEBA "Navegación desde VistaPrincipal por pulsación de tecla":
    CARGAR_PANTALLA VistaPrincipal

    SIMULAR_PULSAR_TECLA(Escape)

    AFIRMAR_PANTALLA_ACTIVA(VistaSalida)
FIN_PRUEBA

13.4. Sintaxis y Primitivas de Aserción Nativas

14. Extensibilidad, Módulos y Espacios de Nombres (Namespaces)

Para permitir la organización modular en proyectos de gran escala, MPL define un sistema estricto de paquetes, visibilidad e importación.

graph LR
    classDef ns fill:#2b4c7e,stroke:#4a90e2,stroke-width:2px,color:#ffffff;
    classDef vis fill:#7b4b94,stroke:#b873d9,stroke-width:2px,color:#ffffff;

    subgraph Estructura_Modulos ["Sistema de Espacios de Nombres MPL"]
        NS["PAQUETE MetsuOS.Interfaz"]:::ns
        Export["PUBLICO
PANTALLA, OBJETO_CONCEPTUAL, FUNCION"]:::vis
        Priv["PRIVADO
Variables internas, métodos auxiliares"]:::vis
    end

    NS --> Export
    NS --> Priv

14.1. Definición de Paquetes e Importación

PAQUETE MetsuOS.Sistema.Seguridad

IMPORTAR MetsuOS.StdLib.Sistema.IO
IMPORTAR MetsuOS.Interfaz.Vistas COMO VistasUI

PUBLICO OBJETO_CONCEPTUAL ControlAcceso:
    PROPIEDADES:
        PUBLICO nivel_permiso: Numero
        PRIVADO clave_hash: Texto

    INTERACCIONES:
        PUBLICO METODO autenticar(usuario: Texto, clave: Texto):
            // Lógica de autenticación

15. Hoja de Ruta Consolidada del Lenguaje MPL

timeline
    title Hoja de Ruta de Desarrollo MPL
    sección Fase 1 : Especificación Formal : Gramática EBNF : Definición de Capas 1, 2 y 3
    sección Fase 2 : Tooling & Parser : Lexer y Parser (ANTLR4) : Transpilador de Referencia (Bootstrap)
    sección Fase 3 : Runtime & StdLib : Bucle de Eventos (Event Loop) : Librería Estándar y I/O : Framework de Pruebas
    sección Fase 4 : Ecosistema MetsuOS : Integración de Entorno de Ejecución : Tooling CLI y Depurador

1. Fase 1: Finalización de la Especificación Formal (Completada): Consolidación de la sintaxis, semántica de capas, runtime y pruebas.
2. Fase 2: Construcción del Front-end del Compilador: Generación de gramáticas ANTLR4 para C1, C2 y C3, y construcción del AST unificado.
3. Fase 3: Implementación del Runtime: Desarrollo del motor de ejecución híbrido con cola de eventos asíncrona y recolector de referencias.
4. Fase 4: Integración en MetsuOS: Despliegue de herramientas de depuración, empaquetador de módulos y entorno de ejecución final.

16. Modelo de Compilación Cruzada y Emisión de Código (Targets)

El compilador de MPL utiliza una arquitectura modular dividida en Front-end (análisis y lowering de capas C3/C2/C1) y Back-end (generación de código destino). Esto permite que una especificación MPL pueda ser compilada hacia múltiples entornos de ejecución sin alterar la lógica de negocio ni la interfaz.

graph TD
    classDef frontend fill:#2b4c7e,stroke:#4a90e2,stroke-width:2px,color:#ffffff;
    classDef ir fill:#7b4b94,stroke:#b873d9,stroke-width:2px,color:#ffffff;
    classDef backend fill:#1e5128,stroke:#4e9f3d,stroke-width:2px,color:#ffffff;

    subgraph Pipeline_Compilacion ["Pipeline de Emisión MPL"]
        Fuente["Código Fuente MPL
 Archivos .mpl (C3, C2, C1)"]:::frontend
        AST["AST Unificado + Tabla de Símbolos
Lowering semántico completo"]:::frontend
        MIR["Metsu Intermediate Representation (MIR)
Representación intermedia optimizada"]:::ir
    end

    subgraph Emision_Targets ["Back-ends de Ejecución (Targets)"]
        TargetNative["Target MetsuOS Native
Bytecode para la VM de MetsuOS"]:::backend
        TargetWeb["Target Web / WASM
WebAssembly + Canvas/DOM Driver"]:::backend
        TargetHost["Target Transpilación
Código fuente en C / C++ / Python"]:::backend
    end

    Fuente --> AST
    AST --> MIR
    MIR --> TargetNative
    MIR --> TargetWeb
    MIR --> TargetHost

16.1. Metsu Intermediate Representation (MIR)

MIR es la representación intermedia de tipo SSA (Static Single Assignment) en la que se reducen todas las construcciones de las tres capas a un grafo de flujo de control linealizado.

• Instrucciones en tres direcciones (3AC): Las llamadas a eventos de Capa 2 y transiciones de Capa 3 quedan aplanadas a instrucciones condicionales y saltos de bloque.
• Optimizaciones del Compiler Pass:
• Dead Code Elimination: Eliminación de vistas o componentes no transitados en Capa 3.
• Inlining de Métodos: Inserción directa de métodos C1 en eventos C2 de alta frecuencia.
• Análisis de Duración de Variables: Minimización del impacto del Garbage Collector/ARC.

16.2. Estrategia de Directivas de Compilación (#COMPILADOR)

MPL permite especificar bloques condicionales o configuraciones para entornos específicos mediante directivas de preprocesamiento e inspección de destino.

#COMPILADOR.TARGET == "METSUOS_NATIVO" ENTONCES:
    #CONFIGURAR_MEMORIA(PAGINACION_ESTATICA)
#FIN_COMPILADOR

PANTALLA VistaConfiguracion:
    COMPONENTE PanelControl:
        OPCION "Reiniciar Motor" CON_ACCION ReiniciarSistema

#COMPILADOR.TARGET == "WEB_WASM" ENTONCES:
    // Sustitución de llamada nativa por puente JavaScript/DOM
    FUNCION ReiniciarSistema():
        HTTP_Solicitar("/api/v1/reset", "POST")
    FIN_FUNCION
#SINO:
    FUNCION ReiniciarSistema():
        Metsus_Core_Reiniciar()
    FIN_FUNCION
#FIN_COMPILADOR

17. Depuración, Trazabilidad e Inspección Dinámica (Reflection)

Para facilitar el diagnóstico en tiempo de desarrollo, MPL incluye herramientas sintácticas para inspeccionar el estado de la aplicación en las tres capas simultáneamente.

sequenceDiagram
    autonumber
    participant Depurador as Depurador MPL
    participant C3 as Monitor UI (Capa 3)
    participant C2 as Monitor Objetos (Capa 2)
    participant C1 as Pila de Ejecución (Capa 1)

    Note over Depurador: Punto de interrupción disparado
    Depurador->>C3: Obtener Pantalla y Componente Activo
    C3-->>Depurador: VistaPrincipal -> PanelControl
    Depurador->>C2: Inspeccionar PROPIEDADES de Objetos
    C2-->>Depurador: GestorRecursos.activo = Verdadero
    Depurador->>C1: Volcar Pila de Llamadas (Stack Trace)
    C1-->>Depurador: IniciarIngesta() [Línea 42]

17.1. Primitivas de Inspección y Reflexión Sintáctica

MPL permite a los programas (en entorno de pruebas o debug) consultar la estructura de sus propios tipos y vistas.

17.2. Sintaxis de Puntos de Interrupción (Breakpoints) Nativos

OBJETO_CONCEPTUAL GestorAuditoria:
    INTERACCIONES:
        METODO registrar_evento(datos: Texto):
            // Punto de interrupción condicional para el depurador de MetsuOS
            #DEPURAR_SI(Longitud(datos) == 0)

            SI Longitud(datos) == 0 ENTONCES:
                LANZAR_ERROR ExcepcionDatosVacios
            FIN_SI

18. Apéndice: Manual de Estilo y Convenciones Sintácticas Canónicas

Para garantizar un código limpio y consistente dentro del ecosistema MetsuOS, se establecen las siguientes reglas de estilo para MPL:

1. Palabras Reservadas de Estructura: Siempre en Mayúsculas Sostenidas (PANTALLA, OBJETO_CONCEPTUAL, FUNCION, SI, FIN_FUNCION).
2. Identificadores de Capa 3 (UI/Vistas): Estilo PascalCase (VistaPrincipal, MenuOpciones).
3. Identificadores de Capa 2 (Objetos/Propiedades):
4. Nombres de Objetos en PascalCase (GestorRecursos).
5. Métodos y Propiedades en snake_case (cargado_exitoso, procesar_entrada()).
6. Identificadores de Capa 1 (Imperativo/Variables):
7. Variables y Funciones en snake_case (i, longitud_total, calcular_hash()).
8. Tipos Primitivos en minúsculas (cadena, entero, booleano).

19. Estado de la Especificación

• ESTADO DE LA ESPECIFICACIÓN METSU PROGRAMMING LANGUAGE (MPL)
• Versión: 1.4.0-draft
• Estado: REVISIÓN DE ARQUITECTURA COMPLETADA
• Aprobado para implementación de prototipo en MetsuOS.

One More Thing

¡Desbloquea el poder de MetsuOS y descubre que la privacidad y la seguridad son la clave para desencadenar tu verdadero potencial en línea!

Contenido registrado en Safe Creative

¡Usa el código de promocional 7ZYM4Z y ahorrate unos eurillos en tu suscripcion de Safe Creative!

MetsuOS Needs You!

Apoyanos en este proyecto difundiendolo en tus redes, o mejor, haznos una donación a la cuenta paypal para poder dedicar más tiempo y recursos a el. No olvides comentarnos que parete te interesa más junto con tu donación.

En este momento, además de mantener los servicios, estoy centrado en crear la siguiente iteración del software que me permite hacer todo esto y creando una biblioteca personal física para poder contrastar contenido.

Sobre el sistema de validez de un contenido en MetsuOS

Empezando a incorporar los niveles de validación de un contenido (también llamada sabiduría o niveles de conocimiento) ⚫🔴 🟡 🟢 🔵⚪ ¿Qué són?

• ⚫① - Dark1 - Conocimiento en Bruto. Modo Cuñao, hablo pero no puedo respaldarlo.
• 🔴② - Rojo2 - Conocimiento Impulsivo, pasional, "lo mio es lo correcto".
• 🟡③ - Yellow3 - Conocimiento Crítico: se comienza a explorar el hecho de que pueda haber otras perspectivas.
• 🟢④ - Green4 - Conocimiento Natural: Surge al comprender la naturaleza de la realidad y del ser humano en una materia.
• 🔵⑤ - Blue5 - Conocimiento Científico: Supone la suma de las fases anteriores aplicando el rigor de lo descubierto por la ciencia hasta ahora, sin caer en la -anticientífica- "opinión científica/opinión de expertos".
• ⚪⑥ - Light6 Conocimiento Consolidado: Se alcanza al integrar todo lo anterior desde una perspectiva empática y asumiendo una verdad probabilística dinámica dependiente del contexto.

Sobre la categorización de los tipos de conocimiento

• Conocimiento Gnoseológico: ⚫① 🔴② 🟡③ 🟢④
• Conocimiento Epistemológico: 🔵⑤
• Conocimiento Metsukeológico: ⚪⑥

La Metsukeología (de Metsuke vision global y logos conocimiento) es la ciencia que estudia el conocimiento como un conjunto potencial de conocimiento del que podemos obtener, procesar o percibir partes concretas dentro de un marco contextual específico, y cuyo contexto general real está muy por encima de lo que somos capaces, como especie, de percibir, procesar e integrar de forma completa (definición en progreso).

La Metsucología (de Metsu aniquilación - en este contexto en forma de colapso - , logos conocimiento) es la ciencia que estudia como extraemos verdades percibidas - colapsadas - como conocimiento desde nuestra perspectiva real (tanto epistemológico como gnoseológico) al tomar una parte específica del conocimiento metsukeológico potencial enmarcado en un contexto concreto, obligando a colapsar el conocimiento potencial en conocimiento específico (definición en progreso).

Mas sobre el contexto

DISCLAIMER: Mi consideración de anticientífico respecto al consenso científico es una hipotesis de trabajo propia, que supone que toda asignación de validez, incluso aquella derivada de la conclusión por acumulación de evidencia NO debe ser supeditada a debate, ni acuerdo, debe ser algo probabilistico sin intervención del ego humano. Podría estar equivocado y, en este punto, es donde se aplicaría entonces ese mismo consenso que ahora considero no valido (incluso dañino)

Existen indicadores para algunas cuestiones adicoinales como los siguientes:

• 🌐 - Contenido Externo sobre cuya validez/validación no tenemos control (usualmente enlaces que salen de #MetsuOS)
• ⚖️ - Analisis
  • ⚖️📚 - Análisis Bibligráfico
  • ⚖️🔬 - Análisis Científico
  • ⚖️🏛️ - Análisis Estructural
  • ⚖️🧠 - Análisis Filosófico
• 📖 - Referencia
  • 📖📚 - Referencia Bibliográfica / Libro
  • 📖🔬- Referencia Científica / Paper
  • 📖🏛️ - Referencia Estructural
  • 📖🧠 - Referencia Filosófica
• 🔍️- Paradigma

Cuando hablamos de un contenido que incluye un texto que hace referencia a otro.

• 🔴②-🌐🟡③ - Nivel del contenido del documento Rojo2, nivel del contenido externo del que habla el documento Yellow3.
• 🔴②-⚖️📚 🔴② - Nivel del contenido del documento Rojo2, en base a análisis bibliográfico nivel Rojo2

También aplicaremos el Sistema de fiabilidad de fuentes y credibilidad de contenidos de la OTAN 🔴②, este sistema incluye una valoración de la fiabilidad de la fuente de A a F (siendo A la de mayor fiabilidad) y una varloración de credibilidad del contenido de 1 a 6 (siendo 1 la mayor credibilidad).

En MetsuOS la agregaremos al final uniendo amos valores como si fuera una coordenada. Por ejemplo: ⚫①-D4 o 🟡③-B2. Esto ayudarña a contextualizar la información sobre la solidez del conocimiento al que se hace referencia en cada momento.

Hay que tener en cuenta que, cuando hay elementos subjetivos o parcialmente subjetivos, el punto de referencia seré yo mismo. Quizá más adelante pueda objetivizar esto más (seria lo deseable), pero en tanto no tenga herramientas que me lo permitan, debo ceñirme al principio de honestidar intelectual, y esperar que mis sesgos dañen lo menos posible la información (en parte este es el nudo gordiano que pretendo resolver, y por ello es dificil resolverlo a priori).

Así de forma resumida, podríamos decir que esta definición es nivel 🔴② (Rojo2 xD) ¿Crees que me dejo algo? Si es así por favor ayudame a mejorarlo contactándome a través de X (Twitter) en mi cuenta, @metsuke 🌐

Consulta la versión completa de la descripcion en ⚫🔴🟡🟢🔵⚪ (🔴②) Un poco más de detalle

• Información IA: Generado asistido por IA (Gemini, Raul Carrillo aka Metsuke). Supervisado por Humano.
• Ultima Modificación: 2026-10-28 12:33:14.877000+00:00
• Versión Documento: 0.2.6