Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004487OCamlOCaml generalpublic2008-01-23 00:502012-03-24 15:01
Reporterjm 
Assigned Togarrigue 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.10+dev 
Target VersionFixed in Version3.12.1+dev 
Summary0004487: Unable to override a value in a module type with ocamlc.
Description% ocamlc -v
The Objective Caml compiler, version 3.10.2+dev2 (2008-01-22)
Standard library directory: /usr/local/lib/ocaml

In a module where two values have the same name and type,
ocamlc does not complain if the related signature has two entries:

% cat m.ml
module M
  : sig val x : int
        val x : int end
  = struct let x = 0
           let x = 42 end;;
print_endline (string_of_int M.x)

% ocamlc -i m.ml
module M : sig val x : int end
% ocamlc -c m.ml
% ocaml m.ml
42


But if the signature is inside a module type,
ocamlc does complain:

% cat t.ml
module type T
  = sig val x : int
        val x : int end
module M
  : T
  = struct let x = 0
           let x = 42 end;;
print_endline (string_of_int M.x)

% ocamlc -i t.ml
module type T = sig val x : int val x : int end
module M : T
% ocamlc -c t.ml
The implementation t.ml does not match the interface (inferred signature):
Module type declarations do not match:
  module type T = sig val x : int val x : int end
does not match
  module type T = sig val x : int val x : int end
Illegal permutation of structure fields
2% ocaml t.ml
42

I would have expected ocamlc to accept a redundant value in a module type,
as ocaml does. Also, note that I'm not posting this report for the sake of hair splitting, but in order to bring into awareness a real-life issue I've encountered while dealing with module type inclusions.

Thanks for considering.
Additional InformationCurrently I'm somehow avoiding my real-life problem with Piotr Wieczorek's sigops.patch at:
  http://rainbow.mimuw.edu.pl/~pw189451/ocaml/ [^]

TagsNo tags attached.
Attached Files

- Relationships
duplicate of 0005164closed Multiple 'module type of' are incompatible 
related to 0005037closed 3.12.0+dev18: "module type of" produces unusable signatures for repeated definitions 
related to 0005061acknowledged mutiple value components in signatures should produce a warning or an error 

-  Notes
(0005523)
garrigue (manager)
2010-05-28 05:37

Fixed by only keeping the last declaration in signatures.
(0005730)
ertai (developer)
2010-12-07 17:06

This issue is not completely resolved, the fix seems to work only on the first duplicate.

$ cat bug.ml
module M : sig
  val t : bool
  val f : bool
  val t : int
  val f : int
end = struct
  let t = 42
  let f = false
end

$ ocamlc -c bug.ml
File "bug.ml", line 6, characters 6-45:
Error: Signature mismatch:
       Modules do not match:
         sig val t : int val f : bool end
       is not included in
         sig val t : int val f : int end
       Values do not match: val f : bool is not included in val f : int
(0005734)
garrigue (manager)
2010-12-12 06:41

The problem did exist in an intermediate fix, but it is already corrected in 3.12.
Your exemple is incorrect: the signatures inferred by the compiler are correct,
and indeed they do not match, so it is correct to report an error here.
(0005737)
ertai (developer)
2010-12-13 10:57

Sorry I made a mistake when reducing the bug (from around ~14000 lines of code), here is the new input:

$ cat bug.ml
module type S = sig
  val t : bool
  val f : bool
end
module M : sig
  include S
  val t : int
  val f : int
end = struct
  let t = 0
  let f = 1
end

$ ocamlc -c bug.ml
File "bug.ml", line 9, characters 6-40:
Error: Signature mismatch:
       Modules do not match:
         sig val t : int val f : int end
       is not included in
         sig val f : bool val t : int val f : int end
       Values do not match: val f : int is not included in val f : bool

This is the same output in 3.12, and today's trunk version.
(0005740)
garrigue (manager)
2010-12-13 13:13

Sorry for the confusion: this problem is completely fixed only in the
3.12 _branch_, i.e. in the upcoming version 3.12.1.
The fix will be merged in trunk following the release.

- Issue History
Date Modified Username Field Change
2008-01-23 00:50 jm New Issue
2008-02-19 15:19 doligez Status new => acknowledged
2010-04-30 17:23 doligez Relationship added related to 0005037
2010-05-27 17:01 xclerc Relationship added related to 0005061
2010-05-28 05:37 garrigue Note Added: 0005523
2010-05-28 05:37 garrigue Status acknowledged => closed
2010-05-28 05:37 garrigue Resolution open => fixed
2010-05-28 05:37 garrigue Fixed in Version => 3.12.0+dev
2010-12-07 17:06 ertai Assigned To => garrigue
2010-12-07 17:06 ertai Note Added: 0005730
2010-12-07 17:06 ertai Status closed => feedback
2010-12-07 17:06 ertai Resolution fixed => reopened
2010-12-12 06:41 garrigue Note Added: 0005734
2010-12-12 06:41 garrigue Status feedback => resolved
2010-12-12 06:41 garrigue Resolution reopened => no change required
2010-12-13 10:57 ertai Note Added: 0005737
2010-12-13 10:57 ertai Status resolved => feedback
2010-12-13 10:57 ertai Resolution no change required => reopened
2010-12-13 13:05 garrigue Relationship added duplicate of 0005164
2010-12-13 13:13 garrigue Note Added: 0005740
2010-12-13 13:13 garrigue Status feedback => resolved
2010-12-13 13:13 garrigue Fixed in Version 3.12.0+dev => 3.12.1+dev
2010-12-13 13:13 garrigue Resolution reopened => fixed
2012-03-24 15:01 xleroy Status resolved => closed


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker