Comment author: @alainfrisch

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.

Comment author: @alainfrisch

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

Comment author: @alainfrisch

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.

Comment author: @damiendoligez

evaluation order is not guaranteed for the moment...

Comment author: @alainfrisch

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?

Comment author: @lefessan

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).

Comment author: @xavierleroy

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).