Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004604OCamlOCaml generalpublic2008-08-26 16:472013-08-31 12:46
ReporterJeremie 
Assigned Toxleroy 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionsuspended 
PlatformOSOS Version
Product Version3.10.2 
Target VersionFixed in Version 
Summary0004604: Exception erroneously considered values in recursive module type checking scheme
DescriptionThe "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 InformationMinimal 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.
TagsNo 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
2013-08-31 12:46 xleroy Status resolved => closed


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker