Par contre, pour moi ce n'est pas un détail de syntaxe. C'est plutôt un point d'implémentation qui vient impacter la syntaxe. Le point sous-jacent étant : est-ce que le développeur a besoin de savoir quelque chose à propos de la curryfication/décurryfication ?
Dis autrement : je suis une quiche totale en programmation fonctionnelle, mais j'ai quand même tendance à penser que pour un être humain normal, la conception se fait en disant "j'ai x et y, deux entiers, qui servent à calculer un produit", donc une seule fonction, et pas un enchaînement de deux fonctions.
Dis encore autrement : je vois que la curryfication permet d'avoir des fonctions pures (et je pense percevoir l'intérêt de celles-ci), mais je ne vois pas en quoi ça justifie de faire de la curryfication systématique, et encore moins de venir impacter la syntaxe avec cette notion. Le remède n'est-il pas pire que le mal ?
[^] # Re: Haskell super expressif ?
Posté par Dring . En réponse au journal Comprendre Go en 5 minutes, en Haskell. Évalué à 4.
Merci beaucoup pour cet éclairage.
Par contre, pour moi ce n'est pas un détail de syntaxe. C'est plutôt un point d'implémentation qui vient impacter la syntaxe. Le point sous-jacent étant : est-ce que le développeur a besoin de savoir quelque chose à propos de la curryfication/décurryfication ?
Dis autrement : je suis une quiche totale en programmation fonctionnelle, mais j'ai quand même tendance à penser que pour un être humain normal, la conception se fait en disant "j'ai x et y, deux entiers, qui servent à calculer un produit", donc une seule fonction, et pas un enchaînement de deux fonctions.
Dis encore autrement : je vois que la curryfication permet d'avoir des fonctions pures (et je pense percevoir l'intérêt de celles-ci), mais je ne vois pas en quoi ça justifie de faire de la curryfication systématique, et encore moins de venir impacter la syntaxe avec cette notion. Le remède n'est-il pas pire que le mal ?