[Grace-core] Fwd: gradual typing and objects

[Kim Bruce]

E-mail from Jeremy Siek about "open" objects.

Kim



Begin forwarded message:

> From: Jeremy Siek <jsiek at indiana.edu>
> Subject: Re: gradual typing and objects
> Date: July 29, 2013 6:50:40 PM PDT
> To: Kim Bruce <kim at cs.pomona.edu>
> 
> 
> On Jul 29, 2013, at 5:30 PM, Kim Bruce <kim at cs.pomona.edu> wrote:
> 
>> Thanks for your quick reply.
>>> 
>>>> One of the issues we've been struggling with has to do with abstract classes or objects.  Suppose an object definition invokes a method m (e.g., by self.m) when no method m occurs in the class or any of its subclasses.  The dynamic typing afficionados among us want that to work fine (perhaps emitting a warning, but certainly not an error that halts computation).  The key seems to be whether one should treat the type of self as "dynamic" or, as you do, as an object type with the methods listed in the object.  (In either case the type is implicit, as there is typically no place to write it down -- though we do have a slot for classes.)  In any case we want to be able to define abstract classes and objects, but we are in some disagreement about how to do that.
>>>> 
>>>> If you've had any experience with the version where self has implicit type dynamic, I'd be very interested in your views.
>>>> 
>>> 
>>> I'm thinking that you'd want to let the programmer choose the type for self on a per-method basis… unlike in our ECOOP paper.
>>> For a Python-like language, or Abadi-Cardelli-style calculus, where self is an explicit parameter, this is easy.
>>> If self is not an explicit parameter, then figuring out syntax for this gets tricky…
>> 
>> I suspect we'd like to avoid this. Self is not an explicit parameters, and even if it were, the notational overhead would be large.
> 
> To reduce notational overhead, there's the option of specifying the self type once per class or object definition instead
> of per method.
> 
>>> 
>>> But once the type for self is specified for a method, then the type checking of the method body should fall out according
>>> to the normal typing rules for the dynamic type and for object types.
>>> 
>>> Perhaps I should mention one thing that we're looking at beyond what was in the ECOOP paper.
>>> In the ECOOP object types were "closed" in that one cannot call a method if it isn't listed in the object type
>>> without getting a compile-time error. Since then we've thought about having "open" object types as well, that
>>> would allow calling methods not listed in the type.
>> 
>> This is exactly what some people have been pushing for.  I'd be interested in knowing what that might look like.
>> 
> 
> Ok, so there'd be an open object type that's syntactically distinguished from closed object types, perhaps 
> using two dots:
> 
> T ::= [ l_i : T_i ^{i \in 1..n} ]           closed
>       | [ l_i : T_i ^{i \in 1..n} ..]         open
> 
> Then the invoke rules for open objects would look like
> the following in an Abadi-Cardelli style object calculus
> 
> G |- e : [ l_i : T_i ^{i \in 1..n}  ..]       j \notin {1..n}
> --------------------------------------------------------------
>    G |- e.l_j  : Dyn
> 
> and
> 
> G |- e : [ l_i : T_i ^{i \in 1..n}  ..]       j \in {1..n}
> --------------------------------------------------------------
>    G |- e.l_j  : T_j
> 
> In the first situation above, their would been a run-time
> check regarding whether the l_j method is present and the return value
> would need to be cast to Dyn.
> 
> Cheers,
> Jeremy
> 
> 
> 
>> Kim
>>> 
>>> I'd be happy to discuss any of this in more detail!
>>> 
>>> Cheers,
>>> Jeremy
>>> 
>>> 
>>> _______________________________
>>> Jeremy G. Siek    <jsiek at indiana.edu>
>>> Associate Professor
>>> School of Informatics and Computing
>>> Indiana University Bloomington
>>> http://homes.soic.indiana.edu/jsiek/
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> _______________________________
> Jeremy G. Siek    <jsiek at indiana.edu>
> Associate Professor
> School of Informatics and Computing
> Indiana University Bloomington
> http://homes.soic.indiana.edu/jsiek/
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20130731/b7124796/attachment.html>