Discussion :

[GnuVince]

Soit le code suivant:

Code :

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

1
2
3
4
5
6
 
let rec boucle i =
  match i with
    | 0 -> true
    | _ -> i = i && boucle (i-1)
in boucle 1000000;;

Si on utilisait un opérateur comme l'addition, on risquerait un débordement de la pile; qu'en est-il avec les opérateurs && et || qui sont à short-circuit?

[gasche]

Les opérateurs short-circuit préservent bien la tail-rec, comme un test te l'aurait appris.

La description des opérateurs booléens du manuel ne mentionne pas la tail-rec (je pense me souvenir que la tail-rec n'est pas définie dans le manuel, mais seulement par l'implémentation), mais elle propose des formes équivalentes ("if a then true else b", etc.) qui préservent la tail-rec.

[InOCamlWeTrust]

&& et || sont considérés des opérateurs de flot par à peu près tous les compilateurs classiques, et Caml n'échappe pas à la règle. S'ils avaient été considérés uniquement de simples opérateurs arithmétiques, cela aurait été une faute (de débutant) commise par les personnes ayant écrit le compilateur.

[smatador]

&& et || sont considérés des opérateurs de flot par à peu près tous les compilateurs classiques, et Caml n'échappe pas à la règle. S'ils avaient été considérés uniquement de simples opérateurs arithmétiques, cela aurait été une faute (de débutant) commise par les personnes ayant écrit le compilateur.

Malheureusement, c'est une erreur qui a été commise par les concepteurs du langage VBA... et ce n'est pas la seule .

[Cacophrene]

Bonsoir,

Malheureusement, c'est une erreur qui a été commise par les concepteurs du langage VBA... et ce n'est pas la seule

Le langage VBA est une erreur.

Non ce n'est pas une incitation à troller.

Cordialement,
Cacophrène

[LLB]

&& et || sont considérés des opérateurs de flot par à peu près tous les compilateurs classiques, et Caml n'échappe pas à la règle. S'ils avaient été considérés uniquement de simples opérateurs arithmétiques, cela aurait été une faute (de débutant) commise par les personnes ayant écrit le compilateur.

Il n'en reste pas moins que ce cas particulier, géré magiquement par le compilateur, introduit des comportements bizarres.

Code :

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

1
2
3
4
# (&&) false  (1/0 = 2);;
- : bool = false
# let f = (&&) in f false  (1/0 = 2);;
Exception: Division_by_zero.

Et même :

Code :

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

1
2
3
4
5
6
# false && (1/0 = 2);;
- : bool = false
# let (&&) = (&&);;
val ( && ) : bool -> bool -> bool = <fun>
#  false && (1/0 = 2);;
Exception: Division_by_zero.

En pratique, ça fait beaucoup plus de bien que de mal, mais c'est un peu dommage sur le plan théorique.

[gasche]

Ça ne me semble pas aberrant non plus. Le comportement est simple à décrire sémantiquement :
- `a op b` et `(op) a b` sont équivalents
- quand `(op)` est passé par valeur (plutôt qu'appelé directement), on passe implicitement `(fun a b -> a op b)`