caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Problème d'oubli dans un module [A problem with modules]
@ 1999-10-30  2:41 Valentin Bonnard
  1999-11-07 14:21 ` Xavier Leroy
  0 siblings, 1 reply; 2+ messages in thread
From: Valentin Bonnard @ 1999-10-30  2:41 UTC (permalink / raw)
  To: caml-list

Avec les objets, je peux faire ceci:

[ With objects, I can do this: ]

# class vide = object end 
    and foo = object method get = 3 end;;
class vide : object end
class foo : object method get : int end

Je crée un objet avec une méthode get:

[ I create an object with a method called get: ]

# let x = new foo;;
val x : foo = <obj>

J'oublie get:

[ I forget ``get'': ]

# let y = (x :> vide);;
val y : vide = <obj>

Je vérifie que get n'est plus là:

[ And ``get'' isn't there anymore: ]

# y#get;;
This expression has type vide
It has no method get

J'utilise get quand même:

[ 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. ]

Maintenant, les modules.

[ Now, I will try to do the same thing with modules. ]

# module type vide = sig end;;
module type vide = sig end

Je crée un module avec get:

[ I create a module with a member called ``get'': ]

# module Foo = struct let get = 3 end;;
module Foo : sig val get : int end

J'oublie get:

[ Again, I forget the ``get'' member: ]

# module Y = (Foo: vide);;
module Y : vide

Je vérifie que get n'est plus là:

[ I can't access the forgotten member: ]

# Y.get;;
Unbound value Y.get

Comment utiliser get quand même ?

[ Now, how can I use ``get'' ? ]

# (Obj.magic Y: sig val get : int end).get;;
Syntax error

Je voudrais récupérer get.

Cette question vient d'un problème réel.

[ I'd like to access the forgotten get member.

In case you are wondering, yes, this need arises 
from a real problem. ]

-- 

Valentin Bonnard



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Problème d'oubli dans un module [A problem with modules]
  1999-10-30  2:41 Problème d'oubli dans un module [A problem with modules] Valentin Bonnard
@ 1999-11-07 14:21 ` Xavier Leroy
  0 siblings, 0 replies; 2+ messages in thread
From: Xavier Leroy @ 1999-11-07 14:21 UTC (permalink / raw)
  To: Valentin Bonnard, caml-list

> [ 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
efficiency.

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



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1999-11-07 21:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-10-30  2:41 Problème d'oubli dans un module [A problem with modules] Valentin Bonnard
1999-11-07 14:21 ` Xavier Leroy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).