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

[James Noble]

On 9/02/2016, at 16:10pm, Andrew P Black <andrew.p.black at gmail.com> 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.  

that’s as may be, but this is the current syntax in Michael’s minigrace, your minigrace, Kernan, Hopper, and the spec… 

> No problem.   All the types exist to build a complete lattice.  

that is the question: do we care about the lattice being complete? 


> 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 () } 

right. I’m certainly in favour of that: the question is (again) 
how “deep” is that “convention” or “restriction” in the language.


> Not also that the diffeence between  `foo( )` and `foo( ,  )`  is purely syntactic, just like the distinction between `foo( )` and  `foo() and ()`.

sure.  And IF we went that way I’d probably want some other syntax for it. 
I agree this isn’t “overloading on type” but I’ve been calling it ”overloading on arity” 
Whatever we call it, the question is: do we want to reopen this issue. 

> 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

what I mean is: we could permit such types to exist, it would not be an error to create them,
but we could still have it be an error to attempt to instantiate such in (inconsistent) object.

i.e: we could permit 

type {
 foo { … } 
 foo(x) { … }
} 

even if we forbade

object {
 method foo { … } 
 method foo(x) { … }
} 


if we permitted the type but did not permit the object, then the type lattice would be complete,
but types that “override on arity” would be uninhabited - there could be no object of that type. 

J