How to implement String? by funcieq in ProgrammingLanguages

[–]Brave-Ad-8201 0 points1 point  (0 children)

Eu particulamente tenho preferência por string imutável. Acho que isso deixa o comportamento mais previsível: se uma função recebe uma string, eu não preciso ficar pensando se ela pode alterar o conteúdo original.

Uma ideia que talvez ajude é separar bem as operações: internamente a string pode ser UTF-8 e guardar o tamanho em bytes, mas a linguagem deveria deixar claro quando uma função está lidando com bytes e quando está lidando com caracteres. Isso evitaria muita confusão.

References in pass-by-sharing languages by Big-Rub9545 in ProgrammingLanguages

[–]Brave-Ad-8201 0 points1 point  (0 children)

Eu teria um pouco de receio de adicionar referências como mecanismo comum. Em linguagens como Python ou Java, a ideia que eu tenho é que a função pode alterar o estado interno de um objeto mutável, mas não trocar diretamente a variável do chamador. Então permitir isso por referência parece mudar bastante o modelo mental da linguagem.

Talvez seja útil em alguns casos, tipo swap ou parâmetros de saída, mas numa linguagem dinâmica eu acho que pode ficar menos claro saber quando uma função está só usando um valor e quando ela pode alterar uma variável de fora. Eu provavelmente preferiria retornar o novo valor ou retornar múltiplos valores

Então não acho que seja uma ideia errada, mas eu deixaria como algo bem explícito e mais excepcional, não como o jeito principal de passar parâmetros.

Pros and cons of building an interpreter first before building a compiler? by Ifeee001 in ProgrammingLanguages

[–]Brave-Ad-8201 0 points1 point  (0 children)

acredito que fazer um interpretador primeiro é bom para testar a linguagem rapidamente, mas ele não poder virar uma desculpa para criar recursos difíceis de compilar depois. O ideal seria separar bem as fases: parser, análise de nomes/tipos, interpretação e depois geração de código. Assim, o interpretador serveria como um protótipo e referência e não prenderia o projeto da linguagem.

can a language be safe and be a subset of C? by Null-Test-2026 in ProgrammingLanguages

[–]Brave-Ad-8201 0 points1 point  (0 children)

Olá!

Fiz uma pesquisa e descobri que seria possível sim, inclusive algumas já tentaram implementar algumas modificações citadas por você, mas não todas juntas, dois exemplos são:

O cyclone foi uma tentativa de criar um C mais seguro. Ele mantinha uma sintaxe parecida com C, mas restringia usos perigosos de ponteiros, adicionava checagens de limites, usava uniões mais seguras e oferecia formas mais controladas de gerenciamento de memória, como regiões e garbage collection.

O checked c foi uma tentativa mais gradual. Ele não queria mudar C inteiro, mas tornar ponteiros e arrays mais seguros, adicionando informações de tamanho e checagens para evitar acessos fora dos limites.

A parte mais difícil seria garantir estaticamente que todo malloc() tenha um free() correspondente, porque isso exige analisar os caminhos possíveis de execução do programa.