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

[James Noble]

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

yep. 

>> It's not as inconsistent as one might think - the three forms of method requests are then:
> 
> Why would I think this is inconsistent?

if not you then somebody might!

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

yes that's right. It uses up the same piece of syntax that would (e.g. in Self) be implicit operator send.

>  Currently, I'm back to thinking that implicit sends are a bad idea in general, and should be eliminated.  

I was talking to Jan Vitek about this (and a few other issues) in Thorn.
Thorn required explicit "self" and also explicit () for method calls - 
he says: 

>> this was ok. Same for (). Would have been nicer to do without but we did not figure how to do it.


> If you like,it's one more option: I can write self.foo or foo.

Yes I can see that (and also the argument for always writing () on any "method send')

Thorn is a "2-lisp" in that it has variables and methods.

They also use the quotes for arbitrary syntax in declaration of names, and setters and 
operators use that rather than special forms of method declaration - 
e.g.  def ‘e:=‘(v) { secret := v; }   (Thorn automatically creates public getters & settors
that you can override to _throw an execption_ if you want something private)

But requiring "this" and "()" for *everything* - even local variables etc -seems to go too far.

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

we can have something that isn't really a "type" declaration.  
Leaving the arrow off: returns nothing
Writing just -> returns dyanmic...

the question is if we *require* the dynamic version to check it.

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


I can see the appeal.  It probably leads towards a "public by default" status;
and it may be nonobvious to casual readers (but non-obvious in a way that doesn't matter)

for publically readable variables you can just write a public getter method (not too bad)

in some ways I think the .Net convention makes the most sense - 
it's at least partly an aesthetic choice.

I should write up a blog post (or someone else could!)

James