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

[Kim Bruce]

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
}

This differs from that provided in section 11 of the spec, which provides the following syntax:

type Cat { 
	color : Color
	name : String 
	miceEaten : Number 
	miceEaten:=(Number) : Unit
}

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.

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

Of course, we also haven't discussed how to even write annotations ... and we need to do that sometime soon.

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailhost.cecs.pdx.edu/mailman/private/grace-core/attachments/20110622/fbd16095/attachment.html>