You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 7663 Reporter: kosik Assigned to:@Octachron Status: resolved (set by @Octachron on 2018-04-04T19:16:46Z) Resolution: fixed Priority: low Severity: minor Version: 4.05.0 Fixed in version: 4.07.0+dev/beta2/rc1/rc2 Category: typing
Bug description
At some point, when I was trying to compile my program, I got this error message:
Error: Cannot safely evaluate the definition
of the recursively-defined module Foo
Unless the user read Section 7.4 of the reference manual
and deduces that "safe evaluation" might be something closely related to "safe module", I do not think that this error message could be of much help to the user.
Since this topic is subtle (one needs to understand what implementors of Ocaml mean by "safe module" and that this is (somehow) closely related to "safe evaluation" so I think it would make sense if the error message referred the user for further information to the corresponding place (Section 7.4 of the User's Manual).
It would be very helpful if Section 7.4 showed:
examples of "unsafe recursive modules"
showed what kind of error messages the user then should expect to see
("Cannot safely evaluate the definition of the recursively-defined module Foo")
and show how, in a given concrete situation, recursive modules can be converted to "safe ones".
The most trivial situation I was able to trigger the error (which confused me completely) is this:
module rec M1 :
sig
val f1 : unit
end = struct
let f1 = ()
let f2 = M2.f1
end
and M2 :
sig
val f1 : unit
end = struct
let f1 = ()
let f2 = M1.f1
end
It would be illustrative to show the necessary workaround that enables one to compile programs like these.
(I.e. changing the type of "M1.f1" to "unit -> unit" or the type of "M2.f1" to "unit -> unit".)
Please consider this as a subjective feedback as this is not really a rigorous area. I am curious what do you think.
The text was updated successfully, but these errors were encountered:
It sounds very reasonable to me to have a reference to the relevant section of the manual in the error message itself in these subtle cases, and having examples of code raising such errors could be nice.
Original bug ID: 7663
Reporter: kosik
Assigned to: @Octachron
Status: resolved (set by @Octachron on 2018-04-04T19:16:46Z)
Resolution: fixed
Priority: low
Severity: minor
Version: 4.05.0
Fixed in version: 4.07.0+dev/beta2/rc1/rc2
Category: typing
Bug description
At some point, when I was trying to compile my program, I got this error message:
Error: Cannot safely evaluate the definition
of the recursively-defined module Foo
Unless the user read Section 7.4 of the reference manual
and deduces that "safe evaluation" might be something closely related to "safe module", I do not think that this error message could be of much help to the user.
Since this topic is subtle (one needs to understand what implementors of Ocaml mean by "safe module" and that this is (somehow) closely related to "safe evaluation" so I think it would make sense if the error message referred the user for further information to the corresponding place (Section 7.4 of the User's Manual).
It would be very helpful if Section 7.4 showed:
("Cannot safely evaluate the definition of the recursively-defined module Foo")
The most trivial situation I was able to trigger the error (which confused me completely) is this:
module rec M1 :
sig
val f1 : unit
end = struct
let f1 = ()
let f2 = M2.f1
end
and M2 :
sig
val f1 : unit
end = struct
let f1 = ()
let f2 = M1.f1
end
It would be illustrative to show the necessary workaround that enables one to compile programs like these.
(I.e. changing the type of "M1.f1" to "unit -> unit" or the type of "M2.f1" to "unit -> unit".)
Please consider this as a subjective feedback as this is not really a rigorous area. I am curious what do you think.
The text was updated successfully, but these errors were encountered: