[Grace-core] Minutes of Teleconference 2011.08.17

[James Noble]

> My argument for using the second notation is that Factory by itself is not a class.  It is a function from types to classes.  Thus Factory[SomeType] is the actual class.  Thus this class is the one we would send a new message to.  Hence
> Factory[SomeType].new(args) is the correct syntax. 

yep - this all makes sense.  Except that (as of now) we don't have functions, or square brackets acting as functions
in Grace --- so I don't know what Factory[SomeType] is (or for that matter what Factory without the brackets is)

I half wonder if we shouldn't explicitly introduce a third level into the language ontology - so we'd
have objects; classes; and then generic classes (or "class schemes" or "templates")...

> Similarly if we assume the declaration of Factory is something like the following:
> 
> class Factory[T] implements GenType[T] { ... }
> 
> then not surprisingly we get the following typing:
> 
> Factory[SomeType].new(...)  :  GenType[SomeType]
> 
> Doesn't that seem more parallel?  

sure it does - but now - especially with the "rewrite into object literals" story,
we don't have a good account of what the Factory is, or how the [SomeType] works.

If we did have a "[]" operator, then we could actually handle things as you suggest
(Michael and I talked about this yesterday) 

> Just as GenType by itself is not a type (stomp out "erasures"!), so Factory by itself is not a class.  Both are functions from types to types/classes.

sure. Note that we can't really "stomp our erasures" if we wish to have collections
(or more generally, generic classes or whatever we call them) that work both
statically & dynamically typed.  I fear we need to write GenType meaning GenType[dynamic]
for each of GenTypes' type parameters. 

Note the ambiguity on the use of square brackets [] as a postfix operator, and for type parameters
really only arises on method parameters. I'm assuming we follow Java (and Scala, and C#) where
generic method parameters are inferred if they can be, but optionally may be specified explicitly.

So writing m[T] to supply type arguments to m is ambiguous with m[x] as an indexing operator.
Going to a Java style syntax where type arguments precede the method name  [T]m would resolve
the ambiguity.  

This also affects how we'll actually write generic type calls - presumably we could arrange the inference
(as in Java) so writing something like this:

def x : GenType[SomeType]  := Factory.new(...)  : 

would infer the types parameters for the Factory method or for the factory. 
Of course going the other way still needs type argumemnts on the Factory:

def x :  := Factory.[SomeType]new(...)  : 

cheers

James