Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange auto-reference in recursive modules in case of name conflict with a functor parameter #5965

Closed
vicuna opened this issue Mar 28, 2013 · 2 comments
Assignees
Milestone

Comments

@vicuna
Copy link

vicuna commented Mar 28, 2013

Original bug ID: 5965
Reporter: @gasche
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2015-12-11T18:18:48Z)
Resolution: fixed
Priority: normal
Severity: minor
Target version: 4.00.2+dev
Fixed in version: 4.01.0+dev
Category: typing
Monitored by: @jberdine

Bug description

Using "module type of X" in the definition of the recursive module X is in general rejected by the type-checker:

module rec X : sig
  module type S = module type of X (*Error on this occurence*)
end = X
Error: Unbound module X

It happens to somehow work when there is a name conflict with a functor parameter:

module Conflict (X : sig type foo end) = struct
  module rec X : sig
    module type S = module type of X (* suspect occurrence *)
  end = X
end

The code above type-check correctly, but the output of -i is strange, and not consistent with the output of -dtypedtree (the latter being only available in the trunk).

ocamlc -i returns

module Conflict :
  functor (X : sig  end) ->
    sig
      module rec X :
        sig
          module type S = sig
            module type S = sig
              module type S = sig type foo end
            end
          end
        end
    end

Note the triple wrapping module type S = sig module ... which is strange.

(Reproduced on 3.12.1, 4.00.1 and trunk)

Finally, the -dtypedtree output appears to indicate instead that the suspect occurrence of X is understood as a self-reference. Here is the output, curated to remove some noise:

Pstr_module "Conflict/1034"
  Pmod_functor "X/1009" (Pmty_signature [ Psig_type [ foo/1008 .. ] ])
    Pmod_structure [
      Pstr_recmodule [
        X/1011
        (Pmty_signature [
          Psig_modtype "S/1013"
            Pmodtype_manifest (Pmty_typeof (Pmod_ident "X/1011"))
        ])
        (Pmod_constraint (Pmod_ident "X/1011")
           (Pmty_signature [
                  Psig_modtype "S/1013"
                  Pmodtype_manifest (Pmty_typeof (Pmod_ident "X/1011"))
              ]
            )
         )
      ]
    ]

Note that the arguments to Ptmy_typeof make reference not to the functor argument X/1009, but to the recursively bound identifier X/1011.

This bug was discovered and reported by Arthur Wendling.

@vicuna
Copy link
Author

vicuna commented Apr 29, 2013

Comment author: @alainfrisch

Fixed in trunk, commit 13619.

@vicuna
Copy link
Author

vicuna commented Apr 29, 2013

Comment author: @gasche

Thank you, Alain !

If I understand correctly, you exactly added the first restriction of Xavier's paper on recursive modules ( http://caml.inria.fr/pub/papers/xleroy-recursive_modules-03.pdf ), page 3, that was not necessary before the addition of "module type of" as module names did not appear in signatures (except in "open" and "with module M = .." that seems handled differently).

The approximation phase (step 1) fails if it encounters
one of the following situations:

  • include module-type in a module signature, in case module-type
    refers to one of the recursively-defined module identifiers Xi ;
  • inherit class-type in a class body type, in case class-type
    refers to a class component of one of the recursively-defined
    module identifiers X

@vicuna vicuna closed this as completed Dec 11, 2015
@vicuna vicuna added the typing label Mar 14, 2019
@vicuna vicuna added this to the 4.00.2 milestone Mar 14, 2019
@vicuna vicuna added the bug label Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants