[Grace-core] San Jose meeting

[James Noble]

carrying on from where my earlier reply left off..

> 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.

The big thing for me is having to do two definitions for variables - we could always just write var x  : T:-)
It would again mean the abbreviation - x:=(T) and x:T.
Or we just list both and be done with it.

> 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: ...

So I've a couple of big questions about this:

- how does it work with dynamic typing?  
   we don't wan't people to be able to do this kind of thing:

    z := secret_secure_object;'
    x : Dynamic := z
    x.doForbiddenOperation().

Is there an operational/dynamic interpretation of this visibility?
(like subjects / context-oriented programming perhaps?)
how would that work - or am I missing something fundamental.

- how do modules differ from classes?  Could modules be syntatic sugar for classes
	(or are modules really types?)  are definition modules types and implementation modules classes? 

- I'm tempted by ownership-style protection for objects, rather than just for names:
    but again, this would need dynamic checking to be safe in the general case.

minor points.
> 
> 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

why is this "const"?  not "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

so you're using var & const here?
doesn't const c : U mean just the same as c : U ??  

>     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.

sure... 

> 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.

I like this idea: I think it's good to get away from private & protected (at least). 
partial revelation seems to make it easier to compose systems. 
I wonder if that can be combined with Newspeak-style parameterised imports
(ie. so there are no global names?)

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

see two big questions above!

James