Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004072OCaml~DO NOT USE (was: OCaml general)public2006-07-27 17:002016-09-08 15:58
Assigned Tolefessan 
PlatformOSOS Version
Product Version3.09.2 
Target VersionFixed in Version3.13.0+dev 
Summary0004072: Ordre d'évaluation inattendu
DescriptionSoit code suivant:
  (print_endline "A"; fun x -> x) (print_endline "B")

ocamlopt produit du code qui affiche d'abord A puis B, contrairement à ocamlc.
L'ordre d'évaluation entre la fonction et l'argument sera inversé dans le cas
d'un appel direct, avec une fonction qui n'utilise pas son environnement mais qui n'est pas pure.

La ligne:
  else Usequence(ufunct, app)
dans Closure.direct_appply est la coupable toute désignée.
TagsNo tags attached.
Attached Files

- Relationships
related to 0007346closedshinwell order of evaluation vs the ! operator 

-  Notes
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.
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
    let args = (fun _ -> Ident.create "arg") uargs in
    let f = Ident.create "fun" in
      (fun e u id -> Ulet (id,u,e))
      (Ulet (f, ufunct,
         pure_direct_apply fundesc (Uvar f)
           ( (fun a -> Uvar a) args)))
      uargs args
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.
doligez (administrator)
2006-08-29 16:57

evaluation order is not guaranteed for the moment...
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?
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).
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
2016-09-08 15:58 doligez Relationship added related to 0007346
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker