[Grace-core] Minutes of Teleconference 2013-07-24

Kim Bruce kim at cs.pomona.edu
Tue Jul 30 11:58:58 PDT 2013


For experts, I don't disagree.  However, novices will regularly leave off a parameter or put in an extra one, etc.  

In a language like Java with overloading, when we designed the library we tried to put in all variants of methods and constructors (for example with moveTo) so any reasonable combination would work.  Of course, arity doesn't resolve all such confusions.  For example, creating a point with polar versus cartesian coordinates, the arity and types are the same.  However, students do screw up and I'd rather the system let them know that they got the number of parameters wrong -- plus once they can overload by arity they'll be pushing to overload by type as well.

Finally, I do hope we require annotations for overriding as mistakes in overriding (overriding where you didn't mean to or trying to override and failing because of a typo) can be very mysterious and hard to debug.

Kim



On Jul 30, 2013, at 10:29 AM, Andrew P Black <black at cs.pdx.edu> wrote:

> 
> On 29 Jul 2013, at 14:22, Kim Bruce wrote:
> 
>> If we tried to do some type checking, we would have to invent partial object types of the form {m:T,...,n:U,?) where ? means any compatible method types might be added (compatible means we don't break our rules on overloading).  That would allow us to pick up some type errors, but at the cost of adding a great deal of complexity to the type system.  People have looked at such systems (Mitchell among others), but they have not generally been adopted because of the complexity of often having to specify negative information as well as positive.
> 
> One of the nice things about allowing overloading by arty is that you don't need negative information.  It's _always_ possible to add a method m to an existing object (through inheritance).   If there is an existing m of a different arty, then now there are two methods m, but they are statically different.   If  the new and old ms have the same arty, then th new one replaces the old one, and the type changes appropriately.  
> 
> This isn't to say that they may not be software engineering arguments in favor of requiring explicit overriding annotations, or against overloading by arity.    I'm just pouting out that the formal system gets simpler without these features.
> 
> 	Andrew
> 

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


More information about the Grace-core mailing list