• [^] # Re: Haskell super expressif ?

    Posté par (site web personnel) . En réponse au journal Comprendre Go en 5 minutes, en Haskell. Évalué à 2. Dernière modification le 31 décembre 2019 à 18:05.

    la vérification que l'appel a le bon nombre d'argument est retardée.

    J'ai déjà avoué dans un autre commentaire que cela pouvait générer des erreurs de type parfois étonnantes, mais je répète que dans mon expérience cela ne m'a jamais dérangé. Cependant mon expérience se limite à Haskell et donc j'ai du mal à voir ce que cela peut donner dans un autre langage.

    la lisibilité si tu as fn f: a b -> c, tu vois tout de suite que tu a et b comme entrée et c comme retour, si tu as fn f: a -> b -> c, c'est moins immédiat.

    L'application partielle biaise notre façon de développer des interfaces, on s'habitue très vite à voir f comme plusieurs possibilités, celle qui te semble immédiate (2 arguments, un retour qui n'est pas une fonction), et l'autre (un argument, un retour qui est une fonction).

    Après si vraiment tout cela t’embêtes et que c'est la seule chose qui te bloque en Haskell, tu peux faire des fonctions qui prennent des tuples, ainsi fn aura comme type (a, b) -> c et son appel se fera avec un tuple: fn (a, b). La vérification sera faite "au bon endroit", la syntaxe de déclaration de fonction va ressembler à quelque chose que tu connais et tout sera bien et chaque fois que tu auras besoin d'une fonction appliquée partiellement, tu pourras faire une lambda: \x -> fn(a, x) ;)