Sucre syntaxique - Syntactic sugar

En informatique , le sucre syntaxique est la syntaxe d' un langage de programmation conçu pour rendre les choses plus faciles à lire ou à exprimer. Cela rend le langage « plus doux » pour l'usage humain : les choses peuvent être exprimées de manière plus claire, plus concise ou dans un style alternatif que certains peuvent préférer.

Par exemple, de nombreux langages de programmation fournissent une syntaxe spéciale pour le référencement et la mise à jour des éléments de tableau . De manière abstraite, une référence de tableau est une procédure de deux arguments : un tableau et un vecteur d'indice, qui pourrait être exprimé sous la forme get_array(Array, vector(i,j)). Au lieu de cela, de nombreux langages fournissent une syntaxe telle que Array[i,j]. De même, une mise à jour d'un élément de tableau est une procédure composée de trois arguments, par exemple set_array(Array, vector(i,j), value), mais de nombreux langages fournissent une syntaxe telle que Array[i,j] = value.

Une construction dans une langue est du sucre syntaxique si elle peut être retirée de la langue sans aucun effet sur ce que la langue peut faire : la fonctionnalité et le pouvoir expressif resteront les mêmes.

Les processeurs de langage, y compris les compilateurs et les analyseurs statiques , étendent souvent les constructions sucrées en constructions plus fondamentales avant le traitement, un processus parfois appelé « désucrage ».

Origines

Le terme sucre syntaxique a été inventé par Peter J. Landin en 1964 pour décrire la syntaxe de surface d'un langage de programmation simple de type ALGOL qui a été défini sémantiquement en termes d'expressions applicatives du calcul lambda , centré sur le remplacement lexical de λ par "où".

Les langages de programmation ultérieurs, tels que CLU , ML et Scheme , ont étendu le terme pour désigner la syntaxe au sein d'un langage qui pourrait être défini en termes de noyau de langage de constructions essentielles; les caractéristiques pratiques de niveau supérieur pourraient être "désucrées" et décomposées en ce sous-ensemble. C'est, en fait, la pratique mathématique habituelle de construire à partir de primitives.

S'appuyant sur la distinction de Landin entre les constructions linguistiques essentielles et le sucre syntaxique, en 1991, Matthias Felleisen a proposé une codification du « pouvoir expressif » pour s'aligner sur les « croyances largement répandues » dans la littérature. Il a défini « plus expressif » comme signifiant que sans les constructions linguistiques en question, un programme devrait être complètement réorganisé.

Exemples notables

• En COBOL , de nombreux mots-clés intermédiaires sont du sucre syntaxique qui peut éventuellement être omis. Par exemple, la phrase MOVE A B.et la phrase MOVE A TO B.remplissent exactement la même fonction, mais la seconde rend plus claire l'action à réaliser.
• Opérateurs d' affectation augmentée ou d' affectation composée : par exemple, a += best équivalent à a = a + ben C et dans des langages similaires, en supposant qu'il an'a pas d'effets secondaires tels que si aest une variable régulière. Certains langages, tels que Python, peuvent permettre de surcharger les opérateurs d'affectation augmentés, de sorte qu'ils peuvent se comporter différemment des langages standard.
• En Perl , unless (condition) {...} est le sucre syntaxique pour if (not condition) {...}. De plus, toute instruction peut être suivie d'une condition, elle statement if conditionest donc équivalente à if (condition) {statement}, mais la première est plus naturellement formatée sur une seule ligne.
• Dans le langage C , la a[i]notation est un sucre syntaxique pour *(a + i). De même, la a->xnotation est un sucre syntaxique pour accéder aux membres à l'aide de l' opérateur de déréférencement (*a).x .
• L' usinginstruction en C# garantit que certains objets sont supprimés correctement. Le compilateur développe l'instruction dans un bloc try-finally.
• Le langage C# permet aux variables d'être déclarées en tant que var x = expr, ce qui permet au compilateur de déduire le type de à xpartir de l'expression expr, au lieu d'exiger une déclaration de type explicite. De même, C++ permet auto x = exprdepuis C++11 et Java var x = exprdepuis Java 11.
• Compréhensions de liste Python (comme [x*x for x in range(10)]pour une liste de carrés) et décorateurs (comme @staticmethod).
• En Haskell , une chaîne, indiquée entre guillemets, est sémantiquement équivalente à une liste de caractères.
• Dans la collection tidyverse de packages R , le pipe , désigné par %>%, déclare que les données (ou la sortie de la fonction) précédant le pipe serviront de premier argument pour la fonction suivant le pipe. Donc, x %>% f(y)est équivalent à f(x,y).
• En SQL , JOINest équivalent à INNER JOIN, ce dernier précisant que l'instruction de jointure est spécifiquement une opération de jointure interne par opposition à une opération de jointure externe.
• Appel de méthode dans les langages POO sous la forme de myObject.myMethod(parameter1, parameter2, parameter3)sucre syntaxique pour appeler une fonction globale en tant que . La référence à l'objet est passée en tant qu'argument caché, généralement accessible depuis la méthode en tant que .myMethod(myObject, parameter1, parameter2, parameter3)this
• Les paramètres appelés par référence sont un sucre de syntaxe pour passer techniquement un pointeur vers le paramètre, mais en le gérant syntaxiquement comme la variable elle-même, pour éviter un déréférencement constant du pointeur dans le code à l'intérieur de la fonction.
• En Java , une importdéclaration permet au compilateur de trouver des classes qui ne sont pas autrement spécifiées avec des noms pleinement qualifiés. Par exemple, import javax.swing.*;permet au programmeur de référencer un objet Swing , par exemple en javax.swing.JButtonutilisant le nom plus court JButton.

Critique

Certains programmeurs pensent que ces fonctionnalités d'utilisation de la syntaxe sont soit sans importance, soit carrément frivoles. Notamment, des formes syntaxiques spéciales rendent un langage moins uniforme et sa spécification plus complexe, et peuvent causer des problèmes lorsque les programmes deviennent volumineux et complexes. Cette vue est particulièrement répandue dans la communauté Lisp , car Lisp a une syntaxe très simple et régulière, et la syntaxe de surface peut être facilement modifiée. Par exemple, Alan Perlis a plaisanté une fois dans " Epigrams on Programming ", dans une référence aux langages délimités par des crochets , que " le sucre syntaxique provoque le cancer des points-virgules ".

Termes dérivés

Sel syntaxique

La métaphore a été étendue en inventant le terme sel syntaxique , qui indique une fonctionnalité conçue pour rendre plus difficile l'écriture de mauvais code. Plus précisément, le sel syntaxique est un cerceau que les programmeurs doivent franchir juste pour prouver qu'ils savent ce qui se passe, plutôt que pour exprimer une action de programme. Par exemple, dans Java et Pascal, affecter une valeur flottante à une variable déclarée comme un entier sans syntaxe supplémentaire indiquant explicitement que l'intention entraînera une erreur de compilation, tandis que C et C++ tronqueront automatiquement tous les flottants affectés à un entier. Cependant, ce n'est pas de la syntaxe, mais de la sémantique.

En C# , lors du masquage d'un membre de classe hérité, un avertissement du compilateur est émis à moins que le newmot-clé ne soit utilisé pour spécifier que le masquage est intentionnel. Pour éviter les bugs potentiels en raison de la similitude de l' instruction switch syntaxe à celle de C ou C ++, C # requiert un breakpour chaque non vide caseétiquette d'un switch( à moins que goto, returnou throwest utilisé) , même si elle ne permet pas implicite fall-through . (L'utilisation gotoet la spécification de l'étiquette suivante produit un fall-through de type C/C++ .)

Le sel syntaxique peut aller à l'encontre de son objectif en rendant le code illisible et ainsi détériorer sa qualité - dans des cas extrêmes, la partie essentielle du code peut être plus courte que la surcharge introduite pour satisfaire les exigences linguistiques.

Une alternative au sel syntaxique est de générer des avertissements du compilateur lorsqu'il y a une forte probabilité que le code soit le résultat d'une erreur - une pratique courante dans les compilateurs C/C++ modernes.

Saccharine syntaxique

D'autres extensions sont la saccharine syntaxique et le sirop syntaxique , ce qui signifie une syntaxe gratuite qui ne facilite pas la programmation.

Types sucrés

Les types de données avec prise en charge syntaxique de base sont dits « types sucrés ». Les exemples courants incluent les chaînes délimitées par des guillemets, les accolades pour les types d'objet et d'enregistrement et les crochets pour les tableaux.

Remarques

Les références