Fonction de somme tail-recursive

Le problème exposé dans ce sujet a été résolu.

Je ne sais pas ce que voulait souligner dab, mais comme le dit Zéphyr quand on définit un opérateur infixe en OCaml son associativité est basée sur le premier caractère (source), et en particulier mettre la même fonction sous les noms @@ et $ ne produira pas le même résultat pour l'exemple qu'il donne.

En OCaml, x $ y $ z donnera (x y) z et x @@ y @@ z donnera x (y z). En Haskell, x $ y $ z est défini comme x (y z).

+0 -0

Effectivement, c'est pas pareil. C'est le genre de truc que j'oublie à chaque fois…

Je ne sais pas ce que voulait souligner dab, mais comme le dit Zéphyr quand on définit un opérateur infixe en OCaml son associativité est basée sur le premier caractère […], et en particulier mettre la même fonction sous les noms @@ et $ ne produira pas le même résultat pour l'exemple qu'il donne.

Sauf que le premier message de @Zéphyr n'est pas compréhensible/clair (en tout cas pour moi).

Oui, en effet. Cependant ton message fait pas énormément sens Zéphir, du coup.

À ce que j'ai compris, olzd parlait de définir $ comme @@. Ce qui fonctionnerait bien si OCaml était pas trop bête. Mais l'idée était bien là. À mon avis.

(et mea culpa, je pensais que tu parlais de Haskell en parlant de x $ y $ z = (x y) z)

Non, je parlais bien d'OCaml, en réponse au post juste au dessus auquel je répondais (et par opposition à la phrase suivante, qui commençait par « en haskell »). Mais on s'en fiche. Est-ce que par contre tu pourrais expliquer pourquoi tu penses qu'OCaml est « trop bête » ?

Et pourquoi pas ? Ça permet d'écrire des opérateurs avec l'associativité qu'on veut, ce qui est utile pour certains idiomes, par exemple f @@ x @@ y ou [1; 2; 3] |> List.map succ |> List.filter is_even, où on a besoin d'une associativité différente. On a bien le droit de préférer un système différent, mais celui-là a le mérite de ne pas demander d'annotation supplémentaire et de donner une syntaxe clairement définie et documentée.

+0 -0

Oui, mais ça a l'inconvénient d'être le moins explicite au monde. Mais genre. Vraiment?

(tu sais vraiment quel caractère va engendrer quelle précédence de tête?)

EDIT: Enfin. Tu as le droit d'aimer ça. Personnellement, je préfère pouvoir dire quelle précédence je veux pour quel opérateur sans avoir à savoir ça de tête et en pouvant utiliser le caractère que je veux et qui me semble faire le plus de sens dans ma situation. Après en effet, c'est un peu plus verbeux.

+0 -0

Bien sûr que non, je ne le sais pas. Mais je n'en ai jamais eu besoin. J'ai vu dans des codes les patterns que j'ai montrés plus haut, et maintenant je sais que ça marche. Si un jour par hasard j'ai besoin de définir un opérateur dont je veux contrôler l'associativité ou la priorité (honnêtement, ça ne m'est jamais arrivé), je lis la documentation, et tant pis si j'écris \_o< au lieu de @^.^@.

Franchement, je ne suis pas spécialement le genre à défendre bec et ongles la syntaxe d'ocaml, que je trouve bien souvent regrettablement verbeuse par rapport à haskell (ces constructeurs avec des virgules et des parenthèses, quelle horreur). Mais en l'occurrence, c'est un peu râler pour le plaisir : ça vous est déjà arrivé combien de fois dans du code réel d'avoir besoin de définir vous-mêmes la priorité d'un opérateur qui devait commencer par un caractère qui n'allait pas bien avec OCaml ?

+0 -0

Zéros, je n'ai jamais fait de OCaml.

Et c'est sans doute pour ça que tu penses que ça pose un problème.

Mais sinon, oui, c'est utile d'avoir une précédence plutôt qu'une autre, typiquement ce dont il était question avant qu'on parte totalement en hors-sujet.

Et dont on s'est parfaitement sortis en utilisant @@ plutôt que $. D'ailleurs, ni le code originel ni l'exemple que Saroupille a donné pour introduire $ n'ont besoin que son associativité soit définie : ils n'utilisent l'opérateur qu'une fois par expression. Ça rejoint ce que je disais plus haut : pouvoir déclarer un opérateur précis avec son associativité (et par extension sa priorité) n'offre que des avantages concrets très limités par rapport à la complexité d'implémentation supplémentaire, qui elle est non négligeable dans le parsing.

+0 -0

Y'a pas besoin de faire du Java pour ne pas aimer sa relative verbosité, pas besoin de faire du C pour regretter les erreurs types buffer overflow que Rust évite par exemple.

Pour ce qui est du parser, je suis pas convaincu par ton argument, sur quoi tu t'appuies ?

Y'a pas besoin de faire du Java pour ne pas aimer sa relative verbosité, pas besoin de faire du C pour regretter les erreurs types buffer overflow que Rust évite par exemple.

Non, mais en l'occurrence à peu près personne parmi les gens qui programment en OCaml ne pense que ce comportement est un problème (et pourtant, des critiques, il y en a).

Pour ce qui est du parser, je suis pas convaincu par ton argument, sur quoi tu t'appuies ?

À ton avis, quelles sont les différentes étapes à suivre pour parser un programme dans un langage comme OCaml, et quelles sont les étapes à suivre pour parser un programme OCaml où on ajoute la possibilité de déclarer l'associativité de ses opérateurs ?

À ton avis, quelles sont les différentes étapes à suivre pour parser un programme dans un langage comme OCaml, et quelles sont les étapes à suivre pour parser un programme OCaml où on ajoute la possibilité de déclarer l'associativité de ses opérateurs ?

Tu ne te poses pas une bonne question. Le but n'est pas "de ne pas se faire chier en écrivant l'interpréteur", c'est de faire un langage de qualité.

Et dont on s'est parfaitement sortis en utilisant @@ plutôt que $. D'ailleurs, ni le code originel ni l'exemple que Saroupille a donné pour introduire $ n'ont besoin que son associativité soit définie : ils n'utilisent l'opérateur qu'une fois par expression. Ça rejoint ce que je disais plus haut : pouvoir déclarer un opérateur précis avec son associativité (et par extension sa priorité) n'offre que des avantages concrets très limités par rapport à la complexité d'implémentation supplémentaire, qui elle est non négligeable dans le parsing.

C'est pas une question de s'en sortir. C'est une question d'ambiguïté induite par le langage. Mais oui tu as raison et tu es très beau.

Sinon, regardons sur Github. Wow. Sur les vrais projets, les gens utilisent plusieurs @@ dans une même expression. Dingue hein ?

À ton avis, quelles sont les différentes étapes à suivre pour parser un programme dans un langage comme OCaml, et quelles sont les étapes à suivre pour parser un programme OCaml où on ajoute la possibilité de déclarer l'associativité de ses opérateurs ?

Tu ne te poses pas une bonne question. Le but n'est pas "de ne pas se faire chier en écrivant l'interpréteur", c'est de faire un langage de qualité.

Bienvenue dans le vrai monde, où la maintenabilité du code est un critère à prendre en compte et où le temps de travail des développeurs n'est pas gratuit.

Et dont on s'est parfaitement sortis en utilisant @@ plutôt que $. D'ailleurs, ni le code originel ni l'exemple que Saroupille a donné pour introduire $ n'ont besoin que son associativité soit définie : ils n'utilisent l'opérateur qu'une fois par expression. Ça rejoint ce que je disais plus haut : pouvoir déclarer un opérateur précis avec son associativité (et par extension sa priorité) n'offre que des avantages concrets très limités par rapport à la complexité d'implémentation supplémentaire, qui elle est non négligeable dans le parsing.

C'est pas une question de s'en sortir. C'est une question d'ambiguïté induite par le langage.

Il n'y a absolument aucune ambiguité. Certains opérateurs sont associatifs à gauche, d'autres à droite, et c'est défini de façon claire et univoque par la documentation.

Mais oui tu as raison et tu es très beau.

Il ne me semble vraiment pas qu'on ait besoin de partir dans des attaques ad hominem pour continuer ce débat. Si ça n'est pas ton avis et que tu as besoin de ça pour t'exprimer, je propose qu'on s'arrête tout de suite, ça ne m'intéresse pas.

Sinon, regardons sur Github. Wow. Sur les vrais projets, les gens utilisent plusieurs @@ dans une même expression. Dingue hein ?

Et alors ? Est-ce que ces gens se plaignent du comportement des opérateurs en OCaml ? Non, c'est un sujet de discussion que je n'ai personnellement jamais vu sur les différents canaux où les gens font des remarques sur le langage. Est-ce que les gens ont du mal à utiliser @@parce qu'en haskell on écrit $ à la place ? Manifestement non, puisque l'usage de cet opérateur plusieurs fois dans la même expression est répandu. Le problème que tu soulèves est en pratique inexistant.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte