[Caml-list] Creating mutually dependent objects?

[Caml-list] Creating mutually dependent objects?

[Thorsten Ohl]

I need to create tuples of mutually dependent objects.  A working
implementation adds a mutable instance variable that is updated after
all objects in a tuple have been created.  With a little bit of work,
this variable can then be hidden.  However, this is a bit tedious.
Why is the much more elegant approach using `let rec' forbidden?

    # class o n o' =
      object (_ : 'a)
	method o' : 'a = o'
	method n : int = n
      end;;
	    class o : int -> 'a -> object ('a) method n : int method o' : 'a end
    # let rec o1 = new o 1 o2 and o2 = new o 2 o1;;
    Characters 13-23:
      let rec o1 = new o 1 o2 and o2 = new o 2 o1;;
		   ^^^^^^^^^^
    This kind of expression is not allowed as right-hand side of `let rec'

Is there a chance that this restriction will be lifted or would such
permissiveness undermine type safety?
-- 
Thorsten Ohl, Physics Dept., Wuerzburg Univ. -- ohl@physik.uni-wuerzburg.de
http://theorie.physik.uni-wuerzburg.de/~ohl/     [<=== PGP public key here]
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Creating mutually dependent objects?

[Jacques Garrigue]

From: Thorsten Ohl <ohl@physik.uni-wuerzburg.de>

> I need to create tuples of mutually dependent objects.  A working
> implementation adds a mutable instance variable that is updated after
> all objects in a tuple have been created.  With a little bit of work,
> this variable can then be hidden.  However, this is a bit tedious.
> Why is the much more elegant approach using `let rec' forbidden?
> 
> Is there a chance that this restriction will be lifted or would such
> permissiveness undermine type safety?

Sure it would: the type system cannot ensure that o1 and o2 will be
initialized at the right time. That is, you could end up with null
pointer errors, which from ocaml point of view are holes in the type
safety. By not allowing them, ocaml also avoids the cost of
dynamically checking for null pointer, as Java does for instance.

A generic answer to that is to use lazy variables (they are more
clever in 3.05).

# class o n o' =
  object (_ : 'a)
    method o' : 'a =     Lazy.force o'
    method n : int = n
  end;;    
class o : int -> 'a Lazy.t -> object ('a) method n : int method o' : 'a end
# let rec o1 = lazy (new o 1 o2) and o2 = lazy (new o 2 o1);;
val o1 : o Lazy.t = <lazy>
val o2 : o Lazy.t = <lazy>
# let o1 = Lazy.force o1 and o2 = Lazy.force o2;;
val o1 : o = <obj>
val o2 : o = <obj>

Note that it will not protect you against null pointer errors, it will
just allow you to detect them at runtime. You can see this with:

# class o n o' =
  let o' = Lazy.force o' in
  object (_ : 'a)   
    method o' : 'a = o'
    method n : int = n
  end;;    
class o : int -> 'a Lazy.t -> object ('a) method n : int method o' : 'a end
[..]
# let o1 = Lazy.force o1 and o2 = Lazy.force o2;;
Exception: Lazy.Undefined.
(Stack overflow with previous versions)

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Creating mutually dependent objects?

[John Prevost]

>>>>> "to" == Thorsten Ohl <ohl@physik.uni-wuerzburg.de> writes:

    to> I need to create tuples of mutually dependent objects.  A
    to> working implementation adds a mutable instance variable that
    to> is updated after all objects in a tuple have been created.
    to> With a little bit of work, this variable can then be hidden.
    to> However, this is a bit tedious.  Why is the much more elegant
    to> approach using `let rec' forbidden?

Think of it in terms of "if a variable holds a value of type t, the
value *must* be a legal value of that type."  In your example, you'd
like to be able to say:

    to> let rec o1 = new o 1 o2 and o2 = new o 2 o1;;

But this can't be done, because the compiler can't know what you mean
to do with the two "new o" calls.  Consider that instantiating an
object is essentially a function call, and can run arbitrary code.
It's like wanting to be able to say:

let fun test x y = (x,y)

let rec o1 = test 1 o2 and o2 = test 2 o1

You can convert this definition to:

let rec o1 = (1,o2) and o2 = (2,o1)

This statement is indeed legal, if you have -rectypes turned on.  And
class types always hae rectypes turned on.


So what's the problem?  Why doesn't the compiler allow the version
with function calls even though it can be converted to an expression
that's allowed?  Well, this function has the same type as test, but
can't be converted to anything good:

let fun test2 (a,b) y = (a+1,y)

In this case, the two "objects" would have to be constructed by
sharing values.  You can't construct either o1 or o2 first because it
requires a valid, fully constructed copy of the other value before it
can be constructed itself.


So that's what's going on.  Since object constructors are like
functions and can use their arguments in code, the arguments must be
well-typed values.  Value constructors (record {..} expressions, sum
type constructors, and the like) are not allowed to run code--they
just plop the value down in the appropriate place.  And even then, if
they're hidden behind functions, they can't be used this way, since
it's *syntactic analysis* of the code that allows these constructions
to be used in a let rec.


Hope this was helpful,

John.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Creating mutually dependent objects?

[Thorsten Ohl]

John Prevost <j.prevost@cs.cmu.edu> writes:

> Value constructors [...] are not allowed to run code--they just plop
> the value down in the appropriate place.  And even then, if they're
> hidden behind functions, they can't be used this way, since it's
> *syntactic analysis* of the code that allows these constructions to
> be used in a let rec.

I see.  My error was to overlook that a typechecker can't figure out
that the mutual references are never used as arguments to non trivial
functions.

> Hope this was helpful,

It was.

Thanks,
-Thorsten
-- 
Thorsten Ohl, Physics Dept., Wuerzburg Univ. -- ohl@physik.uni-wuerzburg.de
http://theorie.physik.uni-wuerzburg.de/~ohl/     [<=== PGP public key here]
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners