Discussion :

[SpiceGuid]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
let rev_fold2 f init l1 l2 =
  let rec helper init l1 l2 =
    match l1 , l2 with
    | [] , [] -> Some init
    | a1::l1 , a2::l2 -> helper (f a1 a2 init) l1 l2
    | _ , _ -> None
  in helper init l1 l2

(* not tail recursive *)
let fold2 f init l1 l2 =
  let rec helper l1 l2 =
    match l1 , l2 with
    | [], [] -> Some init
    | a1::l1 , a2::l2 ->
        ( match helper l1 l2 with
        | None   -> None
        | Some t -> Some (f a1 a2 t)
        ) 
    | _ , _ -> None
  in helper l1 l2

[LLB]

Là encore c'est une question de style, je conçois très bien que pour d'autres usages celà fasse sens que List.map2 lève une exception. Mais c'est à moi qu'il revient d'en décider, au cas par cas, pas à quelqu'un qui aurait déjà choisi son camp.

Comment veux-tu qu'on te laisse le choix ? En mettant les deux fonctions dans la bibliothèque ?

Quelle que soit la méthode choisie dans la bibliothèque, c'est facile d'en changer le comportement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
let force = function Some x -> x | None -> raise (Invalid_argument "force")
let tryf f x = try Some (f x) with Invalid_argument _ -> None

Il y a certains cas où l'exception se justifie pleinement. Ce serait pénible si, par exemple, la division renvoyait un type option.

[alex_pi]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
(* not tail recursive *)
let fold2 f init l1 l2 =
  let rec helper l1 l2 =
    match l1 , l2 with
    | [], [] -> Some init
    | a1::l1 , a2::l2 ->
        ( match helper l1 l2 with
        | None   -> None
        | Some t -> Some (f a1 a2 t)
        ) 
    | _ , _ -> None
  in helper l1 l2

C'est pas simple de faire un choix, mais quand même (bechmark pipo) :

• en cas d'échec
  
  • En byte code
    version avec exception 183% plus lent ! j'avoue, je ne m'attendais pas à un facteur 3, mais surtout pas dans ce sens..
  • En optimisé
    version avec type option 6% plus lent (seulement)
• En cas de réussite
  
  • En byte code :
    option 30% plus lent
  • En optimisé
    option plus lent de... 633% !

Donc effectivement, si on compte compiler en bytecode et généralement échouer, il vaut mieux utiliser la version option. Par contre, en optimisé, en s'attendant à généralement réussir, la version avec exception est plus de 7 fois plus rapide. On peut comprendre le choix de la librairie standard je trouve. Surtout que l'empacter dans une version retournant un type option n'est pas bien complexe.

[Garulfo]

Les exceptions c'est la façon impérative de traiter les erreurs, et parfois ça manque de composabilité sémantique.
Quand tu dois unifier deux listes de termes et que List.map2 unify l1 l2 lève une exception Invalid_argument (listes de longueur différentes) au lieu de te renvoyer None ça te paraît beaucoup moins cohérent (avec ta sémantique).[...]

C'est ton point de vue. Le point de vue des concepteurs d'OCaml a été de considérer que l'exception sert à traiter tout cas anormaux. Et à ce moment cela devient cohérent. Je ne dis pas que l'un est meilleur que l'autre. Je dis que ce sont deux manières différentes de percevoir et que je ne pense pas que l'une est meilleure que l'autre ni plus justifiée. Une justification pour l'exception serait que les cas sont traités plus rapidement. Les méthodes par continuation permettent d'obtenir les exceptions (car sont plus général) et servent même souvent à une ça d'une certaine façon. Je ne crois pas qu'on puisse accuser l'approche par continuation d'être impérative. Donc ça se discute tout ça.

[Garulfo]

[...]
version avec exception 183% plus lent ! j'avoue, je ne m'attendais pas à un facteur 3, mais surtout pas dans ce sens..[...]

Étonnant. Tu es sûr de tes résultats ?
Bon c'est une autre discussion maintenant. On pourrait en ouvrir une non ?
Je serais curieux de savoir pourquoi.

[gasche]

Oui, sans avoir fait de test ça me semble étonnant aussi, je serais curieux de voir le code complet.

Par ailleurs, une "vraie" version avec type option utiliserait une exception en interne (pendant la récursion) et encapsulerait le tout dans un type option, je pense. Ça revient à la doctrine "exceptions en internes, mais pas à l'interface des modules" qui est à mon avis assez intéressante "en général", mais qui n'est effectivement pas le choix de la stdlib.
Comme cela a déjà été montré, on peut facilement envelopper tout ça quand on en ressent le besoin (let result f x = try `Result (f x) with exn -> `Error exn , puis on peut utiliser des monades (pa_monad), etc.).