Skip to content
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

Exception erroneously considered values in recursive module type checking scheme #4604

Closed
vicuna opened this issue Aug 26, 2008 · 2 comments
Closed

Comments

@vicuna
Copy link

vicuna commented Aug 26, 2008

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.

@vicuna
Copy link
Author

vicuna commented Sep 18, 2008

Comment author: @xavierleroy

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.

@vicuna
Copy link
Author

vicuna commented Jan 23, 2012

Comment author: @xavierleroy

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants