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

comma inference for argument lists?

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

I sometimes write class definition headers with each argument on a
separate line with a trailing comment, as in:

class foo( // this is a class called foo
val bar: Int, // this is the first argument
val bax: Boolean = true, // this is the second argument
val baz: String = "" // this is the third argument
)

If I then try to rearrange the order of the arguments, I may need to
insert or delete commas. It occurred to me that maybe the commas could
be inferred using rules very similar to the semicolon inference rules
in Scala. Then I would have:

class foo( // this is a class called foo
val bar: Int // this is the first argument
val bax: Boolean = true // this is the second argument
val baz: String = "" // this is the third argument
)

That form is cleaner, and it simplifies the reordering of arguments.
Is it reasonable, or does it take simplicity a step too far?

Russ P.

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: comma inference for argument lists?
Scala used to support an extra comma at the end, which solves the problem since you can append comma to all lines. It was removed because it overly complicated the parser (IIRC) to little gain. Personally, I liked the extra comma -- it is helpful with DSLs.

On Mon, Jan 24, 2011 at 18:32, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
I sometimes write class definition headers with each argument on a
separate line with a trailing comment, as in:

class foo( // this is a class called foo
   val bar: Int, // this is the first argument
   val bax: Boolean = true, // this is the second argument
   val baz: String = "" // this is the third argument
   )

If I then try to rearrange the order of the arguments, I may need to
insert or delete commas. It occurred to me that maybe the commas could
be inferred using rules very similar to the semicolon inference rules
in Scala. Then I would have:

class foo( // this is a class called foo
   val bar: Int // this is the first argument
   val bax: Boolean = true // this is the second argument
   val baz: String = "" // this is the third argument
   )

That form is cleaner, and it simplifies the reordering of arguments.
Is it reasonable, or does it take simplicity a step too far?

Russ P.



--
Daniel C. Sobral

I travel to the future all the time.
Dan Shryock
Joined: 2010-01-07,
User offline. Last seen 42 years 45 weeks ago.
Re: comma inference for argument lists?

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

Dan

James Iry
Joined: 2008-08-19,
User offline. Last seen 1 year 23 weeks ago.
Re: comma inference for argument lists?
Won't work with Scala's syntax.
Consider "foo(a b c)".  Is that saying "foo(a, b, c)"? or "foo(a.b(c))"?  At parse time it could be either.

On Mon, Jan 24, 2011 at 12:32 PM, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
I sometimes write class definition headers with each argument on a
separate line with a trailing comment, as in:

class foo( // this is a class called foo
   val bar: Int, // this is the first argument
   val bax: Boolean = true, // this is the second argument
   val baz: String = "" // this is the third argument
   )

If I then try to rearrange the order of the arguments, I may need to
insert or delete commas. It occurred to me that maybe the commas could
be inferred using rules very similar to the semicolon inference rules
in Scala. Then I would have:

class foo( // this is a class called foo
   val bar: Int // this is the first argument
   val bax: Boolean = true // this is the second argument
   val baz: String = "" // this is the third argument
   )

That form is cleaner, and it simplifies the reordering of arguments.
Is it reasonable, or does it take simplicity a step too far?

Russ P.

Alex Repain
Joined: 2010-07-27,
User offline. Last seen 1 year 31 weeks ago.
Re: comma inference for argument lists?
I got the same hunch. It's a quite contrieved example, and one that nobody should follow anyway but :

scala> class A {
     | def bar(a: A):A = a
     | }
defined class A

scala> class B {
     | def foo(a:A, b: A => A, c: A) = println("3-arg foo")
     | def foo(a:A) = println("1-arg foo")
     | }
defined class B

scala> val a = new A
a: A = A@1c6cc9c

scala> val b = new B
b: B = B@32a325

scala> b.foo(a bar a)
1-arg foo

scala> val bar = (a:A) => a
bar: (A) => A = <function1>

scala> b.foo(a, bar, a)
3-arg foo

So, this is not that unambiguous. At least it proves the problem would be really complex.

Alex

2011/1/24 James Iry <jamesiry [at] gmail [dot] com>
Won't work with Scala's syntax.
Consider "foo(a b c)".  Is that saying "foo(a, b, c)"? or "foo(a.b(c))"?  At parse time it could be either.

On Mon, Jan 24, 2011 at 12:32 PM, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
I sometimes write class definition headers with each argument on a
separate line with a trailing comment, as in:

class foo( // this is a class called foo
   val bar: Int, // this is the first argument
   val bax: Boolean = true, // this is the second argument
   val baz: String = "" // this is the third argument
   )

If I then try to rearrange the order of the arguments, I may need to
insert or delete commas. It occurred to me that maybe the commas could
be inferred using rules very similar to the semicolon inference rules
in Scala. Then I would have:

class foo( // this is a class called foo
   val bar: Int // this is the first argument
   val bax: Boolean = true // this is the second argument
   val baz: String = "" // this is the third argument
   )

That form is cleaner, and it simplifies the reordering of arguments.
Is it reasonable, or does it take simplicity a step too far?

Russ P.


James Iry
Joined: 2008-08-19,
User offline. Last seen 1 year 23 weeks ago.
Re: comma inference for argument lists?
Alex,
At parse time it doesn't matter what classes and methods you've defined, at least as long as you want an unambiguous context free parser.  A parser has to assign syntactic roles to every token long before anything is known about what identifiers "mean".  The alternative, a parser that understands identifier semantics or that ambiguously creates multiple parse trees for semantic analysis, is too painful to consider (ask any C++ compiler writer).
In other words, it doesn't matter whether there's a case where foo(a,b,c) and foo(a.b(c)) are both semantically valid because they are always both syntactically valid and the current Scala syntactic rules say that foo(a b c) means the later.  Any attempt to infer commas at parse time is going to run afoul of that.

On Mon, Jan 24, 2011 at 2:19 PM, Alex Repain <alex [dot] repain [at] gmail [dot] com> wrote:
I got the same hunch. It's a quite contrieved example, and one that nobody should follow anyway but :

scala> class A {
     | def bar(a: A):A = a
     | }
defined class A

scala> class B {
     | def foo(a:A, b: A => A, c: A) = println("3-arg foo")
     | def foo(a:A) = println("1-arg foo")
     | }
defined class B

scala> val a = new A
a: A = A@1c6cc9c

scala> val b = new B
b: B = B@32a325

scala> b.foo(a bar a)
1-arg foo

scala> val bar = (a:A) => a
bar: (A) => A = <function1>

scala> b.foo(a, bar, a)
3-arg foo

So, this is not that unambiguous. At least it proves the problem would be really complex.

Alex

2011/1/24 James Iry <jamesiry [at] gmail [dot] com>
Won't work with Scala's syntax.
Consider "foo(a b c)".  Is that saying "foo(a, b, c)"? or "foo(a.b(c))"?  At parse time it could be either.

On Mon, Jan 24, 2011 at 12:32 PM, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
I sometimes write class definition headers with each argument on a
separate line with a trailing comment, as in:

class foo( // this is a class called foo
   val bar: Int, // this is the first argument
   val bax: Boolean = true, // this is the second argument
   val baz: String = "" // this is the third argument
   )

If I then try to rearrange the order of the arguments, I may need to
insert or delete commas. It occurred to me that maybe the commas could
be inferred using rules very similar to the semicolon inference rules
in Scala. Then I would have:

class foo( // this is a class called foo
   val bar: Int // this is the first argument
   val bax: Boolean = true // this is the second argument
   val baz: String = "" // this is the third argument
   )

That form is cleaner, and it simplifies the reordering of arguments.
Is it reasonable, or does it take simplicity a step too far?

Russ P.



Alex Repain
Joined: 2010-07-27,
User offline. Last seen 1 year 31 weeks ago.
Re: comma inference for argument lists?
So I guess we are agreeing then ? I didn't say nothing about parse time, but was joining you on the inconsistence with Scala syntax. Then again, although a parser will indeed not give a shit about semantics, if you want it to be unambiguous it can't be consistent with Scala's current rules concerning infix notation, and I just provided some example. Or am I missing your point here ?

2011/1/24 James Iry <jamesiry [at] gmail [dot] com>
Alex,
At parse time it doesn't matter what classes and methods you've defined, at least as long as you want an unambiguous context free parser.  A parser has to assign syntactic roles to every token long before anything is known about what identifiers "mean".  The alternative, a parser that understands identifier semantics or that ambiguously creates multiple parse trees for semantic analysis, is too painful to consider (ask any C++ compiler writer).
In other words, it doesn't matter whether there's a case where foo(a,b,c) and foo(a.b(c)) are both semantically valid because they are always both syntactically valid and the current Scala syntactic rules say that foo(a b c) means the later.  Any attempt to infer commas at parse time is going to run afoul of that.

On Mon, Jan 24, 2011 at 2:19 PM, Alex Repain <alex [dot] repain [at] gmail [dot] com> wrote:
I got the same hunch. It's a quite contrieved example, and one that nobody should follow anyway but :

scala> class A {
     | def bar(a: A):A = a
     | }
defined class A

scala> class B {
     | def foo(a:A, b: A => A, c: A) = println("3-arg foo")
     | def foo(a:A) = println("1-arg foo")
     | }
defined class B

scala> val a = new A
a: A = A@1c6cc9c

scala> val b = new B
b: B = B@32a325

scala> b.foo(a bar a)
1-arg foo

scala> val bar = (a:A) => a
bar: (A) => A = <function1>

scala> b.foo(a, bar, a)
3-arg foo

So, this is not that unambiguous. At least it proves the problem would be really complex.

Alex

2011/1/24 James Iry <jamesiry [at] gmail [dot] com>
Won't work with Scala's syntax.
Consider "foo(a b c)".  Is that saying "foo(a, b, c)"? or "foo(a.b(c))"?  At parse time it could be either.

On Mon, Jan 24, 2011 at 12:32 PM, Russ P. <russ [dot] paielli [at] gmail [dot] com> wrote:
I sometimes write class definition headers with each argument on a
separate line with a trailing comment, as in:

class foo( // this is a class called foo
   val bar: Int, // this is the first argument
   val bax: Boolean = true, // this is the second argument
   val baz: String = "" // this is the third argument
   )

If I then try to rearrange the order of the arguments, I may need to
insert or delete commas. It occurred to me that maybe the commas could
be inferred using rules very similar to the semicolon inference rules
in Scala. Then I would have:

class foo( // this is a class called foo
   val bar: Int // this is the first argument
   val bax: Boolean = true // this is the second argument
   val baz: String = "" // this is the third argument
   )

That form is cleaner, and it simplifies the reordering of arguments.
Is it reasonable, or does it take simplicity a step too far?

Russ P.




Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: comma inference for argument lists?
On Mon, Jan 24, 2011 at 2:16 PM, James Iry <jamesiry [at] gmail [dot] com> wrote:
Won't work with Scala's syntax.
Consider "foo(a b c)".  Is that saying "foo(a, b, c)"? or "foo(a.b(c))"?  At parse time it could be either.

This appears to be a reply to my original post (which you quoted), but apparently you did not understood it. My suggestion for inferred commas was only for function/method definitions, not calls. Or perhaps you were replying to another post, in which case your reply makes perfect sense.

By the way, I hope scala-debate gets moved over completely to google groups soon, because it is a bit confusing dealing with both the google groups and the old mailing list at the same time.

Russ P.

--
http://RussP.us
Alex Repain
Joined: 2010-07-27,
User offline. Last seen 1 year 31 weeks ago.
Re: comma inference for argument lists?


2011/1/25 Russ Paielli <russ [dot] paielli [at] gmail [dot] com>
On Mon, Jan 24, 2011 at 2:16 PM, James Iry <jamesiry [at] gmail [dot] com> wrote:
Won't work with Scala's syntax.
Consider "foo(a b c)".  Is that saying "foo(a, b, c)"? or "foo(a.b(c))"?  At parse time it could be either.

This appears to be a reply to my original post (which you quoted), but apparently you did not understood it. My suggestion for inferred commas was only for function/method definitions, not calls. Or perhaps you were replying to another post, in which case your reply makes perfect sense.

If he was mistaken, I fell in the same mistake as his, so sorry for the spam. Jim Powers post mentioning "foo(a b c) and foo(a,b,c) are both equally unambiguous." kinda confused me.



By the way, I hope scala-debate gets moved over completely to google groups soon, because it is a bit confusing dealing with both the google groups and the old mailing list at the same time.

Russ P.

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

Sorry, I generally was referring to function definition not really so
much function application.

But to the point about parse-time vs semantic analysis

f(a b c) parses fine. Only later does one discover whether or not
there is a 'b' on (directly or indirectly) on the type of 'a' taking a
'c'. If such an occurrence happens then all is well, except when
there are two or more pathways to satisfying the constraints. However
(sadly), treating as ',' will always cause an ambiguity
in function application (as already stated), but in function
definition no such ambiguity arises.

On Jan 24, 6:37 pm, Alex Repain wrote:
> 2011/1/25 Russ Paielli
>
> > On Mon, Jan 24, 2011 at 2:16 PM, James Iry wrote:
>
> >> Won't work with Scala's syntax.
>
> >> Consider "foo(a b c)".  Is that saying "foo(a, b, c)"? or "foo(a.b(c))"?
> >>  At parse time it could be either.
>
> > This appears to be a reply to my original post (which you quoted), but
> > apparently you did not understood it. My suggestion for inferred commas was
> > only for function/method definitions, not calls. Or perhaps you were
> > replying to another post, in which case your reply makes perfect sense.
>
> If he was mistaken, I fell in the same mistake as his, so sorry for the
> spam. Jim Powers post mentioning "foo(a b c) and foo(a,b,c) are both equally
> unambiguous." kinda confused me.
>
>
>
>
>
>
>
> > By the way, I hope scala-debate gets moved over completely to google groups
> > soon, because it is a bit confusing dealing with both the google groups and
> > the old mailing list at the same time.
>
> > Russ P.
>
> > --
> >http://RussP.us

Stefan W.
Joined: 2008-09-10,
User offline. Last seen 46 weeks 2 days ago.
Re: comma inference for argument lists?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russ P. schrieb:
> I sometimes write class definition headers with each argument on a
> separate line with a trailing comment, as in:
>
> class foo( // this is a class called foo
> val bar: Int, // this is the first argument
> val bax: Boolean = true, // this is the second argument
> val baz: String = "" // this is the third argument
> )

You may put the comma in front, like this:

// this is a class called foo
class foo (val bar: Int // this is the first argument
, val bax: Boolean = true // this is the second argument
, val baz: String = "" // this is the third argument
)

In some cases you still need to fuddle with the commas, but it will be
much more obvious. I use this technique all the time with SQL:

q = """ SELECT name
, prename
, street
, zip
, city
FROM you_got_it ..."""

- --

Tschööö--->...Stefan
- ---------------------------
Don't visit my homepage at:
http://home.arcor-online.net/hirnstrom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAk0+FroACgkQQeATqGpDnRqchACbB4uYHl4aUk/Yz1YHCK/oum+z
NG4An19tXgxQrsPPxsObbWfIkGj/FkG/
=/+H8
-----END PGP SIGNATURE-----

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

By putting the commas at the beginning of the line rather than the
end, you didn't eliminate the inconsistency, you just moved it from
the last argument to the first argument. The idea was that you could
have one argument per line and reorder them without having to worry
about commas.

Actually, that is only part of the idea. The more important part is
that eliminating the need for commas cleans up the syntax a bit,
making an elegant language just a tiny bit more elegant.

Russ P.

On Jan 24, 4:18 pm, Stefan Wagner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Russ P. schrieb:
>
> > I sometimes write class definition headers with each argument on a
> > separate line with a trailing comment, as in:
>
> > class foo( // this is a class called foo
> >     val bar: Int, // this is the first argument
> >     val bax: Boolean = true, // this is the second argument
> >     val baz: String = "" // this is the third argument
> >     )
>
> You may put the comma in front, like this:
>
> // this is a class called foo
> class foo (val bar: Int // this is the first argument
>     , val bax: Boolean = true // this is the second argument
>     , val baz: String = "" // this is the third argument
>     )
>
> In some cases you still need to fuddle with the commas, but it will be
> much more obvious. I use this technique all the time with SQL:
>
> q = """ SELECT name
>        , prename
>        , street
>        , zip
>        , city
> FROM you_got_it ..."""
>
> - --
>
> Tsch --->...Stefan
> - ---------------------------
> Don't visit my homepage at:http://home.arcor-online.net/hirnstrom
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org
>
> iEYEARECAAYFAk0+FroACgkQQeATqGpDnRqchACbB4uYHl4aUk/Yz1YHCK/oum+z
> NG4An19tXgxQrsPPxsObbWfIkGj/FkG/
> =/+H8
> -----END PGP SIGNATURE-----

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