Gramática superficial mínima del lenguaje de computación del Sistema Vectorial SV — v0.1

Especificación de la superficie declarativa del DSL canónico

Autor: Juan Antonio Lloret Egea
ORCID: 0000-0002-6634-3351
ISSN: 2695-6411
Licencia: CC BY-NC-ND 4.0
Fecha: marzo 2026
Estado: Especificación técnica del lenguaje — v0.1
Repositorio: SV-lenguaje-de-computacion

© Juan Antonio Lloret Egea, marzo 2026. Todos los derechos reservados conforme a CC BY-NC-ND 4.0.

Resumen

Este documento fija la gramática superficial mínima del lenguaje de computación del Sistema Vectorial SV en su versión 0.1. La gramática es la capa que traduce la intención del programador humano a la representación intermedia canónica (IR v0.2) ya publicada.

La gramática es declarativa, nominal y sin azúcar innecesario. Toda construcción escrita en esta superficie baja unívocamente a un objeto o una operación de la IR v0.2, sin pérdida semántica y sin ambigüedad. La gramática no inventa semántica nueva: es una superficie humana austera de la IR, no una teoría paralela.

El principio rector es que escribir un programa SV correcto sea natural y que escribir uno incorrecto sea imposible o doloroso.

1. Subordinación doctrinal

Este documento es doctrina derivada del corpus publicado del Sistema Vectorial SV. La autoridad normativa suprema reside en los Fundamentos algebraico-semánticos del Sistema Vectorial SV (Release 3).

La gramática se subordina a dos documentos ya publicados en el repositorio del lenguaje:

La gramática no puede contradecir ninguno de estos documentos. En caso de discrepancia, prevalece la IR; si la discrepancia afecta a un invariante constitutivo, prevalecen los Fundamentos.

Cadena de compilación

Archivo .svp → Parser/lowering de referencia → IR canónica v0.2 (JSON canónico) → Backend Rust + Backend Python (referencia) → WASM (futuro)

2. Decisiones de diseño

2.1. Gramática declarativa y nominal

Toda declaración tiene nombre explícito, tipo explícito y campos obligatorios. No hay inferencia amplia de tipos, no hay infijo, no hay sobrecarga, no hay macros. Lo que el usuario escribe, lo declara; lo que no declara, no existe en su programa.

2.2. Resultados obtenidos por operadores, no por literales

La gramática v0.1 no permite construir a mano objetos de resultado (EvalResult, GateResult, ResolutionRecord, QueryResult, SupervisionResult). Estos se obtienen exclusivamente por invocación de operadores (evaluate, gate, resolve, query, supervise). Esta decisión impide falsificaciones sintácticas de objetos de nivel N2/N3 de la IR.

2.3. Exclusión de max y min en la superficie v0.1

El lowering de max/min como azúcar sobre gate con tabla trivial ya está cerrado en la IR v0.2 y reconocido en la Frontera normativa (Bloque A, punto A.9). Sin embargo, la superficie v0.1 no los expone. La razón es doble: no añaden capacidad expresiva (todo lo que max puede hacer, gate con la tabla adecuada lo hace) y su presencia en v0 induciría falsa apariencia de primitividad. max/min entrarán como azúcar derivado en una versión posterior, con lowering visible al usuario.

2.4. Comp como constructor austero

Comp es constructor organizativo de Grado C. Su axiomática fuerte sigue abierta. La gramática permite invocarlo, pero no cierra más semántica de la que el corpus ha cerrado. compose(...) recibe un grafo, relaciones semánticas previas y patrones compositivos declarados explícitamente.

2.5. Zona prohibida sintácticamente inalcanzable

La gramática no ofrece construcciones para escribir lo que la Frontera normativa (Bloque D) prohíbe. La zona prohibida no es una advertencia: es una imposibilidad sintáctica.

2.6. Invariantes constitutivos garantizados por el tipo, no por el usuario

Los invariantes constitutivos 8 (inmutabilidad del polígono/frame) y 9 (trayectoria append-only) son propiedades del tipo que el compilador/verificador garantiza. No aparecen como campos en la gramática. El usuario no escribe immutable: True ni append_only: True porque no existe la alternativa.

2.7. Derivación automática de n desde b

La célula se declara con b y el compilador deriva n = b². La superficie no permite escribir n directamente, lo que hace imposible la incoherencia n ≠ b². La precondición b ≥ 3 se verifica en lowering (error E si se viola).

3. Alcance

3.1. Lo que la gramática v0.1 cubre

3.2. Lo que la gramática v0.1 no cubre

No se incluyen en esta versión: azúcar para max/min, notación infija para compuertas, generación implícita de Frame, atajos para CoverageReport o ArchitectureView, authoring superficial completo de ConflictOperator, análisis discreto como sintaxis de primera clase, ni ninguna construcción del Bloque C de la Frontera normativa.

4. Nomenclatura

La gramática adopta íntegramente la tabla de nomenclatura desambiguada de la Frontera normativa v0 (§3). Las palabras clave de la gramática coinciden con los nombres de esa tabla. No se permite ningún alias que reintroduzca colisiones.

5. Gramática formal

5.0. Estructura general y primitivas

program                ::= { declaration | command } ;

declaration            ::= codomain_decl
                         | output_semantics_decl
                         | cellspec_decl
                         | coupledspec_decl
                         | connector_decl
                         | table_decl
                         | capture_decl
                         | admissibility_decl
                         | ternarizer_decl
                         | resspec_decl
                         | cellstate_decl
                         | coupledstate_decl
                         | graph_decl
                         | semantic_relation_decl
                         | pattern_decl
                         | horizon_decl
                         | frame_decl
                         | transitiondata_decl
                         | trajectory_decl
                         | domain_decl
                         | agent_decl
                         | queryspec_decl ;

command                ::= eval_cmd
                         | gate_cmd
                         | resolve_cmd
                         | query_cmd
                         | supervise_cmd
                         | compose_cmd
                         | projection_cmd ;

tri_literal            ::= "Zero" | "One" | "U" ;
identifier             ::= letter { letter | digit | "_" } ;
nat                    ::= digit { digit } ;
string_literal         ::= '"' { character } '"' ;

list<T>                ::= "[" [ T { "," T } ] "]" ;
pair<A,B>              ::= "(" A "," B ")" ;
tuple_literal          ::= "(" identifier { "," identifier } ")" ;

5.1. Enumeraciones cerradas

role_literal               ::= "Base" | "Supervisor" | "Composite" ;

regime_literal             ::= "Simple" | "General" ;

semantic_relation_kind     ::= "DeclaredRelation" ;

pattern_kind               ::= "DeclaredPattern" ;

query_type_literal         ::= "PointEvaluation"
                             | "TrajectoryState"
                             | "FrameComparison"
                             | "CoverageState"
                             | "PendingU"
                             | "GlobalCriticality" ;

scope_literal              ::= "Cell"
                             | "Pair"
                             | "Architecture"
                             | "Trajectory" ;

supervisable_literal       ::= "CellTarget" "(" identifier ")"
                             | "ComposedTarget" "(" identifier ")"
                             | "SystemTarget" "(" identifier ")" ;

Nota sobre semantic_relation_kind y pattern_kind: en v0.1 se admite únicamente la variante DeclaredRelation y DeclaredPattern. No se cierra un catálogo fuerte de clases de relación o patrón porque el corpus doctrinal no lo ha congelado como enumeración cerrada. El mecanismo de extensión quedará definido en versiones posteriores.

5.2. Nivel 0 — Definición

codomain_decl              ::= "codomain" identifier "="
                               "{" identifier { "," identifier } "}" ";" ;

output_semantics_decl      ::= "output_semantics" identifier "{"
                               { identifier "->" string_literal ";" }
                               "}" ;

cellspec_decl              ::= "cellspec" identifier "{"
                               "b" ":" nat ";"
                               "codomain" ":" identifier ";"
                               "semantics" ":" identifier ";"
                               "role" ":" role_literal ";"
                               "}" ;

coupledspec_decl           ::= "coupledspec" identifier "{"
                               "cell" ":" identifier ";"
                               "bridges" ":" list<nat> ";"
                               "}" ;

connector_decl             ::= "connector" identifier "{"
                               "source_codomain" ":" identifier ";"
                               "target_position" ":" nat ";"
                               "mapping" ":" "{"
                                   { identifier "->" tri_literal ";" }
                               "}" ";"
                               "}" ;

table_decl                 ::= "admissibility_table" identifier "{"
                               "input_codomains" ":" list<identifier> ";"
                               "output_codomain" ":" identifier ";"
                               "table" ":" "{"
                                   { tuple_literal "->" identifier ";" }
                               "}" ";"
                               "}" ;

capture_decl               ::= "capture_spec" identifier "{"
                               "parameter_id" ":" nat ";"
                               "observation_domain" ":" identifier ";"
                               "observation_space" ":" identifier ";"
                               "failure_symbol" ":" "Bottom" ";"
                               "mapping" ":" identifier ";"
                               "}" ;

admissibility_decl         ::= "admissibility_spec" identifier "{"
                               "parameter_id" ":" nat ";"
                               "states" ":" "{Ok, Degraded, Failed, U}" ";"
                               "rule" ":" identifier ";"
                               "}" ;

ternarizer_decl            ::= "ternarizer" identifier "{"
                               "observation_space" ":" identifier ";"
                               "partition_zero" ":" identifier ";"
                               "partition_one" ":" identifier ";"
                               "partition_u" ":" identifier ";"
                               "mapping" ":" identifier ";"
                               "}" ;

resspec_decl               ::= "res_spec" identifier "{"
                               "context" ":" identifier ";"
                               "mechanism" ":" identifier ";"
                               "mapping" ":" identifier ";"
                               "}" ;

Precondiciones verificadas en lowering para cellspec:

• b ≥ 3 (error si se viola).
• n se deriva automáticamente como b². El usuario no escribe n.

5.3. Nivel 1 — Estado

cellstate_decl             ::= "cellstate" identifier "{"
                               "spec" ":" identifier ";"
                               "vector" ":" list<tri_literal> ";"
                               "}" ;

coupledstate_decl          ::= "coupledstate" identifier "{"
                               "spec" ":" identifier ";"
                               "base_vector" ":" list<tri_literal> ";"
                               "updated_vector" ":" list<tri_literal> ";"
                               "}" ;

edge_literal               ::= "edge" "("
                               "source" ":" identifier ","
                               "target" ":" identifier ","
                               "position" ":" nat ","
                               "connector" ":" identifier
                               ")" ;

graph_decl                 ::= "graph" identifier "{"
                               "nodes" ":" list<identifier> ";"
                               "edges" ":" list<edge_literal> ";"
                               "relation" ":" identifier ";"
                               "regime" ":" regime_literal ";"
                               "}" ;

Precondiciones verificadas en lowering para cellstate:

• La longitud del vector debe ser igual a b² del CellSpec referenciado por spec.
• Cada elemento del vector debe ser un tri_literal válido.

Precondiciones verificadas en lowering para graph:

• El campo relation debe apuntar a un identificador de SemanticRelation declarado. Sin relación semántica previa, no hay composición (invariante constitutivo 6).
• El grafo no puede contener ciclos (Bloque D.5 de la Frontera).

5.4. Composición — Relaciones y patrones

semantic_relation_decl     ::= "semantic_relation" identifier "{"
                               "kind" ":" semantic_relation_kind ";"
                               [ "table" ":" identifier ";" ]
                               [ "constraints" ":" list<identifier> ";" ]
                               "}" ;

pattern_decl               ::= "pattern" identifier "{"
                               "kind" ":" pattern_kind ";"
                               [ "arity" ":" nat ";" ]
                               [ "constraints" ":" list<identifier> ";" ]
                               "}" ;

Estas declaraciones son nominales y austeras. No cierran más semántica que la necesaria para alimentar compose(...). La teoría fuerte de relaciones y patrones queda abierta para versiones posteriores, conforme al Grado C de Comp en el corpus.

5.5. Nivel 3 — Evolución

horizon_decl               ::= "horizon" identifier "{"
                               "architecture" ":" identifier ";"
                               "events" ":" list<identifier> ";"
                               "}" ;

frame_decl                 ::= "frame" identifier "{"
                               "index" ":" nat ";"
                               "architecture" ":" identifier ";"
                               "cell_states" ":" list<identifier> ";"
                               "eval_results" ":" list<identifier> ";"
                               "gate_results" ":" list<identifier> ";"
                               "supervision" ":" list<identifier> ";"
                               "criticalities" ":" list<identifier> ";"
                               "}" ;

event_state_literal        ::= "(" identifier "," tri_literal ")" ;

transitiondata_decl        ::= "transition_data" identifier "{"
                               "horizon_ref" ":" identifier ";"
                               "events" ":" list<event_state_literal> ";"
                               "induced_parameters" ":" list<induced_param_literal> ";"
                               [ "metadata" ":" list<identifier> ";" ]
                               "}" ;

induced_param_literal      ::= "(" identifier "," nat "," tri_literal ")" ;

trajectory_entry           ::= "entry" "("
                               "frame" ":" identifier
                               [ "," "transition" ":" identifier ]
                               ")" ;

trajectory_decl            ::= "trajectory" identifier "{"
                               "entries" ":" list<trajectory_entry> ";"
                               "}" ;

Invariantes constitutivos garantizados por el tipo (no escritos por el usuario):

• Frame: inmutable una vez construido (invariante 8). El compilador rechaza toda operación que intente modificar un frame existente.
• Trajectory: append-only (invariante 9). El compilador solo permite añadir entradas al final; no permite reescritura, eliminación ni reordenación.
• TrajectoryEntry: respeta las 4 invariantes de alternancia definidas en la IR v0.2.

5.6. Nivel 4 — Uso

domain_decl                ::= "domain" identifier "{"
                               "parameters" ":" list<identifier> ";"
                               "interface" ":" identifier ";"
                               "horizon" ":" identifier ";"
                               "capture_specs" ":" list<identifier> ";"
                               "admissibility_specs" ":" list<identifier> ";"
                               "ternarizers" ":" list<identifier> ";"
                               "exogeneity_mask" ":" identifier ";"
                               "silent_u" ":" identifier ";"
                               "transduction_policy" ":" identifier ";"
                               "u_policy" ":" identifier ";"
                               "closure_criterion" ":" identifier ";"
                               "}" ;

agent_decl                 ::= "agent" identifier "{"
                               "architecture" ":" identifier ";"
                               "domain" ":" identifier ";"
                               "query_engine" ":" identifier ";"
                               "}" ;

queryspec_decl             ::= "query_spec" identifier "{"
                               "query_type" ":" query_type_literal ";"
                               "scope" ":" scope_literal ";"
                               "restrictions" ":" list<identifier> ";"
                               "}" ;

5.7. Operadores

eval_cmd                   ::= "let" identifier "=" "evaluate" "(" identifier ")" ";" ;

gate_cmd                   ::= "let" identifier "=" "gate" "("
                               list<identifier> "," "using" ":" identifier
                               ")" ";" ;

resolve_cmd                ::= "let" identifier "=" "resolve" "("
                               "U" ","
                               "with" ":" identifier ","
                               "context" ":" identifier ","
                               "mechanism" ":" identifier
                               ")" ";" ;

query_context_literal      ::= "PointEval" "(" identifier ")"
                             | "TrajectoryView" "(" identifier ")"
                             | "FrameComparison" "(" identifier "," identifier ")"
                             | "ArchitectureView" "(" identifier "," list<identifier> ","
                                                       list<identifier> "," list<identifier> ")"
                             | "CoverageReport" "(" identifier "," identifier ","
                                                     identifier ")" ;

query_cmd                  ::= "let" identifier "=" "query" "("
                               identifier ","
                               "by" ":" identifier ","
                               "in" ":" query_context_literal
                               ")" ";" ;

supervise_cmd              ::= "let" identifier "=" "supervise" "("
                               identifier ","
                               "target" ":" supervisable_literal
                               ")" ";" ;

compose_cmd                ::= "let" identifier "=" "compose" "("
                               identifier ","
                               "relations" ":" list<identifier> ","
                               "patterns" ":" list<identifier>
                               ")" ";" ;

projection_cmd             ::= "let" identifier "=" identifier "." identifier ";" ;

Restricciones semánticas verificadas en lowering:

• evaluate: el argumento debe ser un identificador de CellState o CoupledState. El operador ejecuta internamente la factorización evaluate + classify cerrada por la IR v0.2. El EvalResult resultante expone conteos (N₀, N₁, Nᵤ), umbral (T(n)), clasificación y source_state.
• gate: todos los identificadores de la lista deben ser EvalResult. No se aceptan otros tipos. La tabla referida por using debe ser un AdmissibilityTable declarado.
• resolve: devuelve un ResolutionRecord. El valor ternario resuelto se obtiene por proyección explícita: let v = RR1.resolved_to;. No devuelve un par implícito ni un tipo compuesto anónimo.
• query: el constructor de QueryContext debe ser explícito (una de las cinco variantes). No se acepta un identificador opaco como contexto.
• supervise: el primer argumento debe ser un EvalResult válido y su source_state.spec.role debe ser Supervisor. El target debe ser un constructor explícito de Supervisable (CellTarget, ComposedTarget o SystemTarget). No se aceptan identificadores opacos.
• compose: las listas de relations y patterns deben contener identificadores de SemanticRelation y Pattern declarados previamente. No se acepta compose sin relaciones ni patrones.
• projection: permite acceder a campos de objetos de resultado. Es la única forma de extraer valores internos (como ResolutionRecord.resolved_to).

6. Lowering unívoco

Cada forma superficial baja a exactamente un objeto o una operación de la IR v0.2. No hay ambigüedad.

6.1. Declaraciones → Objetos IR

6.2. Operadores → Resultados IR

6.3. Lowering interno de evaluate

El operador evaluate ejecuta internamente la factorización evaluate + classify cerrada por la IR v0.2:

1. evaluate: lectura de conteos N₀(v), N₁(v), Nᵤ(v) sobre el vector del estado.
2. classify: aplicación de T(n) = ⌊7n/9⌋ con precedencia desfavorable (si N₁ ≥ T(n) → NO_APTO; si N₀ ≥ T(n) → APTO; otro caso → INDETERMINADO).
3. Γ: cálculo de criticidad Γ(v) = Nᵤ(v) − min(δ₀(v), δ₁(v)).

El EvalResult resultante contiene: conteos, umbral, clasificación, criticidad y source_state.

6.4. Lowering interno de max/min (reservado para versiones futuras)

Cuando max/min se incorporen como azúcar en una versión posterior, su lowering será:

• max(E1, E2) → gate([E1, E2], using: T_max) donde T_max es la tabla trivial de dominancia homogénea con orden documentado.
• min(E1, E2) → gate([E1, E2], using: T_min) donde T_min es la tabla trivial dual.

Este lowering ya está cerrado en la IR v0.2. La superficie v0.1 simplemente no lo expone aún.

7. Prohibiciones sintácticas

La gramática prohíbe de raíz las siguientes construcciones. No son advertencias: son imposibilidades del parser.

7.1. Prohibiciones derivadas del Bloque D de la Frontera normativa

7.2. Prohibiciones adicionales de la superficie v0.1

8. Ejemplo mínimo de superficie

-- Declaración de codominio y semántica
codomain K3 = { APTO, NO_APTO, INDETERMINADO };

output_semantics Klin {
  APTO -> "Clasificación fuerte favorable";
  NO_APTO -> "Clasificación fuerte desfavorable";
  INDETERMINADO -> "Sin clasificación fuerte";
}

-- Declaración de célula (b=3, n derivado como 9)
cellspec C1 {
  b: 3;
  codomain: K3;
  semantics: Klin;
  role: Base;
}

-- Célula acoplable con posición puente en 3
coupledspec CC1 {
  cell: C1;
  bridges: [3];
}

-- Conector de transmisión
connector Phi1 {
  source_codomain: K3;
  target_position: 3;
  mapping: {
    APTO -> Zero;
    NO_APTO -> One;
    INDETERMINADO -> U;
  }
}

-- Estado de la célula
cellstate S1 {
  spec: C1;
  vector: [Zero, One, U, Zero, Zero, One, U, Zero, One];
}

-- Evaluación (factoriza internamente evaluate + classify + Γ)
let E1 = evaluate(S1);

-- Segunda célula y evaluación
cellspec C2 {
  b: 3;
  codomain: K3;
  semantics: Klin;
  role: Base;
}

cellstate S2 {
  spec: C2;
  vector: [Zero, Zero, Zero, One, Zero, Zero, Zero, One, Zero];
}

let E2 = evaluate(S2);

-- Compuerta con tabla de admisibilidad
admissibility_table T1 {
  input_codomains: [K3, K3];
  output_codomain: K3;
  table: {
    (APTO, APTO) -> APTO;
    (APTO, NO_APTO) -> NO_APTO;
    (APTO, INDETERMINADO) -> INDETERMINADO;
    (NO_APTO, APTO) -> NO_APTO;
    (NO_APTO, NO_APTO) -> NO_APTO;
    (NO_APTO, INDETERMINADO) -> NO_APTO;
    (INDETERMINADO, APTO) -> INDETERMINADO;
    (INDETERMINADO, NO_APTO) -> NO_APTO;
    (INDETERMINADO, INDETERMINADO) -> INDETERMINADO;
  }
}

let G1 = gate([E1, E2], using: T1);

-- Supervisión meta
cellspec Meta {
  b: 3;
  codomain: K3;
  semantics: Klin;
  role: Supervisor;
}

cellstate SMeta {
  spec: Meta;
  vector: [Zero, Zero, Zero, Zero, Zero, Zero, Zero, Zero, Zero];
}

let EMeta = evaluate(SMeta);
let SV1 = supervise(EMeta, target: ComposedTarget(G1));

-- Resolución de U con trazabilidad
res_spec RS1 {
  context: ContextoClinico;
  mechanism: RevisionExperto;
  mapping: MapeoResolucion;
}

let RR1 = resolve(U, with: RS1, context: Ctx1, mechanism: M1);
let valor_resuelto = RR1.resolved_to;

9. Adversarial de cierre

9.1. ¿La gramática preserva la nomenclatura desambiguada?

Sí. Todas las palabras clave coinciden con la tabla de la Frontera normativa v0 (§3). No se introduce ningún nombre nuevo que colisione con los nombres del corpus. Los nombres de operadores (evaluate, gate, resolve, query, supervise, compose) son verbos que no colisionan con los sustantivos de la nomenclatura.

9.2. ¿La zona prohibida es sintácticamente inalcanzable?

Sí. No existe producción gramatical para: coerción implícita de U, composición sin relación, literales de resultado, mutación de frame o trayectoria, max/min como operadores, ni query sin contexto explícito.

9.3. ¿El lowering es unívoco?

Sí. Cada forma superficial baja a exactamente un objeto o una operación IR. Los tres puntos que presentaban ambigüedad potencial han sido cerrados: resolve devuelve ResolutionRecord (con proyección explícita para el valor), gate solo acepta EvalResult, y supervise exige constructor explícito de Supervisable.

9.4. ¿La gramática cierra más de lo debido?

No. Comp se mantiene como constructor austero con SemanticRelation y Pattern nominales. semantic_relation_kind y pattern_kind tienen una sola variante cada uno (DeclaredRelation, DeclaredPattern), lo que refleja que el corpus no ha congelado un catálogo fuerte. supervise entra en v0.1 con las tres variantes de Supervisable que la IR define, sin añadir ninguna.

9.5. ¿Faltan objetos necesarios?

No. TransitionData tiene su propia declaración. SemanticRelation y Pattern son declarables. Todas las enumeraciones tienen producción EBNF explícita. CellSpec se declara solo con b.

9.6. ¿Los 12 invariantes constitutivos se preservan?

10. Relación con los demás documentos del repositorio

Referencias

[R1] Juan Antonio Lloret Egea. Fundamentos algebraico-semánticos del Sistema Vectorial SV. v1.0.0, Release 3. ITVIA, 2026. https://www.itvia.online/pub/fundamentos-algebraico-semanticos-del-sistema-vectorial-sv/release/3

[R2] Juan Antonio Lloret Egea. Frontera normativa del lenguaje de computación del Sistema Vectorial SV — v0. Marzo 2026. https://github.com/juantoniolloretegea/SV-lenguaje-de-computacion/blob/main/FRONTERA_NORMATIVA_LENGUAJE_SV_v0.md

[R3] Juan Antonio Lloret Egea. IR canónica y sistema de bienformación del lenguaje SV — v0.2. Marzo 2026. https://github.com/juantoniolloretegea/SV-lenguaje-de-computacion/blob/main/IR_CANONICA_BIENFORMACION_SV_v0_2.md

[R4] Juan Antonio Lloret Egea. Álgebra de composición intercelular del marco SV — I. Transmisión en serie por parámetro puente. v1, Release 4. ITVIA, 2026.

[R5] Juan Antonio Lloret Egea. Álgebra de composición intercelular del marco SV — II. Gramática general de composición. v1.0, Release 1. ITVIA, 2026.

[R6] Juan Antonio Lloret Egea. Álgebra de composición intercelular del marco SV — III. Horizonte de sucesos y reevaluación discreta. v1, Release 1. ITVIA, 2026.

[R7] Juan Antonio Lloret Egea. Álgebra de composición intercelular del marco SV — IV. Transducción al alfabeto ternario e interfaz paramétrica del sistema. v1, Release 1. ITVIA, 2026.

[R8] Juan Antonio Lloret Egea. Álgebra de composición intercelular del marco SV — V. Invariantes, agentes especializados y operador de consulta del sistema. v2, Release 2. ITVIA, 2026.

[R9] Juan Antonio Lloret Egea. Álgebra de composición intercelular del marco SV — VI. Análisis discreto, representaciones y herramientas de secuencias del sistema. v1, Release 1. ITVIA, 2026.

Especificación técnica del lenguaje de computación del Sistema Vectorial SV. ISSN 2695-6411.
Juan Antonio Lloret Egea | ORCID 0000-0002-6634-3351 | CC BY-NC-ND 4.0