[Grace-core] minor language issues

[Andrew P Black]

My thoughts, for what they are worth!

On 13 May 2015, at 23:36, James Noble <kjx at ecs.vuw.ac.nz> wrote:

> a few smallish issues:
> 
> - should spaces be required around operators?
>  e.g. should "1+2" be legal, or should we be required to write "1 + 2".
>  requiring spaces solves a bunch of issues wrt brackets & generics

No, we should not require spaces, except around < and >

> - should more than statement be permitted on a line?
>  e.g. should "a;b;c;" be legal, or should we have to break the lines, thus:
>    a
>    b
>    c 

Yes.

> - there's no way to pass *no* varargs parameters. 
> given a multi-part method with varargs we can't call then with
> no arguments, because "()" is supposed to be illegal.

I think that this is a misapprehension.   A method that takes a variable number of arguments can clearly take zero arguments, and 
() is a reasonable way to write them.   Similarly, a method that  is declared as

	method  foo(a, b, *c)

can be requested as foo(1, 2), foo(1,2,3), and foo(1,2,3,4) , but not as foo(1).  In foo(1, 2), c is bound to an empty sequence.

What we agreed was illegal is requesting a method declared as

	method none { … }

by writing obj.none(), since the method is being given an argument list but has no parameter to bind to it.

I see nothing wrong with requesting 

	method variable(*a) { … }

as obj.variable(), since here the method `variable` is being given a parameter list of length zero which is bound to the sequence argument a.
A sequence of length zero is a perfectly respectable operation.

I think that the real question is whether it’s legal to request

	obj.variable

with no argument list at all.  In general, it’s a mistake to confuse zero with blank space, or an empty collection with no collection.

Why should methods with multiple argument list be different form those with a single argument list?

> e.g. x.foo(1) foo(11)  and x.foo(1,2) foo(11,22) are both legal, but x.foo() foo()  is not. 

x.foo() foo() seems perfectly reasonable to me, if the method in question was declared as

	method foo(*a) foo(*b)

If it wasn’t, we would get a dynamic error when foo()foo() is invoked with the wrong number of arguments.

> We don't have this problem with single-part requests because x.foo(1)  and  x.foo are both legal requests

Yes, they are both legal requests.  What’s not clear to me is if x.foo is a legal way to call a method declared with a parameter list.

> I don't think operator requests can take varargs.

I think that all infix operators take exactly 1 argument, and all prefix operator take exactly 0 arguments.

I’ve been wondering about allowing [ and ] and indeed any matched pair of brackets other than { and } and ( and ) to be declared as 
methods.  If so, can they be variable arity methods?   It would certainly be convenient to allow matched brackets of any available kind to
be used as factory methods for sequences, sets, etc.

On another, but related, tack, I’ve been thinking about how to eliminate the arity checks that currently happen on every method request.
This would be easy if it were not for variable arity methods.   But so long as we have them (and I don’t see a good alternative),  we will
need a slow path to deal with them.

It’s also a bit frustrating not to have a way of “exploding” a collection into an argument list (like JavaScript’s Function.prototype.apply()).
As with C, every Grace variable arity method really needs to be defined in terms of another method that takes a collection argument.   
It’s not terrible, but it’s a place where we have to teach a programming pattern to get around a language deficiency.   Which was one of 
the things that we said we wanted to avoid.

	Andrew