[Grace-core] Type syntax

[Kim Bruce]

Interestingly, pages 30 and 31 of the current Grace spec have a number of comments on this issue, and are probably worth reviewing again.

A couple of points:

1.  I went back and looked at the objectdraw library code (first 190 or so lines have type definitions).  None would be affected by Andrew's proposal.  In all of my other programs (at least as far as I could tell), all slots holding types used named types.  I never used a type literal expression as a parameter or return type, for example.

2.  I still like the proposal I apparently made in the spec (page 31), which is to restrict type expressions to only being used in type definitions.  Named types would have to be used elsewhere (though see comments in 3 below about generics).  This would also allow something like Andrew's last example (except dropping the last "type") as 

type IndexableCollection =  Collection & { at(ix:Number) -> Element; at(ix:Number) put(e:Element) }
Note that the right-hand side could not be used as the type of a parameter, however.

3.  We also need to worry about generics.  I find that a definition like

type BinarySearchTree<T> = {...}

should be fine (and unambiguous).  Note that there is no need to include "where" clauses restricting type parameters in generic type definitions, though they are clearly needed when writing classes or methods generating objects of the type.  (You could argue that the where clause should be there to indicate programmer intention, but I find that argument a bit weak.)

I like having the type parameter right after the identifier, because the right hand side of the definition is clearly a type, whereas BinarySearchTree by itself is a function from types to types.

With the proposal in 2 above, we could write
      method doSomething(s:Stack<Number>)

Similarly we could write
      method gmeth<T>(s:Stack<T>,...) -> SType<T> {...} 

If this was a method of an object then the type of the object containing the method would look something like:
     type OType = { ... gmeth<T>(s:Stack<T>) -> SType<T> ...}.

---------------

Have I missed anything important here?  

If not, I propose we adopt the proposal in (2) (with variants for generics as explained in (3)), as it is simple, has no optional "type" keywords anywhere, and virtually all existing code conforms already.

Kim



On Feb 7, 2014, at 11:48 AM, Andrew P. Black <apblack at ownmail.net> wrote:

> I’ve posted a proposed resolution at the bottom of the wiki page:  https://projects.cecs.pdx.edu:8443/~black/NewOOL/index.cgi/wiki/RevisedTypeSyntax
> and appended to this message.
> 
> I think that this solves the immediately problem.  However, in our discussions, we have identified two more:
> 
> 	(1) Overloading of ->, as Kim says below.
> 	(2) Too many parameter syntaxes.  Methods, types and blocks can all have parameters, and we use a different syntax for each.  Having three parameter syntaxes is neither Graceful nor simple.
> 
> 
> On 7 Feb 2014, at 11:20, Kim Bruce <kim at cs.pomona.edu> wrote:
> 
>> Is the main issue expressions like {a:Number -> a*a) which could be interpreted as an anonymous function or a type with method a with type Number -> a*a?
>> (Admittedly we wouldn't have a*a as a type, but you get the idea.)
> 
> 
> Proposed Resolution
> 
> Andrew Proposes the following resolution:
> 
> On the right-hand-side of a type declaration
> type NewTypeName = type { meth1(args) -> results; meth2(args2) -> results2 }
> it is permissible to omit the second type keyword. To be omittable, type must appear immediately after = and immediately before { .
> In all other cases, type literals always start with the word type
> So, for example, we would write:
> 
> type IndexableCollection =  Collection & type { at(ix:Number) -> Element; at(ix:Number) put(e:Element) }
> where the second type is compulsory.
> 
> (As an aside, the above definition doesn't work, because IndexableCollection needs to match Collection: they need the same element type and SelfType. I'll leave that to the type theoreticians to figure out.)
> 
> This continues to distinguish type declarations from other declarations, and thus we can continue to allow type parameters in these declarations.
> 
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20140207/774640ff/attachment.html>