Definição rigorosa de açúcar sintático? [fechadas]

Parece que nas guerras sagradas do idioma, as pessoas constantemente denegrem qualquer recurso que não consideram particularmente útil como sendo "apenas açúcar sintático". A linha entre "características reais" e "açúcar sintático" tende a ficar confusa nesses debates. O que você acha que é uma definição razoável e inequívoca de açúcar sintático que evita que seja definido como qualquer recurso que o falante / escritor não considere útil?

Que tal isso: "o açúcar sintático é uma abreviação de conveniência para algumas funcionalidades que não introduzem nenhuma camada significativa de abstração".

Pegue a->b, o que, como você aponta, é equivalente a (*a).b. Essa notação permite que você considere o código de alguma maneira útil e oculta? Não, então é açúcar sintático.

Agora considere a[i] == *(a + i). Pense em qualquer programa C que use matrizes de maneira substantiva. Você pode imaginar tentando compreendê-lo sem a []notação? Com matrizes multidimensionais? É significativo considerar matrizes como unidades inteiras, não como uma referência ao início de um bloco de memória contíguo. Embora seja útil saber como as matrizes funcionam em C se você planeja fazer coisas complicadas com elas, é improdutivo sempre pensar: "Preciso armazenar os dois bits de memória 2 * i bytes à direita do local de memória referenciado por a". O ponto principal de uma matriz é a capacidade de abstrair o processo de armazenamento de uma sequência como uma unidade coerente. A []notação facilita essa abstração. É não açúcar sintático.

Isso não significa que o açúcar sintático seja sempre uma coisa ruim. Como muitas aliterações, tornou-se um epíteto e se opõe a "características reais". Mas LISP e Scheme, por exemplo, seriam ilegíveis se não fosse a letabreviação (e outros).

O operador ternário,, <pred> ? <cnsq> : <alt>é outro exemplo. O açúcar sintático pode ajudar a organizar programas e remover código redundante, o que pode economizar na manutenção. Às vezes, o açúcar sintático pode ser preferível a acumular "recursos reais" se ajudar a remover barreiras sintáticas à programação.

Para citar R ^ 5RS , "As linguagens de programação devem ser projetadas não empilhando recursos em cima de recursos, mas removendo os pontos fracos e restrições que tornam necessários recursos adicionais". IMHO, a sintaxe pode ser considerada uma fraqueza e restrição e, assim, permitir que os programadores se afastem da sintaxe pode aumentar a expressividade de uma linguagem.

IMHO Acho que você não pode definir o açúcar sintático, porque a frase é BS e provavelmente será usada por pessoas que falam de "programadores reais" usando "ferramentas reais" em "sistemas operacionais reais"

É BS, porque a idéia de "características reais" ou "açúcar sintático" é como a falácia verdadeira do escocês . Na medida em que as frases são "tentativas ad hoc de reter uma afirmação irracional". A afirmação aqui é que um recurso aqui é trivial porque você poderia usar um "recurso real".

É BS porque alguns argumentam que o uso de açúcar deve ser evitado, porque você pode escrever um bug, mas deve cumpri-lo porque é mais difícil escrever erros. Isso não é incrível? A mesma frase leva a conclusões exatamente opostas, usando a mesma lógica.

É BS porque ninguém cita estudos de usabilidade ou estudos de contagem de defeitos, para respaldar sua legibilidade ou manutenção ou prováveis ​​argumentos de defeito.

É BS porque as pessoas geralmente estão erradas ou se enganam sobre a equivalência. Por exemplo, esta pergunta afirma que uma string C # é açúcar para uma matriz de caracteres. Eles não são .

No entanto, se você quiser dizer, duas coisas são açúcar, se forem semanticamente equivalentes, e isso ajuda a definir o que você quiser.

Se você quer desprezar alguém, também pode usar a frase.

Aqui está uma definição muito rigorosa para um conceito relacionado: expressividade , de
Matthias Felleisen:

Sobre o poder expressivo das linguagens de programação [O Postscript era a única forma gratuita que eu conseguia encontrar.]

Veja também esta entrada na linguagem Java e nos fechamentos .

Efetivamente, algo é açúcar sintático se puder ser alterado para um formulário sem a sintaxe, fazendo apenas alterações locais. Se, por exemplo, sem a forma sintática, você precisaria alterar vários locais de código diferentes ou mover fragmentos para outros locais, então não é açúcar.

Dito isto, o açúcar sintático é bom quando usado adequadamente. Eu acho que qualquer programador de esquema prefere que exista uma letforma especial do que ter que criar uma nova função anônima e aplicá-la, o que faria a mesma coisa. O objetivo é tornar o código mais claro.

Penso que o termo açúcar sintático indica uma sintaxe alternativa para expressar a mesma semântica subjacente.

Tomemos, por exemplo, uma linguagem de programação A que possui uma operação sumque pode adicionar uma lista de números inteiros de comprimento arbitrário. Nesta linguagem, podemos escrever as expressões

sum []
sum [3, 4, 5, 1]
sum [2, 7]

cujos resultados são 0, 13 e 9, respectivamente.

Agora, suponha que percebemos que 90% das vezes usamos sumcom dois argumentos e, portanto, introduzimos, por conveniência, a nova notação

2 + 7

que é apenas açúcar sintático para sum [2, 7].

Agora pegue um segundo idioma B que não tenha nenhuma operação adicional. Podemos ter operadores como <, =nos permitindo comparar números, mas não há como adicionar números. No release 2 do idioma B, introduzimos uma nova operação de adição com sintaxe

2 + 7

que adiciona números como de costume.

No contexto da linguagem A, a +notação é açúcar sintático (é uma notação alternativa, simplificada e ad-hoc que pode ser usada no lugar da sum [...]notação). Da mesma forma, como foi apontado na resposta de Hoa Long Tam, em C a notação p->fieldé para açúcar sintático (*p).field.

No contexto da linguagem B, a +notação não é um açúcar sintático (é a única sintaxe válida usada para a operação de soma). Da mesma forma, se C pudesse acessar apenas os membros da estrutura por meio de ponteiros e se não tivesse a notação (*p).field, a notação p->fieldnão seria açúcar sintático.

Na minha opinião, existem alguns mal-entendidos sobre o açúcar sintático que podem ser rastreados até uma confusão em relação à semântica da linguagem de programação. O raciocínio é assim:

• A semântica de um programa é o que um programa calcula.
• O poder expressivo de uma linguagem de programação é representado pelos cálculos que podem ser descritos nessa linguagem.
• Duas linguagens de programação que podem descrever todas as funções computáveis ​​(conforme definidas usando máquinas de Turing) têm a mesma potência expressiva ...
• ... e, portanto, diferem apenas na sintaxe.
• Corolário: qualquer extensão de um idioma completo de Turing é apenas sintaxe (açúcar sintático) porque você não altera o poder expressivo do idioma.

A linha de raciocínio acima leva a afirmações genéricas como "o açúcar sintático não pode ser definido adequadamente", é uma "questão de gosto" ou "todo recurso de linguagem de programação é, afinal, apenas açúcar sintático".

Eu acho que o principal problema no argumento acima é que a semântica não é apenas sobre o que pode ser calculado por um programa, mas também sobre como ele é calculado , ou seja, quais construções primitivas são usadas e como elas são combinadas.

Assim, por exemplo, os objetos não são um açúcar sintático para as configurações e transformações de bits subjacentes, são uma construção que permite modelar dados e operações e descrever cálculos. Computar com objetos, métodos, chamadas de método não é o mesmo que computar com bytes, registradores de processador, endereços de memória (mesmo que os dois cálculos tenham o mesmo resultado e mesmo que o segundo cálculo seja usado para implementar o primeiro).

Fiz essa descrição um pouco longo, mas acho que é um aspecto importante que não vi abordado em outras respostas.

Conclusão: o açúcar sintático é uma sintaxe alternativa (possivelmente mais conveniente) para uma construção que já está em um idioma e que já possui uma sintaxe e semântica bem definidas. A nova sintaxe (açúcar sintático) difere da existente, mas tem a mesma semântica . Se você introduzir uma nova construção em um idioma e uma nova sintaxe para ele, não terá açúcar sintático.

o açúcar sintático é um recurso que não estende a expressividade da linguagem em si, sendo redundante e, às vezes, um abuso de notação, mas que simplifica a vida do escritor e fornece ao leitor mais informações.

Para responder à minha própria pergunta, um recurso é o açúcar sintático, se e somente se foi incluído principalmente para melhorar a estética e a legibilidade, e pode ser traduzido trivialmente, de maneira aproximada e individual, na versão sem açúcar. (Por aproximadamente um para um, refiro-me a coisas triviais modulares, como a ordem das operações comutativas, nomes de variáveis ​​e espaços em branco.)

Qualquer recurso que só pudesse ser retirado de açúcar com uma quantidade significativa de disciplina de programador não é um açúcar sintático. Como um subconjunto disso, qualquer recurso que aumente a segurança de tipos não é um açúcar sintático, pois impor manualmente a segurança de tipos por meio da disciplina do programador é altamente não trivial. Por exemplo, o sistema de objetos do C ++ é mais do que açúcar sintático em cima do polimorfismo de conversão do ponteiro C.

Qualquer recurso que exija duplicação significativa de código ou uma reformulação importante se removido não é um açúcar sintático, pois nenhum deles é uma tarefa trivial. Por exemplo, modelos não são apenas açúcar sintático, porque obter a funcionalidade equivalente sem eles exigiria toneladas de clonagem e modificação.

Exemplo de coisas que são açúcar sintático:

a[i] ao invés de *(a + i)

a -> b ao invés de (*a).b

foreach sintaxe em vez de digitar manualmente a sintaxe do iterador.

Toda sobrecarga do operador é puro açúcar sintático.

Isso soa como uma definição justa e razoavelmente inequívoca?

"Açúcar sintático" não é um termo rigorosamente definido. Dependendo de quem você perguntar, provavelmente obterá um dos seguintes tipos de definições:

1. Nenhuma verdadeira abordagem escocesa. As coisas que eu gosto são de programação real e as coisas que eu não gosto são de açúcar sintático.
2. Tudo depois do MIPS era açúcar sintático, e mesmo algumas dessas instruções provavelmente não são necessárias.
3. Qualquer coisa que facilite a programação para alguém em algum lugar é útil e não um açúcar sintático. Como um recurso não teria sido adicionado se ninguém o considerasse útil em nenhuma circunstância, segue-se que todos os recursos existentes não são açúcar sintático. Recursos hipotéticos podem ser açúcar sintático, até que alguém decida que esse recurso é útil para eles.

Não tenho certeza sobre os campos das ciências da computação, mas com o campo da lógica existem os conceitos de conservadoridade e eliminabilidade de definições [ 1 ] que parecem estar na mesma linha.

Aplicando a correspondência de Curry-Howard, pode-se chegar a um conceito paralelo sobre "açúcar sintático".