[Grace-core] Decisions from yesterday's phone conference

[Andrew P. Black]

On 23 Jun 2011, at 4:32, James Noble wrote:

>> You are absolutely correct about the parentheses.  We don't yet omit them in our implementation, but eventually will.
> 
> so - are we cleaving to "no () parens ever" - they aren't optional, they're just not used.

Yes.  No empty parens, unless  one is explicitly constructing the empty-tuple or unit value.  

> It's not as inconsistent as one might think - the three forms of method requests are then:

Why would I think this is inconsistent?
> 
> explicit               implciit
> r.m                      m
> r + o                    !o

Didn't we agree that implicit sends are not allowed with operator symbols?  !o is an explicit send of the prefix ! operation to o.  Currently, I'm back to thinking that implicit sends are a bad idea in general, and should be eliminated.  If you like,it's one more option: I can write self.foo or foo.


> r.m(a, .,., a)        m(a, ... a)
> 
> (zero, one & infinity :-)
> 
>> I'm not sure I have real strong feelings about this, though it may be useful to require the arrow to help catch errors where it was supposed to be there.  I believe the name we talked about however, was Unit rather than Void (but not a big deal).
> 
> I think again we don't want options here - the question is how do notate "not returning a result"? 
> -> Void, -> Unit, -> Nothing (I like the last, I think!) is one way; another way is just leave the arrow & return value off.

To me, saying "returns unit" is not the same as saying does not return anything.   So I like "returns nothing".  But my concern was how to say this in the absence of type declarations. 

> 
> This seems tied into the notation for the types of Blocks (what would be called BlockClosures in Smalltalk Syntax)
> perhaps we should use the terms Block Literal  (in code) and Block Objects (in programs)
> If we use typefunctional syntax - something like BlockObject<A,B,C,Return> - then we presumably need a
> placeholder for the return value when there isn't one - back to Void/Unit/Nothing.
> If we have special syntax for those types: I dunno, in C-style where type syntax follows value syntax:
> { A, B, C -> R } we could again leave off the arrow and return type if there isn't one. 
> 
>>> It seems to be that this is a bit tricky to implement.  Whether the receiver is literally self or super is known only on the requesting side; whether the method is private is known only on the receiving side.  So this would mean somehow we have to pass an extra flag on every method request, in order that the necessary check could take place inside the receiver.  (I'm assuming that you want this to be checked.)
> 
> yes we want this to be checked...
> 
>>> An alternative would be to use as a "private" annotation something like a leading _ in the method name.  Then
>>> 
>>> 	someObject._foo
>>> 
>>> is syntactically illegal, and can be flagged statically; self._foo, on the other hand, would always be OK.
>> 
>> Of course we do want it checked.  Your notion of prefixing "_" to names works.  
> 
> In Smalltalk terms, we could say - is the "private bit" on the message selector or the method body?
> I think in our terminology it would be method name vs method body...
> 
>> Another option would simply be handling private method dispatch slightly differently than regular method dispatch (e.g., have an extra link to go through for self/super calls that would find the method bodies.  External calls wouldn't have access to that link.  Either seems OK to me, as long as they are checked -- either statically (in the statically typed version) or dynamically.  In the static world there is no problem as it definitely would be caught by the type-checker.
> 
> yep. And again, dynamically also no problem - I mean Ruby does this now.
> 
>>> Using the _ scheme would make it impossible to make one of the accessor methods public and the other private.
>>> This is probably a rare case, and rather than inventing more annotations, I suggest instead that we just let the programmer write the single method that she wants.   So for a readonly field iv1:
>>> 
>>> 	var _iv1: T1 := …
>>> 	method iv1 -> T1 {_iv1}
>> 
>> This seems to be creeping toward the notion that instance variables are private and all setters and getters must be written by the programmer.  Perhaps that's not such a bad thing (or maybe it is, I'm not sure!), but it is different from what we've been talking about.
> 
> I don't know. It shows up the advantage of the naming convention.   Otherwise you'd have the option of writing:
> 
> <<private>> var iv1 : T1 := ...
> <<overriding public>> method iv1 -> T1 {super.iv1}  /// ooh, horrid!!
> 
> Hmm. I thought I'd hate that convention (well it's not really a convention, it's a mechanism).
> Now I'm not so sure.  We could choose another character - and there is the Go rules
> initialLowercase for private; InitialUppercase -> Public. 
> This is the convention in .Net it turns out - http://msdn.microsoft.com/en-us/library/ms229043.aspx - 
> and I also like Ewan's warnings not to have conventions: either make them rules or drop them!
> The problem with that is, it will make the code look more like C# and less like Java or Smalltalk (which
> is what I'm used to).  Ahh, another unforseen side effect of the uniform syntax.
> 
> Another thing (whether good or not, I don't know) that this does is means we don't need any rules
> saying things like: private methods may not override public methods - which I think we'll need
> if we don't want to get strange effects with privacy interfering with subtyping or method resolution.
> 
> Rather, you can have the very odd effect of either both a private and public method / variable
> *with the same name* but different visibility.   There is nothing new under the sun:
> but which of these is the most graceful design?

The more we discuss the consequences of the protected annotation, the more I like the _ rule.  It's easy to check, and avoids issues like private methods overriding public ones.  

	Andrew