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

Subtle functor application bug #2388

Closed
vicuna opened this issue Mar 7, 2000 · 2 comments
Closed

Subtle functor application bug #2388

vicuna opened this issue Mar 7, 2000 · 2 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Mar 7, 2000

Original bug ID: 51
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)
Related to: #6651 #7192

Bug description

Hello!

I've been looking at Ocaml module system implementation recently and I
discovered a little subtle bug, which appears when you try to apply a
functor which is a component of a larger structure and whose type is a
"module type" defined in the same structure.....

Well, to be more explicit, here is an example of a functor F with the
caracteristics as described above, and the bug that is produced:

    Objective Caml version 2.04

module X=struct

module type SIG=sig type t=int val x:t end;;
module F(Y:SIG) : SIG = struct type t=Y.t let x=Y.x end;;

end;;
module X :
sig
module type SIG = sig type t = int val x : t end
module F : functor(Y : SIG) -> SIG
end

module DUMMY=struct type t=int let x=2 end;;

module DUMMY : sig type t = int val x : int end

(3 : X.F(DUMMY).t);;

Unbound type constructor X.F(DUMMY).t

Apparenly the type system does not know that there is a type
component "t" in the result of the application of X.F to DUMMY.
The same thing works perfectly well if SIG and F are defined at
toplevel:

    Objective Caml version 2.04

module type SIG=sig type t=int val x:t end;;

module type SIG = sig type t = int val x : t end

module F(Y:SIG) : SIG = struct type t=Y.t let x=Y.x end;;

module F : functor(Y : SIG) -> SIG

module DUMMY=struct type t=int let x=2 end;;

module DUMMY : sig type t = int val x : int end

(3 : F(DUMMY).t);;

  • : F(DUMMY).t = 3

I haven't checked with the recent version of Ocaml, but I looked at
the CVS server and I think that the error will persist...

My guess is that the functor components evaluated for X.F in the
function "components_of_module", correspond to:
fcomp_param = "Y"
fcomp_arg = "X.SIG"
fcomp_res = "X.SIG"
fcomp_env = {... SIG -> sig...end ... }
And since there is no "X.SIG" in fcomp_env but only SIG, the function
"components_of_module_application" computes empty components structure
for X.F(DUMMY).

Best regards

Jacek Chrzaszcz

--
Laboratoire de Recherche en Informatique (LRI) - Equipe DEMONS
batiment 490, bureau 153, Universite Paris-Sud 91405 ORSAY (FRANCE)
tel:33.1.69.15.42.35 - fax:33.1.69.15.65.86 - http://www.lri.fr/~jacek

@vicuna
Copy link
Author

vicuna commented Mar 9, 2000

Comment author: administrator

I've been looking at Ocaml module system implementation recently and I
discovered a little subtle bug, which appears when you try to apply a
functor which is a component of a larger structure and whose type is a
"module type" defined in the same structure.....

(3 : X.F(DUMMY).t);;

Unbound type constructor X.F(DUMMY).t

Right. Thanks for spotting that problem.

My guess is that the functor components evaluated for X.F in the
function "components_of_module", correspond to:
fcomp_param = "Y"
fcomp_arg = "X.SIG"
fcomp_res = "X.SIG"
fcomp_env = {... SIG -> sig...end ... }
And since there is no "X.SIG" in fcomp_env but only SIG, the function
"components_of_module_application" computes empty components structure
for X.F(DUMMY).

Your guess is correct. fcomp_res should be the result signature of
the functor before prefixing (so that it makes sense in fcomp_env),
and the prefixing substitution should be recorded in the
functor_components record for prefixing when components_of_module_app
computes the environment.

The working sources incorporate the fix.

All the best,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Mar 9, 2000

Comment author: administrator

Fixed in 3.00

@vicuna vicuna closed this as completed Apr 25, 2016
This was referenced Mar 14, 2019
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant