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

Undefined_recursive_module #2920

Closed
vicuna opened this issue Jul 8, 2004 · 5 comments
Closed

Undefined_recursive_module #2920

vicuna opened this issue Jul 8, 2004 · 5 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jul 8, 2004

Original bug ID: 2920
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hello,

Doit-on s'attendre à des exceptions Undefined_recursive_module qui
apparaissent avec le compilateur de la branche 3.08, et pas avec 3.07 ?

(Le module ~frisch/cduce/types/types.ml provoque à l'execution:

Fatal error: exception Undefined_recursive_module("types/types.ml", 352, 0)

alors que tout se passe bien avec OCaml 3.07)

Alain

@vicuna
Copy link
Author

vicuna commented Jul 9, 2004

Comment author: administrator

Suite du bug-report 2920.

J'ai réduit le problème à:

=============================================================
module type T = sig type t val f: t -> int end

module type S = sig
include T
type elem
val x : t
val at : elem -> t
end

module F(X : T) = struct
type elem = X.t
type t = int

let x = 0
let at a = X.f a
let f x = assert false
end

module rec A :
sig type t = int val f: t -> int val blabla: int -> int end =
struct type t = int let f x = assert false let blabla x = 0 end

and B : S with type elem = A.t = F(A)

let _ = B.at 0

==> Fatal error: exception Undefined_recursive_module("types.ml", 22, 2)

-- Alain

@vicuna
Copy link
Author

vicuna commented Jul 9, 2004

Comment author: administrator

Suite du bug-report 2920.

Petite réduction supplémentaire:

========================================================
module F(A : sig val f : int -> int end) = struct
let at a = A.f a
let x = 0
end

module rec A :
sig val blabla: int -> int val f: int -> int end =
struct let blabla x = 0 let f x = 5 end

and B :
sig val at:int -> int val x : int end = F(A)

let _ = B.at 100

=======================================================

qui provoque le même problème avec OCaml 3.07.

En regardant la sortie de -dinstr, je vois ce qu'il se passe. Lorsque
le foncteur F est appliqué, la coercion est appliquée au module A
(copie de ses champs); ça crée un nouveau bloc, et c'est celui-ci qui se
retrouve dans la fermeture pour la fonction B.at. Après, caml_update_dummy
modifie le vrai bloc pour A, ce qui n'est pas suffisant pour faire marcher
B.at.

(Le comportement était caché dans 3.07 parce que les coercions étaient
plus souvent l'identité, cf correction d'un autre bug sur la compilation
du module rec.)

Cette manière de compiler le module rec me semble assez fragile: pourquoi
ne pas modifier le contenu des champs de A (écraser une fermeture par une
autre), plutôt que les champs eux-mêmes ?

-- Alain

@vicuna
Copy link
Author

vicuna commented Jul 12, 2004

Comment author: administrator

En regardant la sortie de -dinstr, je vois ce qu'il se passe. Lorsque
le foncteur F est appliqué, la coercion est appliquée au module A
(copie de ses champs); ça crée un nouveau bloc, et c'est celui-ci qui se
retrouve dans la fermeture pour la fonction B.at. Après, caml_update_dummy
modifie le vrai bloc pour A, ce qui n'est pas suffisant pour faire marcher
B.at.

(Le comportement était caché dans 3.07 parce que les coercions étaient
plus souvent l'identité, cf correction d'un autre bug sur la compilation
du module rec.)

Oui, c'est exactement cela.

Cette manière de compiler le module rec me semble assez fragile: pourquoi
ne pas modifier le contenu des champs de A (écraser une fermeture par une
autre), plutôt que les champs eux-mêmes ?

Le problème est qu'on ne sait pas prédire à l'avance la taille de ces
contenus (i.e. de la fermeture si le champ est de type fonction).

Je suis bien d'accord que ce schéma de compilation du "module rec" est
bien (trop) fragile. Malheureusement je ne vois pas d'autre
solution...

  • Xavier

@vicuna
Copy link
Author

vicuna commented Jul 12, 2004

Comment author: administrator

On Mon, 12 Jul 2004, Xavier Leroy wrote:

Le problème est qu'on ne sait pas prédire à l'avance la taille de ces
contenus (i.e. de la fermeture si le champ est de type fonction).

Dans le cas où les définitions sont des abstractions explicites, ça
marche, et c'est assez souvent le cas. Une analyse statique simple peut
faire l'affaire, sinon. Quand ce n'est pas le cas, on s'attend a des
problèmes, de toute manière, et on peut toujours mettre automatiquement
une indirection pour ces rares cas.

Je suis bien d'accord que ce schéma de compilation du "module rec" est
bien (trop) fragile.

Le fait qu'il dépende de l'ordre dans un module "pur" (avec seulement
des abstractions) est effectivement embetant...

-- Alain

@vicuna
Copy link
Author

vicuna commented Aug 13, 2004

Comment author: administrator

Revised 'module rec' compilation. XL, 2004-08-13

@vicuna vicuna closed this as completed Aug 13, 2004
@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