New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delayed effects in partially applied functions #7531
Comments
Comment author: @mshinwell Sigh, unfortunately the other fixes I'd made about evaluation order haven't fixed this. Thanks for the report. I will make a patch. |
Comment author: @mshinwell Superceded by #1162 |
Comment author: @stedolan It turns out that the same issue crops up with default arguments, although this version can occur with bytecode as well as native code: let f ?(x = print_endline "hello") () = fun _ -> 1;;val f : ?x:unit -> unit -> 'a -> int = f ();;
f () ();;hello
|
Comment author: @garrigue With defaults arguments, this is part of the specification (not sure where it is written). |
Comment author: @garrigue About optional arguments: the problem is described in my paper |
Original bug ID: 7531
Reporter: jmi
Assigned to: @mshinwell
Status: resolved (set by @mshinwell on 2017-05-08T11:17:10Z)
Resolution: duplicate
Priority: normal
Severity: minor
Version: 4.04.0
Category: middle end (typedtree to clambda)
Related to: #7533
Bug description
The native code compiler erroneously delays the effect of an operator until (if ever) it is fully applied.
The following program outputs a newline when compiled with the bytecode compiler but not with the native code compiler:
I believe the issue is described by the following comment on line 828 of asmcomp/closure.ml:
(* We convert [f a] to [let a' = a in fun b c -> f a' b c]
when fun_arity > nargs *)
which instead should use an approach along the lines of:
(* We convert [f a] to [let f’ = f in
let a’ = a in fun b c -> f’ a’ b c]
when fun_arity > nargs *)
The above example illustrates the situation when the effect is delayed indefinitely. For an example, where the effect is delayed until the time of full application, consider:
which prints 10 when compiled with the bytecode backend and 01 with the native code backend.
The behaviour is the same for version 4.02.3.
Steps to reproduce
$ ocamlc -o func.byte func.ml
$ ./func.byte
$ ocamlopt -o func.native func.ml
$ ./func.native
$
The text was updated successfully, but these errors were encountered: