Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005818OCamlOCaml typingpublic2012-11-10 15:032014-07-21 17:27
Reportertianyicui 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version4.00.1 
Target Version4.03.0+devFixed in Version 
Summary0005818: Function signatures be dropped out from recursive modules within higher order functor
DescriptionThe background can be seen from the stackoverflow question (http://stackoverflow.com/questions/13304044/implementing-okasakis-bootstrapped-heaps-in-ocaml-why-doesnt-it-compile [^]), below is a reduced example, in which, it seems the signature of HigherOrderFunctor.Base and HigherOrderFunctor2.Base are the same, but the later will not compile.

module type ORDERED =
sig
  type t
  val compare : t -> t -> int
end

module type CARRY = sig
  module M : ORDERED
end

(* works *)
module HigherOrderFunctor
  (Make : functor (X : ORDERED) -> (CARRY with module M = X))
= struct
  module rec Base
    : (ORDERED with type t = string)
    = String
  and Other
    : (CARRY with module M = Base)
    = Make(Base)
end

(* does not work *)
module HigherOrderFunctor2
  (Make : functor (X : ORDERED) -> (CARRY with module M = X))
= struct
  module rec Base
    : sig
      (* 'compare' seems dropped from this signature *)
      type t = string
      val compare : t -> t -> int
    end
    = String
  and Other
    : (CARRY with module M = Base)
    = Make(Base)
end
Tagsrecmod
Attached Filespatch file icon fix-5818.patch [^] (3,496 bytes) 2014-07-18 19:09 [Show Content]

- Relationships

-  Notes
(0011876)
shinwell (developer)
2014-07-17 12:51

This bug was discussed. It is suspected that it's a shortcoming in the type checker, but that there should be work-arounds. May be re-visited for a future release.
(0011887)
lpw25 (developer)
2014-07-18 19:09

The issue here is that inclusion checks can fail spuriously when there are module type approximations in the environment. The attached patch fixes this by weakening inclusion checks whenever the environment contains approximations. This is safe because the checks will be run again later with the correct types, and inclusion checks don't generate any information required in the rest of type-checking.
(0011892)
frisch (developer)
2014-07-21 17:27

Note that Env.t has now a flags field which is a bit mask (this is currently only in the 4.02 branch, not integrated in trunk yet). This could be used to avoid adding an extra field for contains_approx.

- Issue History
Date Modified Username Field Change
2012-11-10 15:03 tianyicui New Issue
2013-01-04 15:22 doligez Tag Attached: recmod
2013-01-04 15:23 doligez Status new => acknowledged
2013-01-04 15:23 doligez Target Version => 4.00.2+dev
2013-06-03 16:51 doligez Target Version 4.00.2+dev => 4.02.0+dev
2013-07-12 18:15 doligez Target Version 4.02.0+dev => 4.01.1+dev
2014-05-25 20:20 doligez Target Version 4.01.1+dev => 4.02.0+dev
2014-07-17 12:51 shinwell Note Added: 0011876
2014-07-17 12:51 shinwell Severity major => minor
2014-07-17 12:51 shinwell Target Version 4.02.0+dev => 4.03.0+dev
2014-07-18 19:09 lpw25 Note Added: 0011887
2014-07-18 19:09 lpw25 File Added: fix-5818.patch
2014-07-21 17:27 frisch Note Added: 0011892


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker