L'une des raisons pour lesquelles les langues basées sur l'algol encouragent les accolades sur leur propre ligne est d'encourager l'ajout de lignes entre les accolades de délimitation sans avoir à déplacer les accolades. Autrement dit, si l'on commence par
if (pred)
{
printf("yes");
}
il est facile de venir et d'ajouter une autre déclaration entre les accolades:
if (pred)
{
printf("yes");
++yes_votes;
}
Si le formulaire d'origine avait été
if (pred)
{ printf("yes"); }
il faudrait alors avoir "déplacé" deux accolades, mais mon exemple concerne plus ce dernier. Ici, les accolades délimitent ce qui est censé être une séquence d'instructions , principalement invoquées pour un effet secondaire.
Inversement, Lisp manque de déclarations; chaque forme est une expression , donnant une certaine valeur - même si dans de rares cas (en pensant au Common Lisp), cette valeur est délibérément choisie pour être «sans valeur» via un (values)
formulaire vide . Il est moins courant de trouver des séquences d'expressions , par opposition aux expressions imbriquées . Le désir «d'ouvrir une séquence d'étapes jusqu'au délimiteur de fermeture» ne se manifeste pas aussi souvent, car au fur et à mesure que les déclarations disparaissent et que les valeurs de retour deviennent une monnaie plus courante, il est plus rare d'ignorer la valeur de retour d'une expression, et donc plus rare d'évaluer une séquence d'expressions pour un effet secondaire seul.
En Common Lisp, le progn
formulaire est une exception (tout comme ses frères et sœurs):
(progn
(exp-ignored-return-1)
(exp-ignored-return-2)
(exp-taken-return))
Ici, progn
évalue les trois expressions dans l'ordre, mais ignore les valeurs de retour des deux premières. Vous pouvez imaginer écrire cette dernière parenthèse fermante sur sa propre ligne, mais notez à nouveau que puisque la dernière forme est spéciale ici (pas dans le sens Common Lisp d'être spéciale , cependant), avec un traitement distinct, il est plus probable que l'on ajoute de nouvelles expressions au milieu de la séquence, plutôt que de simplement «en ajouter une autre à la fin», car les appelants seraient alors affectés non seulement par de nouveaux effets secondaires, mais plutôt par un changement probable de la valeur de retour.
Pour faire une simplification grossière, les parenthèses dans la plupart des parties d'un programme Lisp délimitent les arguments passés aux fonctions - tout comme dans les langages de type C - et ne délimitent pas les blocs d'instructions. Pour les mêmes raisons, nous avons tendance à garder les parenthèses délimitant un appel de fonction en C autour des arguments, nous faisons de même de même en Lisp, avec moins de motivation pour dévier de ce regroupement proche.
La fermeture des parenthèses est beaucoup moins importante que l'indentation du formulaire où elles s'ouvrent. Avec le temps, on apprend à ignorer les parenthèses et à écrire et lire par forme, un peu comme le font les programmeurs Python. Cependant, ne laissez pas cette analogie vous faire penser que la suppression complète des parenthèses serait utile. Non, c'est un débat qu'il vaut mieux conserver comp.lang.lisp
.