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?
Respostas:
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 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:
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".