Como faço para escrever uma especificação de linguagem de programação?

Eu realmente gosto de design de linguagem de programação. Às vezes, acho que meus projetos de idiomas e seus usuários em potencial se beneficiariam de um documento abrangente sobre padrões. Examinei muitos padrões de linguagem, desde o formal (C ++) até o informal (ECMAScript), mas não consigo entender como devo resolver as coisas e organizar esse documento, mesmo que eu acho que sou muito bom em redação técnica em geral.

Devo escrever como um longo tutorial ou mais como um trabalho formal de matemática? Como faço para mantê-lo atualizado se estou desenvolvendo-o juntamente com uma implementação de referência? Devo simplesmente desistir e tratar a implementação e a documentação como o padrão de fato? Além disso, existe realmente algum benefício significativo em ter um padrão? A exigência de um padrão significa que o idioma é desnecessariamente complexo?

Eu achei a especificação da linguagem Java formal e legível, e acho que ela tem uma estrutura sensata. Algumas das especificações do W3C também podem ser bons exemplos.

Fazer o trabalho formal pode ajudar a manter a complexidade do idioma baixa e ver os casos extremos.

Despejo cerebral de cabeçalhos: codificação de origem, lexing, tipos fundamentais, literais, operadores, expressões, declarações simples, condicionais, loops, funções (definições e chamadas), declarações de tipo, módulos, unidades de compilação, escopo variável, vários tipos de resolução de nomes (por exemplo, importações, métodos), modelo de memória, efeitos colaterais, digitação, simultaneidade…

Leia lotes e mantenha-o simples

Projetar um novo idioma é difícil. Muito difícil. Mas, no final das contas, é muito satisfatório se tornar popular e realmente resolver um problema que as pessoas estão enfrentando de maneira elegante.

Como mencionei nos comentários, recomendo que você leia os Idiomas Específicos do Domínio de Martin Fowler pelos seguintes motivos:

1. Ele tem muita profundidade prática sobre por que você deve criar uma linguagem
2. Há detalhes sobre como fazê-lo (analisadores, analisadores lexicais, bancadas de idiomas etc.)
3. Existem instruções detalhadas de implementação sobre como a sintaxe escolhida pode ser feita para lidar com conceitos como fechamentos, anotações, listas literais, recepção dinâmica etc.

Quanto a como escrever sua especificação, pense no seu público. Obviamente, antes de colocar o dedo no teclado para projetar seu idioma, você terá pensado cuidadosamente sobre o que ele pretende fazer.

Se for uma linguagem nova e interpretada para substituir o JavaScript, você precisará de uma abordagem muito laissez faire para alcançar os desenvolvedores da Web com um tempo de atenção limitado e um desejo de resultados imediatos - ou mais rápido, se possível.

Se ele for usado na próxima missão para Titan, então especificações extremamente detalhadas mostrando provas formais exatas do comportamento de cada componente serão o nível mínimo de entrada.

Portanto, não é uma coisa simples. Para abordar a especificação, provavelmente seria melhor ganhar muita experiência na criação de seus idiomas e também trabalhar com aqueles que realmente os usam no dia a dia. Se você tem vítimas dispostas ... er ... desenvolvedores, no trabalho, que podem levar algum tempo para aprender seu idioma, eles podem dar um feedback sobre o que é necessário para fazê-los usá-lo.

Em resumo, mantenha-o simples e mais pessoas o usarão.

A Wirth projetou e implementou muitas linguagens de programação: dentre estas, as especificações para as linguagens Oberon e Oberon2 são notáveis ​​por sua integridade, concisão e legibilidade.

Common Lisp e Haskell têm padrões de linguagem. Ruby e Python têm implementações e documentação. Então, eu diria que um padrão de linguagem não é necessário, mas pode ser útil se você espera que haja mais de uma implementação da linguagem que você está projetando. Por outro lado, um padrão é prematuro se você espera mudanças significativas na sua definição de idioma.

qualquer especificação deve ser concisa e capaz de resistir ao teste do tempo

é por isso que você vê uma abstração como o BNF usada para muitos padrões de linguagem ... é concisa e ainda será entendida muito tempo depois que muitas das nossas ferramentas atuais forem deixadas para trás.

é claro que há mais do que apenas uma gramática. veja o que os outros fizeram ... perl6, schema, C ... eles abordam questões com as quais o implementador também se importa.