DEV Community: nullen box

Soluções para as "procrastinações"

nullen box — Wed, 10 Jan 2024 11:42:29 +0000

Porque procrastinamos?

Isso mesmo, "procrastinação" não uma coisa só, na verdade existem vários "tipos" de procrastinação, mas antes de aprofundarmos nisso vamos entender o porque procrastinamos antes de mais nada.

Procrastinação é na verdade uma solução, nosso cérebro está o tempo inteiro querendo economizar energia e procrastinar é a maneira mais eficiente de completar tarefas, afinal, porque estudar um semestre inteiro para tirar 10 se podemos estudar só na última semana e tirar a nota mínima para não sermos reprovados?

A estratégia de procrastinação maximiza a variável Valor que podemos definir como Valor = Resultado / Esforço. Em alguns contextos como faculdade, trabalho, meio acadêmico, etc. o esperado que é que a gente maximize a Qualidade e não o Valor, nestes contexto a procrastinação pode se tornar inadequada.

Tipos de "procrastinações"

Podemos identificar três mecanismos diferentes que colocamos dentro da grande categoria "procrastinação":

Idealista
Evasiva
Operacional

Cada um desses mecanismos gera emoções diferentes, pensamentos diferentes e consequentemente precisaremos usar soluções diferentes para cada um.

Procrastinação Idealista

Esse é o tipo de procrastinação que é relacionada a uma fantasia ou à procura da perfeição.
A "lógica" é mais ou menos assim: "já que não consigo fazer isso, vou me preparar, fazendo outras atividades, e quando estiver confiante farei a tarefa principal".
Por exemplo, "se eu chamar aquela pessoa pra sair, provavelmente vou escutar um 'não', então vou fazer academia e entrar no shape pra que eu consiga aumentar as chances de ouvir um 'sim'".

Esse tipo de procrastinação geralmente envolve:

um objetivo inalcançável, uma fantasia, um resultado perfeito esperado
tentativa de influenciar o futuro para conseguir atingir o resultado inalcançável
resultado idealista, fruto de imaginação e baseado em esperança excessiva

Soluções:
Para desmantelar essa procrastinação é necessário fazer algumas coisas

Entenda que seu objetivo é na verdade uma fantasia
Desapegue desse objetivo inicial
Passe pelo momento de "luto" depois de se desapegar da fantasia
Defina um objetivo alcançável para sua situação atual
Entenda que você NÃO desistiu do seu objetivo, você apenas aceitou que não aceitaria o objetivo inicial (fantasioso e inalcançável) e agora está seguindo em frente.

Procrastinação Evasiva

Geralmente é baseada em emoções e se dá quando estamos tentando evitar receber um impacto emocional forte.
As emoções evitadas são geralmente as caracterizadas como negativas, por exemplo: medo, vergonha, frustração, ansiedade, etc.

Também é comum perceber que neste estado temos quase certeza absoluta que algo ruim irá acontecer se realizarmos a ação que estamos postergando.
Além disso é comum que a gente tente "solucionar" o problema criando estratégias e usando pensamento lógico, e se falamos sobre isso com alguém, geralmente escutamos "mas é só fazer", "não vai dar nada, só vai lá e faz", o que não ajuda.

Soluções:

Entenda que pensamentos não se dão muito bem com emoções, então tentar usar pensar em razões para realizar a ação não irá ajudar
Identifique a emoção
- Às vezes fazer isso é difícil, tente pensar "qual emoção estou tentando evitar?" ou então "qual consequência estou tentando evitar?"
- Muitas pessoas têm dificuldade de reconhecer as próprias emoções, neste caso use uma estratégia diferente, pense: "se uma pessoa próxima a mim, estivesse passando por essa situação, como ela se sentiria?"
Trabalhe com a emoção
- pense: "Se eu tivesse um(a) parente sentindo , o que eu diria para ele(a)?"
- Diga isso que pensou para você mesmo agora
- Nós temos a tendência de julgar nossas próprias ações como se fossemos um juiz de nós mesmos, desenvolver a habilidade de reconhecer nossos pontos fracos sem julga-los e agir para melhorar eles é essencial. Tente para de ser seu próprio "Juiz" e tente ser seu próprio "Treinador"

Procrastinação Operacional

Acontece quando o cérebro não consegue "computar" os passos necessários para completar uma tarefa.
É o tipo de tarefa que você fica deixando pra depois e quando finalmente faz pensa "nossa, isso foi bem mais fácil do que imaginei, devia ter feito antes!"

Geralmente associado a tarefas abstratas ou simplesmente grandes demais, por exemplo:
Se você pedir para uma criança de quatro anos arrumar seu quarto ela provavelmente vai conseguir entender que "arrumar o quarto" não é um tarefa em si, mas sim um conjunto de tarefas que quando completadas ao mesmo tempo são entendidas como "arrumar o quarto".
Por outro lado se você pedir para uma criança de 2 anos e meio "arrumar o quarto" ela provavelmente não vai entender e vai ficar parada sem fazer nada, mas se você der instruções claras para cada parte do que compõem "arrumar o quarto" (guardar as canetas, colocar os livros nas prateleiras, guardar os brinquedos no cesto de brinquedos) a criança vai conseguir concluir cada sub-tarefa uma por uma, assim "arrumando o quarto".

Um bom exemplo disso para a vida adulta é "arrumar um emprego". Como se arruma um emprego? O emprego está quebrado por um acaso?

Soluções:

Operacionalize a tarefa (divida em pequenos passos)
Começar do fim ajuda

Exemplo:

Aceitar a oferta de emprego
Receber uma oferta de emprego
Mandar mensagem pós-entrevista demonstrando agradecimento
Fazer a entrevista
1. Vestir roupas apropriadas
2. Tomar banho
3. Cortar o cabelo
Aplicar para vagas
1. Quantas vagas?
2. Quais posições?
Pesquisar por vagas de trabalho
Decidir tipo de trabalho que vai procurar

Conclusão

Entender que "procrastinação" é um termo que na verdade encapsula vários fenômenos da nossa mente nos ajuda a usar a melhor estratégia para vencer a "procrastinação" nos momentos aonde não seria apropriado utiliza-la como método de execução de tarefas eficiente.

DISCLAIMER
Este resumo foi elaborado de forma independente e é fundamentado no vídeo do Dr. Alok Kanojia no YouTube, intitulado: Mental Health Bootcamp: Procrastinate MORE not LESS | Healthy Gamer Webinar #3. Não possuo qualquer associação com o Dr. Alok ou sua marca, e meu propósito não é promover seus produtos de maneira alguma. Este resumo é uma interpretação pessoal e não substitui aconselhamento profissional. Recomenda-se verificar diretamente com fontes originais para uma compreensão completa do conteúdo discutido.

Verificando e Gerando Expressões

nullen box — Sat, 06 Jan 2024 13:58:37 +0000

Type Checker

Continuando nosso capítulo de expressões na nossa linguagem, neste post vamos focar na parte de verificação das expressões, alterando nosso type checker e também ajustando nosso generator para criar transformar as ASTs em javascript válido.

Atualmente nossa função check_binary_expression avalia as partes left e right do node são numéricas, porém agora nossas expressões podem conter outras expressões inteiras uma dentro da outra de forma arbitrária.
Nossa função check_program já muda a verificação dependendo do tipo do node, portanto podemos simplesmente usar recursividade e essa nossa função para resolver esse problema.
Nossa função check_binary_expression ficará assim agora:

function check_binary_expression(node) {
  const { left, right } = node
  return check_program(left) && check_program(right)
}

Perceba que essa mudança é bem significativa pois antes estávamos usando a função check_numeric para verificar os componentes left e right do node, assim tínhamos certeza que os operadores aritméticos estavam sendo usado apenas com números, porém isso não faz mais sentido, primeiro porque temos mais tipos diferentes de expressões binárias e não só aritméticas e segundo que um operador é tecnicamente uma função e ainda não temos um mecanismo definido para verificar "assinaturas" de funções comparado com os argumentos da função, só conseguiremos fazer uma verificação mais profunda quando tivermos esse mecanismo criado.
Por enquanto vamos fazer verificação estrutural apenas, seguindo a lógica vamos alterar nossa função check_unary_expression também:

function check_unary_expression(node) {
  const { argument } = node
  return check_program(argument)
}

IMPORTANTE: Ao fazer um teste com a função check_program atual achei um erro que tinha passado despercebido, no meio da função temos a verificação if (type === 'literal') { porém não existem nodes do tipo literal, na verdade literal representa todos os tipos de node de valores como int, float, string, etc. Por isso vamos alterar nossa função para corrigir esse erro:

function check_program(ast) {
  const { type } = ast
  if (check_literal(ast)) {
    return true
  } else if (type === 'binary_expression') {
    return check_binary_expression(ast)
  } else if (type === 'unary_expression') {
    return check_unary_expression(ast)
  } else {
    console.log(`Invalid AST has type = ${type}`)
    return false
  }
}

Nesta nova versão utilizamos a função já previamente definida check_literal para "pular" o caso do node to "tipo" literal.

Agora com os novos ajustes vamos altera nosso arquivo exemplo para 2 * 3 + 4 || 3 - (3 * 1 + 3) == 1 rodar o comando node parser ex.ln0 e depois o comando node typecheck ast.json
Na tela é printado true indicando que a AST está "correta", isso ainda não significa muita coisa, mas em breve vamos trabalhar mais nisso e implementar o sistema de validação de "assinatura" de funções, por enquanto isso já está bom o suficiente.

Generator

Vamos focar agora no generator e transformar nossa AST em javascript válido contendo as várias expressões que já conseguimos parsear.

No nosso generator temos os mesmos problemas para resolver, precisamos usar recursão e arrumar nossa função principal que também contêm a verificação do tipo literal que não faz sentido.

Primeiro vamos alterar nossas funções geradoras gen_binary_expression e gen_unary_expression usando recursão para gerar os parâmetros:

function gen_binary_expression(node) {
  const { operator, left, right } = node
  return `${gen_program(left)} ${operator.value} ${gen_program(right)}`
}

function gen_unary_expression(node) {
  const { operator, argument } = node
  return `${operator.value}${gen_program(argument)}`
}

E depois alteramos nossa função principal, pra isso vamos "emprestar" nossa função check_literal do módulo typecheck:

module.exports.check_literal = check_literal

const { check_literal } = require('./typecheck')
//...
function gen_program(ast) {
  const { type } = ast
  if (check_literal(ast)) {
    return gen_literal(ast)
  } else if (type === 'binary_expression') {
    return gen_binary_expression(ast)
  } else if (type === 'unary_expression') {
    return gen_unary_expression(ast)
  } else {
    console.log(`Invalid AST has type = ${type}`)
    return ''
  }
}

Agora com todas essas modificações, basta rodarmos o comando node generator ast.json o nosso arquivo output.js fica dessa forma: 2 * 3 + 4 || 3 - 3 * 1 + 3 == 1. Está quase correto, o único problema é a falta dos parênteses que estavam no arquivo original, eles sumiram porque atualmente nossa definição gramática ignora os parênteses, para arrumarmos isso precisamos alterar nossa gramática primeiro:

primary_expression
  -> literal {% id %}
  | %lparen term_expression %rparen {% data => ({
    type: 'parenthesized_expression',
    expression: data[1],
  }) %}

Agora introduzimos um novo type de node, o parenthesized_expression, com essa diferenciação conseguimos preservar a estrutura original, mas antes de continuar vamos buidlar nossa gramática rodando o comando pnpm nc.

Agora precisamos adicionar os handlers do tipo parenthesized_expression no typecheck.js e no generator.js, começando com o typecheck.js:

function check_program(ast) {
  const { type } = ast
  if (check_literal(ast)) {
    return true
  } else if (type === 'binary_expression') {
    return check_binary_expression(ast)
  } else if (type === 'unary_expression') {
    return check_unary_expression(ast)
  } else if (type === 'parenthesized_expression') {
    const { expression } = ast
    return check_program(expression)
  } else {
    console.log(`Invalid AST has type = ${type}`)
    return false
  }
}

Por ser algo bem simples de se fazer vou deixar no meio da função mesmo, vamos fazer agora o do generator.js:

function gen_program(ast) {
  const { type } = ast
  if (check_literal(ast)) {
    return gen_literal(ast)
  } else if (type === 'binary_expression') {
    return gen_binary_expression(ast)
  } else if (type === 'unary_expression') {
    return gen_unary_expression(ast)
  } else if (type === 'parenthesized_expression') {
    return gen_parenthesized_expression(ast)
  } else {
    console.log(`Invalid AST has type = ${type}`)
    return ''
  }
}

Neste caso vamos criar uma função separada mesmo, a função gen_parenthesized_expression:

function gen_parenthesized_expression(node) {
  const { expression } = node
  return `(${gen_program(expression)})`
}

Agora, ao rodar o comando node typecheck ast.json temos o resultado true, indicando que tudo está funcionando bem e ao rodar o comando node generator ast.json o resultado é: 2 * 3 + 4 || 3 - (3 * 1 + 3) == 1 agora com os parêntesis.

Finalização

Nossa linguagem agora consegue "enxergar" vários tipos de expressões com vários níveis de profundidade e depois consegue transformar tudo em javascript. Por enquanto não há nenhuma diferença pois estamos tratando apenas de expressões básicas e ainda não implementamos nosso sistema de tipagem nem de funções, nem de verificação de "assinatura" de funções e é isso que vamos focar no próximo post. Até mais!

Expressões encadeadas e agrupamento

nullen box — Sat, 30 Dec 2023 11:54:36 +0000

Já temos um bom arsenal de expressões singulares preparado, nossa linguagem já "entende" expressões aritméticas binárias e unárias e agora precisamos fazer com que ela "entenda" expressões encadeadas.

Pra isso vamos definir todos os tipos de expressões e usaremos a sequência de precedência para fazer as alterações necessárias.

No nível mais baixo temos os valores literais e os agrupamentos, que são expressões entre parênteses, para trabalharmos com agrupamentos primeiro precisamos alterar nosso tokenizer:

//...
  lparen: '(',
  rparen: ')',
//...

Agora podemos criar a regra primary_expression que representa o primeiro nível de expressões:

primary_expression
  -> literal {% id %}
  | %lparen term_expression %rparen {% data => data[1] %}

Essa regra interpreta literais ou expressões entre parênteses.

A próxima na lista é a unary_expression que já temos, porém precisaremos fazer alguma alterações:

unary_expression
  -> primary_expression {% id %}
  | unary_operator primary_expression {% data => ({
    type: 'unary_expression',
    operator: data[0],
    argument: data[1],
  }) %}

Perceba a alteração de literal para primary_expression, e a adição da variante anterior primary_expression como opção de resolução, essas alterações fazem uma regra depender da outra ao mesmo tempo que evita ambiguidade, vamos continuar com essa lógica subindo a hierarquia.

A próxima da lista é a factor_expression:

factor_expression
  -> unary_expression {% id %}
  | factor_expression __ factor_operator __ factor_expression {% data => ({
    type: 'binary_expression',
    operator: data[2],
    left: data[0],
    right: data[4],
  }) %}

E por último a term_expression:

term_expression
  -> factor_expression {% id %}
  | term_expression __ term_operator __ term_expression {% data => ({
    type: 'binary_expression',
    operator: data[2],
    left: data[0],
    right: data[4],
  }) %}

Testando

Basta compilar a gramática com o comando pnpm nc
Vamos também alterar nosso arquivo ex.ln0 escrevendo a expressão 2 + 3 * 4
Ao rodar o comando node parser ex.ln0, temos a seguinte AST:

{
  "type": "binary_expression",
  "operator": {
    "type": "plus",
    "value": "+",
    //...
  },
  "left": {
    "type": "int",
    "value": "2",
    //...
  },
  "right": {
    "type": "binary_expression",
    "operator": {
      "type": "star",
      "value": "*",
      //...
    },
    "left": {
      "type": "int",
      "value": "3",
      //...
    },
    "right": {
      "type": "int",
      "value": "4",
      //...
    }
  }
}

O resultado é o esperado, o primeiro operador colapsado é o +, e a propriedade right é uma expressão binária inteira com o operador * portanto a regra de precedência se faz correta visto que o símbolo de * será avaliado primeiro por estar mais longe da raiz da AST.

Vamos alterar nosso exemplo dessa forma 2 + -(3 * 4 + 1) / 2, assim podemos ver na prática todas as variações de expressões.
Depois de rodar o comando node parser ex.ln0, temos o resultado:

{
  "type": "binary_expression",
  "operator": {
    "type": "plus",
    "value": "+",
    //...
  },
  "left": {
    "type": "int",
    "value": "2",
    //...
  },
  "right": {
    "type": "binary_expression",
    "operator": {
      "type": "slash",
      "value": "/",
      //...
    },
    "left": {
      "type": "unary_expression",
      "operator": {
        "type": "dash",
        "value": "-",
        //...
      },
      "argument": {
        "type": "binary_expression",
        "operator": {
          "type": "plus",
          "value": "+",
          //...
        },
        "left": {
          "type": "binary_expression",
          "operator": {
            "type": "star",
            "value": "*",
            //...
          },
          "left": {
            "type": "int",
            "value": "3",
            //...
          },
          "right": {
            "type": "int",
            "value": "4",
            //...
          }
        },
        "right": {
          "type": "int",
          "value": "1",
          //...
        }
      }
    },
    "right": {
      "type": "int",
      "value": "2",
      //...
    }
  }
}

Por enquanto tudo parece estar dentro dos conformes.

Expansão rápida

Já possuímos um "framework" de expressões binárias e unárias agora podemos expandir para não só expressões aritméticas mas também comparativas, lógicas e bitwise. Vamos aproveitar o fato de que é só copiar e colar para melhorar um pouco a nossa organização de código e fazer algumas refatorações.

Primeiramente vamos criar uma função especial para compilar nossos nodes do tipo binary_expression no nosso arquivo de gramática:

@{%
const tokenizer = require('./tokenizer')

function binary_expression(data) {
  return {
    type: 'binary_expression',
    operator: data[2],
    left: data[0],
    right: data[4]
  }
}
%}

Dessa forma podemos para de copiar e colar esse pedaço de código nas expressões binárias, a refatoração fica dessa forma:

factor_expression
  -> unary_expression {% id %}
  | factor_expression __ factor_operator __ factor_expression {% binary_expression %}

term_expression
  -> factor_expression {% id %}
  | term_expression __ term_operator __ term_expression {% binary_expression %}

Antes de continuar precisamos aumentar nosso vocabulário de tokens adicionando os items >=, <=, !=, ==, >, <, =, |, & e ^ (lembrando de definir os tokens duplos antes dos simples para evitar errors):

//...
  gte: '>=',
  lte: '<=',
  neq: '!=',
  eqeq: '==',
  lor: '||',
  land: '&&',
//...
  or: '|',
  gt: '>',
  lt: '<',
  eq: '=',
  and: '&',
  caret: '^',
//...

Vamos agora adicionar nossas regras de operadores comparativos, lógicos e bitwise:

comparison_operator
  -> %gt {% id %}
  | %gte {% id %}
  | %lt {% id %}
  | %lte {% id %}

equality_operator
  -> %eqeq {% id %}
  | %neq {% id %}

Note que não precisamos definir regras para operadores lógicos e bitwise pois cada um deles possuiu um nível de precedência diferente e fazer isso seria redundante.

O próximo passo é definir as regras de expressões de comparação e de igualdade :

comparison_expression
  -> term_expression {% id %}
  | comparison_expression __ comparison_operator __ comparison_expression {% binary_expression %}

equality_expression
  -> comparison_expression {% id %}
  | equality_expression __ equality_operator __ equality_expression {% binary_expression %}

E depois as regras individuais de expressões bitwise e de lógica:

# bitwise start
bitwise_and_expression
  -> equality_expression {% id %}
  | bitwise_and_expression __ %and __ equality_expression {% binary_expression %}

bitwise_xor_expression
  -> bitwise_and_expression {% id %}
  | bitwise_xor_expression __ %caret __ bitwise_and_expression {% binary_expression %}

bitwise_or_expression
  -> bitwise_xor_expression {% id %}
  | bitwise_or_expression __ %or __ bitwise_xor_expression {% binary_expression %}
# bitwise end

# logical start
logical_and_expression
  -> bitwise_or_expression {% id %}
  | logical_and_expression __ %lor __ bitwise_or_expression {% binary_expression %}

logical_or_expression
  -> logical_and_expression {% id %}
  | logical_or_expression __ %land __ logical_and_expression {% binary_expression %}
# logical end

por último basta trocar nossa definição de program para usar a última expressão da lista a logcal_or_expression:

program
  -> logical_or_expression {% id %}

Depois de compilar a gramática com pnpm nc e alterar nosso programa exemplo para 1 + 2 > 3 * 4 == 3 < 1 | 3 - 1
Vamos rodar o comando node parser ex.ln0 e o resultado é:

{
  "type": "binary_expression",
  "operator": {
    "type": "or",
    //...
  },
  "left": {
    "type": "binary_expression",
    "operator": {
      "type": "eqeq",
      //...
    },
    "left": {
      "type": "binary_expression",
      "operator": {
        "type": "gt",
        //...
      },
      "left": {
        "type": "binary_expression",
        "operator": {
          "type": "plus",
          //...
        },
        "left": {
          "type": "int",
          "value": "1",
          //...
        },
        "right": {
          "type": "int",
          "value": "2",
          //...
        }
      },
      "right": {
        "type": "binary_expression",
        "operator": {
          "type": "star",
          //...
        },
        "left": {
          "type": "int",
          "value": "3",
          //...
        },
        "right": {
          "type": "int",
          "value": "4",
          //...
        }
      }
    },
    "right": {
      "type": "binary_expression",
      "operator": {
        "type": "lt",
        //...
      },
      "left": {
        "type": "int",
        "value": "3",
        //...
      },
      "right": {
        "type": "int",
        "value": "1",
        //...
      }
    }
  },
  "right": {
    "type": "binary_expression",
    "operator": {
      "type": "dash",
      //...
    },
    "left": {
      "type": "int",
      "value": "3",
      //...
    },
    "right": {
      "type": "int",
      "value": "1",
      //...
    }
  }
}

O que é bem impressionante!

Próximos Passos

Até agora fizemos a parte da expansão gramatical, porém ainda precisamos adequar nosso type checker e nosso generator para que eles funcionem corretamente. Faremos isso no próximo post, até mais!

Mais níveis de precedência e mais operadores

nullen box — Sat, 23 Dec 2023 13:10:25 +0000

No último post adicionamos os operadores binários + e - em nossa linguagem, nesse post vamos adicionar os operadores binários * e / além dos unários ! e -, repare que o sinal de menos poder tanto um operador binário onde realmente seria uma operação de subtração ou pode ser um operador unário indicando que o número é negativo.

Olhando nas nossas definições de tokens iniciais, podemos já identificar um problema, os token incluem sinalização, teremos que alterar isso para não causar confusão no parser:
Atualmente temos essas duas definições:

//...
  float: /[-+]?(?:\d+\.\d*|\.\d+)(?:[eE][-+]?\d+)?/,
  int: /0|[-+]?[1-9][0-9]*/,
//...

Vamos altera-las para:

//...
  float: /(?:\d+\.\d*|\.\d+)(?:[eE][-+]?\d+)?/,
  int: /0|[1-9][0-9]*/,
//...

Dessa forma temos controle total da nossa gramática e o tokenizer não vai nos atrapalhar.

Com isso resolvido vamos continuar com nossa modificação, primeiramente implementando os operadores * e /

Adicionando os operadores `*` e `/`

Vamos adicionar os operadores à gramática:

factor_operator
  -> %star {% id %}
  | %slash {% id %}

E a regra de expressão única do tipo factor:

factor_expression
  -> literal __ factor_operator __ literal {% data => ({
    type: 'binary_expression',
    operator: data[2],
    left: data[0],
    right: data[4],
  }) %}

vamos também adicionar a regra factor_expression como opção para definição de um program válido:

program
  -> literal {% id %}
  | term_expression {% id %}
  | factor_expression {% id %}

Lembrando mais uma vez que por enquanto a linguagem suporta apenas uma expressão por vez. Uma multi-expressão como essa 2 + 3 * 4 ainda não é suportada pela nossa linguagem, trabalharemos nisso mais pra frente.

Para prosseguirmos vamos compilar nossa gramática com o comando pnpm nc.
Também vou alterar nosso programa exemplo dessa forma:

2 * 2

E compilar o programa: node parser ex.ln0
O resultado final é correto e fica dessa forma (omiti algumas informações por efeitos de concisão):

{
  "type": "binary_expression",
  "operator": {
    "type": "star",
    "value": "*",
    //...
  },
  "left": {
    "type": "int",
    "value": "2",
    //...
  },
  "right": {
    "type": "int",
    "value": "2",
    //...
  }
}

Como os novos operadores geram nodes do tipo binary_expression não precisamos alterar nosso arquivo typecheck.js. Da mesma forma nossa função gen_binary_expression do nosso arquivo generator.js já funcionará corretamente.

Para verificar vou continuar com o processo rodando o comando node typecheck ast.json, o resultado é true.
E rodando o comando node generator ast.json, o resultado é o arquivo output.js contendo o texto 2 * 2, ou seja, tudo funcionando perfeitamente.

Adicionando operadores unários

Operadores unário são operadores que recebem apenas um operando, os principais são o operador de negação lógica ! e o operador de negação aritmética - repare que o o símbolo - pode ser tanto o operador binário de subtração aritmética quanto a outra versão, o operador unários.

Para evitar confusão vamos definir uma regra geral para a linguagem onde os operadores unário dever estar localizados imediatamente ao lado do operando, por exemplo, esse seria um código inválido - 2, por causa do espaço, o correto seria -2 sem espaço.

Para isso precisamos alterar nossa gramática e nosso tokenizer mais uma vez.

Começando com alterações dos tokens, vamos adicionar o símbolo de negação lógica !:

//...
  bang: '!',
//...

Na nossa gramática vamos criar as regras para operadores e expressões unárias:

unary_operator
  -> %bang {% id %}
  | %dash {% id %}

#...

unary_expression
  -> unary_operator literal {% data => ({
    type: 'unary_expression',
    operator: data[0],
    argument: data[1],
  }) %}

Perceba que na definição de unary_expression não há nenhuma regra de espaçamento (_ ou __) para indicarmos que espaço entre o operador e o operando é proibido.

Precisamos incluir a nova regra na definição de program:

program
  -> literal {% id %}
  | term_expression {% id %}
  | factor_expression {% id %}
  | unary_expression {% id %}

Agora podemos compilar o arquivo de gramática usando pnpm nc

Vamos alterar nosso exemplo agora para fazer o teste de compilação:

-3

rodando o comando node parser ex.ln0 temos como resultado a seguinte AST:

{
  "type": "unary_expression",
  "operator": {
    "type": "dash",
    "value": "-",
    "text": "-",
    "offset": 0,
    "lineBreaks": 0,
    "line": 1,
    "col": 1
  },
  "argument": {
    "type": "int",
    "value": "3",
    "text": "3",
    "offset": 1,
    "lineBreaks": 0,
    "line": 1,
    "col": 2
  }
}

O que indica que tudo está funcionando corretamente.

Para finalizar basta adicionar novas funções para expressões unárias nos arquivos typecheck.js e generator.js

Começando com o typecheck.js precisamos criar uma função check_unary_expression e alterar nossa lógica principal.
Primeiro criamos a função:

function check_unary_expression(node) {
  const { argument } = node
  return check_number(argument)
}

E agora alteramos a lógica principal adicionando a branch de unary_expression:

function check_program(ast) {
  const { type } = ast
  if (type === 'literal') {
    return check_literal(ast)
  } else if (type === 'binary_expression') {
    return check_binary_expression(ast)
  } else if (type === 'unary_expression') {
    return check_unary_expression(ast)
  } else {
    console.log(`Invalid AST has type = ${type}`)
    return false
  }
}

Rodando o comando node typecheck ast.json o resultado no console é true indicando sucesso.

Por último vamos criar a função no arquivo generator.js:

function gen_unary_expression(node) {
  const { operator, argument } = node
  return `${operator.value}${argument.value}`
}

E agora basta alterar a lógica principal também:

function gen_program(ast) {
  const { type } = ast
  if (type === 'literal') {
    return gen_literal(ast)
  } else if (type === 'binary_expression') {
    return gen_binary_expression(ast)
  } else if (type === 'unary_expression') {
    return gen_unary_expression(ast)
  } else {
    console.log(`Invalid AST has type = ${type}`)
    return ''
  }
}

Rodando o comando node generator ast.json o arquivo output.js possuiu o texto -3 indicando que tudo está funcionando corretamente

Próximos passos

Por enquanto nossa expressões são "únicas", ou seja, expressões encadeadas como essa 2 + 3 * 4 simplesmente não são suportadas pela nossa linguagem ainda e é nisso que vamos trabalhar no próximo capítulo.

Operadores numéricos são mais complexos do que parece

nullen box — Wed, 20 Dec 2023 20:53:36 +0000

O que faremos

No último post, expandimos nossa linguagem para "enxergar" uma única instância de qualquer um dos valores literais que definimos: int, float, bool, string e char. Nesse post nosso foco será integrar operadores aritméticos na nossa gramática. Spoiler Alert: é mais difícil do que parece.

Isso porque precisamos criar nossa AST corretamente, seguindo a ordem de precedência dos operadores, ou seja, os sinais + e - têm mais "importância" do que os de * e /. Isso parece ser contraditório, mas faz total sentido, pra entender melhor vamos precisar criar algumas árvores.

Vamos transformar essa expressão aritmética 2 * 3 + 4 em uma AST:

perceba que a raiz da AST é a operação +, isso porque esta operação tem menor precedência, ou seja, ela se "encaixa" na árvore depois, uma outra maneira de entender isso é imaginando que cada operador tem uma distância limite onde procuram os operandos, quanto maior essa distância menor a precedência do operador.

Na prática, precisamos criar regras gramaticais diferentes para cada nível de precedência para que o compilador crie a AST de forma correta.

Alterando o tokenizer

Como estamos introduzindo novos elementos na linguagem precisamos adicionar novas regras no nosso tokenizer, e neste caso isso é bem fácil, basta definir nomes para caracteres específicos:

//...
  bool: /true|false/,
  plus: '+',
  dash: '-',
  star: '*',
  slash: '/',
  NL: { match: '\n', lineBreaks: true },
})

Isso já é o suficiente para adicionar os operadores primários na nossa linguagem, agora o próximo passo é alterar nossa gramática para gerarmos ASTs corretas.

Atualizando gramática

Um ponto importante que não podemos ignorar é que agora temos que lidar com espaços em branco, ao escrever uma expressão matemática geralmente escrevemos com espaços em branco ao redor dos operadores, portanto o primeiro passo é definir regras para espaço em branco na nossa gramática.

A princípio teremos dois tipos de espaço em branco, espaço obrigatório e espaço opcional, isso é uma prática comum de gramática nearley então vamos manter, vamos ignorar a existência de quebras de linha por enquanto.

Por questões de simplicidade vamos usar um único underscore _ para a regra de espaço opcional e underscore duplo __ para a regra de espaço obrigatório dessa forma:

#...

_ -> %WS:* {% id %}
__ -> %WS:+ {% id %}

Vamos agora criar a regra para os operadores de menor precedência (+, -), pois temos que seguir a hierarquia de precedência inversa (de menor precedência para maior precedência) para formarmos ASTs corretas.
Primeiro definimos a regra de operadores e depois de expressões., a regra de expressão a princípio aceitará uma única instância de expressão, depois vamos expandir para aceitar expressões encadeadas.
A regra para expressões também terá espaçamento obrigatório entre os termos.

#...
term_operator
  -> %plus {% id %}
  | %dash {% id %}

term_expression
  -> literal __ term_operator __ literal {% data => ({
    type: 'binary_expression',
    operator: data[2],
    left: data[0],
    right: data[4],
  }) %}
#...

Vamos alterar nossa regra program para aceitar agora um único valor literal (como já era antes) ou uma única expressão simples.

#...
program
  -> literal {% id %}
  | term_expression {% id %}
#...

Agora vamos compilar nossa gramática mais uma vez rodando o comando nearleyc lang0.ne -o lang0.js

Nota: Nesse momento percebo que estamos rodando esse comando toda vez, portanto decidi criar um script no meu arquivo package.js para rodar esse comando automaticamente.

"scripts": {
  "nc": "nearleyc lang0.ne -o lang0.js"
},

Portanto a partir de agora vou usar o comando pnpm nc para compilar minha gramática.

Voltando ao que estávamos fazendo antes, precisamos testar agora essa nova regra, pra isso vou alterar nosso arquivo de teste para conter apenas um número:

Rodar o comando: node parser ex.ln0
E o resultado está correto:

{
  "type": "int",
  "value": "1",
  "text": "1",
  "offset": 0,
  "lineBreaks": 0,
  "line": 1,
  "col": 1
}

Se alterarmos o arquivo exemplo para conter uma expressão de soma agora:

1 + 2

E rodarmos o comando novamente: node parser ex.ln0
O resultado é esse:

{
  "type": "binary_expression",
  "operator": {
    "type": "plus",
    "value": "+",
    "text": "+",
    "offset": 2,
    "lineBreaks": 0,
    "line": 1,
    "col": 3
  },
  "left": {
    "type": "int",
    "value": "1",
    "text": "1",
    "offset": 0,
    "lineBreaks": 0,
    "line": 1,
    "col": 1
  },
  "right": {
    "type": "int",
    "value": "2",
    "text": "2",
    "offset": 4,
    "lineBreaks": 0,
    "line": 1,
    "col": 5
  }
}

Está correto.

Vamos testar com o operador de menos: 1 - 2
Resultado (omiti algumas informações pra ficar mais conciso):

{
  "type": "binary_expression",
  "operator": {
    "type": "dash",
    "value": "-",
    //...
  },
  "left": {
    "type": "int",
    "value": "1",
    //...
  },
  "right": {
    "type": "int",
    "value": "2",
    //...
  }
}

Alterando o type checker

Agora temos um novo node possível, o binary_expression node, por isso precisamos criar uma nova função específica para checkar esse node.
Neste começo vamos fazer com que os operadores aritméticos só funcionem com valores numéricos, por tanto, primeiro precisamos criar a função check_number que retornará true caso o node seja um valor numérico e false caso contrário.

function check_number(node) {
  const { type } = node
  return check_int(node) || check_float(node)
}

Agora podemos criar a função check_binary_expression:

function check_binary_expression(node) {
  const { left, right } = node
  return check_number(left) && check_number(right)
}

Com essa nova função em mãos precisamos apenas fazer uma função mais high level que será responsável por checkar o programa inteiro, visto que, como foi definido anteriormente, um programa nessa linguagem agora pode ser apenas um valor literal ou apenas uma expressão simples.

function check_program(ast) {
  const { type } = ast
  if (type === 'literal') {
    return check_literal(ast)
  } else if (type === 'binary_expression') {
    return check_binary_expression(ast)
  } else {
    console.log(`Invalid AST has type = ${type}`)
    return false
  }
}

Basta alterarmos a chamada principal do programa agora:

//...
  const ast = JSON.parse(content);
  console.log(check_program(ast));
} catch(e) {
//...

Vamos testar agora rodando o comando: node typecheck ast.json e o resultado é true como esperado.

Vamos alterar nosso arquivo exemplo para "somar" duas strings:

"2" + "a"

Vamos compilar: node parser ex.ln0
E verificar: node typecheck ast.json
O resultado é false, como esperado, pois definimos que os operandos dos operadores devem ser numéricos.

Atualizando o gerador de código

Agora só precisamos criar a função geradora para transformarmos nossa AST de expressão binária em javascript válido.

Pra isso precisamos criar a função gen_binary_expression, responsável por transformar um node do tipo binary_expression em string:

function gen_binary_expression(node) {
  const { operator, left, right } = node
  return `${left.value} ${operator.value} ${right.value}`
}

E a função gen_program, que será nossa função high level para decidir qual função ustilizar:

function gen_program(ast) {
  const { type } = ast
  if (type === 'literal') {
    return gen_literal(ast)
  } else if (type === 'binary_expression') {
    return gen_binary_expression(ast)
  } else {
    console.log(`Invalid AST has type = ${type}`)
    return ''
  }
}

Agora é só alterar nossa chamada principal para executar a função gen_program:

//...
  const ast = JSON.parse(contents);
  const output = gen_program(ast);
  fs.writeFileSync('output.js', output);
} catch(e) {
//...

Antes de testar vamos voltar nosso arquivo exemplo para algo mais coerente com nossa linguagem e passar por todas as etapas:

Alterar o arquivo ex.ln0 para conter a expressão 42 + 1
Compilar a AST do nosso programa rodando node parser ex.ln0
Fazer verificação de tipos rodando node typecheck ast.json
Como o resultado foi positivo vamos gerar o javascript final rodando node generator ast.json

Se verificarmos nosso arquivo output.js agora teremos:

42 + 1

E assim concluímos a primeira etapa do conceito de expressões.

Próximos passos

Ainda precisamos dos outros operadores aritméticos * e / (que são de outro nível de precedência) para completarmos nossas expressões aritméticas simples, depois ainda temos os operadores unários, operadores de comparação, de lógica, de operações de bit, em fim, muitas coisas ainda pra termos um bom set de operadores.
Porém tudo ficará mais fácil agora e será mais ou menos só uma questão de copiar, colar e ajustar.
Até a próxima!

Além dos números: expandindo a linguagem

nullen box — Sat, 16 Dec 2023 12:11:14 +0000

O que faremos

Nós já completamos a primeira parte do desafio, criamos uma gramática para uma linguagem que só reconhece números inteiros e usamos o compilador do pacote nearley para transformar o arquivo em uma AST, depois fizemos uma simples verificação de tipagem e por último criamos um arquivo javascript válido.
Pode não parecer muita coisa porque nossa linguagem só "enxerga" números, mas agora temos uma ideia mais concreta de como continuar com o processo.

O próximo passo é fazer nossa linguagem "enxergar" não só números inteiros, mas também os principais valores primitivos como números float, strings, etc.

Mas antes de continuar com o código queria fazer uma pausa para tomar decisões de design da linguagem. Como já disse antes essa linguagem será tipada, então seria como se fosse Typescript ou Rust e embora no final tudo será compilado para javascript eu acho que será um desafio interessante se fizermos algumas divergências de tipos em relação ao javascript.

No javascript temos alguns tipos literais bem básicos, eles são:

boolean
number
string
undefined
null
symbol
bigint

Comparado com C por exemplo quem tem 13 variações dos principais tipos de char até long double. JavaScript tem uma variação de tipos muito pequena, meu objetivo com essa linguagem é mirar em algo como Rust ou Go, ou seja, será uma linguagem bem simples, porém mais sofisticada do que JavaScript.

Para começar podemos definir os seguintes tipos básicos:

integer (int)
float
char
string
boolean (bool)

Não vou incluir nenhum tipo como null ou undefined ou algo assim, pois quero usar conceitos mais funcionais. Também não pretendo usar variações de números como octal ou binary por enquanto, vamos focar no que é mais importante primeiro.

Ajustando tokenizer e testando

Precisamos criar as RegExps dos novos tokens e alterar nosso objeto do tokenizer

//...
const tokenizer = moo.compile({
  WS: /[ \t]+/,
  string: /"(?:\\["\\]|[^\n"\\])*"/,
  char: /'(?:[^'\\]|\\.)*'/,
  float: /[-+]?(?:\d+\.\d*|\.\d+)(?:[eE][-+]?\d+)?/,
  int: /0|[-+]?[1-9][0-9]*/,
  bool: /true|false/,
  NL: { match: '\n', lineBreaks: true },
})
//..

Lembrando que a ordem aqui importa, por exemplo, o token string deve ser o primeiro dos valores literais, pois independente do que estiver escrito dentro de uma string (números, keywords, etc) ela sempre vai ser uma string.

Agora vamos alterar nossa gramática, criaremos uma nova regra chamada literal que representará todos os valores literais possível (os que discutimos anteriormente) e então nosso programa será definido como uma única instância de um de tais valores.

#...
program -> literal {% id %}

literal
  -> %int {% id %}
  | %float {% id %}
  | %string {% id %}
  | %char {% id %}
  | %bool {% id %}

Com a mudança da gramática temos que compilar a gramática javascript mais uma vez rodando o comando nearleyc lang0.ne -o lang0.js
Com a nova gramática podemos compilar nosso arquivo exemplo: node parser ex.ln0
Esperamos que tudo continue ocorrendo como antes e que o resultado seja esse:

{
  "type": "int",
  "value": "42",
  "text": "42",
  "offset": 0,
  "lineBreaks": 0,
  "line": 1,
  "col": 1
}

Porém agora podemos alterar nosso programa para qualquer um dos valores literais que definimos e tudo deve funcionar corretamente, por exemplo, temos aqui um número float:

3.141592

E o resultado depois de rodar o comando node parser ex.ln0:

{
  "type": "float",
  "value": "3.141592",
  "text": "3.141592",
  "offset": 0,
  "lineBreaks": 0,
  "line": 1,
  "col": 1
}

ou a string "3.141592":

{
  "type": "string",
  "value": "\"3.141592\"",
  "text": "\"3.141592\"",
  "offset": 0,
  "lineBreaks": 0,
  "line": 1,
  "col": 1
}

Perceba que o programa associa corretamente o "type" do objeto.

Ajustando type checker

Agora que nosso partes gera vários tipos de "ASTs" precisamos criar as funções necessárias para verificar os nodes seguindo a mesma lógica de antes.

Já possuíamos a função check_int e vamos apenas copiar e colar, fazer algumas alterações e criar as outras funções:

//...
function check_float(node) {
  const { type } = node
  return type === 'float'
}

function check_char(node) {
  const { type } = node
  return type === 'char'
}

function check_string(node) {
  const { type } = node
  return type === 'string'
}

function check_bool(node) {
  const { type } = node
  return type === 'bool'
}

Perceba que notoriamente teria como criar uma abstração ou tornar o código menos repetitivo, vou propositalmente ignorar isso por enquanto e futuramente quando tivermos algo mais estável podemos voltar para refatorar.

Temos agora funções específicas para cada tipo de dado, mas precisamos de uma função que vai checkar se um valor é literal ou não, isso significa que se conseguirmos o valor true de alguma das funções que criamos então valor é literal.
Podemos aproveitar o fato de que todas as funções retornam boolean para tornar esse processo muito fácil, nossa funções pode ser escrita assim:

function check_literal(node) {
  return (
    check_int(node) ||
    check_float(node) ||
    check_char(node) ||
    check_string(node) ||
    check_bool(node)
  )
}

E depois disso, basta trocar a função de checkagem para ser a check_literal ao invés de ser a check_int que estávamos usando até então:

//...
try {
  const content = fs.readFileSync(filename, 'utf8');
  const ast = JSON.parse(content);
  console.log(check_literal(ast));
} catch(e) {
  console.error(e?.message);
  process.exit(1);
}
//...

Por enquanto nosso type checker apenas printa na tela true ou false e isso não ajuda muito a gente, mas futuramente podemos usar ele de maneira mais integrada, por enquanto vamos manter dessa forma para avançarmos mais rápido.

Finalizando com `generate`

O último passo é adaptar nosso generator, tecnicamente nossa função gen_int já vai funcionar para todos os tipos de node automaticamente, então a solução mais simples é simplesmente renomear nossa função de gen_int para gen_literal e pronto:

//...
try {
  const contents = fs.readFileSync(filepath, 'utf8');
  const ast = JSON.parse(contents);
  const output = gen_literal(ast);
  fs.writeFileSync('output.js', output);
} catch(e) {
  console.error(e?.message);
  process.exit(1);
}

function gen_literal(node) {
  const { value } = node
  return value
}

Finalização

Nossa linguagem acaba de dar mais um passo e agora consegue "enxergar" instância únicas de int, float, bool, string e char.

Pensando em próximos passos, já podemos trabalhar com operadores aritméticos como +, -, * e /.

Te vejo no próximo post :)

A linguagem mais simples possível

nullen box — Sun, 10 Dec 2023 16:02:27 +0000

Para ler esse conteúdo é recomendado que você saiba:

como um lexer funciona
como um parser funciona
o que são parser generators
o que é uma AST
o básico sobre type checking
o básico sobre type inference

Como nosso objetivo é criar uma linguagem pequena e focando no aprendizado, vamos fazer uma linguagem transpilada para javascript, ou seja, nosso objetivo é pegar um arquivo escrito nessa nossa linguagem e gerar um arquivo javascript que produza o mesmo resultado. Além disso vamos incluir camadas de tipagem para tornar o processo mais desafiador e interessante.

Durante o processo inteiro estarei seguindo este dilema: "faça funcionar, faça do jeito certo, faça ser eficiente.", porém como foco maior na primeira parte para ganharmos velocidade.

Criar uma linguagem de programação, mesmo que muito pequena, é uma tarefa muito grande, por tanto o primeiro passo dessa jornada será dividir o conceito de "linguagem de programação" em pequenas partes e atacar cada um deles individualmente, a famosa estratégia de dividir para conquistar

Primeiro vamos refletir sobre o que compõem um linguagem de programação. A princípio podemos fazer essa reflexão em um nível mais alto de abstração, ao meu ver, os principais componentes são:

sintaxe: o que e como escrever
semântica: construções de código, como resolver problemas e significado
ferramentas: compiladores, sugestões, relatório de erros, colorização, gerenciadores de pacotes, etc.
bibliotecas: bibliotecas nativas, suporte para bibliotecas da comunidade, etc.
comunidade: pessoas engajadas e interessadas na linguagem

Como nosso objetivo é fazer uma linguagem pequena com foco maior em aprendizado, vamos focas apenas nos dois primeiros pontos: sintaxe e semântica. Obviamente precisaremos de ferramentas básicas, mas ao invés de construirmos tais ferramentas vamos usar bibliotecas prontas para acelerar nosso processo, futuramente podemos fazer um mergulho na construção dessas bibliotecas.

Existem vários conceitos que precisamos definir nessa nossa linguagem, por exemplo, o que é uma função, o que é um operador binário, um objeto, uma lista, etc. Além disso existem várias etapas que precisamos passar para sair da nossa linguagem criada e chegar no javascript final, essas etapas são:

tokenize: transformar o texto inicial em tokens
parse: criar uma AST a partir dos tokens
type-check: realizar inferência e checagem de tipos na AST gerada
generate: transformar a AST em javascript válido

Podemos enxergar isso como uma matrix, onde as colunas são as etapas e as linhas são os conceitos, existem duas estratégias possíveis, column-first ou row-first.
Utilizando a estratégia column-first nós focamos em criar todos os conceitos de uma vez etapa por etapa, já na estratégia row-first, atravessamos todas as etapas um conceito por vez.
Pessoalmente prefiro a última opção, pois nela conseguimos aprender mais sobre o problema que estamos resolvendo enquanto fazemos ajustes e ao mesmo tempo não precisamos nos comprometer muito em cada evolução, resumindo, é uma maneira Agile de fazer isso.

Já sabemos as etapas, mas falta aprofundarmos nos conceitos da linguagem, uma lista inicial seria:

valores literais
expressões matemáticas
expressões lógicas
variáveis
funções
estruturas de controle
estruturas de dados
comentários
estruturas de tratamento de erros
closures
recursão

Esses são os principais conceitos da linguagem em si, mas ainda temos que pensar nos conceitos de tipagem:

tipos primitivos, de função e de estruturas
inferência de tipos
anotações de tipos
polimorfismo
tipos criados
casting
covariante e contravariante

Esse parece ser um bom resumo do que precisamos fazer, então vamos começar. Pensando no programa mais simples possível, temos um programa com um único valor literal, por exemplo, um número inteiro.

vamos criar nosso arquivo, ao longo de todo o processo utilizarei a extensão de arquivo .ln0 para denotar programas na linguagem que estamos criando

Como tínhamos combinado antes, vamos passar por todas as etapas do processo agora, como é a primeira vez precisaremos criar muitas coisa

A primeira etapa é "tokenize", pra isso vamos precisar de uma biblioteca chamada moo. Vamos instalar a biblioteca e criar nosso arquivo tokenizer.
Nota: estou utilizando o gerenciador de pacotes pnpm provavelmente você precisará adaptar os comandos se estiver utilizando algum outro.

Primeiro vamos iniciar o projeto: pnpm init
Agora instalar o pacote moo: pnpm i moo
E criar o arquivo tokenizer.js (na raiz do projeto mesmo)

No nosso arquivo tokenizer vamos criar uma instância do moo tokenizer e definir nosso tokens iniciais.

const moo = require('moo')

const tokenizer = moo.compile({
  WS: /[ \t]+/,
  int: /0|[-+]?[1-9][0-9]*/,
  NL: { match: '\n', lineBreaks: true },
})

module.exports = tokenizer

Primeira etapa concluída, nós temos agora um tokenizer que é capaz de gerar tokens de números inteiros (e também de espaços e de quebra de linha). A próxima etapa é a etapa de parsing onde vamos transformar o token em uma AST.
Pra isso vamos utilizar a biblioteca nearley.
Instalando nearley: pnpm i nearley
Precisamos do compilador então vamos instalar também globalmente: pnpm i -g nearley
Para utilizar essa biblioteca precisamos criar um arquivo de gramática com a extensão .ne, esse arquivo será utilizado para gerar um outro arquivo de gramática em javascript que por sua vez será utilizado pelo próprio nearley para compilar nossa linaguagem.
O primeiro passo é importar nosso tokenizer (que também pode ser chamado de lexer), fazemos isso dessa forma:

@{%
const tokenizer = require('./tokenizer')
%}

@lexer tokenizer

Agora vamos criar nossa primeira regra gramatical que define que nosso programa consiste de um único número inteiro (recomendo dar uma olhada na documentação do nearley pra entender melhor a sintaxe)

#...
program -> %int {% id %}

Com nosso arquivo gramatical em mãos vamos usar o compilador no nearley nearleyc para gerar nossa gramática em javascript, pra isso rodamos o comando nearleyc lang0.ne -o lang0.js. Automaticamente um novo arquivo será gerado.

O próximo passo é criar um arquivo parser.js, vamos cria-lo por partes.
Primeiramente vamos verificar os argumentos e pegar o primeiro argumento que deve ser o nome do arquivo que será compilado:

const args = process.argv.slice(2);
const filepath = args[0];

if (!filepath) {
  console.error('Usage: node parser.js <filename>');
  process.exit(1);
}

Agora para rodar esse programa precisamos passar um argumento, o próximo passo é usar esse argumento filepath para ler o conteúdo do arquivo, vamos ignorar os edge-cases por enquanto.

const fs = require('fs');

const args = process.argv.slice(2);
//...
}

const file = fs.readFileSync(filepath, 'utf8');

Com a habilidade de pegarmos o conteúdo do arquivo de input, vamos agora importar nossa gramática javascript e o parser do nearley para compilar o conteúdo do arquivo e escrever a AST final

const nearley = require('nearley')
const grammar = require('./lang0')
const fs = require('fs');
//...
const file = fs.readFileSync(filepath, 'utf8');
const parser = new nearley.Parser(nearley.Grammar.fromCompiled(grammar))
parser.feed(file)

if (parser.results.length === 0) {
  console.log('Parsing error')
} else if (parser.results.length === 1) {
  const ast = parser.results[0];
  fs.writeFileSync('ast.json', JSON.stringify(ast, null, 2));
} else {
  console.log('Ambiguous grammar')
}

Note que existem 3 casos finais, ao compilar o arquivo input o compilador pode encontrar algum erro e gerar nenhum resultado, pode encontrar nenhum erro e gerar um resultado (o que esperamos que aconteça) ou pode encontrar nenhum erro porém gerar mais de um resultado o que indica uma falha na nossa gramática.

Para compilar nosso arquivo exemplo basta executar nosso arquivo parser: node parser ex.ln0
Ao executar o comando um novo arquivo será criado, o nosso arquivo ast.json que deve estar assim

{
  "type": "int",
  "value": "42",
  "text": "42",
  "offset": 0,
  "lineBreaks": 0,
  "line": 1,
  "col": 1
}

Mais uma etapa concluída, temos apenas mais duas etapas pela frente, checagem de tipos e geração do arquivo final

Checar a tipagem desse nosso programa é muito simples porque temos apenas um número e um número é um valor literal, além disso como podemos notar a nossa AST possui um atributo "type" que podemos utilizar, mas antes de qualquer coisa precisamos montar a AST em memória para trabalharmos com ela, pra isso vamos iniciar nosso arquivo typecheck.js dessa forma:

const path = require('path');
const fs = require('fs');

const args = process.argv.slice(2);
const filename = args[0];

if (!filename) {
  console.error('Usage: node typecheck.js <filename> [.json]');
  process.exit(1);
}

if (path.extname(filename) !== '.json') {
  console.error('Filename must have .json extension');
  process.exit(1);
}

try {
  const content = fs.readFileSync(filename, 'utf8');
  const ast = JSON.parse(content);
} catch(e) {
  console.error(e?.message);
  process.exit(1);
}

Agora podemos criar a função que verifica se nossa AST (node) é um número inteiro, repare que a partir de agora vou chamar os objetos de node porque futuramente usaremos recursão para analisarmos estruturas mais complexas

Nossa função de verificação será muito básica, dê uma olhada:

function check_int(node) {
  const { type } = node
  return type === 'int'
}

E agora é só verificar nossa AST de antes de printar o resultado na tela

//...
  const ast = JSON.parse(content);
  console.log(check_int(ast));
} catch(e) {
//...

Por enquanto isso é o que precisamos.
Por último vamos transformar essa AST em um arquivo javascript, para fazer isso vamos criar o arquivo generator.js: Iniciamos com a mesma lógica do último arquivo para criarmos a AST em memória

const path = require('path');

const args = process.argv.slice(2);
const filepath = args[0];

if (!filepath) {
  console.error('Usage: node generator.js <filename>');
  process.exit(1);
}

if (!path.extname(filepath) === '.json') {
  console.error('Filename must have .json extension');
  process.exit(1);
}

try {
  const contents = fs.readFileSync(filepath, 'utf8');
  const ast = JSON.parse(contents);
} catch(e) {
  console.error(e?.message);
  process.exit(1);
}

E agora podemos criar nossa função geradora:

function gen_int(node) {
  const { value } = node
  return value
}

Por fim podemos chamar essa função passando nossa AST e salvando o resultado em um arquivo javascript:

const fs = require('fs');
const path = require('path');
//...
  const ast = JSON.parse(contents);
  const output = gen_int(ast);
  fs.writeFileSync('output.js', output);
} catch(e) {
//...

Depois de rodar o comando node generator ast.json um novo arquivo output.js deve ter sido criado na raiz do projeto contendo um único número inteiro:

Se quiser é possível rodar esse programa javascript com node output

Pronto, finalizamos o menor conceito dentro do nosso escopo, começamos com um número inteiro na nossa linguagem e passamos por 4 etapas até chegar em um número inteiro em javascript.
Como números inteiros são sempre os mesmos então isso não parece ser muita coisa, mas já temos todo o pavimento necessário para as próximas evoluções.
Números inteiros fazem parte do grupo dos valores literais, assim como os números com ponto flutuante, strings, chars, bools, entre outros.
Nosso próximo passo agora está muito claro, expandir todo o nosso sistema para que possamos criar um programa com qualquer um dos valores literais e conseguir chegar em um arquivo javascript válido no final.

DEV Community: nullen box

Soluções para as "procrastinações"

Porque procrastinamos?

Tipos de "procrastinações"

Procrastinação Idealista

Procrastinação Evasiva

Procrastinação Operacional

Conclusão

Verificando e Gerando Expressões

Type Checker

Generator

Finalização

Expressões encadeadas e agrupamento

Testando

Expansão rápida

Próximos Passos

Mais níveis de precedência e mais operadores

Adicionando os operadores * e /

Adicionando operadores unários

Próximos passos

Operadores numéricos são mais complexos do que parece

O que faremos

Alterando o tokenizer

Atualizando gramática

Alterando o type checker

Atualizando o gerador de código

Próximos passos

Além dos números: expandindo a linguagem

O que faremos

Ajustando tokenizer e testando

Ajustando type checker

Finalizando com generate

Finalização

A linguagem mais simples possível

Adicionando os operadores `*` e `/`

Finalizando com `generate`