Re: Pourquoi ?

Tu sais aussi que c'est le même genre d'erreur si il y a redefinition de type, ce qui donne :
Error: This expression has type mytype_t but an expression was expected of type mytypet_

Je crois qu'ils sont en train de travailler dessus, ce qui manque c'est les adresses dans les fichiers du pourquoi de l'erreur, en gros, les 2 définitions qui entre en conflit.

Effectivement, à ce niveau tu as raison. Il me semble aussi qu'ils travaillent dessus, ce qui est d'ailleurs plus une question de temps à consacrer au sujet que de difficultés. À mon avis, si ce n'est pas encore présent c'est que ceux qui s'occupent du compilateur bossent tous sur Emacs et que leurs extensions résolvent déjà ce problème, donc de leur seul point de vue il n'existait pas.

Pour des pures débutant, je ne suis pas sur que map et fold_left fasse si peur. Gérer correctement une boucle peut être bien plus compliqué que l'on peut le croire (erreur d'off by one). Et une fois que l'on a gouter au filtrage de type, on a plus besoin du "if" :)

Le if peut bien servir de temps en temps (test d'égalité physique ou structurelle) mais assurément le pattern matching est le cœur d'un code OCaml. Mais l'ouvrage que je citais amène bien évidemment tous ces concepts (pour preuve l'exemple de code que j'ai cité) mais dans une approche progressive que je trouve bien faite sur le plan pédagogique. Et l'on n'y trouve pas tous les gros mots que tu as cités : monades, type algébrique, clôture, currification... ou du moins pas d'entrée de jeu. Il n'y est jamais question de monade (c'est indispensable en Haskell pour les IO, mais pas en OCaml) ni de clôture (il me semble), et ils parlent un peu de types algébriques et de currification (c'est indispensable) mais sans rentrer dans le détail : c'est inutile, il vaut mieux apprendre par l'exemple. Mais l'on aborde des techniques évoluées du langage comme la fonctorisation.

Pour revenir sur la non-nécessité des monades en OCaml, qui reste pour moi le concept le plus abstrait et sans doute le plus dur à comprendre dans ta liste, je vais revenir sur le code que j'avais cité en exemple. Au fond ce qu'ils codent pour avoir des tableaux persistants c'est un système de contrôle de version sur des tableaux : faire un set c'est faire un commit sur la structure et la fonction reroot a pour rôle de se rebaser sur le tableau sur lequel on veut opérer : on modifie le graphe des diff jusqu'à ce que notre tableau soit à la base et un « véritable » tableau. Et pour faire cela, ils manipulent des pointeurs ce qui est impossible en fonctionnel pur à la Haskell. Néanmoins pour l'utilisateur d'une telle structure de données, on lui présentera cette interface dans le fichier .mli :

type 'a t
val init : int -> (int -> 'a) -> 'a t
val length : 'a t -> int
val get : 'a t -> int -> 'a
val set : 'a t -> int -> 'a -> 'a t
val iteri : (int -> 'a -> unit) -> 'a t -> unit

La fonction reroot fait partie de la machinerie interne (du point de vue du mathématicien, c'est un lemme qui n'a pas besoin d'être connu de l'utilisateur), la représentation concrète du type lui est cachée (il ne peut donc pas manipuler les pointeurs) et pour lui tout ce passe comme si c'était du fonctionnel. C'est pour cela que les auteurs aiment bien définir ainsi une des caractéristiques du paradigme fonctionnel :

Une structure de données persistantes n'est pas nécessairement codée sans effet de bord. La bonne définition de persistant est observationnellement immuable et non purement applicatif (au sens de l'absence d'effet de bord). On a seulement l'implication dans un sens : purement applicatif ⇒ persistant. La réciproque est fausse, à savoir qu'il existe des structures de données persistantes faisant usages d'effets de bord.

Et effectivement la structure des tableaux persistants fonctionne avec des effets de bord (les fonctions set et reroot) mais cela c'est en interne et l'utilisateur ne l'observe pas : pour lui la structure est persistante.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.