0004072: Ordre d'évaluation inattendu

(0003715)
frisch (developer)
2006-07-27 17:18

En fait, ça arrive aussi avec une fonction qui utilise son environemment:

let f u = (print_endline "A"; fun x -> u) (print_endline "B") in f ()

Pour le coup, c'est à cause de:
if fundesc.fun_closed then uargs else uargs @ [ufunct] in
toujours dans Closure.direct_apply.

(0003716)
frisch (developer)
2006-07-27 17:29

Pour régler le problème, on peut remplacer direct_apply par:

let pure_direct_apply fundesc ufunct uargs =
  let app_args =
    if fundesc.fun_closed then uargs else uargs @ [ufunct] in
  match fundesc.fun_inline with
      None -> Udirect_apply(fundesc.fun_label, app_args)
    | Some(params, body) -> bind_params params app_args body

let direct_apply fundesc funct ufunct uargs =
  if is_pure funct then pure_direct_apply fundesc ufunct uargs
  else
    let args = List.map (fun _ -> Ident.create "arg") uargs in
    let f = Ident.create "fun" in
    List.fold_left2
      (fun e u id -> Ulet (id,u,e))
      (Ulet (f, ufunct,
         pure_direct_apply fundesc (Uvar f)
           (List.map (fun a -> Uvar a) args)))
      uargs args

(0003717)
frisch (developer)
2006-07-27 17:40

On peut aussi vouloir optimiser pour le cas où la fonction est une abstraction (car is_pure renvoie alors false) puisqu'il s'agit alors seulement de faire apparaître la définition de fonction, mais l'ordre d'évaluation n'a pas d'importance. Ce cas peut se présenter si on fait de l'inlining.

(0003744)
doligez (manager)
2006-08-29 16:57

evaluation order is not guaranteed for the moment...

(0006865)
frisch (developer)
2012-01-31 23:04

> evaluation order is not guaranteed for the moment...

The "official" position on this seems to be:

<<
An observable difference in evaluation order between
ocamlc and ocamlopt is a quality of implementation issue: even if it
doesn't contradict the documentation, it's undesirable and should be
avoided if we reasonably can.
>>

Isn't it a case where we reasonably can?

(0006867)
lefessan (developer)
2012-02-01 10:38

Fixed in commits r12108 and 12109, by changing the execution order in bytecode to be the same one as in native code (better to avoid changes in production executables).

(0006939)
xleroy (administrator)
2012-02-18 18:25

As discussed at the latest bug hunt meeting, I am very uncomfortable with changing ocamlc to implement an evaluation order different from that predicted by the push-enter model of the ZAM abstract machine. I reverted commits 12108 and 12109, and I'm putting this PR in the "suspended" category (= no immediate action necessary).

Issue History
Date Modified	Username	Field	Change
2006-07-27 17:00	frisch	New Issue
2006-07-27 17:18	frisch	Note Added: 0003715
2006-07-27 17:29	frisch	Note Added: 0003716
2006-07-27 17:40	frisch	Note Added: 0003717
2006-08-29 16:57	doligez	Note Added: 0003744
2006-08-29 16:57	doligez	Severity	minor => feature
2006-08-29 16:57	doligez	Status	new => acknowledged
2012-01-31 23:04	frisch	Note Added: 0006865
2012-02-01 10:38	lefessan	Note Added: 0006867
2012-02-01 10:38	lefessan	Status	acknowledged => resolved
2012-02-01 10:38	lefessan	Fixed in Version	=> 3.13.0+dev
2012-02-01 10:38	lefessan	Resolution	open => fixed
2012-02-01 10:38	lefessan	Assigned To	=> lefessan
2012-02-15 22:24	frisch	Status	resolved => assigned
2012-02-18 18:25	xleroy	Note Added: 0006939
2012-02-18 18:25	xleroy	Resolution	fixed => suspended
2012-04-08 19:38	xleroy	Status	assigned => resolved

Notes
(0003715) frisch (developer) 2006-07-27 17:18	En fait, ça arrive aussi avec une fonction qui utilise son environemment: let f u = (print_endline "A"; fun x -> u) (print_endline "B") in f () Pour le coup, c'est à cause de: if fundesc.fun_closed then uargs else uargs @ [ufunct] in toujours dans Closure.direct_apply.

(0003716) frisch (developer) 2006-07-27 17:29	Pour régler le problème, on peut remplacer direct_apply par: let pure_direct_apply fundesc ufunct uargs = let app_args = if fundesc.fun_closed then uargs else uargs @ [ufunct] in match fundesc.fun_inline with None -> Udirect_apply(fundesc.fun_label, app_args) \| Some(params, body) -> bind_params params app_args body let direct_apply fundesc funct ufunct uargs = if is_pure funct then pure_direct_apply fundesc ufunct uargs else let args = List.map (fun _ -> Ident.create "arg") uargs in let f = Ident.create "fun" in List.fold_left2 (fun e u id -> Ulet (id,u,e)) (Ulet (f, ufunct, pure_direct_apply fundesc (Uvar f) (List.map (fun a -> Uvar a) args))) uargs args

(0003717) frisch (developer) 2006-07-27 17:40	On peut aussi vouloir optimiser pour le cas où la fonction est une abstraction (car is_pure renvoie alors false) puisqu'il s'agit alors seulement de faire apparaître la définition de fonction, mais l'ordre d'évaluation n'a pas d'importance. Ce cas peut se présenter si on fait de l'inlining.

(0003744) doligez (manager) 2006-08-29 16:57	evaluation order is not guaranteed for the moment...

(0006865) frisch (developer) 2012-01-31 23:04	> evaluation order is not guaranteed for the moment... The "official" position on this seems to be: << An observable difference in evaluation order between ocamlc and ocamlopt is a quality of implementation issue: even if it doesn't contradict the documentation, it's undesirable and should be avoided if we reasonably can. >> Isn't it a case where we reasonably can?

(0006867) lefessan (developer) 2012-02-01 10:38	Fixed in commits r12108 and 12109, by changing the execution order in bytecode to be the same one as in native code (better to avoid changes in production executables).

(0006939) xleroy (administrator) 2012-02-18 18:25	As discussed at the latest bug hunt meeting, I am very uncomfortable with changing ocamlc to implement an evaluation order different from that predicted by the push-enter model of the ZAM abstract machine. I reverted commits 12108 and 12109, and I'm putting this PR in the "suspended" category (= no immediate action necessary).

Relationships