Version française
Home     About     Download     Resources     Contact us    
Browse thread
Problème_d'oubli_dans_un_module_[A_problem_with_modul es]
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: Problème_d'oubli_dans_un_module_[A_problem_with_modul es]
> [ I can still use ``get'': ]
> # let z = Obj.magic y;;
> val z : '_a = <poly>
> # print_int (z#get);;
> 3- : unit = ()
> [ And it works, I understand that it is guarantied to work. ]

No, it's not.  To begin with, any piece of code that contains
"Obj.magic" is not guaranteed to work.  (You'd be amazed at how many
type-based compiler optimizations can be broken by innocuous-looking
uses of Obj.magic.  I spent one full day once tracking a GC "bug" in
ocamlopt that had been reported to us; the "bug" turned out to be one
such use of Obj.magic in the user's code.  Since then, I've been
grepping for "Obj.magic" in every bug report that we get, and throwing
away immediately those where it occurs.  You've been warned!)

Second, you're making assumptions on how subtyping coercions are
compiled.  (See below.)

> [ Now, I will try to do the same thing with modules. ]
> [ Now, how can I use ``get'' ? ]
> # (Obj.magic Y: sig val get : int end).get;;

You can't.  First of all, there is no module-level equivalent of
Obj.magic.  (Thanks God.)  Second, the run-time representation of Y
really contains no "get" member, it's just the empty tuple.

Subtyping between modules is coercitive, meaning that at the point
where a module is viewed with a supertype, the run-time representation
of the module changes to reflect the change in type.  This allows to
compile accesses to structure fields by offsets (computed from the
signature of the structure) rather than by name, which is good for

In contrast, subtyping between objets doesn't change the object
representation in the OCaml compiler.  There are several reasons for
this, one being that it makes it much easier to preserve object
identity (for objects having mutable instance variables).  But one
could come up with compilation schemes where subsumption on objects
changes the internal representation.

> [ I'd like to access the forgotten get member.
> In case you are wondering, yes, this need arises 
> from a real problem. ]

What about looking for a type-safe solution to that real problem?

- Xavier Leroy