Re: comma inference for argument lists?

> It would also be highly ambiguous.
>
> I don't think any of those is relevant to grokking a parenthesized list of
> items on separate lines. What is relevant is whether comma inference would
> create problematic ambiguities. Because Scala ignores indentation and allows
> arbitrary identifiers in infix position, comma inference seems infeasible
> for argument lists, but might be doable for other contexts such as a list of
> formal parameters (which was the original request). But allowing it in one
> context but not the other introduces an inconsistency that it might well be
> better to avoid by forgetting the whole idea.

I agree about the inconsistency, but do you care to elaborate on the
"highly ambiguous" issue? What are the problems that would show up
that haven't already been solved in the context of semicolon
inference?

If we write

 val sum = 1 + 2 + 3 + 4
   + 5 + 6 + 7 + 8 + 9

people people learn pretty quickly that owing to semicolon inference,
this doesn't have the expected effect, and that you should write a
trailing + on the first line instead. Plus, with e.g. Matt Russel's
great Scalariform formatter, you can see at once that this gets
formatted to


 val sum = 1 + 2 + 3 + 4
 +5 + 6 + 7 + 8 + 9

and here, you really *see* the problem.

Why wouldn't the same principles apply in the case of comma inference?

On Feb 9, 5:07 pm, Jim Balter <J [dot] [dot] [dot] [at] Balter [dot] name> wrote:
> On Wed, Feb 9, 2011 at 1:02 PM, Linas <vejobro [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> > On Wed, 2011-02-09 at 05:23 -0800, Jean-Philippe Pellet wrote:
> > > Imagine this file without the trailing commas. It would really look
> > > nice.
>
> It would also be highly ambiguous.
>
> > IMHO the Scala is obfuscating enough as it is. Understanding what a real
> > world Scala code snippet means usually involves running implicit
> > conversions, type inference and decoding cryptic operator names all in
> > your head. All while trying to recall the rules of the type system which
> > never ceases to surprise.
>
> I don't think any of those is relevant to grokking a parenthesized list of
> items on separate lines. What is relevant is whether comma inference would
> create problematic ambiguities. Because Scala ignores indentation and allows
> arbitrary identifiers in infix position, comma inference seems infeasible
> for argument lists, but might be doable for other contexts such as a list of
> formal parameters (which was the original request). But allowing it in one
> context but not the other introduces an inconsistency that it might well be
> better to avoid by forgetting the whole idea.
>
> -- Jim

I usually put formal arguments on separate lines when I want to add a
comment for each one, as in

class foo( // like goo, but fooier
   val bar: Int, // where you get beer
   val bat: String, // hits a ball
   val baz: Boolean // who knows?
   )

I'd be happy if an end-of-line comment inferred a comma. It would be
cleaner, and it would allow re-ordering of the arguments by moving a
line at a time without having to worry about commas.

class foo( // like goo, but fooier
   val bar: Int // where you get beer
   val bat: String // hits a ball
   val baz: Boolean // who knows?
   )

See, isn't that nicer?

Russ P.

On 10/02/2011 06:31, Russ P. wrote:
> I'd be happy if an end-of-line comment inferred a comma. It would be
> cleaner, and it would allow re-ordering of the arguments by moving a
> line at a time without having to worry about commas.

I don't mind the comma, it is unobtrusive on the eye, IMHO. But I would appreciate
allowing trailing comma, for consistency and ease of shuffling parameters.
After all, Java accepts them in array constructors:
String[] items =
{
"a",
"b",
"c",
};