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

[Andrew P. Black]

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
}

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)

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

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

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

	Andrew