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

[James Noble]

On 9/02/2016, at 20:39pm, Andrew P Black <andrew.p.black at gmail.com> wrote:

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

yes.

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

yes. 

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

that is the *main* question for debate here: the current answer is “no”

there is a subsidiary question - even if the answer remains “no” -
as to whether we allow foo(0) and foo(2) in the same *type*.
if the answer is “yes” then we have to allow both in the same type. 

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

I note that this their reason is exactly the one that that I am using to say we should support symmetric semantics for inheritance.

James