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: 4604 Reporter: Jeremie Assigned to:@xavierleroy Status: closed (set by @xavierleroy on 2013-08-31T10:46:07Z) Resolution: suspended Priority: normal Severity: feature Version: 3.10.2 Category: ~DO NOT USE (was: OCaml general) Monitored by: Jeremie "Julien Signoles"
Bug description
The "safe/unsafe" typing rule puts an undue restriction on exceptions: exceptions are considered on par with values, and cause a module to be tagged as unsafe.
(The severity of this bug has been marked as major, insofar as it is seriously hindering my own modular programming; it might not be such a problem for most programmmers.)
=> Why can't I just define exceptions outside of the recursive/problematic module (which we will call module A)? Because often enough, exceptions contain "parameters" of which the type(s) is(/are) defined in A:
exception Error of A.t
module A : sig .. end =
struct
...
raise (Error v)
...
end
=> Why do I need such exceptions? In modular code, A.myfunc throws exception A.Ex1(t) to let module B know that it was not able to complete its task for some reason, and passes all relevant information as "t"; module B might know something more about how to handle this situation, and manage to resolve it. This, to some degree, could be achieved using 'a option types; but it produces much less legible (and elegant) code.
=> Why should exceptions be "safe"? Exceptions are basically type definitions, which generate values for the try/with construct; you could thus argue that an exception should be "unsafe", because it would always need to be available for such constructs. However, this disregards the fact that try/with can only be called:
...
and B = struct ...
let x = try A.zero () with A.no_zero -> 0
... end
from a value; and in this case, module B would already be flagged as being unsafe because of value x
or
let x () = try A.zero () with A.no_zero -> 0
from a function, and in this case, the function won't (theoretically) be called until all modules are initialized (under the hypothesis that the modules can be correctly ordered in the safe/unsafe scheme).
Additional information
Minimal code to highlight the issue:
module type CLIENT =
sig
type t
exception Error of t
end
module type HOST =
sig
module Client : CLIENT
end
module Client(Host : HOST) : CLIENT =
struct
type t = int
exception Error of t
end
module rec Host : HOST =
struct
module Client = Client(Host)
end;;
Characters 228-269:
struct
module Client = Client(Host)
end..
Cannot safely evaluate the definition of the recursively-defined module Host
Reporter can be e-mailed for further examples.
The text was updated successfully, but these errors were encountered:
I understand your need for exceptions defined within recursive modules. However, in the current implementation, exceptions are values: the evaluation of a declaration "exception E" allocates a reference whose address is used as a unique identifier for the exception. I see no way to adapt the evaluation strategy for recursive modules so that a proper fixpoint is reached (i.e. so that the identity of the exception remains unique). So, I'll keep this PR open as a feature wish, but don't expect any solution soon.
Following new PR handling policy, I put this feature request in the "resolved/suspended" state, meaning that in the absolute, a solution to this problem would be nice, but we Caml dev team cannot find a reasonable solution.
Original bug ID: 4604
Reporter: Jeremie
Assigned to: @xavierleroy
Status: closed (set by @xavierleroy on 2013-08-31T10:46:07Z)
Resolution: suspended
Priority: normal
Severity: feature
Version: 3.10.2
Category: ~DO NOT USE (was: OCaml general)
Monitored by: Jeremie "Julien Signoles"
Bug description
The "safe/unsafe" typing rule puts an undue restriction on exceptions: exceptions are considered on par with values, and cause a module to be tagged as unsafe.
(The severity of this bug has been marked as major, insofar as it is seriously hindering my own modular programming; it might not be such a problem for most programmmers.)
=> Why can't I just define exceptions outside of the recursive/problematic module (which we will call module A)? Because often enough, exceptions contain "parameters" of which the type(s) is(/are) defined in A:
exception Error of A.t
module A : sig .. end =
struct
...
raise (Error v)
...
end
=> Why do I need such exceptions? In modular code, A.myfunc throws exception A.Ex1(t) to let module B know that it was not able to complete its task for some reason, and passes all relevant information as "t"; module B might know something more about how to handle this situation, and manage to resolve it. This, to some degree, could be achieved using 'a option types; but it produces much less legible (and elegant) code.
=> Why should exceptions be "safe"? Exceptions are basically type definitions, which generate values for the try/with construct; you could thus argue that an exception should be "unsafe", because it would always need to be available for such constructs. However, this disregards the fact that try/with can only be called:
...
and B = struct ...
let x = try A.zero () with A.no_zero -> 0
... end
from a value; and in this case, module B would already be flagged as being unsafe because of value x
or
let x () = try A.zero () with A.no_zero -> 0
from a function, and in this case, the function won't (theoretically) be called until all modules are initialized (under the hypothesis that the modules can be correctly ordered in the safe/unsafe scheme).
Additional information
Minimal code to highlight the issue:
module type CLIENT =
sig
type t
exception Error of t
end
module type HOST =
sig
module Client : CLIENT
end
module Client(Host : HOST) : CLIENT =
struct
type t = int
exception Error of t
end
module rec Host : HOST =
struct
module Client = Client(Host)
end;;
Characters 228-269:
struct
module Client = Client(Host)
end..
Cannot safely evaluate the definition of the recursively-defined module Host
Reporter can be e-mailed for further examples.
The text was updated successfully, but these errors were encountered: