Qual linguagem de programação prática e não teórica não possui palavras-chave reservadas?

22

Eu tenho procurado por uma linguagem de programação prática que não tenha palavras-chave reservadas, mas não tive sorte em encontrar uma.

Estou trabalhando em uma linguagem de programação para minha própria edificação e entretenimento e ainda não precisei incluir nenhuma palavra-chave, foi isso que me levou à minha pesquisa e à pergunta:

Não vejo conveniência para o escritor do compilador como sendo importante para o usuário final do idioma. Os computadores são poderosos o suficiente nos dias de hoje para poder inferir significados do contexto. Assim como um escritor não precisa rotular substantivos, verbos e outros itens ao escrever um romance, por que um programador deve rotular funções e variáveis com function x() {}or set x = 1ou var x = 1etc; quando posso deduzir do contexto das declarações que é uma declaração de função ou uma invocação ou que um rótulo é uma atribuição a um valor ou uma referência a esse valor de rótulos?

Aqui está um exemplo concreto do que meu analisador atual está fazendo, sem necessidade de palavras-chave reservadas para suportar coisas comuns que normalmente teriam muito barulho, como funcou functionou decnão.

Declaração de Função

sum3(a,b,c) -> a + b + c.

Invocação de Função

x = sum3(1,2,3).

Função anônima nomeada x

x = (a,b,c) -> a + b + c.
y = x(1,2,3).

Gostaria de saber por que as palavras-chave são importantes para uma linguagem de programação bem-sucedida?

theory languages

8

Quarto é bastante prático e não possui nenhuma palavra-chave.

— SK-logic

4

@ JamesAnderson, não, são apenas palavras, o mesmo que todas as outras palavras. Nenhum significado especial.

— SK-logic

7

Os operadores e a pontuação contam como "palavra-chave"? se sim, nenhum idioma pode existir, pois nenhuma sintaxe pode ser definida.

— Emilio Garavaglia

2

@ SK-logic: normalmente. Mas o que são "identificadores" se você ainda não usa token? Como um token é "qualquer coisa que possa ser reconhecida", "int", "myvalue" e "+" não são diferentes, antes que uma regra de sintaxe fosse fornecida. Se "+" não estiver definido como operador, pode ser apenas um nome para algo como qualquer outra cadeia de caracteres únicos unicode. Os operadores, pelo ponto de vista da sintaxe pura, nada mais são do que "palavras-chave de caractere único".

— Emilio Garavaglia

2

Nesse contexto, o que é uma palavra-chave? É um identificador que tem um significado especial para o compilador? É um identificador que o programador não deve usar como variável ou algo assim? Será considerado sem palavras-chave se as palavras-chave tiverem de ser especialmente designadas? (Há muito tempo atrás eu vi um sistema ALGOL onde palavras-chave precisava ser cotado para ser palavras-chave.)

— David Thornley

12

O MUMPS é altamente bem-sucedido, sendo amplamente utilizado em seguros e assistência médica e não possui palavras reservadas. Eu diria que eles ajudam em termos de código mais claro, mas não são estritamente necessários. APL é outro exemplo. A APL vê o uso de scripts pontuais na indústria nuclear, entre outros. J , um membro da família APL também não possui palavras-chave.

As palavras-chave ajudam os escritores do compilador a implementar a análise mais facilmente. A APL é notoriamente associativa. Eles também ajudam a reforçar convenções e melhorar a legibilidade. O APL não é conhecido por ser extremamente legível para a maioria.

— Engenheiro Mundial
fonte

2

+1 em "Palavras-chave ajudam os escritores do compilador a implementar a análise mais facilmente". Eu acho que é isso mesmo. As palavras-chave foram inventadas para reduzir a quantidade de contexto que um analisador precisa manter na memória, quando o compilador inteiro e seu conjunto de trabalho precisavam caber em uma dúzia de KB de RAM.

— Jörg W Mittag

2

É mais fácil escrever um analisador para APL do que quase qualquer outro idioma! Considere que a primeira implementação de um intérprete de APL foi feita usando transistores e diodos.

— James Anderson

2

Acho que o principal motivo das palavras-chave é facilitar a análise mais fácil do idioma pelos humanos. Os computadores ficariam mais felizes se a linguagem consistisse inteiramente de números e padrões de bits, assim como seu código de máquina.

— James Anderson

6

O que falta ao APL nas palavras-chave, mais do que compensa ao exigir sua própria fonte.

— Blrfl

@Blrfl Esse é o ponto de J, K e Q. Eles são todos em um grau ou outro, APL em ASCII.

— World Engineer

9

Um idioma conhecido sem palavras-chave é Lisp. O que há de mais próximo das palavras-chave são as chamadas formas especiais - seu número pode variar entre os dialetos - que recebem tratamento especial do intérprete. Além disso, eles são indistinguíveis das funções regulares em termos de como são usados, com a exceção de que não podem ser redefinidos (pelo menos em Lisps eu estou familiarizado).

Isso resulta em uma sintaxe simples (mas pesada) e é uma das coisas que permitiram ao Lisp ter um sistema de macro tão poderoso. Por outro lado, costuma-se dizer que Lisp é difícil de ler. APL e MUMPS, mais ainda, já vi ambos descritos a meio caminho do Brainf * ck. As palavras-chave ajudam nesse departamento e tornam a leitura de código mais fácil para nós, humanos também.

Portanto, não diria que as palavras-chave são necessárias para um idioma bem-sucedido, mas elas certamente ajudam um idioma a ter sucesso.

— scrwtp
fonte

1

O IIRC Lisp não possui palavras-chave. As formas especiais devem ser tratadas especialmente pelo compilador, mas seus nomes são símbolos regulares.

— Jan Hudec

2

Palavras-chave são um recurso da sintaxe, que Lisp também não possui. Eu acho que nem faz sentido falar sobre palavras-chave no Lisp, na verdade.

— Jörg W Mittag

2

Eu concordo com o Jörg. Acho que se pode falar de palavras-chave quando um idioma tem tokens que devem ser definidos explicitamente como especiais para serem distinguidos dos tokens com uma estrutura semelhante. Tokens diferentes levam a diferentes árvores de sintaxe. Por exemplo, ifem C seria um identificador válido se não fosse definido como especial (uma palavra-chave). Isso significa que ifnão é um identificador e if = 10gera um erro de sintaxe. Se não me engano, a sintaxe mínima de Lisp não faz distinção defunde f, x, ye +no (defun f (x y) (+ x y)).

— Giorgio

@Giorgio notadamente if é um nome de variável válido em Common Lisp (e outros Lisp-2s) (defparameter if nil)não vai quebrar nada e ele pode ser usado em formas como(unless if (setf if t))

— tobyodavies

Na mesma nota, porém, (defun if ...)falhará. Levou em consideração as anotações dos comentários e editou a resposta. Posso concordar que formulários especiais não são palavras-chave no mesmo nível que em C, por exemplo, ainda são a coisa mais próxima que o Lisp tem.

— scrwtp

8

O TCL não possui palavras-chave e, de fato, apenas 12 regras de sintaxe. Embora não seja tão popular como era antes, ele tem seu nicho de expectativa e está incorporado no ECAD e nos roteadores, por isso certamente conta como uma prática para mim.

Também acho que pode mostrar por que muitos idiomas não seguem esse caminho. Sim, é perfeitamente possível escrever um analisador TCL (sem dúvida mais fácil do que muitos outros idiomas), no entanto, você não pode escrever uma gramática BNF muito útil para o idioma e muitas pessoas parecem ter problemas para aprender o idioma. Eu suspeito que isso seja pelo menos em parte devido à falta de palavras-chave.

— jk.
fonte

2

Tcl é muito semelhante ao Lisp nesse aspecto, exceto que em vez de "tudo é uma lista", ele tem "tudo é uma string". Uma lista é apenas uma string com espaços em branco e uma chamada de procedimento é apenas uma lista cujo primeiro elemento é interpretado como o nome de um procedimento e o restante é interpretado como seus argumentos. Isso é essencialmente uma Expressão S Lisp.

— Jörg W Mittag

sim, ambos usam notação polonesa e são homo-icônicos, portanto, têm semânticas bastante semelhantes

— jk.

5

Os computadores são poderosos o suficiente nos dias de hoje para poder inferir significados do contexto.

Isso significa que você deseja uma gramática que não seja livre de contexto? Boa sorte.

Não se trata de ser poderoso ou não. Existem regras eternas e imutáveis sobre as línguas - as matemáticas. Isso e o fato de uma linguagem de programação ser sintaticamente fácil fará com que os CFGs governem nas próximas décadas.

Aliás, em Haskell como sintaxe, basta escrever algo como

f x y = (x+1)*(y-1)

para definir uma função. Mas observe que a "palavra-chave" neste caso é o '='. Se você errar, coisas terríveis acontecerão no analisador.

Mas este é um ponto em que concordo com você; acho isso muito mais intuitivo do que todas as palavras-chave def, dcl, fun, fn, function ou outras palavras-chave que introduzem funções em outros idiomas.

No entanto, essa gramática pode ser escrita na antiga LALR (1), nenhum significado é "inferido a partir do contexto" aqui.

— Ingo
fonte

1

+1 para abordar esta afirmação (os computadores são poderosos o suficiente nos dias de hoje para poder inferir significados do contexto). Penso que a razão pela qual as gramáticas do CFG são preferidas é que elas permitem que a estrutura do programa seja definida indutivamente. Não vejo por que alguém gostaria de mudar isso, mesmo em 100 anos, talvez só me falta imaginação?

— Giorgio

2

Os CFGs estão bastante mortos e estavam mortos há décadas. JavaScript dentro de HTML, mesmo as seqüências de formato C dentro de C, e até comentários aninhados em, digamos, OCaml - tudo isso não é livre de contexto. E, por que você quer se restringir a um formalismo escolhido tão arbitrário, agora, na era do PEG e GLR?

— SK-logic

1

@ Ingo, sim, você está certo, uma escolha errada de exemplo. Eu quis dizer gramáticas mistas e extensíveis (de alta ordem), que não são CFG.

— SK-logic

2

@ SK-logic: Eu não sei onde você conseguiu as informações de que os CFGs estão bastante mortos. Conversei com um ex-colega meu que ensina a construção de compiladores nos últimos 20 anos e os CFGs parecem estar longe de morrer.

— Giorgio

1

@ Ingo: Tanto quanto me lembro, os aspectos não CF são tratados posteriormente, analisando a árvore de análise semanticamente. Por exemplo, { int x = 0; x = "HELLO"; }deve produzir uma árvore de análise, mas quando o compilador procura x na segunda atribuição, ele vê que foi declarado como int e emite um erro de tipo. Portanto, o programa é rejeitado, mesmo que sua estrutura de CF esteja correta.

— Giorgio

4

Até onde eu sei, Smalltalk é o idioma que tem menos palavras-chave (se eu não estiver contando idiomas como Brainfuck). Smalltalk palavras-chave são true, false, nil, self, supere thisContext.

Eu projetei um idioma, inspirado em smalltalk, que não tinha palavras-chave. Mas, após algum tempo de uso, acabei adicionando algumas palavras-chave, principalmente para açúcar sintático.

Portanto, minha opinião é que o idioma sem palavras-chave é possível, mas não é muito prático e é por isso que todos os idiomas populares têm palavras-chave.

— del-boy
fonte

Se o Smalltalk tivesse suporte para o envio de mensagens com um receptor implícito, pelo menos true, falsee nilpoderia ser definido como métodos nesse receptor implícito e, dadas as capacidades de reflexão, provavelmente os outros três também.

— Jörg W Mittag

1

Essas não são palavras-chave, são pseudovariáveis. "Pseudo" porque true, falsee nilsão valores conhecidos fornecidos pelo ambiente e self, supere thisContextsão variáveis que você não pode definir, mas cujos valores mudam como resultado da execução.

— precisa saber é o seguinte

3

Você parece estar trabalhando sob uma suposição falsa, de que as palavras-chave existem para facilitar as coisas para o compilador. Enquanto eles facilitam as coisas para o compilador, eles têm um benefício muito mais importante: facilitam as coisas para quem lê o código .

Sim, você pode olhar para um monte de contexto e descobrir que está vendo uma declaração de função ou uma declaração de variável, mas dependendo do contexto e da complexidade do código envolvido, isso pode levar muito tempo para descobrir . Ou então, você pode ter uma palavra-chave útil, como function ou var , e saber imediatamente o que está vendo.

Sim, eles tornam o código mais complicado de escrever , mas considerando que os programas gastam muito mais tempo em manutenção do que em produção e que o código é lido, depurado e mantido muito mais do que é criado, tentando projetar seu idioma para tornar mais fácil escrever em vez de fácil ler é um caso clássico de otimização prematura prejudicial.

Além disso, não despreze os conceitos que facilitam o trabalho do compilador. Quanto mais fácil é analisar, mais rápido seu código será compilado, o que significa que os ciclos de edição, construção e depuração ficam mais rápidos, o que significa que sua produtividade aumenta.

Quando você tem uma base de código grande e complexa, isso pode resultar em uma diferença não trivial de produtividade. Por exemplo, onde trabalho, temos um programa em funcionamento que é de cerca de 4 milhões de linhas de Delphi. Temos outro módulo que é cerca de 300.000 linhas de C ++. Ambos levam aproximadamente o mesmo período de tempo para compilar. (Cerca de 3 minutos.) Se tivéssemos 4 milhões de linhas de C ++, levaria uma hora para construir!

— Mason Wheeler
fonte

Todos excelentes pontos. 1

se cada substantivo, verbo, advérbio e adjetivo de um romance fosse rotulado como tal, tornaria MAIS DIFÍCIL ler mais fácil!

@JarrodRoberson: Claro, sim, mas o código não é um romance. Linguagens naturais são muito diferentes das linguagens de programação. A linguagem natural é entendida intuitivamente, enquanto uma linguagem de programação possui semântica formal. As técnicas usadas para ler e entender o significado são muito diferentes, e é um erro tentar igualar as duas como você.

— Mason Wheeler

Eu disse que o compilador é diferente do compilador . Compiladores ficam mais rápidos em hardware mais rápido, escritores de compiladores são humanos, não aderimos à Lei de Moore!

as bases de código com as quais eu costumo trabalhar são ordens de magnitude maiores que os romances, a maioria tem mais de 1.000.000 de linhas de código, a maioria dos romances mais longos tem menos de 2.000.000 de palavras ! E, como os romances, eles são lidos por seres humanos, na verdade, é gasto mais tempo lendo o código do que escrevendo! Dada uma base de código com mais de 10 anos e mais de 1.000.000 de linhas, o número de vezes que é lido por desenvolvedores com mais de 10 anos diminui o tempo que levou para criar.

2

Existem alguns exemplos raros.

O APL usa apenas símbolos - mas muitos! Você precisa de um teclado especial para usar o idioma.

Veja este artigo da Wikipedia

CORAL 66 - tinha palavras-chave, mas só as reconheceu se citadas com aspas simples.

O PL / 1 também tinha palavras-chave - mas você também pode usá-las como nomes de variáveis ou procedimentos.

Em suma, sua pergunta é como perguntar "por que as línguas faladas têm palavras?".

— James Anderson
fonte

Só para acrescentar que, se você gosta da aparência do APL, mas não quer comprar um novo teclado, J é o ideal.

— AakashM

0

A principal razão é que é mais fácil analisar humanos e computadores. Desambiguar uma linguagem complexa sem palavras-chave exigiria muitos símbolos como sintaxe, e seria massiva e desnecessariamente confusa. É muito mais fácil ler do functionque $!{}. E o contexto não resolve todas as ambiguidades.

— DeadMG
fonte

1

Penso que a palavra-chave na sua resposta é complexa , uma linguagem suficientemente projetada deve ser simples , não complexa .

1

@Jarrod Roberson: Leonardo da Vinci: "A simplicidade é a sofisticação máxima", Antoine de Saint Exupéry: "Parece que a perfeição é alcançada não quando não há mais nada a acrescentar, mas quando não há mais o que tirar".

— Giorgio

1

@ Jarrod: Todas as linguagens de computador expressivamente significativas são complexas.

— 91313 DeadMG

1

@DeadMG: O esquema é muito simples e ao mesmo tempo muito expressivo. Infelizmente, até onde eu sei, falta uma biblioteca padronizada.

— Giorgio

Erlang é muito expressivo e não é complexo sintaticamente. Acho que todas as linguagens funcionais acabam sendo mais expressivas com palavras-chave menos reservadas.