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

[Andrew P Black]

On 8 Feb 2016, at 21:02, James Noble <kjx at ecs.vuw.ac.nz> wrote:

>> 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. 
> 

So we are all agreed that `foo( )` and `foo ( , )` are different.   We are also all agreed that both are allowed, in separate objects.  And we are further agreed that in designing new objects, we prefer the `foo ( ) and ( )` style to the `foo ( , )` style.

I think that we are also likely to agree that we are not going to outlaw `foo ( , )` entirely, because that form is compatible with other languages.

The only question up for debate is whether we allow `foo( )` and `foo ( , )` to be defined in the same object, or make that a syntax error.   If we make it an error, then 
combing two traits, one with `foo( )` and one with  `foo ( , )` , would also be an error, as would inheriting both, or inheriting one and then defining the other.

I’m in favor of allowing both methods to coexist, for two reasons.   The first reason is simplicity of the spec, and the implementation.   Once we have said that the two forms are different, we don’t need to make any special rules about them, in either the spec or the implementation.

The second reason is to make it easy to migrate to a better interface.   Allowing both forms makes it easy, for example, to fix the "primitive envy" smell in an interface by using "the replace primitives with object” refactoring.

The third reason of the two is that if the core language allows it, then a teaching dialect could always flag it as an error.  But if we outlaw it, a useful migration tool is forbidden to us.

	Andrew