[Grace-core] Extending types (Was Re: Type syntax)

[Kim Bruce]

Basically my proposal is that we first do a simple type system and then do the more complicated "correct" system with SelfType. The simple type system will allow specialization of return types, making methods like clone or those returning self work fine. The main issue will be specializing types returned when combined with subtyping. We will definitely want Selftype with collection classes, but there will be little impact on most cs1 topics/examples. 

Sent from my iPad

> On Feb 8, 2014, at 12:55 PM, "Andrew P. Black" <apblack at ownmail.net> wrote:
> 
> 
>> On 7 Feb 2014, at 17:27, Kim Bruce <kim at cs.pomona.edu> wrote:
>> 
>> Thanks for the clarification.  I agree with your solution to the unbound E.  Interestingly, the return type issue with Indexable Collection really only appears with immutable collections, as the Collection type doesn't show up in the return type of methods if the collections are mutable (unless you decide to throw in a clone type operation).
> 
> Actually, it does.  There is a widely flowed convention that mutation operations should return self, so that one can chain operations, as in
> 
> 	mySet.remove(4).remove(7).remove(9)
> 
> rather than having to write
> 
> 	mySet.remove(4)
> 	mySet.remove(7)
> 	mySet.remove(9)
> 
> But even without such a convention, SelfType wills till show up in clone, copyWithout(), copyWith() and so on.
> 
>> Of course, we do want to support immutable collections, so don't want to ignore this.  It is the case that handling of SelfType is easy if it appears in positive positions (like return types), so that would be a relatively simple addition.  It will, however, get more complex if SelfType can appear in negative positions (like parameter types).
> 
> It gets different, because adding operations does not create a subtype.   But I don’t see why that is “more complex”.   It does  get harder to understand the effects of type extension.   
> 
>> As I believe Michael would likely argue, this is a matter of choosing the right pluggable type system (and hence dialect) for use in this circumstance.  We will need to address this at some point, but I would urge us to get the basics designed and implemented and then decide how to support the richer SelfType.  For now we could use the (ugly) solution like that in Java, where we use matching to get the right type.  (The MyType solution in my book would work fine if we decide to implement it later.) 
> 
> As James noted, the dynamic type system will raise a dynamic error if the dynamics type of an object type does not conform to what is actually required.   If the static type system is unsound, this may come as a surprise to the programmer.   The Go folk figured that this was better than the alternative — getting the static type system “right”.   
> 
> If our static type system gives warnings, but doesn’t actually stop me from running my program if I insist, then maybe its OK not to get it right.  And maybe its OK to get it right, but “more complex”.
> 
> 	Andrew
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20140208/4bfc0633/attachment.html>