[Grace-core] Names for the […] literal

[Kim Bruce]

While I agree that you can make sense of discriminating by number of arguments (essentially considering one to be foo_1 (for 1 argument) and the other foo_2 (for taking two arguments), I’d still like to ban them as it is not uncommon for students to screw up the number of arguments (esp. with things like points where you could use a single point variable or separate x and y coordinates).  (Though I must admit that multipart method names makes long parameter lists less of a problem.)  It’s not a life and death issue, but it is helpful to pick those up as mistakes.  

The life and death issue is overloading by static types — that we cannot do.  This is possible, but not preferable in my opinion.  I’d be happier seeing a variant of the method name (e.g. with and() or some other change).

I don’t really see how varargs plays a role here, aside from confusing the issue even more. I prefer the route of replacing them with explicit lists.

For me, two & three would simply be the bottom type, which is uninhabited.  I would like to see us indicate the problem with either a warning (or even better) an error, explaining that the type in uninhabitable.  (Of course if we allow overloading by arity, it would not be an error.) 


> On Feb 8, 2016, at 7:10 PM, Andrew P Black <andrew.p.black at gmail.com> wrote:
> 
> 
> On 8 Feb 2016, at 18:27 , James Noble <kjx at ecs.vuw.ac.nz> wrote:
> 
> 
>> type one { foo(x) }
>> type two { foo(x, y) } 
> 
> These are misleading, since the argument names are not, and never have been, part of the types.  They are there for documentation purposed only.  More properly, these types would be written as 
> 
>> type one { foo( ) }
>> type two { foo( ,  ) } 
> 
> The method names in these two cases are different, so 
> 
>    type two & three = type {  foo( )  ;   foo( ,  ) } 
> 
> No problem.   All the types exist to build a complete lattice.  
> 
> As a matter of style, we might choose not to do this, but to instill in our library writers and students the convention that they should write
> 
>    type two { foo() and () } 
> 
> instead,  but for purposes of type completeness there is not problem.
> 
> Not also that the diffeence between  `foo( )` and `foo( ,  )`  is purely syntactic, just like the distinction between `foo( )` and  `foo() and ()`.  We unlike Java, we don't need to do a type analysis to decide what method to send.   It's that type analysis that leads to "overloading" and the confusion with "overriding"  In my opinion, allowing both `foo( )` and `foo( ,  )` is not more overriding than allowing both `foo( )` and  `foo() and ()`.  In both cases, we have a pair of syntactically distinct method names.
> 
> I don't understand your phraseology when you write: 
> 
>> option 2 - permit overloading in types but NOT in objects
>> so intersection types will exist but are uninhabitable
> 
> 	Andrew
> 
>