4

Cara, parabéns. Sério. Você está fazendo um mestrado/doutorado em compiladores sem formalizar. Vi que você é de Minas, então já estou torcendo para te ver no Laboratório de Compiladores do DCC da UFMG fazendo pós junto com a graduação, estilo Artur Avila da computação rs.

Gostei muito dos extensors em Lua/Runa. Isso é uma ideia muito interessante porque transforma codegen em algo hackeável pela comunidade. E me parece ser algo original. Certo? Ou "roubou" essa ideia de algum lugar?

A entrada docs parece arquivo vazio, symlink quebrado ou submodule mal configurado...

Algumas outras perguntas (não é cobrança, é curiosidade real)

  1. Quando você diz que Carla é “mais baixo nível que C”, o que isso significa exatamente? Pergunto porque C já é basicamente assembly portável com tipos e UB de brinde rs. Algo como -nostdlib e __attribute__(()) nativos?

  2. Qual é o modelo de memória da Carla? Você cita "as good as Rust" então existe algum esquema de ownership/borrow/lifetime ou a gestão é manual mesmo?

  3. Codegen via Lua compete direto com o objetivo de "compilação rápida". Tu já mediu Morgana+extensor vs QBE gerando o mesmo asm pro mesmo programa? Se Morgana ganhar, vira paper no SBLP hora. Se perder, sem problemas, ainda é muito defensável pelo ângulo da extensibilidade, mas o pitch muda.

Carregando publicação patrocinada...
1

Opa! Quem sabe! ksksk

Não, é algo mais original mesmo. Eu tenho mania de acordar no meio da noite com ideias, e começar a fazer. Neste caso, foi uma das raras boas ideias ksksks

Quando digo "mais baixo nível do que C", eu digo:

Carla é pensado para ser apenas um "wrapper" de assembly. Ser o mais próximo e direto possível. Sem muitas abstrações. Apenas algumas de qualidade de vida, como disse.

Sobre -nostdlib, não. Teremos libs std bem trabalhadas.

já o __attribute__, depende. Teremos sim, os atributos do C, mas, de forma mais simples. Isso vai ser consequência da "qualidade de vida do Carla", exemplo:

int32 foo = () naked {
    return 2;
}

int32 main = () {
    return foo();
}

Em relação ao modelo de memória, Carla usará Arenas de memória combado com um defer para desalocação ao pop do escopo.

E sim, também será compatvel com alocação 100% manual, assim como Rust, Zig e C++ são.

string name = arena.alloc(128);
defer arena.dump(name);

-- resto do código

Sobre a performance de compilação, o Runa não faz muitas coisas. Ele é reponsável por adaptar a sintaxe do Assembly para a arquitetura ou assembler específico. Claro, que se o usuário quiser ele pode e deve delegar mais funções ao Runa. Mas nos extensors oficiais é o mínimo possível. Grande parte das coisas processadas em tempo de compilação estão dentro do core C++ do Morgana.

Até o momento não realizei benchmarks, mas tenho absoluta certeza que se o comptime ficar pior em um projeto pequeno, em um grande nunca será pior, o que ainda sim gera vantagem.

Além de que, nos meus testes de performance do Runa (que estes sim eu realizei), o Runa chegava ser até 3x mais rápido em algumas situações do que o Lua oficial. Depois trarei mais dados sobre isto.

Muito obrigado pelo review!

Edit. Sobre as docs, eu removi. Por que ainda não tenho a sintaxe 100% estabelecida. Alguns detalhes MINIMOS ainda estão sendo decididos. Tipo:

  • Devo usar parênteses no if?
  • Devo implementar tipagem "automatica" com auto como C++ ou let?
  • Em caso de ser um let, devo implementa-lo por padrão constante e permiti-lo ser mutável com mut tal como Rust?
  • Quando o tipo é definido em tempo de compilação, devo usar := ou mantenho = ?

Estes são alguns dos exemplos.

2

Legal demais a ideia de arena + defer.

Sobre auto, tenho sentimentos mistos. Ótimo quando o tipo está evidente no RHS, perigoso quando começa a esconder informação. Então talvez isso seja algo que a própria linguagem possa restringir melhor, não só deixar para “code standart". Sobre := vs =, eu tenderia a deixar explícito.

E sobre o “mais baixo nível que C” / “as good as Rust”: eu entendi melhor agora o que você quis dizer, mas eu tomaria bastante cuidado com essas frases. Como marketing elas são fortes, mas em comunidade técnica/científica o pessoal cobra é precisão.

C já é um wrapper para assembly. Mas muita coisa para controlar o binário gerado tipo alinhamento, seções, naked, freestanding fica espalhado entre atributos específicos do compilador, flags e convenções da toolchain. Então talvez a tese da Carla seja pegar essas coisas que em C são meio "escondidas" e tornar elas primitivas de primeira classe. E deixar isso claro para defender a alegação.

Carla tenta ser “mais baixo nível que C” porque torna explícito na linguagem controle que em C fica implícito na toolchain.

Sobre “Good as Rust”, eu evitaria essa formulação. “Good” é subjetivo demais e abre uma guerra religiosa desnecessária, tem gente que nem acha Rust bom rs (yours truly). Rust só é "bom" porque entrega segurança de memória sem GC.

Carla oferece segurança de memória por arenas e escopos sem trazer toda a complexidade do modelo de ownership do Rust.

Isso é uma promessa técnica bem mais precisa e talvez até mais interessante.

E a melhor dica que posso te dar: não subestime documentação. Não deixa para documentar só quando “a sintaxe estiver pronta”, porque linguagem nunca fica pronta (C++ está aí para provar). Vai deixando a documentação evoluir junto com a implementação. Mesmo que seja provisório, escreva design docs. No mínimo vão te ajudar a pensar melhor.

1

Ótimos colamentos sobre o "auto", levarei em consideração!

E sobre o “mais baixo nível que C” / “as good as Rust”: eu entendi melhor agora o que você quis dizer, mas eu tomaria bastante cuidado com essas frases. Como marketing elas são fortes, mas em comunidade técnica/científica o pessoal cobra é precisão.

Eu pretendo ainda mudar um pouco essa proposta para deixar mais clara, você não é a primeira que comentou sobre isto. E, vocês estão certos. é muito genérico. Não diz muito sobre a proposta da linguagem, e pode soar como a nomenclatura usada por você: "Marketing forte."

C já é um wrapper para assembly. Mas muita coisa para controlar o binário gerado tipo alinhamento, seções, naked, freestanding fica espalhado entre atributos específicos do compilador. [...]

Este é apenas um dos pontos que quero mudar. Eu não vejo por que termos structs que a ordem dos campos altera a quantidade de bytes ocupados na stack. Não vejo por que termos tanta abstração em cima de estruturas de dados. Tudo deve ser "raw" em Carla.

E, claro, mantendo a tão dita "qualidade de vida do Rust/C++".

Sobre “Good as Rust”, eu evitaria essa formulação. “Good” é subjetivo demais e abre uma guerra religiosa desnecessária, tem gente que nem acha Rust bom rs (yours truly). Rust só é "bom" porque entrega segurança de memória sem GC.

Na verdade, como dito, isso será mudado. Mas, o "Good as Rust" quer dizer:

Não te deixar ser burro tal como Rust. Segurança de memória implementada de forma nativa ao máximo possível, mas que não afetará a sua responsabilidade de "assegurar" a segurança do seu código. Tal como C++, por exemplo.

A oferta de alocadores customizados em Rust, e a simplicidade da criação destes alocadores também são algo que pretendo trazer par ao Carla.

E a melhor dica que posso te dar: não subestime documentação. Não deixa para documentar só quando “a sintaxe estiver pronta”, porque linguagem nunca fica pronta (C++ está aí para provar). Vai deixando a documentação evoluir junto com a implementação. Mesmo que seja provisório, escreva design docs. No mínimo vão te ajudar a pensar melhor.

Não irei. Ainda não esta implementada pelos motivos que eu te citei acima, mas ainda há mais um: O projeto está migrando da fase "imatura", para a fase "matura", agora. E isto não foi minha prioridade agora. Eu estava focado na compatibilidade com Windows até ontem.

Ainda não consegui distinguir quais pronomes usar para você, usei o feminino, peço desculpas caso não seja uma mulher. (O username me parece mais feminino)

1

Gostei muito dos extensors em Lua/Runa. Isso é uma ideia muito interessante porque transforma codegen em algo hackeável pela comunidade.

Só de curiosidade, vale dizer que o GCC e o Clang suportam plugins:

Ah, e meio que o -nostdlib é nativo de C porque a especificação determina os ambientes freestanding e hosted, onde freestanding não tem libc. Então já é nativo da especificação da linguagem um ambiente sem libc. Eu explico melhor isso aqui:

1

Sim, tenho ciência disto, e entendo que tenha feito uma correlação entre ambos. Então, esta minha resposta nem é muito direcioanda à ti, mas sim pessoas "de fora" que lerem isto:

A enorme diferneça entre os Plugins do GCC/Clang e os Extensors do Morgana, é:

Morgana não tem "comportamente padrão" quando se trata no codegen. Tudo é customizado.

GCC/Clang tem. Mas, coisas podem ser modificadas.

1

Acho que meu comentário foi interpretado errado. Eu estava respondendo isso:

[...] porque transforma codegen em algo hackeável pela comunidade.

Os plugins do GCC/Clang tornam codegen hackeável pela comunidade, não quis dizer que eram a mesma coisa que os Extensors no seu projeto.

Não entenda como uma crítica, mas sugiro observar qual comentário responde quem. Eu não estava falando com você, mas você respondeu como se eu estivesse.

Não é uma crítica, é só que se você achar que todo comentário no seu post é para você, você vai interpretar errado o comentário.