Multiline math expressions

662 views
Skip to first unread message

Oliver Ruebenacker

unread,
Sep 4, 2013, 10:32:49 AM9/4/13
to scala-l...@googlegroups.com

     Hello,

  Often, I have math expressions that span multiple lines. The preferred style for such expressions is to begin new lines with operators and vertically align those, e.g.

  val sum = a + b + c
                 + d + e
                 + f + g
                 + h + i

  (see, e.g. http://www.computer.org/portal/web/publications/style_exp)

  However this won't compile as intended. Scala will happily consume the first line and consider it a complete statement, splitting off the other lines (which then, at best, will cause a syntax error).

  This all would not happen, of course, if expressions were parsed always up to the next divider (semicolon, brace, parenthesis or whatever C++ or Java do). So I would like to propose exactly that.

  I know, it sounds so un-Scalaish to do something the same way as dinosaurs like C++ and Java, but dinosaurs aren't wrong on everything. And since discussing changes in syntax are currently fashion, this is the opportunity to correct this flaw in Scala.

  Thoughts?

     Best,
     Oliver

--
Oliver Ruebenacker
IT Project Lead at PanGenX (http://www.pangenx.com)
Be always grateful, but never satisfied.

Ryan Hendrickson

unread,
Sep 4, 2013, 10:40:44 AM9/4/13
to scala-l...@googlegroups.com
> val sum = a + b + c
> + d + e
> + f + g
> + h + i

Is it so onerous to type

val sum = (a + b + c
+ d + e
+ f + g
+ h + i)

? And I can't tell, but are you proposing the end of semicolon inference in order to correct this?






(please forgive me my corporate legal disclaimer)

----------------------------------------

This message is intended exclusively for the individual(s) or entity to
which it is addressed. It may contain information that is proprietary,
privileged or confidential or otherwise legally exempt from disclosure.
If you are not the named addressee, you are not authorized to read,
print, retain, copy or disseminate this message or any part of it.
If you have received this message in error, please notify the sender
immediately by e-mail and delete all copies of the message.

Paul Hudson

unread,
Sep 4, 2013, 10:44:05 AM9/4/13
to scala-l...@googlegroups.com

On 4 September 2013 15:32, Oliver Ruebenacker <cur...@gmail.com> wrote:
  This all would not happen, of course, if expressions were parsed always up to the next divider (semicolon, brace, parenthesis or whatever C++ or Java do).

Or you could use indentation to indicate a continuation line :-P


The preferred style for such expressions 

Preferred by who? I prefer (partly for this reason) to use a trailing operator...

  val sum = a + b + c +
                 d + e +
                 f + g +
                 h + i

resolves the issue, no?

Paul Phillips

unread,
Sep 4, 2013, 10:52:24 AM9/4/13
to scala-l...@googlegroups.com
On Wed, Sep 4, 2013 at 7:44 AM, Paul Hudson <phu...@pobox.com> wrote:
  val sum = a + b + c +
                 d + e +
                 f + g +
                 h + i

resolves the issue, no?

No, because nobody I know is smart enough never to miss this. Shoot I've seen merge come up with expressions like this.

  val sum = a + b + c +
                 d + e
                 f + g +
                 h + i

The issue is resolved by using parentheses, and everything else is paint on an imaginary bikeshed.


Paul Hudson

unread,
Sep 4, 2013, 10:59:26 AM9/4/13
to scala-l...@googlegroups.com

On 4 September 2013 15:52, Paul Phillips <pa...@improving.org> wrote:
The issue is resolved by using parentheses, and everything else is paint on an imaginary bikeshed.

As long as people are smart enough never to miss that, either

(And it should be painted "teal", of course)

Paul Phillips

unread,
Sep 4, 2013, 11:05:14 AM9/4/13
to scala-l...@googlegroups.com

On Wed, Sep 4, 2013 at 7:59 AM, Paul Hudson <phu...@pobox.com> wrote:
As long as people are smart enough never to miss that, either

"Smart enough not to miss" is code for "if I follow practice A, will the compiler tell me about obvious-in-isolation error B?"

In this case "practice A" is "use parentheses", and we exclude the discipline to do so from the intelligence test, whereas "error B" is the dangling unattached expression, about which you will certainly be told if you follow practice A. You might even be told about it without practice A, but it's not guaranteed.


Paul Phillips

unread,
Sep 4, 2013, 11:14:00 AM9/4/13
to scala-l...@googlegroups.com
And in case anyone is looking for code formatting tips, here is how I put "use parentheses" into actual practice. I wouldn't want to lose the parentheses even given the option.

private def isUnwarnableTypeArgSymbol(sym: Symbol) = (
     sym.isTypeParameter                     // dummy
  || sym.name.toTermName == nme.WILDCARD     // _
  || nme.isVariableName(sym.name)            // type variable
)
private def isIneligible(info: ImplicitInfo) = (
     info.isCyclicOrErroneous
  || isView && isPredefMemberNamed(info.sym, nme.conforms)
  || shadower.isShadowed(info.name)
  || !context.macrosEnabled && info.sym.isTermMacro
)

Oliver Ruebenacker

unread,
Sep 4, 2013, 11:16:42 AM9/4/13
to scala-l...@googlegroups.com

     Hello,

On Wed, Sep 4, 2013 at 10:40 AM, Ryan Hendrickson <Ryan.Hen...@bwater.com> wrote:
>   val sum = a + b + c
>                  + d + e
>                  + f + g
>                  + h + i

Is it so onerous to type

  val sum = (a + b + c
                  + d + e
                  + f + g
                  + h + i)

  And then add a comment to other developers that these parentheses actually serve a purpose, so that no one goes and deletes them? Yes, that would be onerous.

? And I can't tell, but are you proposing the end of semicolon inference in order to correct this?

  Yes, I am proposing semicolons. Posing it as "semicolon interference", you are implying that the semicolons provide no additional information. The truth is, they do, as the example shows.

     Best,
     Oliver

Oliver Ruebenacker

unread,
Sep 4, 2013, 11:20:51 AM9/4/13
to scala-l...@googlegroups.com

     Hello,

On Wed, Sep 4, 2013 at 10:44 AM, Paul Hudson <phu...@pobox.com> wrote:

On 4 September 2013 15:32, Oliver Ruebenacker <cur...@gmail.com> wrote:
  This all would not happen, of course, if expressions were parsed always up to the next divider (semicolon, brace, parenthesis or whatever C++ or Java do).

Or you could use indentation to indicate a continuation line :-P

  How would that work?


The preferred style for such expressions 

Preferred by who? I prefer (partly for this reason) to use a trailing operator...

  It's quite ironic that Scala goes great lengths to allow DSLs, but you can't write math expressions according to international standards.

     Best,
     Oliver

Tom Switzer

unread,
Sep 4, 2013, 11:21:16 AM9/4/13
to scala-l...@googlegroups.com
Right, but you are proposing we enforce semicolons. Given that idiomatic Scala typically has 0 semicolons, suddenly asking everyone to add semicolons after several years seems significantly more onerous than having a coding standard for parens around multiline expressions with infix operators.


--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Oliver Ruebenacker

unread,
Sep 4, 2013, 11:28:53 AM9/4/13
to scala-l...@googlegroups.com

     Hello,

On Wed, Sep 4, 2013 at 11:21 AM, Tom Switzer <thomas....@gmail.com> wrote:
Right, but you are proposing we enforce semicolons. Given that idiomatic Scala typically has 0 semicolons, suddenly asking everyone to add semicolons after several years seems significantly more onerous than having a coding standard for parens around multiline expressions with infix operators.

  We could make it optional per-scope switched on by an import statement.

     Best,
     Oliver
 

Paul Hudson

unread,
Sep 4, 2013, 11:30:22 AM9/4/13
to scala-l...@googlegroups.com

On 4 September 2013 16:20, Oliver Ruebenacker <cur...@gmail.com> wrote:
Or you could use indentation to indicate a continuation line :-P

  How would that work?

I was just making a link to the other email thread.

But if you really wanted that. you could have a rule that continuation lines of expressions were indicated by additional indentation.

(this probably isn't going to work in your mail reader...)

val sum = a + b + c
      + d + e
      + f + g
      + h + i


computes the sum of a ... i

 val sum = a + b + c
 + d + e
 + f + g
 + h + i

computes the sum of a. .. c, then evaluates and discards the result of d + e, f + g, and h + i (maybe discards, for the last one, depending on where this fragment is)

I'm not proposing this, though.

Paul Hudson

unread,
Sep 4, 2013, 11:32:22 AM9/4/13
to scala-l...@googlegroups.com
On 4 September 2013 16:20, Oliver Ruebenacker <cur...@gmail.com> wrote:
  It's quite ironic that Scala goes great lengths to allow DSLs, but you can't write math expressions according to international standards.


Those are typesetting standards. The range of possible symbols, options (and mathematical conventions) greatly exceeds the range of possibilities for computer code meant for consumption by a compiler, as well as a human reader.  I don't see it as particularly ironic that the two different domains have different standards.

Jim

unread,
Sep 8, 2013, 5:05:54 AM9/8/13
to scala-l...@googlegroups.com


On Wednesday, September 4, 2013 8:16:42 AM UTC-7, Oliver Ruebenacker wrote:

     Hello,

On Wed, Sep 4, 2013 at 10:40 AM, Ryan Hendrickson <Ryan.Hen...@bwater.com> wrote:
>   val sum = a + b + c
>                  + d + e
>                  + f + g
>                  + h + i

Is it so onerous to type

  val sum = (a + b + c
                  + d + e
                  + f + g
                  + h + i)

  And then add a comment to other developers that these parentheses actually serve a purpose, so that no one goes and deletes them? Yes, that would be onerous.

If you normally have people editing your code base who are unfamiliar with the rules of the language it is written in, you're going to need a lot of such comments. But sensible shops don't do that, and don't need them.
 

? And I can't tell, but are you proposing the end of semicolon inference in order to correct this?

  Yes, I am proposing semicolons. Posing it as "semicolon interference", you are implying that the semicolons provide no additional information. The truth is, they do, as the example shows.

It's "inference", not "interference", and it's not being "posed", it's an existing feature of the Scala language, one that is heavily used and widely liked. To even suggest eliminating it amounts to trolling.
 

Oliver Ruebenacker

unread,
Sep 8, 2013, 11:11:00 AM9/8/13
to scala-l...@googlegroups.com

     Hello,

On Sun, Sep 8, 2013 at 5:05 AM, Jim <jqba...@gmail.com> wrote:


On Wednesday, September 4, 2013 8:16:42 AM UTC-7, Oliver Ruebenacker wrote:

     Hello,


On Wed, Sep 4, 2013 at 10:40 AM, Ryan Hendrickson <Ryan.Hen...@bwater.com> wrote:
>   val sum = a + b + c
>                  + d + e
>                  + f + g
>                  + h + i

Is it so onerous to type

  val sum = (a + b + c
                  + d + e
                  + f + g
                  + h + i)

  And then add a comment to other developers that these parentheses actually serve a purpose, so that no one goes and deletes them? Yes, that would be onerous.

If you normally have people editing your code base who are unfamiliar with the rules of the language it is written in, you're going to need a lot of such comments. But sensible shops don't do that, and don't need them.

  This thread makes it pretty clear that the merit of such parentheses is not obvious.
 

? And I can't tell, but are you proposing the end of semicolon inference in order to correct this?

  Yes, I am proposing semicolons. Posing it as "semicolon interference", you are implying that the semicolons provide no additional information. The truth is, they do, as the example shows.

It's "inference", not "interference", and it's not being "posed", it's an existing feature of the Scala language, one that is heavily used and widely liked. To even suggest eliminating it amounts to trolling.

  Yes, I meant "semicolon inference". My argument, which you are ignoring, is that it is a misnomer for something that, yes, is an existing feature.

  If you consider a suggestion to change the syntax as trolling then I wonder if you would consider this one also trolling:

  https://groups.google.com/forum/?hl=en#!topic/scala-language/yl9BRqlpjJ0

     Best,
     Oliver
 
 

     Best,
     Oliver

--
Oliver Ruebenacker
IT Project Lead at PanGenX (http://www.pangenx.com)
Be always grateful, but never satisfied.

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Lex Spoon

unread,
Sep 8, 2013, 4:05:36 PM9/8/13
to scala-l...@googlegroups.com
+1

It's good style to write multi-line expressions with some kind of
parentheses or other brackets. Even if we assume that the reader of
the code will be a super-programmer--which is not a great
assumption--it is still a waste of their time to make them scan each
line to make sure all of those lines really do attach together.

Be nice to the maintainers.

Lex
Reply all
Reply to author
Forward
0 new messages