Nova linguagem de programação

[Vinícius dos Santos Oliveira]

Esse ano comecei a desenvolver uma nova linguagem de programação
sucessora de C++. Gostaria de convidar quaisquer membros do grupo que
tenham interesse numa empreitada assim a se juntar a mim. O projeto
ainda está bem no começo (só terminei o parser e estou fazendo o
sistema de tipos agora, mas já brinquei com o codegen pra testar a API
do LLVM também, e já deu pra ter uma ideia do quanto falta pro projeto
ficar pronto), e é a hora perfeita pra você dar pitaco nas bases
fundamentais da linguagem.

Só pra saber se a visão que tenho pro projeto se alinha com algo com o
qual você gostaria de contribuir, o restante desse email seguirá um
estilo de “rant”.

Rust está roubando o mercado de C/C++. Os efeitos colaterais são:

* Abrir mão de todo o ecossistema existente de software. Suponha que
queiramos reescrever o LLVM em Rust, por exemplo. Seria o
empreendimento mais burro do mundo. O software poderia estar escrito
em Rust, mas você não trouxe o capital intelectual para Rust. Qualquer
IA (que não pensa) seria capaz de fazer essa reescrita. Porém você não
poderia expandir o software com novas ideias se você não trouxer junto
o capital intelectual. A grande massa de Rust não tem interesse em
atrair capital intelectual porque acha que a linguagem vale mais do
que os anos de árduo suor por trás de quem faz software.

* A comunidade desaprendeu a fazer segurança. Acham que segurança se
resume a fazer software memory-safe. Eu não tenho saco pra entrar num
debate com alguém que acha que segurança termina em memory safety.
Rust não protege de backdoors, por exemplo. Todos esses ataques de
supply chain que vimos acontecer com NodeJS nas últimas semanas irão
acontecer em Rust também. O problema nem vai ser os ataques existirem
em si, mas a imaturidade da comunidade Rust em lidar com segurança e o
*desinteresse* em aprender qualquer coisa sobre tal. Vão ficar tipo
peixe fora d'água se debatendo só esperando a morte.

A Google está tentando lançar Carbonlang pra resolver o problema de
manter e ecossistema de C++ usável, porém é frustrante ver qualquer
entrevista com os devs de Carbonlang. Eles vão se limitar a copiar o
que Rust faz quando for a hora de adicionar segurança. Há formas
melhores de manter uso do ecossistema legado enquanto mantém a
segurança do sistema como um todo (e performance). Eu gastei 4 anos de
minha vida com pesquisa e desenvolvimento de sandboxes em diversos
sistemas. Os desenvolvedores do FreeBSD, por ex., mudaram várias
coisas do sistema frente a análise e pedidos que fiz. Eu posso afirmar
que mecanismos de segurança atuais ainda estão em sua infância. É
possível fazer jurisdições entre módulos de um sistema de forma muito
mais interessante (ex.: mesmo que um dos módulos esteja sob posse de
um hacker, nenhum dado de seu sistema irá vazar). Estou trocando uma
ideia com pesquisadores do tema de capabilities há algumas meses e
isso está me dando ideias do como bolar uma solução ainda melhor do
que eu conseguiria sozinho.

O parser, que já está pronto, rouba a sintaxe de Carbonlang (o que
eles fazem bem, não há porque evitar). O repositório não tem muita
informação atualmente, mas já tem código funcional pra vários
subsistemas de um compilador: https://gitlab.com/emilua/asiobg

Fico disponível pra tirar dúvidas e explicar o projeto.

[Thiago Adams]

Em 23/09/2025 19:26, Vinícius dos Santos Oliveira escreveu:
> Esse ano comecei a desenvolver uma nova linguagem de programação
> sucessora de C++. Gostaria de convidar quaisquer membros do grupo que
> tenham interesse numa empreitada assim a se juntar a mim. O projeto
> ainda está bem no começo (só terminei o parser e estou fazendo o
> sistema de tipos agora, mas já brinquei com o codegen pra testar a API
> do LLVM também, e já deu pra ter uma ideia do quanto falta pro projeto
> ficar pronto), e é a hora perfeita pra você dar pitaco nas bases
> fundamentais da linguagem.

Legal, desejo que a motivação continue por muito tempo!
Tenho interesse em fazer um IR e backend, ou C89-- backend.

> Só pra saber se a visão que tenho pro projeto se alinha com algo com o
> qual você gostaria de contribuir, o restante desse email seguirá um
> estilo de “rant”.
>
> Rust está roubando o mercado de C/C++. Os efeitos colaterais são:
>
> * Abrir mão de todo o ecossistema existente de software. Suponha que
> queiramos reescrever o LLVM em Rust, por exemplo. Seria o
> empreendimento mais burro do mundo. O software poderia estar escrito
> em Rust, mas você não trouxe o capital intelectual para Rust. Qualquer
> IA (que não pensa) seria capaz de fazer essa reescrita. Porém você não
> poderia expandir o software com novas ideias se você não trouxer junto
> o capital intelectual. A grande massa de Rust não tem interesse em
> atrair capital intelectual porque acha que a linguagem vale mais do
> que os anos de árduo suor por trás de quem faz software.

O rust usa o LLVM. daria para reescrever, mas acho que nao existe
motivacao para isso.

> * A comunidade desaprendeu a fazer segurança. Acham que segurança se
> resume a fazer software memory-safe. Eu não tenho saco pra entrar num
> debate com alguém que acha que segurança termina em memory safety.
> Rust não protege de backdoors, por exemplo. Todos esses ataques de
> supply chain que vimos acontecer com NodeJS nas últimas semanas irão
> acontecer em Rust também. O problema nem vai ser os ataques existirem
> em si, mas a imaturidade da comunidade Rust em lidar com segurança e o
> *desinteresse* em aprender qualquer coisa sobre tal. Vão ficar tipo
> peixe fora d'água se debatendo só esperando a morte.

na minha visao tudo que pode ser mais seguro , deve ser. mas o que nao
da para abrir

mao eh poder fazer "unsafe " se preciso.

>
> A Google está tentando lançar Carbonlang pra resolver o problema de
> manter e ecossistema de C++ usável, porém é frustrante ver qualquer
> entrevista com os devs de Carbonlang. Eles vão se limitar a copiar o

Iniciou como um c++ diferente e nao se achou. (diferente do go, que na
minha opniao

tinha uma meta mais definida)

> que Rust faz quando for a hora de adicionar segurança. Há formas
> melhores de manter uso do ecossistema legado enquanto mantém a
> segurança do sistema como um todo (e performance). Eu gastei 4 anos de
> minha vida com pesquisa e desenvolvimento de sandboxes em diversos
> sistemas. Os desenvolvedores do FreeBSD, por ex., mudaram várias
> coisas do sistema frente a análise e pedidos que fiz. Eu posso afirmar
> que mecanismos de segurança atuais ainda estão em sua infância. É
> possível fazer jurisdições entre módulos de um sistema de forma muito
> mais interessante (ex.: mesmo que um dos módulos esteja sob posse de
> um hacker, nenhum dado de seu sistema irá vazar). Estou trocando uma
> ideia com pesquisadores do tema de capabilities há algumas meses e
> isso está me dando ideias do como bolar uma solução ainda melhor do
> que eu conseguiria sozinho.

Nao tem como aplicar as ideias em C or C++?

> O parser, que já está pronto, rouba a sintaxe de Carbonlang (o que
> eles fazem bem, não há porque evitar). O repositório não tem muita
> informação atualmente, mas já tem código funcional pra vários
> subsistemas de um compilador: https://gitlab.com/emilua/asiobg
>
> Fico disponível pra tirar dúvidas e explicar o projeto.

Olhando pelo site achei bem difícil entender o projeto.

Nao parece ser uma linguagem não achei a descrição classica esperada

de uma linguagem com exemplos.

[Vinícius dos Santos Oliveira]

Em ter., 23 de set. de 2025 às 21:57, Thiago Adams
<thiago...@gmail.com> escreveu:

> Legal, desejo que a motivação continue por muito tempo!
> Tenho interesse em fazer um IR e backend, ou C89-- backend.

Sua IR vai ser SSA ou CPS? LLVM usa SSA pra IR, mas alguns projetos
acabam introduzindo uma “segunda IR” (assim como Rust mesmo[1]), e
essas “segundas IRs” não precisam ser SSA, mesmo que a IR final do
LLVM o seja. Ainda estou estudando o assunto, e gostaria de ouvir
opiniões. O que já deu pra perceber, é que uma IR intermediária assim
como Rust adota vale a pena.

> > Abrir mão de todo o ecossistema existente de software [...] você não

> > poderia expandir o software com novas ideias se você não trouxer junto
> > o capital intelectual. A grande massa de Rust não tem interesse em
> > atrair capital intelectual porque acha que a linguagem vale mais do
> > que os anos de árduo suor por trás de quem faz software.
>
> O rust usa o LLVM. daria para reescrever, mas acho que nao existe
> motivacao para isso.

Teve treta com os devs do ffmpeg também, que foi apenas mais um dos
casos do modus operandi dessa comunidade:
https://news.itsfoss.com/ffmpeg-swipe-at-rust/

Em vez de pagar ao dev que ficou anos estudando processamento de
sinais, teoria da informação, estatística, e tudo o que é necessário
pra implementar um codec, pagam um aluno de faculdade que olha pra um
código em C/C++ e reescreve em Rust sem ter a menor ideia do que o
código por trás está fazendo (seja a versão C/C++ seja a versão Rust).

E o pior é que mesmo usando o conjunto safe, você não tem nenhuma das
promessas da linguagem: https://github.com/Speykious/cve-rs

> na minha visao tudo que pode ser mais seguro , deve ser. mas o que nao
> da para abrir
> mao eh poder fazer "unsafe " se preciso.

É como um kernel vai funcionar, por exemplo. Para alguns projetos,
unsafe é necessário. Rust na verdade acertou em permitir unsafe na
tentativa de bibliotecas que usam unsafe pra encapsular padrões safe
que o compilador não pode provar.

> > A Google está tentando lançar Carbonlang pra resolver o problema de
> > manter e ecossistema de C++ usável, porém é frustrante ver qualquer
> > entrevista com os devs de Carbonlang. Eles vão se limitar a copiar o
>
> Iniciou como um c++ diferente e nao se achou. (diferente do go, que na
> minha opniao
> tinha uma meta mais definida)

Porém há coisas boas em Carbonlang. Tô pegando tudo que é bom. Zero
necessidade de ter orgulho e rejeitar onde acertaram. A ideia de fazer
ponteiros não-nulos por padrão pra que eles se comportem como
referências e aí chamar funções que recebem referência exigirem que
você explicite o uso de uma chamada por referência elimina 99% das
complexidades de entender qual função vai ser chamada em cenário X.

Dito isso, não basta parar aí. Tem que buscar mais simplificação.
C++26 vai estar aí com reflexão, e é só o começo. Já no anúncio do
Herb Sutter divulgando que que reflexão havia sido votada pra entrar
no padrão, foi mencionado que o próximo passo é “token injection”:

>In the future we’ll also get token injection to generate C++ source right within the same source file
-- https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meeting-sofia-bulgaria/

C++ tá ficando cada vez mais complexo. Toda versão trás novas
ferramentas de metaprogramação. Pra dominar metaprogramação em C++,
você primeiro se pergunta: em qual nível de metaprogramação vou agir?
Tem Boost.PP, Boost.VMD, Boost.MP11, Boost.Describe, Boost.Hana,
constexpr no C++23 que consegue entender meus usos de metaprogramação
sem reclamar, e reflection do C++26. E vai ter o próximo C++ depois do
26 que em algum momento vai permitir “token injection”.

Usando um design clean-slate, é possível você colapsar *todas* essas
camadas de metaprogramação em uma única camada de metaprogramação (e
inclusive ter o “token generation” que é mencionado no post do Herb
Sutter). Isso enquanto mantém o estilo de programação que já é
familiar pro código do dia-a-dia, como é o caso com constexpr. O
primeiro blog post que farei será sobre esse tema, Pratt parsers (e
higiene de macros em Lisp).

> > [...] manter uso do ecossistema legado enquanto mantém a
> > segurança do sistema como um todo [...]

>
> Nao tem como aplicar as ideias em C or C++?

Eu apliquei em Lua. Essa é uma demo que fiz pra turma com a qual tenho
me encontrado pra discutir segurança:
https://www.youtube.com/watch?v=anu-onpDMBc

Também dá pra aplicar em C/C++, mas se estou fazendo uma linguagem pra
ser compatível com C/C++ (assim como Carbonlang), o ecossistema já não
está garantido? Apesar de ter feito muito, não consegui aplicar ainda
tudo que eu queria porque eu não tinha controle sobre a implementação
de Lualang. Controlar o tooling te dá liberdade pra fazer mais coisas.
Pra dar exemplos concretos, essas são duas mudanças que pedi pro povo
da glibc e do FreeBSD:

* https://sourceware.org/bugzilla/show_bug.cgi?id=32509
* https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283528

Sem essas mudanças, fica muito difícil fazer código “C/C++ portável”
que implemente camadas de compatibilidade pra código antigo (que não
foi escrito pensado em capabilities) rodar dentro de sandboxes de
capabilities. Se eu faço código pra linking dinâmico, falha caso a
pessoa use linking estático (e vice-versa). Bolei umas gambiarras, mas
há limites. A solução (em C/C++), é escrever código *fora* de C/C++
(isto é, scripts de linking, por ex.). E isso é muito básico. Dá pra
fazer coisa *muito* mais interessante do que já consegui fazer até
então, mas só se a gente partir pra ter controle do tooling (por ex.
em uma linguagem nova, mesmo a linguagem nova seja compatível com o
ecossistema de C/C++).

Teve um bug que encontrei na libstdc++ e na libc++. Correção: mover a
ordem de duas linhas. Situação do LLVM: corrigiram na mesma semana.
Situação do GCC: anos e anos e nada de aplicar minha patch. Deferir
tudo pros mantenedores dos projetos open source mais acima cria esse
tipo de fricção e atrasa demais uma solução.

> Olhando pelo site achei bem difícil entender o projeto.
> Nao parece ser uma linguagem não achei a descrição classica esperada
> de uma linguagem com exemplos.

Vou trabalhar nisso depois que estiver gerando executáveis úteis. O
projeto tá em bem early stage, e estou explicando aqui antes de outros
cantos. Próximo mês mando outro email pra cá avisando do progresso.

[Thiago Adams]

On 9/24/2025 12:21 AM, Vinícius dos Santos Oliveira wrote:
> Em ter., 23 de set. de 2025 às 21:57, Thiago Adams
> <thiago...@gmail.com> escreveu:
>> Legal, desejo que a motivação continue por muito tempo!
>> Tenho interesse em fazer um IR e backend, ou C89-- backend.
> Sua IR vai ser SSA ou CPS? LLVM usa SSA pra IR, mas alguns projetos
> acabam introduzindo uma “segunda IR” (assim como Rust mesmo[1]), e
> essas “segundas IRs” não precisam ser SSA, mesmo que a IR final do
> LLVM o seja. Ainda estou estudando o assunto, e gostaria de ouvir
> opiniões. O que já deu pra perceber, é que uma IR intermediária assim
> como Rust adota vale a pena.

Eu estou pensando no backend direto.  O "IR" não tão intermediário.
O intermediário seria C89 -- ou algo tipo gnu assembler.
Estou mais inclinado para C89--.

>>> Abrir mão de todo o ecossistema existente de software [...] você não
>>> poderia expandir o software com novas ideias se você não trouxer junto
>>> o capital intelectual. A grande massa de Rust não tem interesse em
>>> atrair capital intelectual porque acha que a linguagem vale mais do
>>> que os anos de árduo suor por trás de quem faz software.
>> O rust usa o LLVM. daria para reescrever, mas acho que nao existe
>> motivacao para isso.
> Teve treta com os devs do ffmpeg também, que foi apenas mais um dos
> casos do modus operandi dessa comunidade:
> https://news.itsfoss.com/ffmpeg-swipe-at-rust/
>
> Em vez de pagar ao dev que ficou anos estudando processamento de
> sinais, teoria da informação, estatística, e tudo o que é necessário
> pra implementar um codec, pagam um aluno de faculdade que olha pra um
> código em C/C++ e reescreve em Rust sem ter a menor ideia do que o
> código por trás está fazendo (seja a versão C/C++ seja a versão Rust).
>
> E o pior é que mesmo usando o conjunto safe, você não tem nenhuma das
> promessas da linguagem: https://github.com/Speykious/cve-rs
>
>> na minha visao tudo que pode ser mais seguro , deve ser. mas o que nao
>> da para abrir
>> mao eh poder fazer "unsafe " se preciso.
> É como um kernel vai funcionar, por exemplo. Para alguns projetos,
> unsafe é necessário. Rust na verdade acertou em permitir unsafe na
> tentativa de bibliotecas que usam unsafe pra encapsular padrões safe
> que o compilador não pode provar.

Tudo é política e a política vai direcionar o investimento de dinheiro
tempo.
Cada um tem uma visão diferente. A propaganda do Rust é forte e já
influenciou muitas empresas como MS.

>>> A Google está tentando lançar Carbonlang pra resolver o problema de
>>> manter e ecossistema de C++ usável, porém é frustrante ver qualquer
>>> entrevista com os devs de Carbonlang. Eles vão se limitar a copiar o
>> Iniciou como um c++ diferente e nao se achou. (diferente do go, que na
>> minha opniao
>> tinha uma meta mais definida)
> Porém há coisas boas em Carbonlang. Tô pegando tudo que é bom. Zero
> necessidade de ter orgulho e rejeitar onde acertaram. A ideia de fazer
> ponteiros não-nulos por padrão pra que eles se comportem como
> referências e aí chamar funções que recebem referência exigirem que
> você explicite o uso de uma chamada por referência elimina 99% das
> complexidades de entender qual função vai ser chamada em cenário X.

Eu não me importo muito com sintaxe e não gosto de linguagem aonde a
propaganda é justamente isso.

Eu tenho um analisador estático para C, que tem o conceito de nullable
pointers.
É mais uma peça deste quebra-cabeças.
Tenho interesse na segurança via análise estática.

> Dito isso, não basta parar aí. Tem que buscar mais simplificação.
> C++26 vai estar aí com reflexão, e é só o começo. Já no anúncio do
> Herb Sutter divulgando que que reflexão havia sido votada pra entrar
> no padrão, foi mencionado que o próximo passo é “token injection”:
>
>> In the future we’ll also get token injection to generate C++ source right within the same source file
> -- https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meeting-sofia-bulgaria/
>
> C++ tá ficando cada vez mais complexo. Toda versão trás novas
> ferramentas de metaprogramação. Pra dominar metaprogramação em C++,
> você primeiro se pergunta: em qual nível de metaprogramação vou agir?
> Tem Boost.PP, Boost.VMD, Boost.MP11, Boost.Describe, Boost.Hana,
> constexpr no C++23 que consegue entender meus usos de metaprogramação
> sem reclamar, e reflection do C++26. E vai ter o próximo C++ depois do
> 26 que em algum momento vai permitir “token injection”.
>
> Usando um design clean-slate, é possível você colapsar *todas* essas
> camadas de metaprogramação em uma única camada de metaprogramação (e
> inclusive ter o “token generation” que é mencionado no post do Herb
> Sutter). Isso enquanto mantém o estilo de programação que já é
> familiar pro código do dia-a-dia, como é o caso com constexpr. O
> primeiro blog post que farei será sobre esse tema, Pratt parsers (e
> higiene de macros em Lisp).

Acho que a reflection foi uma péssima ideia para C++.

>>> [...] manter uso do ecossistema legado enquanto mantém a
>>> segurança do sistema como um todo [...]
>> Nao tem como aplicar as ideias em C or C++?
> Eu apliquei em Lua. Essa é uma demo que fiz pra turma com a qual tenho
> me encontrado pra discutir segurança:
> https://www.youtube.com/watch?v=anu-onpDMBc

Lua é interpretado que segurança a mais se quer?
O que é preciso no caso de linguagem interpretada seria
isolar mais do SO (como é o caso do browser JS e WASI)

Em resumo, não sei se os nossos interesses de backend se alinham, mas
estou pensando em ter um gerador de "executáveis" a partir de uma input
que poderia ser C89-- ou algo como um gnu Assembler. Um dos meus
critérios é algo que já exista para poder comparar e até poder usar
backend já testado antigo etc. Não sei se você conhece este projeto?
https://c9x.me/compile/ Se este QBE gerasse código diretamente e fosse
windows, linux talvez alinhasse com o que eu queria.

[Vinícius dos Santos Oliveira]

Em qua., 24 de set. de 2025 às 08:43, Thiago Adams
<thiago...@gmail.com> escreveu:

> On 9/24/2025 12:21 AM, Vinícius dos Santos Oliveira wrote:
> > Em ter., 23 de set. de 2025 às 21:57, Thiago Adams
> > <thiago...@gmail.com> escreveu:
> >> Legal, desejo que a motivação continue por muito tempo!
> >> Tenho interesse em fazer um IR e backend, ou C89-- backend.
> > Sua IR vai ser SSA ou CPS? LLVM usa SSA pra IR, mas alguns projetos
> > acabam introduzindo uma “segunda IR” (assim como Rust mesmo[1]), e
> > essas “segundas IRs” não precisam ser SSA, mesmo que a IR final do
> > LLVM o seja. Ainda estou estudando o assunto, e gostaria de ouvir
> > opiniões. O que já deu pra perceber, é que uma IR intermediária assim
> > como Rust adota vale a pena.
>
> Eu estou pensando no backend direto. O "IR" não tão intermediário.
> O intermediário seria C89 -- ou algo tipo gnu assembler.
> Estou mais inclinado para C89--.

Existem motivos pelos quais utilizamos IRs como o LLVM (um tipo de
SSA). Toda literatura de passes de otimização usa essas coisas. Você
gerar assembler “direto” vai lhe prejudicar mais do que ajudar. Usar
C89 como intermediário vai lhe deixar preso no tipo de coisa que C já
é bom em expressar. Qual a vantagem então?

> É mais uma peça deste quebra-cabeças.
> Tenho interesse na segurança via análise estática.

O que você acha de reference capabilities[1]? A minha ideia é usar
isso como base pra um sistema maior que sirva pra descrever os
domínios de segurança dentro de uma aplicação (verificado/assegurado
em compile-time), e usar capabilities pra assegurar que essas
proteções sejam respeitadas em runtime.

> >>> [...] manter uso do ecossistema legado enquanto mantém a
> >>> segurança do sistema como um todo [...]
> >> Nao tem como aplicar as ideias em C or C++?
> > Eu apliquei em Lua. Essa é uma demo que fiz pra turma com a qual tenho
> > me encontrado pra discutir segurança:
> > https://www.youtube.com/watch?v=anu-onpDMBc
>
> Lua é interpretado que segurança a mais se quer?
> O que é preciso no caso de linguagem interpretada seria
> isolar mais do SO (como é o caso do browser JS e WASI)

LuaJIT tem um módulo FFI que lhe permite acessar qualquer biblioteca
de C. No exemplo, eu mostrei sandboxing de media parsing (envolvendo
Qt e media codecs) e de uma aplicação extensível que pode executar
código de não confiáveis enquanto seu sistema permanece seguro
(cooperação sob suspeita mútua).

Dê uma lida nisso:
<https://www.cs.cmu.edu/~aldrich/papers/ecoop17modules.pdf>. É o mesmo
problema, e o paper é bom pra *descrever* o problema. A solução não
serve pra C/C++, mas é por isso que vou fazer uma solução diferente.

> Não sei se você conhece este projeto?
> https://c9x.me/compile/ Se este QBE gerasse código diretamente e fosse
> windows, linux talvez alinhasse com o que eu queria.

QBE é toy tool pra quem tem preguiça de estudar LLVM. Não tô
interessado em segundo lugar no pódio, e não vou usar toy tool. Meu
convite é pra participar de projeto que vai ficar em primeiro lugar, e
não pra tomar atalhos. Diretamente da homepage do QBE, logo no
primeiro parágrafo, pra não dizer que estou interpretando errado a
filosofia do projeto:

> aims to provide 70% of the performance of industrial optimizing compilers in 10% of the code

Eles próprios assumem que são projeto pra ficar em segundo lugar por preguiça.

Tenho zero interesse em QBE.

[1] https://tutorial.ponylang.io/reference-capabilities/reference-capabilities

[Thiago Adams]

On 9/24/2025 1:01 PM, Vinícius dos Santos Oliveira wrote:
> Em qua., 24 de set. de 2025 às 08:43, Thiago Adams
> <thiago...@gmail.com> escreveu:
>> On 9/24/2025 12:21 AM, Vinícius dos Santos Oliveira wrote:
>>> Em ter., 23 de set. de 2025 às 21:57, Thiago Adams
>>> <thiago...@gmail.com> escreveu:
>>>> Legal, desejo que a motivação continue por muito tempo!
>>>> Tenho interesse em fazer um IR e backend, ou C89-- backend.
>>> Sua IR vai ser SSA ou CPS? LLVM usa SSA pra IR, mas alguns projetos
>>> acabam introduzindo uma “segunda IR” (assim como Rust mesmo[1]), e
>>> essas “segundas IRs” não precisam ser SSA, mesmo que a IR final do
>>> LLVM o seja. Ainda estou estudando o assunto, e gostaria de ouvir
>>> opiniões. O que já deu pra perceber, é que uma IR intermediária assim
>>> como Rust adota vale a pena.
>> Eu estou pensando no backend direto. O "IR" não tão intermediário.
>> O intermediário seria C89 -- ou algo tipo gnu assembler.
>> Estou mais inclinado para C89--.
> Existem motivos pelos quais utilizamos IRs como o LLVM (um tipo de
> SSA). Toda literatura de passes de otimização usa essas coisas. Você
> gerar assembler “direto” vai lhe prejudicar mais do que ajudar. Usar
> C89 como intermediário vai lhe deixar preso no tipo de coisa que C já
> é bom em expressar. Qual a vantagem então?

Concordo, mas é preciso ir por partes. Na minha opinião, a geração do
executável,
mesmo sem otimizações, é mais importante do que ter otimizações e não gerar
o executável. A menos que se queira depender do LLVM, o que não é o meu
caso.
Também toda a parte de entender a parte dos registradores etc. ABI.

>> É mais uma peça deste quebra-cabeças.
>> Tenho interesse na segurança via análise estática.
> O que você acha de reference capabilities[1]? A minha ideia é usar
> isso como base pra um sistema maior que sirva pra descrever os
> domínios de segurança dentro de uma aplicação (verificado/assegurado
> em compile-time), e usar capabilities pra assegurar que essas
> proteções sejam respeitadas em runtime.

O meu foco é static analysis por enquanto.

>
>>>>> [...] manter uso do ecossistema legado enquanto mantém a
>>>>> segurança do sistema como um todo [...]
>>>> Nao tem como aplicar as ideias em C or C++?
>>> Eu apliquei em Lua. Essa é uma demo que fiz pra turma com a qual tenho
>>> me encontrado pra discutir segurança:
>>> https://www.youtube.com/watch?v=anu-onpDMBc
>> Lua é interpretado que segurança a mais se quer?
>> O que é preciso no caso de linguagem interpretada seria
>> isolar mais do SO (como é o caso do browser JS e WASI)
> LuaJIT tem um módulo FFI que lhe permite acessar qualquer biblioteca
> de C. No exemplo, eu mostrei sandboxing de media parsing (envolvendo
> Qt e media codecs) e de uma aplicação extensível que pode executar
> código de não confiáveis enquanto seu sistema permanece seguro
> (cooperação sob suspeita mútua).

"qualquer biblioteca de C" - este é o problema teria que ser um sandbox.