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

[Kim Bruce]

On Jun 22, 2011, at 2:34 PM, Andrew P. Black wrote:

> 
> On 22 Jun 2011, at 13:22 , Kim Bruce wrote:
> 
>> Here are a few of the things we decided on yesterday:
>> 
>> 1.  Method signatures in types.  We decided to leave out all colons in method specifications in types.  E.g.
>> 
>> type Cat {
>>        color () -> Color
>>        name() -> String
>>        miceEaten() -> Number
>> 	miceEaten:= (Number) -> Unit
>> }
> 
> Yes, that's right with respect to colons.  However, I don't recall putting in the empty parens for methods with no parameters.  We have previously worked very hard to eliminate them.  So, I believe that this examples should be:
> 
> type Cat {
>        color -> Color
>        name -> String
>        miceEaten -> Number
> 	miceEaten:= (Number) -> Unit
> }
> 
You are absolutely correct about the parentheses.  We don't yet omit them in our implementation, but eventually will.

> I vaguely recall that we had talked about using -> Void or omitting the arrow and type entirely for methods that don't return any value.  But this needs a but more thought, because without type declarations, how do we distinguish those that do return a value form those that don't?  In any case, what you wrote above is certainly OK; my only question is whether we could shorten the final method to miceEaten:= (Number)

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).
> 
>> 
>> 2.  We provisionally decided that we would include a private/public classification of method declarations in objects or classes.  Private methods could only be accessed via self or super.  Thus if m(...) is declared to be private, then self.m(...) and super.m(...) are legal, but o.m(...) will not be legal if o is not syntactically the self or super keywords.  My preference is that everything is private unless provided with the annotation "public", but I don't believe we discussed that.
> 
> 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.)
> 
> 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.  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.
> 
>> 
>> We also did not discuss how to include this annotation for (methods generated implicitly by) instance variables.  One proposal might be to include the following set of options.
>> 	var iv0: T0 := ...                        // both methods private
>>        <readonly> var iv1: T1 := ...  // only the iv1() method is public
>>        <writeonly> var iv2: T2 := ...  // only the iv2:=(...) method is public
>>        <readwrite> var iv3: T3 := ... // both methods are public
> 
> 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.

> 
>> 
>> Of course, we also haven't discussed how to even write annotations ... and we need to do that sometime soon.
> 
> Yes.
> 
>> 
>> 3.  We are considering two possibilities for numeric types.
>> a.  Rational and Float64 are independent types, not subtypes of Number (as opposed to what the spec currently says).  Operations like sqrt, sine, cosine, etc. may be written for Rational, but would give results in Float64.  It would take explicit coercions to move from one to the other.  Presumably we could use methods like "asRational" and "asFloat64".  Literals would be by default Rational unless they were annotated, e.g., 2.73 is rational while 2.73d is Float64.  Rather than writing x+y where x has type Rational and y has type Float64, we would instead have to write x.asFloat64 + y.
>> 
>> One advantage of this is simplicity.  A key advantage for me is that it is important to be able to determine statically whether something is available to be used as an index (e.g., for a list).  While I still worry about this for Rational (i.e., would we be better off having a separate Integer type), I'm willing to experiment with the Rational type to see if this works in practice.  
>> 
>> b.  Andrew is drawing up a plan for a unified system with a Number supertype for the various numeric types.
>> 
>> ---------
>> We also still need to discuss generics, particularly constrained generics.  We could talk about SelfType as well, though I am still hesitant to put that in the core of a language for novices (as opposed to an extended version).
>> 
> 
> I have no idea how to do an OO type system that is sound and complete without doing selfType, by some name or other.  Am I missing something?  Or am I just out of date?

I'm not sure we are using the same terminology.  Java doesn't have a selfType, yet is safe (at least dynamically -- stupid arrays!).

What am I missing here?
> 
> 	Andrew
> 
>