Comment author: @garrigue

Je comprends votre confusion, mais cet exemple n'est pas un bug, meme si il demontre la fragilite de la relaxed value restriction dans certains cas.
En effet le type de [lazy (raise Not_found)] n'est pas le meme quand on le met directement dans l'enregistrement ou lorsqu'on definit une valeur intermediaire.
Dans le premier cas, la contrainte de type induite par l'enregistrement donne le type
[('a list -> int) Lazy.t] qui n'est pas generalisable suivant la restriction relaxee (occurence contravariante).
Dans le second cas c'est ['a Lazy.t] qui est lui generalisable (occurence covariante).
Ce genre de phenomene n'est pas rare, et c'est donc une bonne idee d'utiliser un let explicite pour aider le typeur. On pourrait en theorie retarder l'application de la contrainte de type pour pouvoir mieux generaliser, mais ca risquerait d'induire des messages d'erreur moins clairs.

Comment author: lavi

Hum ça reste bizarre, parce que le code suivant ne passe pas non plus :

# type t = {f: 'a. ('a list -> int) Lazy.t}
  let l = { f = let tmp = raise Not_found in tmp };;

pour le coup, c'est la première fois que je vois le type changer selon que l'on utilise un "let" ou un "let in"...
(ceci n'est évidemment pas grave, et ne me gène aucunement dans ma programmation en caml, qui reste un merveilleux langage !)

Comment author: lavi

oups typo:

let l = { f = let tmp = lazy (raise Not_found) in tmp };;

mais ça reste vrai: si on sort le "let tmp", ça passe...

Comment author: @garrigue

Je ne vois pas de solution simple: le problème vient du fait qu'on propage le type attendu vers
l'expression à typer, ce qui rend impossible de généraliser une variable devenue contravariante.
La seule option ici semble être de backtracker, pour retyper sans propagation...

Comment author: @garrigue

Fixed in version/3.12, revision 10538.
Used backtracking, but as long as one doesn't nest polymorphic record expressions, this shouldn't cause an exponential behaviour,