Quelle est la différence entre «Syntaxe» et «Sucre syntaxique»


46

Contexte

La page Wikipedia sur Sucre syntaxique dit:

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, de manière plus concise ou dans un style alternatif que certains préfèrent.

Je ne comprends pas vraiment quelle est la différence entre le sucre syntaxique et la syntaxe.

J'apprécie le fait que la version sucrée puisse être plus claire, plus concise, peut-être faire bouillir du plasma. Mais j’estime qu’à un certain niveau, toute la syntaxe consiste essentiellement à le faire pour former une abstraction sur laquelle le code est compilé.

De la même page Wikipedia:

Les processeurs de langage, y compris les compilateurs, les analyseurs statiques, etc., développent souvent des constructions sucrées en constructions plus fondamentales avant traitement, un processus parfois appelé "désuculation".

En tant qu’exercice de réflexion, si je prends souvent le mot «souvent» dans cette déclaration, cela signifie «toujours»: du compilateur sait (ou fait attention) quelle est la syntaxe de Sugar'd ou non?

Une question très liée sur ce site "Définition rigoureuse du sucre syntaxique?" a une réponse qui commence:

IMHO 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" en utilisant de "vrais outils" sur des "systèmes d'exploitation réels"

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 l'auteur du compilateur? Même s’il peut y avoir des cas où il est utile que le codeur utilisant la langue sache ce qui se cache sous le capot du Sucre syntaxique? (Mais peut-être qu'en réalité, tout discours sur le sujet tend à utiliser le terme d'appât à la flamme?)

Le coeur de la question

Alors ... la version courte de la question:

  • Existe-t-il une réelle différence entre la syntaxe et le sucre syntaxique?
  • Qui est-ce important?

Extra nourriture pour la pensée

Bonus sur la contradiction de sujet:

Sur la page Wikipedia, un exemple est donné:

Par exemple, en langage C, la a[i]notation est un sucre syntaxique pour*(a + i)

Attendu qu'une autre réponse à 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 significative.

Et résume que:

La []notation facilite cette abstraction. Ce n'est pas du sucre syntaxique.

La conclusion opposée pour le même exemple!


9
Dans ma réponse à la question citée, j'explique que le sucre syntaxique est une syntaxe alternative (à une syntaxe déjà existante dans le langage) qui facilite l'expression de certains idiomes communs sans introduire de nouvelle sémantique. En ce sens, le sucre syntaxique dépend du contexte (de la langue dans laquelle il est utilisé): la même notation peut être la syntaxe normale dans une langue et le sucre syntaxique dans une autre langue. Cette explication vous aide-t-elle?
Giorgio

7
Un problème est que certaines personnes semblent penser que "sucre syntaxique" est un mot vulgaire, alors que ce n'est pas le cas. Chaque fonction ou classe que vous ajoutez à un système peut être considérée comme un "sucre syntaxique", dans la mesure où elle facilite la formulation d'idées clairement exprimables dans la langue.
Joris Timmermans

Apparemment, cela compte pour vous.
SShaheen

12
En fin de compte, il n’ya que le sucre syntatique sur l’électricité.
Anthony Pegram

Réponses:


34

La principale différence est que la syntaxe est la grammaire définie dans un langage pour vous permettre d'exposer certaines fonctionnalités. Dès que vous pouvez accéder à cette fonctionnalité, toute autre syntaxe qui vous permet de faire la même chose est considérée comme du sucre. Cela se heurte bien entendu à des scénarios étranges sur la syntaxe choisie pour l’une des deux syntaxes, d’autant plus que la première place n’est pas toujours claire.

En pratique, le sucre syntaxique n’est utilisé que pour décrire la syntaxe ajoutée à une langue afin de faciliter son utilisation, comme pour infixer la lhs + rhsmappe lhs.Add(rhs). Je considérerais que l'indexation sur les tableaux de C est un sucre syntaxique.

Cela importe surtout parce que les designs élégants ont tendance à limiter le nombre de duplications. Avoir (ou du moins vouloir) du sucre syntaxique est perçu par certains comme un signe d'échec.


"Dès que vous pouvez accéder à cette fonctionnalité, toute autre syntaxe vous permettant de faire la même chose est considérée comme un sucre." . Le programme sucre et le sucre doivent avoir la même sémantique .
Giorgio

3
@Giorgio Comment "ces deux programmes calculent la même fonction" différente de "ces deux programmes ont la même sémantique"? En dehors de cela, vous vous concentrez sur les programmes, pas sur les éléments syntaxiques. Des programmes entiers ne peuvent pas être du sucre syntaxique. Un opérateur, une sorte d'énoncé, etc. peut être un sucre syntaxique.

@Giorgio - En effet, j’envisage une fonctionnalité similaire avec une sémantique différente. Et oui, il pourrait y avoir saut de cerceau comme écrire votre propre compilateur qui a la même sémantique et appeler cela "sucre". Franchement, une définition formelle ne se produira pas pour un concept aussi informel.
Telastyn

1
@Giorgio Encore une fois, mon point fort n’est pas votre point de vue de l’équivalence, mais que vous essayez d’appliquer le concept de sucre syntaxique aux programmes. Le terme ne fait pas référence à des programmes entiers! Selon votre définition, il s'agit soit uniquement de blocs de construction atomiques, soit de fragments de programme courts (le premier semble couvrir> 80%, mais je ne suis pas sûr que cela couvre tout ce qui est communément considéré comme du sucre syntaxique).

3
@Giorgio Par exemple, des programmes entiers ;-) ou quelque chose d'assez gros pour que les deux formulations impliquent plusieurs mots-clés de langue sans rapport. Quelque chose que je n'ai jamais été traité comme sucre syntaxique est if (a) return blah; ...par opposition result_type res; if (a) res = blah; else {...}; return res;. Vous devez assumer des langages spécifiques et faire preuve d’une extrême rigueur linguistique (souvent jusqu’à une sémantique opérationnelle modeste) pour trouver la différence entre ces programmes.

10

La syntaxe est ce qu'un processeur de langage utilise pour comprendre la signification des constructions d'un langage. Les constructions considérées comme du sucre syntaxique doivent également être interprétées par le processeur de langage et font donc partie de la syntaxe d'un 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 pouvant être écrits dans cette langue.

Pour donner une définition plus formaliste, je dirais

Les sucres syntaxiques sont les parties de la syntaxe d'une langue dont les effets sont définis en termes d'autres constructions de syntaxe dans la langue.

Cela n’a aucunement pour but de 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.


"Il n’existe aucun moyen de dire de façon définitive" c’est du sucre syntaxique et c’est de la syntaxe ", car le sucre syntaxique fait partie de la syntaxe d’une langue.": False. C'est le concepteur de langage qui introduit une syntaxe en tant que sucre syntaxique pour une construction qui existe déjà dans le langage et qui a une syntaxe. Le sucre syntaxique est normalement ad-hoc (moins général) mais plus lisible / plus pratique à utiliser.
Giorgio

@Giorgio: J'ai reformulé mon premier paragraphe car c'était un peu gênant. Mais je ne suis pas d'accord pour dire que le sucre syntaxique est normalement ajouté ad-hoc. Le bit de sucre syntaxique le plus connu est probablement l' ->opérateur de C et je ne vois pas en quoi cet opérateur est moins général que les autres.
Bart van Ingen Schenau

1
@Giorgio: Dans ce cas, tout ce qui ne correspond pas directement à une instruction d'assemblage unique doit être considéré comme un sucre syntaxique, car il peut toujours être décomposé en éléments plus simples (y compris les fonctions). Je ne pense pas que vous ne trouverez pas beaucoup de personnes partageant ce point de vue.
Bart van Ingen Schenau

1
"Ad-hoc" signifie qu'il est utilisé dans une situation spéciale restreinte. Le terme n'a pas de connotation négative en général. Le terme solution ad-hoc a une connotation négative, car on souhaite généralement des solutions générales, et non des solutions particulières (pour éviter de résoudre encore et encore des problèmes similaires).
Giorgio

1
Puisque les "solutions ad-hoc" sont souvent mauvaises, il peut sembler que "ad-hoc" signifie en soi mauvais. Mais il y a aussi un "polymorphisme ad hoc" sur la surcharge de la fonction AKA ( en.wikipedia.org/wiki/Ad_hoc_polymorphism ), ce qui n'est pas mauvais. Au moins en italien (ma langue maternelle), l'utilisation du latin "ad-hoc" n'est pas négative en soi. Si cela a une connotation négative en anglais, alors excusez mon ignorance.
Giorgio

6

Les autres réponses n'ont pas mentionné un concept clé: la syntaxe abstraite ; sans cela, le terme "sucre syntaxique" n'a pas de sens.

La syntaxe abstraite définit les éléments et la structure des langues et explique comment combiner des expressions de cette langue pour créer des expressions plus volumineuses. La syntaxe abstraite est indépendante de la syntaxe concrète. Le terme "sucre syntaxique", si je comprends bien, désigne une syntaxe concrète.

En général, lors de la conception d'une langue, vous souhaiterez créer une syntaxe concrète pour chaque terme de votre syntaxe abstraite, afin que les utilisateurs puissent écrire du code dans votre langue en utilisant du texte brut.

Maintenant, supposons que vous créez une syntaxe concrète délicate 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 que vous avez maintenant deux syntaxes concrètes pour le même terme de syntaxe abstraite.

Je pense que c'est ce que les gens veulent dire quand ils parlent de "sucre syntaxique" - des changements qui n'affectent que la syntaxe concrète, mais qui n'affectent pas la syntaxe abstraite ni la sémantique.

Ainsi, la différence entre "sucre syntaxique" et "syntaxe concrète" est maintenant claire. Pour moi. :)

Cette interprétation aide également à expliquer ce qu'Alan Perlis aurait pu vouloir dire quand il a dit "le sucre syntaxique cause le cancer du point-virgule": tout le sucre syntaxique concret dans le monde ne peut pas réparer la syntaxe abstraite faible, et tous les efforts que vous déployez en ajoutant que le sucre est effort que vous ne dépensez pas pour traiter le vrai problème - la syntaxe abstraite.


Je devrais également noter que ceci est uniquement mon opinion; Je n'y crois que parce que c'est la seule interprétation à laquelle je puisse penser qui a du sens pour moi.


1
J'avais aussi pensé à la comparaison syntaxe abstraite / concrète, mais je ne suis pas sûr que cela explique toujours le sucre syntaxique. Par exemple, en C, étant donné un pointeur pvers une structure contenant un champ x, faire les expressions (*p).xet p->xla même syntaxe abstraite? Mais je pense que ce serait bien si tout se résumait à une syntaxe abstraite ou concrète.
Giorgio

@Giorgio, malheureusement, je ne connais pas suffisamment C pour pouvoir affirmer avec certitude que l'un de ces éléments est un sucre syntaxique pour l'autre, ou à quoi ressemblerait leur arbre de syntaxe abstraite. Ou même si la spécification de C définit en réalité une syntaxe abstraite. :(

1
La première expression peut être analysée comme un arbre avec un .à la racine. Le sous-noeud gauche de la racine est a *et son enfant est p. Le sous-noeud de droite de la racine est x. Pour la deuxième expression, l'arbre de syntaxe abstraite a un ->à la racine et la racine a deux enfants pet x. J'essaie de comprendre s'il est logique d'analyser les deux expressions différemment afin qu'elles aient le même arbre de syntaxe abstraite, mais je ne vois pas comment pour le moment.
Giorgio

3
Je ne pense pas que cet arbre d'analyse, même s'il est souvent décrit comme un AST, est identique à la syntaxe abstraite dont parle Matt. Les deux expressions ont la même action ( convertir le type de pointeur en type de référence, puis obtenir une référence à un membrex )
Inutile

1
"Les deux expressions ont la même action (convertir le type de pointeur en type de référence, puis obtenir une référence au membre x)": il s'agit d'une sémantique et non d'une syntaxe abstraite. La syntaxe abstraite consiste à laisser de côté des détails inutiles de la syntaxe concrète (comme (ou ;) pour produire un arbre qui reflète la structure réelle d'un programme (voir en.wikipedia.org/wiki/Abstract_syntax_tree ). Cependant, dans la syntaxe abstraite, rien n’est dit (encore) sur la sémantique du programme.
Giorgio

4

Le sucre syntaxique est un sous-ensemble de la syntaxe des langages. L'idée de base est qu'il y a plus d'une façon de dire la même chose.

Ce qui rend difficile de dire quelles pièces sont du sucre syntaxique et quelles pièces sont de la "syntaxe pure" sont des énoncés du type "il est difficile de dire quelle forme est apparue en premier" ou "il est difficile de savoir de quelle manière l'auteur du langage est destiné" ou "c'est quelque peu arbitraire de décider quelle forme est la plus simple ".

Ce qui permet de choisir facilement les éléments 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 correspond aux éléments qu'un compilateur convertit directement en code machine ou auxquels l'interpréteur répond directement. Le sucre est ce qui a d’abord été transformé en quelque chose de syntaxe avant que ces choses directes ne se produisent. Selon l’implémentation, il peut s’agir ou non de ce que l’auteur avait l'intention de faire ou même de ce que prétend la langue.

En pratique, c’est ainsi que la réalité de la question est décidée.


Cette réponse relie à tort l'implémentation de la syntaxe à si c'est du sucre ou pas. Je n'ai jamais vu d'arguments sur la question de savoir si un élément d'une langue est "sucre" ou non, et concerne la manière dont l'élément est implémenté. Il s'agit simplement de savoir si cela duplique un élément différent, plus laid, syntaxiquement.
GreenAsJade

3

Vraiment, votre première citation de Wikipedia dit tout: "... rend les choses plus faciles à lire ...", ".... plus doux pour les humains à utiliser ....".

En écriture, les formes abrégées telles que "ne pas" ou "ne pas" pourraient être considérées comme du sucre syntaxique.


Considérez (1) "Je devrais y aller maintenant" par rapport à (2) "Je devrais y aller maintenant": Le sucre (1) syntaxique est-il pour (2)?
Giorgio

1
@ Georges je dirais non.
ozz

En raison de la lisibilité ("devrait" n'est pas plus lisible que "devrait") ou en raison du sens ("devrait" et "devrait" ont des significations différentes).
Giorgio

@Giorgio assez juste :)
ozz

1
Ah je vois :) je pense que je ne pense pas que l'un soit plus lisible que l'autre dans cet exemple
ozz

3

Généralement, le sucre de syntaxe est la partie du langage qui peut être exprimée par une partie existante du langage (syntaxe) sans perte de généralité, mais avec éventuellement une perte de clarté. Parfois, les compilateurs ont une étape de desugaring explicite qui transforme l'AST créé par le code source et applique des étapes simples pour supprimer les nœuds correspondant au sucre.

Par exemple, Haskell a un 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 le moment, 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 fondamental sur RHS (à savoir les applications de fonction, lambdas et lets). Cette étape permet de garder le meilleur des deux mondes:

  1. La syntaxe sur LHS est plus facile pour le programmeur (sucre de syntaxe) exprimant les idées existantes de manière plus claire
  2. Cependant, étant donné que le compilateur prend en charge les constructions RHS, il n'a pas besoin de le traiter comme quelque chose de spécial en dehors de l'analyseur syntaxique et du desugaring (à l'exception des rapports d'erreur).

De même, en C, vous pouvez imaginer une règle de réécriture dérisoire (en raison de la surcharge des opérateurs, etc., ce n'est pas vrai pour C ++):

f->h ~> (*f).h
f[h] ~> *(f + h)

Vous pouvez 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 syntaxique (je suppose que dans les années 70, cela pourrait aussi 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 

La syntaxe est-elle mauvaise? Pas nécessairement - il y a le danger qu'il soit utilisé comme culte de la cargaison sans comprendre un sens plus profond. Par exemple, les fonctions suivantes sont équivalentes dans Haskell, mais beaucoup de débutants écriraient le premier formulaire sans comprendre qu'ils utilisaient trop de sucre dans la syntaxe:

f1 = do x <- doSomething
        return x
f2 = doSomething

De plus, la syntaxe sucre peut compliquer excessivement le langage ou être trop étroite 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 dû à la conception (ne donnez pas aux développeurs des outils pointus ou un langage de niche très spécifique qui ajouterait une construction plus puissante nuirait à d'autres objectifs) ou par omission - ce dernier la forme donnait à la syntaxe sugar 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.


3

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. La seconde forme 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 / prefix comme exemple canonique, mais j'ai réalisé qu'il s'agissait de plus que du sucre syntaxique. Il n'y a aucun moyen d'exprimer la différence entre ++ i et i ++ dans une seule expression à l'aide de la i = i + 1syntaxe.


+ = peut être utile dans des cas comme a[f(x)] += 1.
Florian F

1

Quelle que soit la signification originale de cette expression, il s’agit aujourd’hui essentiellement d’un sucre péjoratif, presque toujours qualifié de sucre syntaxique "juste" ou "uniquement". Cela ne concerne quasiment que les programmeurs qui aiment faire les choses de façon illisible et veulent une façon concise de justifier cela auprès de leurs collègues. Une définition de 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 un support pour les 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 de notation en tableau utilise la signification originale du terme, quelque chose de similaire à la réponse de Bart. Votre deuxième exemple consiste à défendre la notation de tableau contre l’accusation de 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 pense que la signification péjorative du terme ("ce n'est que du sucre syntaxique") vient du fait que le sucre syntaxique n’ajoute aucune information.
Giorgio

1
Cela pourrait venir de l'idée que syntaxique n'ajoute aucune information , mais cette idée n'est pas un fait. Les informations sur l'intention (par exemple, utiliser un idiome connu) sont toujours des informations.
Inutile

@Useless: Par information, je voulais dire qu'un programme se comporte de la même manière avec ou sans sucre syntaxique. Bien sûr, cela peut être plus lisible avec du sucre syntaxique (cela ajoute des informations / documentation au lecteur), ce qui est un avantage.
Giorgio

Faux. Le sucre syntaxique n'est pas un péjoratif. Tout programmeur digne de ce nom créera des bibliothèques qui encapsuleront et simplifieront des tâches plus complexes, plutôt que de copier et coller le même code partout. Cela conduit à un code plus sage, plus maintenable. C’est essentiellement ce que le sucre syntaxique accomplit en synthétisant des modèles communs, bien que complexes, en une syntaxe plus simple.
Craig

Je dis que les gens entendent généralement le terme comme une insulte, je ne commente pas la pratique sous-jacente elle-même. Dire que le mot "idiot" est un parjoratif n'implique pas que tous les gens sont des idiots. Lorsque les gens veulent parler positivement de la pratique, ils utilisent généralement des termes tels que "abstraction" ou "encapsulation".
Karl Bielefeldt

1

Premièrement, je vais 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.-à-d. une version sucrée de)

for (auto iterator = begin(container); iterator != end(container); ++iterator) {
    do_something_with(*iterator);
}

Maintenant, malgré l’ajout de nouvelle syntaxe abstraite ou sémantique au langage, celui-ci a un réel utilité.

La première version rend l'intention explicite (visiter chaque élément d'un conteneur). Elle interdit également les comportements inhabituels, tels que la modification du conteneur pendant la traversée, l'avancée ultérieure iteratordans le corps de la boucle ou l'obtention de conditions de boucle légèrement fausses. Cela évite les sources possibles de bogues et, ce faisant, réduit les difficultés de lecture et de raisonnement concernant le code.

Par exemple, une erreur d’un caractère dans la deuxième version:

for (auto iterator = begin(container); iterator <= end(container); ++iterator) {
    do_something_with(*iterator);
}

donne une erreur d'un passé 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:

Existe-t-il une réelle différence entre la syntaxe et le sucre syntaxique?

Non, "sucre syntaxique" est une syntaxe de langage (concrète), considérée comme "sucre" car elle ne prolonge pas la syntaxe abstraite ou les fonctionnalités essentielles du langage. J'aime la réponse de Matt Fenwick à ce sujet.

Qui est-ce important?

Il importe aux utilisateurs de la langue, autant que toute autre syntaxe, et le sucre est fourni pour soutenir (et dans un certain sens, 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), en utilisant des pointeurs en tant que tableaux. La p[i]forme n’est pas vraiment plus restrictive que la précédente *(p+i), de sorte que la seule différence est la communication claire de l’intention (et un léger gain de lisibilité).


Tout d'abord, vous dites "[la plage basée sur la boucle] est exactement équivalente à (c'est-à-dire une version sucrée de) [quelque chose d'autre]". Mais ensuite, vous dites que c'est différent, en ce sens qu'il interdit de modifier le conteneur pendant la traversée ... et qu'il existe d'autres différences qui le rendent plus que la simple transformation syntaxique que vous avez décrite (par exemple, le comportement lorsque "conteneur" est temporaire). Ces différences impliquent qu'il ne s'agit pas que de sucre syntaxique, non? Il me semble donc que ce n’est pas un bon exemple de sucre syntaxique.
Don Hatch

Je n'ai pas dit que c'était équivalent à une boucle générale , j'ai dit que c'était équivalent à la boucle spécifique donnée. La boucle spécifique ne modifie pas le conteneur et représente un idiome très commun - mais vous devez tout de même lire attentivement chaque boucle générale pour savoir si elle suit cet idiome commun ou si quelque chose d'inhabituel se cache dans le corps de la boucle. La boucle la plus récente est idéale pour cet idiome commun : elle est à la fois moins verbeuse et communique plus clairement l'idiome utilisé. Ce n’est pas, et je n’ai jamais prétendu que c’était, en quelque sorte une suggestion pour l’idée générale d’une boucle.
Inutile
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.