[Caml-list] Allow declaring classes "final" so self type has no type variables?

[Caml-list] Allow declaring classes "final" so self type has no type variables?

[Tim Freeman]

I find that when I'm writing types of objects, there are a lot more
type variables running around than I need.  The fundamental cause of
this appears to be that it is possible to inherit from any class, so
the type of "self" for an object is never constant; it always has to
be a type variable just in case the present object is a subclass of
the object that's presently being defined.

In practice, it seems that many of the classes I write will never have
a subclass and these type variables are unnecessary.  I'd like to be
able to declare that a class will never have a subclass, and then the
compiler will be willing to unify constant types with the type of
self.  In this case, of course, any attempt to inherit the class
should get an error.

Here's some sample code illustrating the situation.  The comment at
the end shows how I'd like to be able to write the last class.

I suspect method invocation on a final class could be more efficient
than method invocation in the general case, too.

Any comments on whether this is a good idea?

-- 
Tim Freeman       
tim@fungible.com
GPG public key fingerprint ECDF 46F8 3B80 BB9E 575D  7180 76DF FE00 34B1 5C78 

(* The real hierarchy_node is exported by a package that displays trees of
   nodes in general.  The type variables are necessary. *)
class type hierarchy_node = object ('node)
  method children: 'node array
end

(* I can believe the type variables are necessary here, too. *)
class type nodetype =
object ('node)
  constraint 'node = #hierarchy_node
  method children: 'node array
  method add_child: 'node -> unit
  method parent: 'node option
end

(* I omitted a bunch of code here that uses nodetype (above) and is used by
   omitted methods on node (below).  This is why I have to separate the
   declaration of nodetype from the declaration of node. *)

(* I don't think the type variables in the definition of node make anything
   better at all.  Fundamentally, node has to be polymorphic when considering
   its own class so we can cope with taking a subclass of node.
   But I know that I don't want to take any subclasses, so I'd rather not have
   the polymorphism.  I'd like the option of telling the compiler this so I
   could avoid type variables I don't need. *)

class node ~(parent: 'node option) =
object (self: 'node)
  constraint 'node = #nodetype
                      
  val mutable children: 'node array = [||]

  initializer
    match parent with
        None -> ()
      | Some p -> p#add_child self

  method children: 'node array = children

  method add_child (n: 'node): unit =
    assert (n#parent = Some self);
    for i = 0 to Array.length children - 1 do
      assert (n != children.(i));
    done;
    children <- Array.append children [|n|]

  method parent: 'node option = parent
end

(* I propose that the way to tell the compiler that the class will never have a
   subclass is by using the new keyword "final", as in Java.  Then I could
   write something like this instead:

class final node ~(parent: node option): nodetype =
object self
  val mutable children: node array = [||]

  initializer
    match parent with
        None -> ()
      | Some p -> p#add_child self

  method children: node array = children

  method add_child (n: node): unit =
    assert (n#parent = Some self);
    for i = 0 to Array.length children - 1 do
      assert (n != children.(i));
    done;
    children <- Array.append children [|n|]

  method parent: node option = parent
end
*)
-------------------
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] Allow declaring classes "final" so self type has no type variables?

[james woodyatt]

On Friday, Sep 6, 2002, at 12:12 US/Pacific, Tim Freeman wrote:
>
> Any comments on whether this is a good idea?

Hide the class with a module signature.  Publish only the class type 
and one or more functions for constructing objects.

In other words, don't put your "class node" in the module type.  
Instead just define a function:

	val create_node: parent:nodetype option -> nodetype

The way to prevent programmers from using your class in an "inherit" 
clause is to not give them the class in the first place.  Just give 
them the class type and a collection of functions.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

-------------------
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] Allow declaring classes "final" so self type has no type variables?

[Alessandro Baretta]

james woodyatt wrote:
> On Friday, Sep 6, 2002, at 12:12 US/Pacific, Tim Freeman wrote:
> 
>>
>> Any comments on whether this is a good idea?
> 
> 
> Hide the class with a module signature.  Publish only the class type and 
> one or more functions for constructing objects.

I don't think this is what he meant. I think he would like 
to "finalize" a class for efficiency purposes as opposed to 
"safety" purposes. He is asking for some compiler magic.

Alex

-------------------
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] Allow declaring classes "final" so self type has no type variables?

[james woodyatt]

On Friday, Sep 6, 2002, at 13:38 US/Pacific, Alessandro Baretta wrote:
> james woodyatt wrote:
>> On Friday, Sep 6, 2002, at 12:12 US/Pacific, Tim Freeman wrote:
>>>
>>> Any comments on whether this is a good idea?
>>
>> Hide the class with a module signature.  Publish only the class type 
>> and one or more functions for constructing objects.
>
> I don't think this is what he meant. I think he would like to 
> "finalize" a class for efficiency purposes as opposed to "safety" 
> purposes. He is asking for some compiler magic.

The opportunity to optimize method dispatch simply isn't there.  The 
reason is that two objects with identical class types need not have 
methods with the same definition.

> 	# class a = object method f = print_string "a\n" end;;
> 	class a : object method f : unit end
> 	# class b = object method f = print_string "b\n" end;;
> 	class b : object method f : unit end
> 	# let print (p : a) = p#f;;
> 	val print : a -> unit = <fun>
> 	# print (new b);;
> 	b
> 	- : unit = ()

In the above excerpt, class a and class b are different classes with 
equivalent class types.  The function 'print' may look like it requires 
objects constructed of class a, but all it really requires is objects 
of class type a (and since class type b is equivalent to class type a, 
objects of class b will work just as well).

And anyway... last I checked, method dispatch was not the low-hanging 
fruit for optimizing Ocaml code with objects and classes.  The size of 
class initializers (generated by the compiler and executed in enclosing 
module initializers) are where it seems to me the big opportunities are 
to be had.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

-------------------
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] Allow declaring classes "final" so self type has no type variables?

[Tim Freeman]

On Friday, Sep 6, 2002, at 13:38 US/Pacific, Alessandro Baretta wrote:
> I don't think this is what he meant. 

I agree.

> I think he would like to 
> "finalize" a class for efficiency purposes as opposed to "safety" 
> purposes. 

Well, I actually wanted the class to be final so its "self" didn't
have to be polymorphic while it was being defined.  It's harder to get
the types to work out when some of the type variables running around
are useless.  No big deal, though.

> He is asking for some compiler magic.

I agree.

From: james woodyatt <jhw@wetware.com>
>The opportunity to optimize method dispatch simply isn't there.

I agree.  I had the idea because the documentation for Java says that
methods on finalized objects are faster.  The difference is that in
Java two objects are the same type if they have the same declaration,
so it's practical to find *the* declaration for the class of an
object and thus find out if the class is final.  In OCAML two
objects are the same type if they have the same bag of methods, more
or less, so there is no unique class declaration that can be
discovered to be final or not.

-- 
Tim Freeman       
tim@fungible.com
GPG public key fingerprint ECDF 46F8 3B80 BB9E 575D  7180 76DF FE00 34B1 5C78 
-------------------
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] Allow declaring classes "final" so self type has no type variables?

[james woodyatt]

On Tuesday, Sep 10, 2002, at 17:16 US/Pacific, Tim Freeman wrote:
>
> Well, I actually wanted the class to be final so its "self" didn't
> have to be polymorphic while it was being defined.

Well that's problematic, of course.  The reason class types are harder 
to use than record types is basically the same reason that polymorphic 
variant types are harder to use than regular variant types.

Perhaps someone with deeper knowledge of the issue will comment on 
whether and how it would cause problems if the self type in a class 
body could be unified with a closed object type.

> It's harder to get the types to work out when some of the type 
> variables running around are useless.

I have a technique for avoiding this kind of trouble.  Don't use class 
types where record types and/or functors are sufficient.  Keep class 
types simple, and use signatures to hide internals.  When subtyping 
without method inheritance is all you need, consider using functions 
and abstract types with polymorphic variants as phantom type parameters.

There's a lot you can do with Caml without using the 'object' keyword.  
Use classes only when all other language facilities are insufficient.

> No big deal, though.

Okay.  Hope I've been helpful anyway.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

-------------------
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