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
Recursive modules - awkward dynamic semantics #2629
Comments
Comment author: administrator Dear Markus,
This is consistent with the operational interpretation of "module rec"
I see no way to do this while remaining in a call-by-value semantics. Best regards,
|
Comment author: administrator Feature wish: compile-time detection of ill-founded "module rec" |
Comment author: administrator Dear Xavier, On Sun, 20 Jun 2004, Xavier Leroy wrote:
Well, it's certainly in accordance with the specification, but since
It might be possible to use indirections for function values, but this One workaround I had tried was to call a dummy-functor with the recursive I actually wanted to use this trick ("include"ing recursive modules) Best regards, -- |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Maybe the semantics is "awkward", or maybe it's just let-rec in call-by-value that demands eta-expansion sometimes. At any rate the dynamic semantics and lack of static analysis have remained much the same in 16 years, so I'm closing. |
Original bug ID: 2629
Reporter: administrator
Status: acknowledged
Resolution: open
Priority: normal
Severity: feature
Category: typing
Tags: recmod
Monitored by: "Julien Signoles"
Bug description
Hi,
there is a very confusing issue concerning the dynamic semantics of
recursive modules. Please consider the following code:
module type S = sig
val f : unit -> unit
val g : unit -> unit
end
module MakeA (X : S) = struct
let g = X.f
let f () = print_endline "f"
end
module MakeB (X : S) = struct
include X
end
module rec A : S = MakeA (B)
and B : S = MakeB (A)
let () = B.g ()
The above code will fail with an exception "Undefined_recursive_module",
but IMHO it should print "f".
Eta-expanding the definition of "g" in "MakeA" solves the problem.
This seems a little bit awkward to me. I think that this should be
handled transparently, i.e. that intermediate bindings are also updated
when the recursive definition is completely evaluated rather than letting
them point to the dummy function that throws an exception.
What do you think, could this be fixed?
Best regards,
Markus
--
Markus Mottl http://www.oefai.at/~markus markus@oefai.at
The text was updated successfully, but these errors were encountered: