[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