0004604: Exception erroneously considered values in recursive module type checking scheme

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0004604

OCaml

OCaml general

public

2008-08-26 16:47

2012-01-23 16:37

Reporter

Jeremie

Assigned To

xleroy

Priority

normal

Severity

feature

Reproducibility

always

Status

resolved

Resolution

suspended

Platform

OS Version

Product Version

3.10.2

Target Version

Fixed in Version

Summary

0004604: Exception erroneously considered values in recursive module type checking scheme

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.

Tags

No tags attached.

Attached Files

Relationships

Notes
(0004621) xleroy (administrator) 2008-09-18 13:48	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.

(0006785) xleroy (administrator) 2012-01-23 16:37	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.

Issue History
Date Modified	Username	Field	Change
2008-08-26 16:47	Jeremie	New Issue
2008-09-04 15:54	doligez	Assigned To	=> xleroy
2008-09-04 15:54	doligez	Status	new => acknowledged
2008-09-18 13:48	xleroy	Note Added: 0004621
2008-09-18 13:48	xleroy	Severity	major => feature
2008-09-19 09:59	xleroy	Status	acknowledged => confirmed
2012-01-23 16:37	xleroy	Note Added: 0006785
2012-01-23 16:37	xleroy	Status	confirmed => resolved
2012-01-23 16:37	xleroy	Resolution	open => suspended