Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006356OCamlOCaml typingpublic2014-03-28 10:372014-07-16 15:49
Reporterfrisch 
Assigned To 
PrioritylowSeverityfeatureReproducibilityhave not tried
StatusfeedbackResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0006356: Allowing extra 'type' fields in signature inclusion check
DescriptionIt is slightly annoying having to maintain the same definition of a type (resp. class type / module type) in both the interface and the implementation of a module, especially when the definition is not required within the implementation itself.

For instance, for a structure such as:

module type S = sig ... end
module Make(X : S) = struct ... end


one might want to give a signature which gives a name to the result type:

module type S = sig ... end
module type T = sig ... end

module Make(X : S) : T with ...


But this doesn't work: one needs to copy the definition of T within the implementation.

What about extending the inclusion check to allow more type items in the supertype? I don't know if I really want to push for it, but I'm wondering if there is any deeper implication in allowing that. The patch would be rather trivial:

Index: typing/includemod.ml
===================================================================
--- typing/includemod.ml	(revision 14492)
+++ typing/includemod.ml	(working copy)
@@ -297,6 +297,8 @@
               (* Do not report in case of failure,
                  as the main type will generate an error *)
               Field_type (String.sub s 0 (String.length s - 4)), false
+          | (Sig_type _ | Sig_modtype _ | Sig_class_type _), name2 ->
+              name2, false
           | _ -> name2, true
         in
         begin try


TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0011186)
frisch (developer)
2014-04-02 23:09

FWIW, this change enables two cases currently failing in testsuite/tests/typing-module/firstclass.ml:

module type S = sig type u type t end;;
module type S' = sig type t = int type u = bool end;;
module type S2 = sig type u type t type w end;;

let f2 (x : (module S2 with type t = 'a and type u = 'b)) =
  (x : (module S'));; (* no longer fails *)

let k (x : (module S2 with type t = 'a)) =
  (x : (module S with type t = 'a));; (* no longer fails *)
(0011216)
garrigue (manager)
2014-04-04 04:49

I would be very careful with this kind of change, because basically you enter uncharted territory.
Some properties, like the substitution property for modules, would not work anymore
(it already doesn't work stricto sensu due to open and include, but we go to another level).
A proof of soundness would be a first step :-)

- Issue History
Date Modified Username Field Change
2014-03-28 10:37 frisch New Issue
2014-04-02 23:09 frisch Note Added: 0011186
2014-04-04 04:49 garrigue Note Added: 0011216
2014-07-16 15:49 doligez Status new => feedback


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker