[Grace-core] San Jose meeting

[James Noble]

>> Sure - and not just java. Tho if we don't have any other types this could just be "type"
> 
> I don't really object to interface, but "type" seems to be shorter and just what other people men by the word.  Did you have in mind reserving "type" for something else?

it depends on the structure of the types we have! 

if we allow algebraic types, or union types, etc, perhaps type means more than just an interface structure.
Although that seems to make sense only if the types are fundamentally nominal

> In the language, we use -> to indicate the return type, so it would make more sense to me to use it here too.
> If we interpret : to mean typeof, the two possibilities that occur to me would be 
> 
> 	m: A B -> C
> 
> and
> 
> 	m(A, B) -> C
> 
> The names of the parameters are not part of the type. At least, if they are part of the type, they are surely ignored during type checking, so why have them?

indeed.  I'd been thinking about m(A,B) -> C I guess.

things do get weird though give multi-part method names:

m(A) n(B) -> C is OK  but how to make that m()n() : (A)(B) -> C seems **very weird**

another example of how methods & blocks are syntactically very different in the current design

>> 
>>> Here is how we interpret this:
>>> 
>>> -- Only methods are listed.  
> 
> And I'm fine with missing out the method keyword, since everything in a type is a method.

yep. 

> I think that it makes more sense to treat x and x:=() like any other methods — I don't see why they need a special syntax.  It's just one more thing for teachers to explain and for students to learn.  The students will have already learned that a var foo gives rise to a method foo:=(), so why make them learn something else?

I'm with andrew on this. Ok, I admit I've started to get to like x:= as a name, but I hated it when Gilad suggested it.
And I do prefer it to newspeak's x:: !

>>> 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. 
> 
> I agree that in general, attributes are better going after the "thing" that they label.

two different things! 
For methods, a nice place to put metadata is between the header and the body

method m() 
 requires P
 ensures Q
 invariant X {

}

that's what Rustan's Dafny does - and it also has explicit named return variables like Go.

But for variables - I dunno. 

I keep assuming - perhaps mostly on the evidence of Ceylon, that we can do metadata annotation nicely.

>> 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
> 
> It's much better than set_x!  And it avoids the case-change problems of setX.  

indeed. 

> We have to be a bit careful of reacting against something because it looks "ugly".  Things that are different from our conditioning _will_ look ugly — until we are used to them, after which they will look natural.   Students will be less conditioned.  For them, I think that uniformity is more important than being similar to some 20th century language.  So, I believe that we should either use x:=() everywhere, and learn to love it, or not use it at all.

yep me too. Although I'm worried this leads us towards self.foo for most method calls -
but I guess if its in a good cause.  Thinking about the pythonic self.x proposal
it would remove a source of ambiguity from the language, and simplfy it.

It would make teaching procedural decomposition harder - if we keep to our decision that
methods only nest inside objects.   You couldn't do very much before teaching "self"

> I like the late binding that Gilad gets by treating imports as parameters.  That is, you as the module implementor get to state your _requirements_, not how they must be satisfied.  So if your module needs a Set class, I as a client, get to choose which Set class, provided that it meets your spec.  If your module needs a constant maxNumberOfNodes, I, as your client, get to choose it.  Otherwise, we don't actually get modularity from our modules!

me too, I like that in Newspeak (& E I guess?)
I like not having a global namespace - and think that could help with configuring "language levels"

> Moreover, providing modules with parameters also gives us the renaming that Eric Tanter was advocating.

yep  - so it does! 

> It's how we have been specifying then up until now.   Obviously, we could require a keyword function or fun or fn or λ.  The benefit would be making it clear to the novice.  The cost would be making closures bigger.  
> For me, the advantage of not having to write
> 
> 	if condition then function {oneBranch} else function {otherBranch} 
> 
> is clear, and brevity wins hands down.

right. me too. 

James