[Grace-core] Modules & Inheritance
Andrew P. Black
black at cs.pdx.edu
Fri Oct 19 15:05:27 PDT 2012
On 18 Oct 2012, at 22:15 , Kim Bruce wrote:
> 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: ...}
I think that you meant to write
type 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: ...}
Again, I think that you mean t = {a... b...}
>
>
> Kim
Yes, that's just what I was saying. Note that, although the types of o1 and o2 would be different from each other, they might both conform to type T:
def T = {type t = {a ... b ... } , m:...}
def o1 = object {
type t = {a ... b...}
method m ....
}
def o2 = object {
type t = {a ... e...}
method m ....
}
Then, when one refers to o2.t in a type context, we know that we need a manifest type, and that's T.t
In my previous email I was saying that, if o has type T, and T.t is a type, then o.t must also be a type such that o.t conforms to T.t
I can see that this creates some type-checking issues when o2.t is used in a negative (contravariant) context. Suppose that o2's method m takes an argument of type o2.t . Giving it an argument of type T.t may not be good enough, because the body of m might request method e on that argument.
The alternative — and perhaps this is what you are saying — is that if o has type T, and T.t is a type, then o.t must also be a type such that o.t = T.t. This is obviously a lot more restrictive, but the type-checking issues go away.
Andrew
Andrew
More information about the Grace-core
mailing list