Hello again. Notice that I'm concerned about type system issues, and not how to represent objects physically, which is another important topic.
On Thu, Feb 10, 2005 at 08:14:17AM -0500, Jonathan S. Shapiro wrote:
> On Thu, 2005-02-10 at 09:44 +0100, J�rgen Hermanrud Fjeld wrote:
> > On Wed, Feb 09, 2005 at 09:38:45PM -0500, Jonathan S. Shapiro wrote:
> > > There are also the so-called "row types" in ML. These simply are not
> > > objects in the sense that concerns us.
> > >
> > Could you provide some notion to this statement?
>
> The definition of records in SML is such that each field label binds a
> global identifier. This is simply broken. In any case, row types do not
> have associated methods.
>
I was under the impression believe that the encoding of objects in O'Caml
was done with extensible records, as outlined [1] by R�my and Vouillon.
I know that O'Caml only allows one instance of a particular record
label per name space, but the restrictions seems lifted for objects,
despite objects being encoded as extensible records.
This is a valid O'Caml session:
####
# class a = object method get = 4 end ;;
class a : object method get : int end
# class b = object method get = "two" end;;
class b : object method get : string end
# let a = new a ;;
val a : a = <obj>
# let b = new b;;
val b : b = <obj>
# let get o = o#get ;;
val get : < get : 'a; .. > -> 'a = <fun>
# get a;;
- : int = 4
# get b;;
- : string = "two"
####
My understanding of row variable polymorphism is that it is a
convenient way of encoding objects such that matching occurs naturally,
where matching is the same notion that i introduced [2] by MyType and
matching by Bruce.
On a detailed level, a row variable is a "here goes any methods" flag
in an object type. The type of an object with a get method that returns
an int is
< get : ()->int >
while if a function requires a method that at least has a get method
that returns an int, the following row variable polymorphic type is
appropriate
< get:() -> int , .. >
hence the .. shows that there can be other methods in the object, but
that isn't important, and that .. is polymorphic, such that it can
operate on different "unimportant" objects, as long as the objects
agree on the get method.
Which brings us into the territory of inheritance and subtyping, or the
problem [3] of binary methods.
On Thu, Feb 10, 2005 at 09:35:46AM -0500, Swaroop Sridhar wrote:
> On Thu, 10 Feb 2005, Jonathan S. Shapiro wrote:
> > On Thu, 2005-02-10 at 09:44 +0100, J�rgen Hermanrud Fjeld wrote:
> > > I would like to know if inheritance in BitC implies overloading, as
I meant subtyping and not overloading here ^^^^^^^^^^^
> > > well as if and/or how you plan to handle binary methods?
> > >
> > I shall answer this shortly, but in the meantime can you explain what
> > you mean by "binary methods"?
> >
> I think what he means is a method like plus: c1 -> c1, which is a member
> of a class, and takes in another object of the same class.
>
Yes, exactly.
The trouble is that inheritance with contravariance on method input
parameters and covariance on output parameters prevents useful
code reuse, described briefly in the first chapter [2] by Bruce, and
by [4] Cook, Hill and Canning.
In short, by replacing subtyping with matching, a binary method can
specialize input parameters in a covariant manner, while providing
static type safety. This allows more code reuse with classes.
Matching is subtyping without subsumption, and captures the idea of
protocol extension. Objects that matches understand the same set of
messages, but the objects need not be subtypes.
The terms MyType and matching are coined by Bruce, but as it turns out
the extensible records with row polymorphic captures the same notion of
protocol extension, and is compatible with type inference.
Comparisons between MyType and extensible records with polymorphic row
variables have been conductedby for instance Bono [6], Bono and Bugliesi [5]
and less formally by R�my and Vouillon [7], in conclusion the
expressibility is the same, both capture matching in their own way.
I think the bottom line for BitC is that if you want binary methods to
interact nicely with inheritance, then you must adopt matching, and can
realistically choose between either MyType or row variables.
> If so, I guess that the next question would be:
> What are the visibality rules are among the different instantiations
> of the same class? what about represenatation abstraction?
> what about friend classes?
>
Actually no, Bruce suggests that modules are needed to do this kind of
stuff anyway, and by adding some public, private, friend keywords I'm sure one
can think of a canonical translation into an O'Caml equivalent for the
sake of type checking in BitC.
> In other words, what is the equivalent of Ocaml's:
>
> module
> .. shared state among friends
>
> .. firend class 1
> .. friend class
>
> end.
>
I perceive the O'Caml approach where module interfaces are specified
separately as very clean, but not programmer friendly, and would be prepared
to have more keyword based approach, with a canonical translation into
a signature and an implementation, but this is something I say without
having read about type system issues, and is provided by my intuition.
[1] Didier Remy and Jerome Vouillon, 1998
Objective ML: An Effective Object-Oriented Extension to ML
ftp://ftp.inria.fr/INRIA/Projects/cristal/Didier.Remy/objective-ml!tapos98.ps.gz
[2] Kim B. Bruce, 2002
Foundations of Object-Oriented Languages,
The MIT Press, Cambridge, Massachusetts, London, England.
[3] Kim B. Bruce and Luca Cardelli and Giuseppe Castagna and Jonathan
Eifrig and Scott F. Smith and Valery Trifonov and Gary T. Leavens and
Benjamin C. Pierce, 1995
On Binary Methods
http://citeseer.ist.psu.edu/article/bruce95binary.html
[4] William R. Cook and Walter Hill and Peter S. Canning, 1990
Inheritance is not subtyping
http://doi.acm.org/10.1145/96709.96721
[5] Viviana Bono and Michele Bugliesi, 1999
Matching for the lambda calculus of objects
http://citeseer.ist.psu.edu/bono98matching.html
[6] V. Bono, 1999
Type Systems for the Object Oriented Paradigm"}},
http://citeseer.ist.psu.edu/bono99type.html
[7] Didier R�my and J�r�me Vouillon, 1998
The reality of virtual types for free!
http://pauillac.inria.fr/~remy/work/virtual/virtual.html
--
Sincerely | Homepage:
J�rgen | http://www.hex.no/jhf
| Public GPG key:
| http://www.hex.no/jhf/key.txt
signature.asc
Description: Digital signature
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
