[Grace-core] minor language issues

[Michael Homer]

(resending copy to the list)
On Tue, May 19, 2015 at 4:56 AM, Andrew P Black
<andrew.p.black at gmail.com> wrote:
>
> On 17 May 2015, at 22:39 , James Noble <kjx at ecs.vuw.ac.nz> wrote:
>
> My thoughts, for what they are worth!
>
>
> always good!
>
>
> - 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 >
>
>
> that's what I originally thought, but I don't like the exceptions for "<"
> etc.
> I'm slowly coming around to the "all spaces, all the time" position.
>
>
> The problem that you are identifying comes from trying to use < and > as
> brackets, not from
> not allowing x+1 as an expression.   If you are not happy with teh exception
> for < and >, then let's use
> some real brackets instead of < and >.
You should always write spaces around your operators, just like and
exactly as you should always indent your code.
> - 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.
>
>
> I don't - we've talked about "()" especially being always and everywhere
> *illegal*.
> so I don't want to lose that.   And I don't like the JS/C/BCPL conventions
> where
> writing "foo" gets you the reified method for foo, while "foo()" calls it!
>
>
> I think that you are mis-remembering the discussion, but since we have been
> very bad
> at documenting discussions, I can't be sure.  I certainly agree that we
> talked about the
> C and BCPL convention where empty brackets are used to distinguish between
> referencing
> a function and invoking the function, and I agree that we decided that we
> didn't want to do that,
> mostly so that field accesses and method requests had the same syntax.
>
> But that's a completely different topic fro the current topic, which is how
> to construct an argument
> list of length zero.   () seems like a perfectly rational way of doing this.
> In fact, I can't think of
> another way of doing it — and I'm guessing that you can't either, or else
> you would have
> suggested it.   What's the problem with using () for a zero-length sequence
> of arguments?
He is remembering the discussion correctly, but it was utterly bonkers
at the time and that hasn't changed since.
> 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.
I'm not clear on why the arity checks are so objectionable; can you
elaborate? I know you want to overload methods by arity, which isn't
currently possible*, but checking arity seems an implicit part of
parameter binding anyway.

* You can get the same impact in the public interface if that's
desirable through careful use of varargs and pattern matching, but
it's not the same as multiple separated definitions.
> I have thought about getting rid of variable arity methods too,  but have
> always decided against the idea.  The argument for elimination is that it
> would simplify the language a little, and simplify the implementation
> considerably.  Without variable arity methods, the number of parameters in
> the lists of the receiving method is always known statically, so we could
> eliminate the checks on arity that currently take place on every request.
> Since method request has to be fast in any reasonable implementation of
> Grace, this is not unimportant.
>
> The downside is that programs become harder to write.  We have to explain to
> novice students why they have to write
>
> x.foo( "A", "B", [1, 2, 3])
>
>
> rather than
>
> x.foo( "A", "B", 1, 2, 3)
>
> Smalltalk doesn't have variable arity methods.  As a result, it has a kludge
> every place they would be needed, such as value, value:, value: with:,
> value: with: with:, ... and finally valueWithArguments:  Not Graceful.
>
> One possibility is to subsume variable arity methods into some more general
> scheme for methods with regular expressions for for names instead of
> strings, such as if()then()[elseif()then()]*else().    I know that you are
> fond of this, and it would eliminate three special cases from the syntax.
> But at what cost?
These may be useful for other reasons, but they aren't really a
replacement for variable-arity parameter lists unless you want to
write something like "listOf(1)and(2)and(3)and(4)..." all the time.
> I did have an early syntax where ( and ) always constructed a tuple, and
> there was a 1-tupling coercion of some sort so that x could be considered to
> be either a value or a tuple of values of length 1.  In this syntax, all
> argument lists are of length 1, and methods use a pattern-matching syntax to
> un-tuple the argument.  (Like Python 2.  Notice that Python 3 dropped this.
> Anyone know why?)
It's very fragile and broke in unexpected ways when you passed the
wrong thing in.
> Michael, you are very good at thinking through the consequences of design
> changes.  I would be surprised if you haven't considered dropping variable
> arity methods and replacing them by something else.   What did you conclude?
If you want variable-arity effects, which you probably do, variadic
parameters or collection-passing are really the only options. Hitherto
there has been opposition to collection literals, so that approach was
impractical, and it's less pleasant to work with anyway. You'd need a
strong motivation to get rid of them.
-Michael