ti-enxame.com

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

Parece que na linguagem guerras sagradas, as pessoas constantemente denigram qualquer característica que não acham particularmente úteis como sendo "apenas de açúcar sintático". A linha entre "características reais" e "açúcar sintático" tende a ficar desfocado nesses debates. O que você acredita ser uma definição razoável e inequívoca do açúcar sintático que a evita ser definida como qualquer recurso que o orador/escritor não acha útil?

9
dsimcha

Que tal isso: "Açúcar sintático é uma taquigrafia de conveniência para alguma funcionalidade que não introduza qualquer camada significativa de abstração".

Tome a->b, Que, como você aponta, é equivalente a (*a).b. Essa notação permite que você considere o código que está em qualquer maneira útil, caso contrário oculta? Não, por isso é o açúcar sintático.

Agora considere a[i] == *(a + i). Pense em qualquer programa C que usa matrizes de forma substantiva. Você pode imaginar tentando compreendê-lo sem a notação []? Com matrizes multidimensionais? É significativo considerar matrizes como unidades inteiras, não como referência ao início de um bloco contíguo de memória. Embora ajude a saber como os arrays funcionam em C Se você está pensando em fazer coisas complicadas com eles, é improdutivo sempre ter que pensar "Eu preciso armazenar os dois pedaços de memória 2 * i bytes à direita do Localização de memória referenciada por a. " O ponto inteiro de uma matriz é a capacidade de resumir o processo de armazenar uma sequência como uma unidade coerente. O [] A notação facilita essa abstração. É não açúcar sintático.

Isso não é para implicar que o açúcar sintático é sempre ruim. Como muitas aliterações, tornou-se um epíteto e caroço contra "características reais". Mas lisp e esquema, por exemplo, seriam ilegíveis se não para o let taquigrafia (e outros).

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

Para citar R ^ 5RS , "Idiomas de programação devem ser projetados não embocando o recurso no topo do recurso, mas removendo as fraquezas e restrições que fazem recursos adicionais parecem necessários." IMHO, a sintaxe pode se qualificar como uma fraqueza e restrição e, portanto, os programadores se afastam da sintaxe podem Aumentar A expressividade de uma linguagem.

19
Hoa Long Tam

Aqui está a muito Definição rigorosa para um conceito relacionado: expressividade , por
[.____] Matthias Felleisen:

sobre o poder expressivo das linguagens de programação [PostScript foi a única forma livre que eu poderia encontrar.]

Veja também esta entrada em o Java idioma e fechamentos .

Efetivamente, algo é o açúcar sintático se ele puder ser alterado para um formulário sem a sintaxe apenas fazendo alterações locais. Se, por exemplo, sem o formulário sintático, 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 esquema preferiria haver uma forma especial let do que para criar uma nova função anônima e, em seguida, aplicá-la, o que faria a mesma coisa. O objetivo é tornar o código mais claro.

7
Macneil

IMHO Eu não acho que você pode ter uma definição para o açúcar sintático, porque a frase é BS e é provável que seja usado por pessoas que falam sobre "programadores reais" usando "Ferramentas reais" em "sistemas operacionais reais" em "sistemas operacionais reais"

Seu BS porque a ideia de "características reais" ou "açúcar sintático" é como o nenhum verdadeiro escocês falácia . Em que as frases são "AD HOC tenta reter uma afirmação irracional". A afirmação aqui é que um recurso aqui é trivial porque você poderia usar um "recurso real" em vez disso.

Seu BS porque alguns argumentam o uso de açúcar devem ser evitados Porque você pode escrever um bug, mas você deve ficar com ele Porque é mais difícil escrever bugs. Não é incrível. A mesma frase leva a conclusões exatamente opostas usando a mesma lógica.

Seu BS, porque ninguém cita estudos de usabilidade ou estudos de contagem de defeitos, para fazer backup de sua legibilidade ou manutenção ou provável defeito argumentos.

Seu BS porque as pessoas geralmente estão erradas ou se tornam erradas sobre a equivalência. Por exemplo esta pergunta afirma que um string C # é açúcar para uma matriz de caractere. eles não são .

No entanto, se você quiser dizer que duas coisas são açúcares se forem equivalentes semanticamente e que ajude a ir em frente e defini-lo de qualquer maneira desejada.

Se você quer ser desdenhoso de alguém, você também pode usar a frase.

7
Conrad Frix

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

  1. Nenhuma verdadeira abordagem escocês. Coisas que eu gosto são de programação real, e coisas que eu não gosto são de açúcar sintático.
  2. Tudo após MIPS foi o açúcar sintático, e até mesmo algumas dessas instruções provavelmente não são necessárias.
  3. Qualquer coisa que faça programação mais fácil para alguém em algum lugar é útil e não sintático açúcar. Como um recurso não teria sido adicionado se ninguém achasse útil em qualquer circunstância, segue-se que cada recurso existente não é o açúcar sintético. Recursos hipotéticos podem ser açúcar sintáticos, até que alguém decida esse recurso seja útil para eles.
0
Patrick87

o açúcar sintático é um recurso que não prolonga a própria expressividade da linguagem, sendo, portanto, redundante e, às vezes, um abuso de notação, mas tanto simplifique a vida do escritor quanto a leitor mais insight.

0
Lorenzo Stella

Para responder à minha própria pergunta, um recurso é o açúcar sintático se e somente se ele foi incluído principalmente para melhorar a estética e a legibilidade e pode ser traduzido trivialmente em uma moda aproximadamente um para um versão açucarada. (Por mais ou menos um-para-um, quero dizer coisas triviais como a ordem de operações comutativas, nomes variáveis ​​e espaço em branco.)

Qualquer característica que só poderia ser de açucarado com uma quantidade significativa de disciplina de programador não é o açúcar sintético. Como um subconjunto disso, qualquer recurso que aumenta a segurança do tipo não é o açúcar sintático, uma vez que a segurança manual de segurança via disciplina programadora é altamente não-trivial. Por exemplo, o sistema de objetos de C++ é mais do que o açúcar sintático em cima do polimorfismo fundido de ponteiro C.

Qualquer recurso que exija uma duplicação de código significativa ou um grande redesenho se removido não for o açúcar sintático, já que nenhum deles é uma empresa trivial. Por exemplo, modelos não são apenas açúcar sintáticos porque obter a funcionalidade equivalente sem eles exigiriam toneladas de clone e modify.

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

a[i] Em vez de *(a + i)

a -> b Em vez 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?

0
dsimcha