Syntax Design - Pourquoi utiliser des parenthèses quand aucun argument n'est passé?

Dans de nombreuses langues, la syntaxe function_name(arg1, arg2, ...)est utilisée pour appeler une fonction. Lorsque nous voulons appeler la fonction sans aucun argument, nous devons le faire function_name().

Je trouve étrange qu'un compilateur ou un interpréteur de script ait besoin ()de le détecter avec succès en tant qu'appel de fonction. Si une variable est connue pour être appelable, pourquoi ne serait-il pas function_name;suffisant?

Par contre, dans certaines langues, on peut faire: function_name 'test';ou même function_name 'first' 'second';appeler une fonction ou une commande.

Je pense que les parenthèses auraient été meilleures si elles n’avaient été nécessaires que pour déclarer l’ordre de priorité. À d’autres endroits, elles étaient facultatives. Par exemple, faire if expression == true function_name;devrait être aussi valide que if (expression == true) function_name();.

La chose la plus agaçante à mon avis est de le faire 'SOME_STRING'.toLowerCase()quand clairement, la fonction prototype ne nécessite aucun argument. Pourquoi les concepteurs ont-ils décidé de ne pas utiliser le plus simple 'SOME_STRING'.lower?

Disclaimer: Ne vous méprenez pas, j'aime la syntaxe C-like! ;) Je demande simplement si cela pourrait être mieux. Requérir ()présente des avantages en termes de performances, ou facilite-t-il la compréhension du code? Je suis vraiment curieux de savoir quelle est exactement la raison.

Pour les langages qui utilisent des fonctions de première classe , il est assez courant que la syntaxe de référence à une fonction soit la suivante:

a = object.functionName

alors que l'acte d' appeler cette fonction est:

b = object.functionName()

adans l'exemple ci-dessus serait une référence à la fonction ci-dessus (et vous pourriez l'appeler en faisant a()), tout en bcontenant la valeur de retour de la fonction.

Bien que certaines langues puissent faire des appels de fonction sans parenthèses, il peut être difficile de dire si elles appellent la fonction ou font simplement référence à la fonction.

En effet, Scala le permet, bien qu’une convention soit suivie: si la méthode a des effets secondaires, les parenthèses doivent néanmoins être utilisées.

En tant qu’écrivain du compilateur, la présence garantie de parenthèses me conviendrait fort bien; Je saurais toujours que c'est un appel à une méthode et je n'aurais pas à construire une bifurcation pour les cas impairs.

En tant que programmeur et lecteur de code, la présence de parenthèses ne laisse aucun doute sur le fait qu'il s'agit d'un appel de méthode, même si aucun paramètre n'est transmis.

Le passage de paramètres n'est pas la seule caractéristique qui définit un appel de méthode. Pourquoi devrais-je traiter une méthode sans paramètre différente de la méthode qui a des paramètres?

Il s’agit en fait d’un choix assez subtil de choix de syntaxe. Je parlerai de langages fonctionnels, basés sur le calcul lambda typé.

Dans ces langues, chaque fonction a exactement un argument . Ce que nous considérons souvent comme des "arguments multiples" est en réalité un paramètre unique du type de produit. Ainsi, par exemple, la fonction qui compare deux entiers:

leq : int * int -> bool
leq (a, b) = a <= b

prend une seule paire d'entiers. Les parenthèses ne désignent pas les paramètres de la fonction; ils sont utilisés pour faire correspondre l'argument. Pour vous convaincre qu'il ne s'agit vraiment que d'un argument, nous pouvons utiliser les fonctions projectives au lieu du filtrage par motif pour déconstruire la paire:

leq some_pair = some_pair.1 <= some_pair.2

Ainsi, les parenthèses sont vraiment une commodité qui nous permet de mettre en correspondance des motifs et d’économiser du texte. Ils ne sont pas nécessaires.

Qu'en est-il d'une fonction qui n'a apparemment aucun argument? Une telle fonction a effectivement du domaine Unit. Le membre unique de Unitest habituellement écrit ainsi (), c'est pourquoi les parenthèses apparaissent.

say_hi : Unit -> string
say_hi a = "Hi buddy!"

Pour appeler cette fonction, il faudrait l'appliquer à une valeur de type Unit, qui doit être (), pour finir par écrire say_hi ().

Donc, il n’existe vraiment pas de liste d’arguments!

En Javascript par exemple, utiliser un nom de méthode sans () renvoie la fonction elle-même sans l'exécuter. De cette façon, vous pouvez par exemple transmettre la fonction en tant qu'argument à une autre méthode.

En Java, le choix a été fait qu'un identifiant suivi de () ou (...) désigne un appel de méthode, tandis qu'un identifiant without () se réfère à une variable membre. Cela pourrait améliorer la lisibilité, car vous ne doutez pas qu'il s'agisse d'une méthode ou d'une variable membre. En fait, le même nom peut être utilisé à la fois pour une méthode et pour une variable membre, les deux seront accessibles avec leur syntaxe respective.

La syntaxe suit la sémantique, alors commençons par la sémantique:

Quelles sont les manières d'utiliser une fonction ou une méthode?

En réalité, il y a plusieurs façons:

• une fonction peut être appelée, avec ou sans arguments
• une fonction peut être traitée comme une valeur
• une fonction peut être appliquée partiellement (créer une fermeture en prenant au moins un argument de moins et en fermant les arguments passés)

Avoir une syntaxe similaire pour des utilisations différentes est le meilleur moyen de créer un langage ambigu ou à tout le moins déroutant (et nous en avons assez).

En langage C et C-like:

• l'appel d'une fonction se fait en utilisant des parenthèses pour entourer les arguments (il peut n'y en avoir aucun) comme dans func()
• traiter une fonction comme une valeur peut être fait simplement en utilisant son nom comme dans &func(C créer un pointeur de fonction)
• dans certaines langues, vous avez une syntaxe abrégée pour appliquer partiellement; Java permet someVariable::someMethodpar exemple (limité au récepteur de la méthode, mais toujours utile)

Notez que chaque utilisation utilise une syntaxe différente, ce qui vous permet de les distinguer facilement.

Aucune des autres réponses n'a tenté de répondre à la question suivante: quelle redondance devrait-il y avoir dans la conception d'une langue? Parce que même si vous pouvez concevoir un langage de telle sorte que x = sqrt yx soit défini à la racine carrée de y, cela ne signifie pas nécessairement que vous devriez le faire.

Dans une langue sans redondance, chaque séquence de caractères signifie quelque chose, ce qui signifie que si vous faites une seule erreur, vous n'obtiendrez pas de message d'erreur, votre programme agira de manière erronée, ce qui peut être très différent de ce que vous destiné et très difficile à déboguer. (Comme le savent tous ceux qui ont travaillé avec des expressions rationnelles.) Un peu de redondance est une bonne chose, car elle permet de détecter bon nombre de vos erreurs. Plus il y a de redondance, plus les diagnostics seront précis. Maintenant, bien sûr, vous pouvez aller trop loin (aucun de nous ne veut écrire en COBOL ces jours-ci), mais il existe un juste équilibre.

La redondance facilite également la lisibilité, car il y a plus d'indices. Il serait très difficile de lire un anglais sans redondance, de même que les langages de programmation.

Dans une langue avec des effets secondaires, l’OMI est vraiment utile pour différencier la lecture d’une variable (en théorie, sans effets secondaires)

variable

et en appelant une fonction pouvant entraîner des effets secondaires

launch_nukes()

OTOH, s'il n'y a pas d'effets secondaires (autres que ceux encodés dans le système de types), il est alors inutile de faire la différence entre lire une variable et appeler une fonction sans argument.

Dans la plupart des cas, il s’agit de choix syntaxiques de la grammaire du langage. Il est utile que la grammaire de chaque construction individuelle soit (relativement) non ambiguë quand elle est prise dans son ensemble. (S'il y a des ambiguïtés, comme dans certaines déclarations C ++, il doit y avoir des règles spécifiques pour la résolution.) Le compilateur n'a pas la latitude de deviner; il est nécessaire de suivre la spécification de langue.

Visual Basic, sous différentes formes, différencie les procédures qui ne renvoient pas de valeur et les fonctions.

Les procédures doivent être appelées en tant qu'énoncé et ne nécessitent pas de parenthèse, mais uniquement des arguments séparés par des virgules, le cas échéant. Les fonctions doivent être appelées dans le cadre d'une expression et requièrent les parenthèses.

C'est une distinction relativement inutile qui rend la refactorisation manuelle entre les deux formes plus douloureuse que nécessaire.

(D'autre part Visual Basic utilise les mêmes parens ()pour les références de tableau comme pour les appels de fonction, de sorte que les références de tableau ressemble à des appels de fonction. Et cela facilite refactoring manuelle d'un tableau dans un appel de fonction! Alors, nous pourrions réfléchir à d' autres langues utilisent []l » pour les références de tableau, mais je m'éloigne du sujet ...)

Dans les langages C et C ++, le contenu des variables est automatiquement accessible en utilisant leur nom. Si vous souhaitez faire référence à la variable elle-même au lieu de son contenu, vous appliquez l' &opérateur unaire .

Ce type de mécanisme pourrait également être appliqué aux noms de fonction. Le nom de la fonction brute pourrait impliquer un appel de fonction, alors qu'un &opérateur unaire serait utilisé pour désigner la fonction (elle-même) en tant que donnée. Personnellement, j'aime bien l'idée d'accéder à des fonctions sans argument sans effets secondaires sans la même syntaxe que les variables.

Ceci est parfaitement plausible (comme le sont d’autres choix syntaxiques pour cela).

Cohérence et lisibilité.

Si j'apprends que vous appelez la fonction Xcomme ceci: X(arg1, arg2, ...), alors je pense que cela fonctionne de la même façon pour aucun argument: X().

Maintenant, en même temps, j'apprends que vous pouvez définir la variable comme un symbole et l'utiliser comme ceci:

a = 5
b = a
...

Maintenant, qu'est-ce que je penserais quand je trouverais ça?

c = X

Votre proposition est aussi bonne que la mienne. Dans des circonstances normales, le Xest une variable. Mais si nous prenions votre chemin, cela pourrait aussi être une fonction! Dois-je me rappeler si quel symbole correspond à quel groupe (variables / fonctions)?

Nous pourrions imposer des contraintes artificielles, par exemple "Les fonctions commencent par une lettre majuscule. Les variables commencent par une lettre minuscule", mais cela n'est pas nécessaire et complique les choses, même si cela peut parfois aider certains des objectifs de conception.

Note 1: Les autres réponses ignorent complètement une dernière chose: la langue peut vous permettre d'utiliser le même nom pour la fonction et la variable et de faire la distinction par contexte. Voir à Common Lisptitre d'exemple. Fonction xet variable xcoexistent parfaitement bien.

Side note 2: La réponse acceptée nous montre la syntaxe: object.functionname. Premièrement, les langages dotés de fonctions de premier ordre ne sont pas universels. Deuxièmement, en tant que programmeur, je considérerais cela comme une information supplémentaire: functionnameappartient à un object. Que ce objectsoit un objet, une classe ou un espace de noms importe peu, mais cela me dit qu'il appartient quelque part . Cela signifie que vous devez soit ajouter une syntaxe artificielle object.pour chaque fonction globale, soit en créer une objectpour contenir toutes les fonctions globales.

Et de toute façon, vous perdez la possibilité d'avoir des espaces de noms séparés pour les fonctions et les variables.

Pour ajouter aux autres réponses, prenons cet exemple C:

void *func_factory(void)
{
        return 0;
}

void *(*ff)(void);

void example()
{
        ff = func_factory;
        ff = func_factory();
}

Si l'opérateur d'invocation était facultatif, il n'y aurait aucun moyen de faire la distinction entre l'attribution de fonction et l'appel de fonction.

Ceci est encore plus problématique dans les langues dépourvues de système de type, par exemple JavaScript, où l'inférence de type ne peut pas être utilisée pour déterminer ce qui est ou non une fonction.