[Grace-core] San Jose meeting

[Kim Bruce]

Hi,

Hope all went well for James and Andrew for the end of this trip.  I thought our meeting on Saturday was very productive.  I believe both of you took pictures of our notes on the board.  Could you send me a copy?  

If either of you took good notes, I'd appreciate seeing those as well.  For example, I believe we agreed not to allow local variables to shadow instance variables (or indeed any existing defined identifiers).  I'd like to get that right in our interpreter.

A few random thoughts.

1.  It will be interesting tracing through the consequences of our ideas for going back and forth between typed and untyped worlds.  It seems to have real possibilities.

2.  I found myself being almost convinced by Gilad that we need nominal typing in order to provide better error messages.  However, that would seem to make our movement back and forth from the statically to dynamically typed worlds much harder.  It is probably easier to stick with structural typing for now as it should be relatively easy to tighten up to nominal typing.  That may be a decision we make based on whether we can come up with good error messages.

3.  After my talk at PLDesign and our other conversations, I found myself thinking about types and modules.  I'd like to spend some time working on this for the next week or two.  Here are some initial thoughts.

a.  I don't believe we've talked about how to write down object types.  I propose the following notations:

interface T {
        m(a:A, b:B) : C
	x: T1
	writeonly y: T2   // see notes below
	readwrite z: T3
}

I'd be happy to replace "interface" by "objecttype" (because I think of an interface as a module interface), but keep interface for now for consistency with Java.

Here is how we interpret this:

-- Only methods are listed.  Thus x is a parameterless method, while m has the parameters shown.  The annotations "writeonly" and "readwrite" are syntactic sugar to make things look readable.  The first indicates that there is a method "y:=(y':T2)" while the second indicates there are a pair of methods z:T3 and z:=(z': T3).

I use these keywords because we don't want to commit to having y or z as actual instance variables (they could be overridden with methods) and I think it is exceptionally ugly to have to write down method names like "y:=(...)".  Does this make sense and are you agreeable to this?  I am open to other notational suggestions.

I'd actually prefer writing writeonly and readwrite after the declaration, and perhaps surrounded by "<...>" (either before or after the declaration), though I'm uncertain as to how to get it to look good, so I'm happy to hear other suggestions.

b.  Modules

I would like to propose a simpler version of what I proposed in my talk at PLDesign.  Modules are of the following form:

Implementation Module implements DMod, ... {
     import D1, D2, ... (or better yet, D1.X, D2.Y, ...)
     interface T { ... }
     class C implements T {x: S -> ...}     // implements clause is optional
     object o {...}
     const c:U := ...              (I still prefer "=" to ":=" to associate values to constants, but oh well ...)
     var v:V := ...
     const f: T -> U := {x:T -> exp}   // is this how we specify closures?  Should we just write "function f(x:T):T = {...}?
     const makeT(x:S): T = C.new(x)   // a "factory" method
}

[Obviously we would allow more than one of each of these kinds of definitions]

Definition Module DMod {
      interface T {...}  // If this is the same as that inside implementation, then only list it here, not in implementation
           // Can also hide some methods, giving a partial revelation:
      interface T extends {
            m:....
            ...   // list only features you want publicly available outside of module
      }
     const o: U    // list type, but not implementation
     var v: V
     const f: T -> U
     const makeT(x:S): T
}

So basically, identifiers (and their associated types) are listed here, but implementation information is left out.  We could list classes, but I would discourage that compared to factory methods like makeT.

As shown in the example, we can provide partial information about an interface.  Leaving out method definitions in partial revelations would allow the designer to hide those methods.  (As I stated in my talk, I believe we could decide to entirely leave out access annotations like public and private from classes and just use the module system.)

This module system is very similar to that in Modula-3, which seemed to work well.

Feedback is welcome.  If any of this is obscure, let me know and I will elaborate.

Kim