[Grace-core] Modules & Inheritance

Kim Bruce kim at cs.pomona.edu
Thu Oct 18 22:15:57 PDT 2012


It occurred to me tonight as I was navigating the LA freeways that the simplest solution is to have the associated type include the full definition.  That is the type of o1 below would be
def T{type t = {a... b..., m: ...}
That is type definitions don't just have type "type", they must exhibit the full type definition.  thus the types of o1 and o2 would be different, and anything of type T must have t = {a... b..., m: ...}

Kim



On Oct 18, 2012, at 5:12 PM, Andrew P. Black wrote:

> 
> On 18 Oct 2012, at 15:18 , Kim Bruce wrote:
> 
>> My concern is the following
>> 
>> def T = {type t, m:...}
>> 
>> def o1 = object {
>>                    type t = {a ... b...}
>>                    method m ....
>>               }
>> 
>> def o2 = object {
>>                    type t = {c ... d...}
>>                    method m ....
>>               }
>> 
>> method p(o:T) {
>>    var x: o.t
>> }
>> 
>> Now I don't know whether o.t has methods a and b or methods c and d.
> 
> Right.  And what I'm suggesting is that in this case, where o is not statically known, we either
> 
> 	(1) disallow o.t  with a message like "o not manifest"
> 
> or 
> 
> 	(2) allow it, but make it mean T.t, that is, take the t from the declared type of o.   This seems weird, but I don't think that it is, really.  Presumably, the actual t's in o1 and o2 would have to conform to T.t, or else I couldn't pass o1 and o2 as arguments to p.  So typing x as T.t might be weaker than using o1.t or o2.t, but not incompatible.
> 
> You might say, if we are going to do either of the above, my allow types in objects?  My answer is: to solve the problem that you outlined in your long email, and allow the use of objects as modules.
> 
> 	Andrew
> 



More information about the Grace-core mailing list