J'ai toujours du mal avec les langages qui préfèrent les math aux utilisateurs, je m'explique: pour moi une fonction a des entrées et des sorties mais sous prétexte qu'il y a la curryfication, au lieu d'avoir des fonction avec plusieurs entrées et plusieurs sorties, on a: fonction: entree1 -> entree2 -> … sortie1 -> sortie2 (1) Beurk, ce n'est pas parce que la curryfication existe qu'il faut la montrer systématiquement!
1: par exemple si on tape le programme du dessus dans l'interpréteur OCaml on a en sortie:
val process_file : (in_channel -> 'a) -> string -> 'a = < fun >
mais la fonction dans le code du programme avait des entrées et des sorties, pourquoi l'interpréteur n'affiche pas:
val process_file : ((in_channel -> 'a), string) -> ('a = < fun >)
ça serait beaucoup plus fidèle au code..
[^] # Re: Version fonctionnelle
Posté par reno . En réponse à la dépêche OCaml 4.00.0 est sorti. Évalué à 1.
J'ai toujours du mal avec les langages qui préfèrent les math aux utilisateurs, je m'explique: pour moi une fonction a des entrées et des sorties mais sous prétexte qu'il y a la curryfication, au lieu d'avoir des fonction avec plusieurs entrées et plusieurs sorties, on a: fonction: entree1 -> entree2 -> … sortie1 -> sortie2 (1)
Beurk, ce n'est pas parce que la curryfication existe qu'il faut la montrer systématiquement!
1: par exemple si on tape le programme du dessus dans l'interpréteur OCaml on a en sortie:
val process_file : (in_channel -> 'a) -> string -> 'a = < fun >
mais la fonction dans le code du programme avait des entrées et des sorties, pourquoi l'interpréteur n'affiche pas:
val process_file : ((in_channel -> 'a), string) -> ('a = < fun >)
ça serait beaucoup plus fidèle au code..