1 Synesis: Ideias

Ideias: Propostas de especificação de Extensões da Linguagem

1.1 Introdução às Extensões

Esta especificação detalha os novos recursos planejados para a versão 1.2 da linguagem Synesis. O foco desta atualização é evoluir a linguagem de um sistema de anotação linear para um motor de inferência qualitativa e gestão de conhecimento (Zettelkasten), além de introduzir suporte nativo para loci canônicos (textos sagrados).

1.2 Configuração de Artefatos de Saída (RENDER)

O comando RENDER permite declarar explicitamente, dentro do arquivo de projeto, quais formatos de arquivo devem ser gerados e onde devem ser salvos. Isso garante a reprodutibilidade da compilação sem depender de parâmetros de linha de comando.

1.2.1 Sintaxe

RENDER AS [JSON | CSV | EXCEL] INTO "path/to/filename"

1.2.1.1 Semântica

  • RENDER: Verbo de comando que inicia a definição de um alvo de compilação. Indica a criação de uma representação estruturada (artefato) a partir dos dados interpretados.

  • AS: Cláusula que especifica o formato de serialização.

  • JSON: Gera a árvore de sintaxe abstrata completa com metadados de rastreabilidade.

  • CSV: Gera tabelas relacionais planas (separadas por tipo de bloco).

  • EXCEL: Gera um arquivo .xlsx com abas correspondentes às tabelas CSV.

  • INTO: Cláusula que define o caminho de destino.

  • Deve ser uma string entre aspas duplas.

  • Recomenda-se o uso de caminhos relativos à raiz do projeto para garantir portabilidade entre diferentes máquinas.

  • Se o diretório de destino não existir, o compilador tentará criá-lo.

1.2.1.2 Exemplo no Contexto (.synp)

PROJECT "Estudo Fenomenológico 2026"

TEMPLATE "templates/research_v1.synt"
INCLUDE BIBLIOGRAPHY "data/references.bib"
INCLUDE ANNOTATIONS "data/interviews/*.syn"
INCLUDE ONTOLOGY "ontology/main.syno"

# Configuração Declarativa de Saída
# Gera múltiplos formatos simultaneamente em diretórios organizados

RENDER AS JSON  INTO "dist/full_data.json"
RENDER AS EXCEL INTO "reports/human_readable/matrix.xlsx"
RENDER AS CSV   INTO "reports/raw_data/export.csv"

END

1.2.1.3 Regras de Validação

  1. Multiplicidade: É permitido declarar múltiplos comandos RENDER no mesmo projeto. O compilador processará todos sequencialmente.
  2. Permissão de Escrita: O compilador deve ter permissão de escrita no diretório alvo. Se o arquivo de destino estiver bloqueado (ex: aberto no Excel), a compilação falhará com erro de E/S.
  3. Caminhos Absolutos: O uso de caminhos absolutos (ex: C:/Users/...) emitirá um Warning, pois quebra a portabilidade do projeto.

1.3 Análise Semântica Avançada

O compilador passa a atuar como assistente metodológico, não apenas validador sintático.

1.3.1 Detecção de Redundância Ontológica (Fuzzy Matching)

O compilador analisará a ontologia em busca de conceitos com grafia similar (Lexical Similarity), prevenindo a fragmentação do grafo de conhecimento.

  • Algoritmo: Distância de Levenshtein / Jaro-Winkler.
  • Comportamento: Warning (Aviso) durante a compilação.
  • Exemplo de Detecção: InteracaoSocial vs Interacao_Social.

1.3.2 Validação de Ciclos Hierárquicos

Impede a criação de loops lógicos nas definições taxonômicas. * Regra: Um conceito não pode ser ancestral de si mesmo. * Erro Fatal: A compilação é abortada se um ciclo for detectado (ex: A > B > C > A).

1.3.3 Eliminação de Código Morto (Ghost Concepts)

Identifica conceitos definidos na ontologia que nunca foram aplicados em nenhum ITEM ou ZETTEL. * Comportamento: Warning (Relatório de limpeza de Codebook).

1.4 Novos Comandos Estruturais

1.4.1 TAXONOMY (Hierarquia Rígida)

Substitui o uso solto de TOPIC para definições estritas de relacionamento “é-um” (is-a). Permite herança de propriedades.

Sintaxe:

TAXONOMY
    Emoções
        > Negativas
            > Raiva
            > Medo
        > Positivas
            > Alegria
END

1.4.2 CONSTRAINT (Regras de Negócio)

Define invariantes lógicas para garantir a consistência metodológica das anotações.

Sintaxe:

CONSTRAINT
    # Exclusão mútua: Um item não pode ter ambos os códigos simultaneamente
    FORBID Code "Sentimento: Positivo" WITH Code "Risco: Crítico"

    # Dependência lógica: O código B exige a presença do código A
    REQUIRE Code "Solução" IF Code "Problema" PRESENT
END

1.4.3 CROSSREF (Rede de Citações)

Formaliza as relações retóricas entre fontes bibliográficas (Source-to-Source), independente de anotações internas.

Sintaxe:

CROSSREF
    @smith2019 -> REFUTES -> @doe2018
    @jones2020 -> EXTENDS -> @smith2019
END

1.5 Gestão de Conhecimento (Zettelkasten)

Introduz a capacidade de criar “Notas Permanentes” que sintetizam conhecimento independente de uma fonte bibliográfica específica.

1.5.1 4.1 Bloco ZETTEL

Entidade de nível superior, irmã de SOURCE e ONTOLOGY. Não requer @bibref.

Sintaxe:

# Sintaxe: ZETTEL [ID_UNICO]
ZETTEL 2026011401
    title: "O Princípio da Atomicidade"
    body: "Uma DSL deve forçar a quebra de conceitos..."
    
    # Conexões explícitas (Rizoma)
    links: 2026011205, 2025123001
    
    # Metadados
    tags: DSL Design
    origin: @turing1936
END

1.5.2 Campos Exclusivos (ZETTEL FIELDS)

No arquivo de template .synt, novos tipos de campos são suportados:

  • LINK (Type REFERENCE): Cria arestas bidirecionais entre nós ZETTEL.
  • ORIGIN (Type REFERENCE): Cria aresta de citação para um SOURCE.

1.6 Anotação Canônica (Bíblica/Exegética)

Sistema de endereçamento especializado para textos que utilizam o padrão Locus (Livro, Capítulo, Versículo) em vez de referência bibliográfica autor-data.

1.6.1 Bloco BIBLE

Substitui o bloco SOURCE para textos sagrados. Utiliza o padrão USX para identificação de livros.

Sintaxe:

# Sintaxe: BIBLE [USX_CODE] [CAP:VERSO] [(VERSAO)]
BIBLE ROM 8:28-30 (ARA)
    
    # Título da perícope (String com aspas obrigatórias para suportar pontuação)
    pericope: "A eficácia da vocação: O propósito eterno."

    ITEM
        quote: "Sabemos que todas as coisas cooperam..."
        code: Providência
    END
END

1.6.2 Regras de Endereçamento (Parsing)

O parser aplica regras estritas para evitar ambiguidade:

  1. USX Code: Exatamente 3 letras maiúsculas (ex: MAT, GEN, PSA).
  2. Separadores: Uso obrigatório de : para separar capítulo/verso e - para intervalos.
  3. Perícope: Deve ser delimitada por aspas duplas "" ou triplas """ para permitir caracteres especiais, vírgulas e quebras de linha sem quebrar o parser.

1.6.3 Exemplo de Template para Canon

TEMPLATE biblical_exegesis

BIBLE FIELDS
    OPTIONAL pericope
END

ITEM FIELDS
    REQUIRED quote
    REQUIRED code
    OPTIONAL original_term  # Ex: Grego/Hebraico
END

1.6.3.1 Apêndice A: Notas de Implementação (Lark Grammar)

Snippet da gramática para suportar o cabeçalho BIBLE:

// Definição do Bloco Canon
canon_block: "BIBLE" usx_code bible_ref version? block_body "END"

// Códigos USX (3 letras maiúsculas estritas)
usx_code: UCASE_LETTER UCASE_LETTER UCASE_LETTER 

// Referências suportadas: 8, 8:28, 8:28-30, 8:28-9:1
bible_ref: chapter
         | chapter ":" verse
         | chapter ":" verse "-" verse
         | chapter ":" verse "-" chapter ":" verse

chapter: INT
verse: INT | "END"
version: "(" UCASE_LETTER+ ")" | "@" LCASE_LETTER+ DIGIT+

1.7 Visualização Imediata

O output JSON é útil para processamento, mas humanos precisam ver o grafo.

Ideia: Criar um comando synesis serve que sobe um servidor local simples mostrando o grafo de conexões (usando D3.js ou Cytoscape) gerado a partir do JSON exportado.

1.8 Integração com Data Science

O suporte a exportação CSV/Excel é bom, mas uma integração direta com Pandas seria matadora.

Exemplo: Uma biblioteca Python import synesis que permite carregar o projeto diretamente em um DataFrame sem passar pelo terminal, facilitando o uso em Jupyter Notebooks.

1.9 Possível Workflow

Correto. A premissa é exata: o Core do Compilador (Parser + Análise Semântica) atua como a única fonte da verdade. Tanto a exportação de arquivos, quanto a biblioteca Python (synesis.load), quanto o servidor LSP consomem a mesma Árvore Sintática Abstrata (AST) e a mesma Tabela de Símbolos.

Aqui está o workflow objetivo para essa implementação, focando na arquitetura “Compiler as a Library” (Compilador como Biblioteca):

1.9.1 Passo 1: Desacoplamento de I/O (Entrada/Saída)

O primeiro passo é garantir que o compilador não “saiba” que está escrevendo arquivos.

  • Ação: Separar as funções de exportação. Hoje, provável que exista uma função export_csv(ast, filepath).
  • Refatoração: Dividir em duas:
  1. transform_to_tabular_data(ast): Recebe a AST e retorna listas de dicionários/objetos em memória (sem tocar no disco).
  2. write_csv(data, filepath): Recebe os dados e apenas grava o arquivo.

1.9.2 Passo 2: Exposição da API Pública do Core

O módulo principal do Synesis deve expor o acesso programático à compilação.

  • Ação: Tornar a função de orquestração acessível externamente.
  • Definição: Criar/Ajustar um método (ex: Synesis.compile_source()) que aceita uma string ou caminho de arquivo e retorna o objeto Project (o resultado da validação semântica contendo todas as estruturas ligadas).

1.9.3 Passo 3: Criação do Adaptador Python (Data Science)

Este é o consumidor que você sugeriu (synesis.load).

  • Dependência: Definir Pandas como dependência opcional.
  • Fluxo:
  1. Chama a API do Passo 2 para obter o objeto Project em memória.
  2. Chama a função de transformação do Passo 1 (transform_to_tabular_data).
  3. Instancia DataFrames do Pandas usando esses dados.
  4. Aplica tipagem (converte strings para datetime objects, categorias, etc.) baseada nos tipos da AST.

1.9.4 Passo 4: Adaptação para o LSP (Editor Intelligence)

O LSP consome a mesma AST, mas precisa de dados diferentes (localização em vez de valor).

  • Ação: Garantir que os nós da AST (Item, Source, Field) preservem metadados de origem (linha, coluna, arquivo).
  • Fluxo:
  1. O LSP envia o texto do arquivo atual (mesmo incompleto).
  2. O Core tenta fazer o parse (com tolerância a erros).
  3. O Core retorna a Tabela de Símbolos (lista de ontologias e definições disponíveis).
  4. O LSP usa essa tabela para fornecer Autocomplete e Go to Definition.

1.9.5 Passo 5: CLI como “Cliente Magro”

O comando synesis compile no terminal passa a ser apenas mais um cliente, igual ao Python ou ao LSP.

  • Ação: O CLI apenas coleta argumentos, chama a API do Passo 2 e usa as funções de escrita de arquivo (write_csv, write_json) definidas no Passo 1.

1.9.6 Resumo do Fluxo de Dados

  1. Entrada: Arquivos .syn / .synt
  2. Motor Central (Synesis Core): Gera AST + Validação Semântica.
  3. Distribuição:
  • via CLI -> Escreve no Disco (JSON/CSV).
  • via Python SDK -> Entrega Objetos/DataFrames em Memória.
  • via LSP -> Entrega Metadados de Posição e Erros para o Editor.