[Grace-core] Closures and classes and typing, oh my!

[Kim Bruce]

Hi,

I made it back with no further travel disasters -- just jet-lagged and otherwise exhausted.  I haven't had a chance to catch up on today's e-mails, but I did want to note two things that came up in discussion with my student assistant this morning.

1.  Closures are more than just an object with an apply (or run) method, because we are dealing with "self" specially inside closures.  That is, any occurrence of "self" inside of a closure refers to the self (if any) outside of the closure.  This takes a bit of special wiring to accomplish (we'll probably handle it by having a hidden instance variable that refers to the outer self and then changing all references to self in the closure refer to that instance variable).

The main point for bringing this up is that our closures must thus be more than just an object with a method "apply".  Of course the user could write such a method, pass it in somewhere that we expect a closure, but any uses of self in the body of the apply method would have to refer to its own self rather than the scope it was defined in.

I don't believe there is something to be fixed here, but we do need to remember that this differs from what some users may expect in the treatment of self if they do think of it as simply an object with an apply method.

2.  A key concern with classes shows up in the following example.

Suppose we have 
class A { <hidden> m(n:Number)-> String {"hello"}...}

class B {extends A.new 
	<hidden> m(n:Number) -> Number{47}...}

The definition of B should be erroneous, because B defines adds a conflicting method m with the same name, but different return types (that are not related in a subtype relation) from the one in A.  The type information associated with any objects representing class A (not objects generated by the class using new, but an object that is the "embodiment" of A) must be sufficient that we can rule out this example statically in the statically typed version of the language.  Similar issues arise with checking whether <override> is correct with respect to a hidden method.  

This is not particularly hard to do -- just make sure the object corresponding to A has those hidden method signatures available.  However, this is worse for extending objects, as we could then have no hidden methods -- i.e., everything has to show up in the type.  (I can explain more if necessary.)

Kim