[Grace-core] San Jose meeting

[Eric Tanter]

Hi James, Kim,

Just two quick comments on what you report here.

- nominal/structural: Donna Malayeri came up with a nice way to actually have both (in essence a type really has two components, a nominal one and a structural one, which are optional in the syntax). ECOOP'08 I think, the language was called Unity.

- module system: the Racket experience tends to suggest that a very useful feature is to have explicit exports in modules, with renaming support in both imports and exports (ie. you can import X as Y, and export Z as T). That's very helpful so that you can implement your module as you believe it should, with the names you like, and don't have to worry about clashes with what you import and what you (have to) export.

Hope this is somewhat useful (sorry if that was obvious/already discussed)

Best,

-- Éric


On Jun 6, 2011, at 8:49 PM, James Noble wrote:

> Hi Kim 
> 
>> Hope all went well for James and Andrew for the end of this trip.
> 
> Yeah all good. Jan dropped me back to the hotel, and made some more notes then slept - I was exhausted after it all. 
> 
>> I thought our meeting on Saturday was very productive.
> 
> Yes me too!
> 
>> I believe both of you took pictures of our notes on the board.  Could you send me a copy?  
> 
> Yep but I deleted it from my phone 
> I'll send them along later. (in seminar at MSR) 
> 
>> 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.
> 
> Yes. I think that was it - I put that up on the blog. I think of it as finding the kind of pointlessly difficult programs I'd set in my terms test and banning them..
> 
>> 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.
> 
> Yes!  I think we made a good start on that and other things...
> 
>> 2.  I found myself being almost convinced by Gilad that we need nominal typing in order to provide better error messages.
> 
> ...
> 
> Was just talking to Manuel Fandrich who also liked structural types. 
> 
>> However, that would seem to make our movement back and forth from the statically to dynamically typed worlds much harder.
> 
> Hmm or less flexible. 
> 
>> 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.
> 
> Yep..  There is also a Scala like mixed option.  Hopefully we can factor the subtype relation out of the rest of the spec - and also out of interpreters at least.
> 
> But I should probably put that onto the list. 
> 
>> 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.
> 
> OK good
> 
>> 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
>> }
> 
> There is a bit in the latest spec. 
> 
>> 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.
> 
> Sure - and not just java. Tho if we don't have any other types this could just be "type"
> 
>> 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 think it makes sense - not sure I at least agree. 
> 
> 
>> 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.
> 
> I think we should be able to get a common approach to metadata/attributes/annotations which might help here. 
> 
> But if the method is called x:= then shouldn't that be in the interface?  If we really dont like that syntax shouldn't we change it to match?  For what it's worth I think x:= isnt too bad and was convinced it was better then set_x
> 
>> 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:
> 
> Ok...  I wondered if you would. 
> 
>> 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 ...)
> 
> So do we all but Michael was persuasive...
> I guess xp
> 
>>    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
>> 
>> 
>> 
>> 
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core
>