Quelle est la différence entre "Syntax" et "Syntactic Sugar"
Contexte
La page Wikipedia sur Sucre syntaxique déclare:
En informatique, le sucre syntaxique est la syntaxe d'un langage de programmation conçu pour faciliter la lecture ou l'expression. Cela rend le langage "plus doux" pour les humains: les choses peuvent être exprimées plus clairement, plus concis ou dans un style alternatif que certains préfèrent.
Je ne comprends pas vraiment quelle est la différence entre Syntactic Sugar et Syntax.
J'apprécie le fait que la version sucrée peut être plus claire, plus concise, peut-être faire bouillir un passe-partout. Mais je pense qu'à un certain niveau, toute la syntaxe fait essentiellement cela pour former une abstraction sur ce à quoi le code est compilé.
De la même page Wikipédia:
Les processeurs de langage, y compris les compilateurs, les analyseurs statiques et similaires, développent souvent les constructions sucrées en constructions plus fondamentales avant le traitement, un processus parfois appelé "désuchage".
Comme exercice de réflexion, si je prends "souvent" dans cette déclaration pour signifier "toujours": si la différence était juste de savoir si le compilateur "désugar" la syntaxe avant de passer à une étape suivante, comment un codeur qui ne connaît pas les entrailles du compilateur sait (ou fait attention) qu'est-ce que la syntaxe Sugar'd ou non?
Une question très connexe sur ce site "" Définition rigoureuse du sucre syntaxique? " a une réponse qui commence:
À mon humble avis, je ne pense pas que vous puissiez avoir une définition du sucre syntaxique, car l'expression est BS et est susceptible d'être utilisée par des gens qui parlent de "vrais programmeurs" utilisant de "vrais outils" sur de "vrais systèmes d'exploitation"
Ce qui pourrait m'indiquer qu'il n'y a peut-être pas de différence énorme entre le codeur utilisant la langue? Peut-être que la différence n'est perceptible que par le rédacteur du compilateur? Bien qu'il puisse y avoir des cas dans lesquels il est utile que le codeur utilise le langage pour savoir ce qui est sous le capot du sucre syntaxique? (Mais peut-être qu'en réalité, tout discours sur le sujet a tendance à utiliser le terme comme appât à flamme?)
Le cœur de la question
Alors ... la version courte de la question:
- Y a-t-il une vraie différence entre Syntax et Syntactic Sugar?
- Pour qui est-ce important?
Supplément de réflexion
Bonus sur la contradiction du sujet:
Sur la page Wikipedia un exemple est donné:
Par exemple, dans le langage C, la notation
a[i]Est un sucre syntaxique pour*(a + i)
Alors qu'un autre réponse sur la question liée ci-dessus parle du même exemple:
Considérons maintenant
a[i] == *(a + i). Pensez à tout programme C qui utilise des tableaux de manière substantielle.
Et résume que:
La notation
[]Facilite cette abstraction. Ce n'est pas du sucre syntaxique.
La conclusion inverse pour le même exemple!
La principale différence est que la syntaxe est une grammaire définie dans un langage pour vous permettre d'exposer certaines fonctionnalités. Dès que vous pouvez accéder à cette fonctionnalité, toute syntaxe autre qui vous permet de faire la même chose est considérée comme du sucre. Cela se heurte bien sûr à des scénarios étranges sur lequel des deux syntaxes est le sucre, d'autant plus qu'il n'est pas toujours clair qui est venu en premier.
Dans la pratique, le sucre syntaxique est uniquement utilisé pour décrire la syntaxe ajoutée à un langage pour faciliter la facilité d'utilisation, comme faire infixe lhs + rhs Mapper à lhs.Add(rhs). Je considérerais l'indexation de tableaux de C comme du sucre syntaxique.
Cela importe surtout parce que les designs élégants ont tendance à limiter la quantité de duplication. Le besoin (ou du moins le fait de vouloir) de sucre syntaxique est considéré par certains comme le signe d'un échec de conception.
La syntaxe est ce qu'un processeur de langage utilise pour comprendre ce que signifient les constructions d'un langage. Les constructions qui sont considérées comme du sucre syntaxique doivent également être interprétées par le processeur de langage et font donc partie d'une syntaxe de langage.
Ce qui distingue le sucre syntaxique du reste de la syntaxe d'une langue, c'est qu'il serait possible de supprimer le sucre syntaxique de la langue sans affecter les programmes qui peuvent être écrits dans la langue.
Pour donner une définition plus formaliste, je dirais
Le sucre syntaxique sont les parties de la syntaxe d'une langue dont les effets sont définis en termes d'autres constructions syntaxiques dans la langue.
Ceci n'est nullement destiné à dénigrer le sucre syntaxique, ou les langages qui en contiennent, car l'utilisation du sucre syntaxique conduit souvent à des programmes dont l'intention est plus compréhensible.
Les autres réponses n'ont pas mentionné de concept clé: syntaxe abstraite; sans lui, le terme "sucre syntaxique" n'a aucun sens.
La syntaxe abstraite définit les éléments et la structure des langues, et comment les expressions de cette langue peuvent être combinées pour créer des expressions plus grandes. La syntaxe abstraite est indépendante de la syntaxe concrète. Le terme "sucre syntaxique", si je comprends bien, fait référence à une syntaxe concrète.
En général, lors de la conception d'un langage, vous souhaiterez créer une syntaxe concrète pour chaque terme de votre syntaxe abstraite, afin que les gens puissent écrire du code dans votre langue en utilisant du texte brut.
Supposons maintenant que vous créez une syntaxe concrète maladroite pour foo . Les utilisateurs se plaignent et vous implémentez une nouvelle syntaxe concrète pour représenter la même syntaxe abstraite. Le résultat est que votre syntaxe abstraite et votre sémantique n'ont pas changé, mais vous avez maintenant deux syntaxes concrètes pour le même terme de syntaxe abstraite.
C'est, je crois, ce que les gens veulent dire quand ils disent "sucre syntaxique" - des changements qui n'affectent que la syntaxe concrète, mais qui n'affectent pas la syntaxe abstraite ou la sémantique.
Et donc la différence entre "sucre syntaxique" et "syntaxe concrète" est maintenant claire. Tome. :)
Cette interprétation aide également à expliquer ce qu'Alan Perlis aurait pu signifier quand il a dit que "le sucre syntaxique cause le cancer du point-virgule": tout le sucre syntaxique concret dans le monde ne peut pas fixer une syntaxe abstraite faible, et tous les efforts que vous consacrez à ajouter ce sucre sont effort que vous ne dépensez pas pour résoudre le vrai problème - la syntaxe abstraite.
Je dois également noter que ce n'est que mon opinion; Je ne le crois que parce que c'est la seule interprétation à laquelle je peux penser qui a du sens pour moi.
Le sucre syntaxique est un sous-ensemble de la syntaxe des langues. L'idée de base est qu'il y a plus d'une façon de dire la même chose.
Ce qui le rend difficile pour dire quels morceaux sont du sucre syntaxique et quels morceaux sont "de la syntaxe pure" sont des déclarations comme "il est difficile de dire quelle forme est venue en premier" ou "il est difficile de savoir de quelle manière l'auteur de le langage prévu "ou" il est quelque peu arbitraire de décider quelle forme est la plus simple ".
Ce qui fait qu'il est facile de décider quels morceaux sont purs ou sucrés, c'est de poser la question dans le cadre d'un compilateur ou d'un interprète spécifique. La syntaxe pure est la substance qu'un compilateur convertit directement en code machine ou à laquelle l'interprète répond directement. Le sucre est la substance qui est d'abord transformée en une autre substance de syntaxe avant que ces choses directes ne se produisent. Selon l'implémentation, cela peut ou non être le même que ce que l'auteur a voulu ou même ce que la spécification de langue prétend.
Dans la pratique, c'est ainsi que se décide la réalité de l'affaire.
Le sucre de syntaxe est généralement la partie du langage qui peut être exprimée par une partie existante du langage (syntaxe) sans perte de généralité mais avec une perte de clarté possible. Parfois, les compilateurs ont une étape de désagrégation explicite qui transforme le AST créé par le code source et applique des étapes simples pour supprimer les nœuds correspondant au sucre.
Par exemple, Haskell a du sucre de syntaxe pour les monades avec les règles suivantes appliquées de manière récursive
do { f } ~> f
do { g; h } ~> g >> do h
do { x <- f; h } ~> f >>= \x -> do h
do { let x = f; h } ~> let x = f in do h
Pour l'instant, peu importe ce que cela signifie exactement - cependant vous pouvez voir que la syntaxe spéciale sur LHS peut être transformée en quelque chose de plus basique sur RHS (à savoir les applications de fonction, les lambdas et les let). Cette étape permet de garder le meilleur des deux mondes:
- La syntaxe sur LHS est plus facile pour le programmeur (sucre syntaxique) exprimant les idées existantes de manière plus claire
- Cependant, comme le support dans le compilateur pour les constructions RHS existe déjà dans le compilateur, il n'a pas besoin de le traiter comme quelque chose de spécial en dehors de l'analyseur et du désagrégation (sauf pour le rapport d'erreurs).
De même en C, vous pouvez imaginer une règle de réécriture désucréante (en raison de la surcharge de l'opérateur, etc., ce n'est pas vrai pour C++):
f->h ~> (*f).h
f[h] ~> *(f + h)
Vous pourriez imaginer écrire tous les programmes sans utiliser -> ou [] en C qui utilisent cette construction aujourd'hui. Cependant, il serait plus difficile pour les programmeurs de l'utiliser, d'où le sucre de syntaxe fourni (je suppose que dans les années 70, cela pourrait également simplifier le travail des compilateurs). C'est peut-être moins clair car vous pouvez techniquement ajouter la règle de réécriture suivante, parfaitement valide:
*f ~> f[0] -- * and [] have the same expressiveness
Le sucre de syntaxe est-il mauvais? Pas nécessairement - il y a un risque qu'il soit utilisé comme culte du fret sans comprendre une signification plus profonde. Par exemple, les fonctions suivantes sont équivalentes dans Haskell, mais de nombreux débutants écriraient le premier formulaire sans comprendre qu'ils utilisent trop le sucre de syntaxe:
f1 = do x <- doSomething
return x
f2 = doSomething
De plus, le sucre de syntaxe peut compliquer la langue de manière excessive ou être trop étroit pour permettre un code idiomatique généralisé. Cela peut également signifier que le langage n'est pas assez puissant pour faire certaines choses facilement - cela peut être par conception (ne donnez pas aux développeurs des outils pointus ou un langage de niche très spécifique que l'ajout d'une construction plus puissante nuirait à d'autres objectifs) ou par omission - ce dernier forme a donné le sucre de syntaxe le mauvais nom. Si le langage est suffisamment puissant pour utiliser d'autres constructions sans ajouter de sucre de syntaxe, il est considéré comme plus élégant de les utiliser.
Je pense que l'exemple le plus évident serait la syntaxe "+ =" en C.
i = i + 1;
et
i += 1;
faites exactement la même chose et compilez exactement le même ensemble d'instructions machine. Le deuxième formulaire enregistre quelques caractères en tapant, mais, plus important encore, il est très clair que vous modifiez une valeur en fonction de sa valeur actuelle.
J'allais citer l'opérateur post/préfixe "++" comme exemple canonique mais j'ai réalisé que c'était plus que du sucre syntaxique. Il n'y a aucun moyen d'exprimer la différence entre ++ i et i ++ dans une seule expression en utilisant le i = i + 1 syntaxe.
Vraiment, votre première citation de Wikipedia dit tout "... rend les choses plus faciles à lire ...", ".... plus doux pour les humains à utiliser ....".
Par écrit, des formes abrégées telles que "ne pas" ou "n'ont pas" pourraient être considérées comme du sucre syntaxique.
Quelle que soit la connotation originale de la phrase, elle est aujourd'hui principalement péjorative, presque toujours formulée comme "juste" ou "seulement" sucre syntaxique. Cela ne concerne à peu près que les programmeurs qui aiment faire les choses de manière illisible et veulent un moyen concis de justifier cela auprès de leurs collègues. Une définition par ceux qui utilisent principalement le terme aujourd'hui, de leur point de vue, serait quelque chose comme:
Syntaxe redondante avec d'autres syntaxes plus largement applicables, afin de fournir une béquille aux programmeurs qui ne comprennent pas vraiment le langage.
C'est pourquoi vous obtenez deux conclusions opposées pour le même élément syntaxique. Votre premier exemple sur la notation de tableau utilise la signification positive originale du terme, quelque chose de similaire à la réponse de Bart. Votre deuxième exemple défend la notation de tableau contre l'accusation d'être du sucre syntaxique au sens péjoratif. En d'autres termes, il soutient que la syntaxe est une abstraction utile plutôt qu'une béquille.
Je vais d'abord aborder certaines des autres réponses avec un exemple concret. La boucle for basée sur la plage C++ 11 (un peu comme les boucles foreach dans divers autres langages)
for (auto value : container) {
do_something_with(value);
}
est exactement équivalent à (c'est-à-dire une version sucrée de)
for (auto iterator = begin(container); iterator != end(container); ++iterator) {
do_something_with(*iterator);
}
Maintenant, malgré l'ajout d'aucune nouvelle syntaxe abstraite ou sémantique au langage, il a une réelle utilité.
La première version rend l'intention (visiter chaque élément d'un conteneur) explicite. Il interdit également un comportement inhabituel tel que la modification du conteneur pendant la traversée, ou la progression de iterator dans le corps de la boucle, ou l'obtention de conditions de boucle subtilement erronées. Cela évite les sources possibles de bogues et, ce faisant, réduit la difficulté de lecture et de raisonnement sur le code.
Par exemple, une erreur à un caractère dans la deuxième version:
for (auto iterator = begin(container); iterator <= end(container); ++iterator) {
do_something_with(*iterator);
}
donne une erreur une fois après la fin et un comportement indéfini.
Ainsi, la version sucrée est utile précisément parce qu'elle est plus restrictive, et donc plus simple à faire confiance et à comprendre.
Deuxièmement, à la question initiale:
Y a-t-il une vraie différence entre Syntax et Syntactic Sugar?
Non, le "sucre syntaxique" est une syntaxe (concrète) du langage, considéré comme du "sucre" car il ne prolonge pas la syntaxe abstraite ou la fonctionnalité de base du langage. J'aime la réponse de Matt Fenwick à ce sujet.
Pour qui est-ce important?
Il est important pour les utilisateurs de la langue, comme pour toute autre syntaxe, et en ce sens que le sucre est fourni pour prendre en charge (et en quelque sorte bénir) des idiomes spécifiques.
Enfin, sur la question bonus
La notation [] facilite cette abstraction.
cela ressemble beaucoup à la définition du sucre syntaxique: il prend en charge (et fournit la bénédiction des auteurs du langage) l'utilisation de pointeurs comme tableaux. Le formulaire p[i] N'est pas vraiment plus restrictif que *(p+i), donc la seule différence est la communication claire de l'intention (et un léger gain de lisibilité).