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

Line Continuations for +/- Prefixed Numerics

23 replies
duckworthd
Joined: 2011-09-04,
User offline. Last seen 1 year 7 weeks ago.

Hi all,

This is a simple feature request in response to an "unintended
feature" of Scala I just found after 4 hours of debugging. It was
only by luck that I eventually stumbled upon it now.

Consider the following line of code:

val a = 1
+ 2
- 4

In most people's minds, the result of this expression should be 7. Of
course, it is not -- it is 1. The reason being that "+" and "-" are
both binary and unary operators. The rules of Scala dictate that
first the compiler check if either the preceding or following line is
invalid on its own before automatically assuming a line continuation
is desired. Here, "val a = 1" and "+2" are both valid expressions, so
the "1.+(2)" is never considered.

Speaking from a language design point of view, that is perfectly
sensible. Desirable even. However, cases such as this highlight how
error prone this logic can be when both unary and binary operators
have the same method name.

I do not have a clear cut recommendation as to how this sort of
scenario should be avoided, but if not enforced via warnings in the
language, it should be brazenly noted in some sort of official
documentation. Without luck and having encountered this logical
error before, I fear I never would have found this bug.

Philippe Lhoste
Joined: 2010-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics

On 04/09/2011 13:06, Daniel Duckworth wrote:
[...]
> Consider the following line of code:
>
> val a = 1
> + 2
> - 4
[...]
> Speaking from a language design point of view, that is perfectly
> sensible. Desirable even. However, cases such as this highlight how
> error prone this logic can be when both unary and binary operators
> have the same method name.
>
> I do not have a clear cut recommendation as to how this sort of
> scenario should be avoided, but if not enforced via warnings in the
> language, it should be brazenly noted in some sort of official
> documentation. Without luck and having encountered this logical
> error before, I fear I never would have found this bug.

I have seen various warnings about this style of writing in Scala (it is
perfectly OK in Java, hence the confusion), but indeed I don't know if
there is any official warning about this (might be worth mentioning in A
Tour of Scala, perhaps).

Personally, even in Java, I prefer the style

val a = 1 +
2 -
4

because when reading, we are notified, from the first line, that there
is a continuation on the next line.
On the other hand, I understand the proponents of the first style as the
indentation and starting symbol are also strong visual hints. So I have
no strong opinion on the topic... :-)

Sometime, I wonder if replacing whitespace heuristics with an explicit
continuation symbol wouldn't have been better... A bit more noisy, but
after all, we don't split lines that often, are we?
Visual Basic uses an underscore at the end of a line to indicate
continuation on the next line, but this symbol is already a bit too
overloaded in Scala... ;-)

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Line Continuations for +/- Prefixed Numerics
The compiler could add a warning of the effect that 'a is never references' and that +2 is dead code (assuming a block where -4 would be the value.) I can imagine cases where the side effects would not be considered "dead" though, and it would probably be a very common warning.

Another option would be for the compiler to hint that there is a possible ambiguity if the code is valid both with and without line continuation.

A third option would be to have the IDE hint at inferred line continuation with some symbol. Similar to how you can enable visual whitespace symbols.

Of those three options I guess 1 would just be a pain for the developer. 2 would be a pain for the compiler writer. So the most viable options is probably number 3.

BR,
John

On Sun, Sep 4, 2011 at 2:38 PM, Philippe Lhoste <PhiLho [at] gmx [dot] net> wrote:
On 04/09/2011 13:06, Daniel Duckworth wrote:
[...]
Consider the following line of code:

val a = 1
    + 2
    - 4
[...]
Speaking from a language design point of view, that is perfectly
sensible.  Desirable even.  However, cases such as this highlight how
error prone this logic can be when both unary and binary operators
have the same method name.

I do not have a clear cut recommendation as to how this sort of
scenario should be avoided, but if not enforced via warnings in the
language, it should be brazenly noted in some sort of official
documentation.   Without luck and having encountered this logical
error before, I fear I never would have found this bug.

I have seen various warnings about this style of writing in Scala (it is perfectly OK in Java, hence the confusion), but indeed I don't know if there is any official warning about this (might be worth mentioning in A Tour of Scala, perhaps).

Personally, even in Java, I prefer the style

val a = 1 +
   2 -
   4

because when reading, we are notified, from the first line, that there is a continuation on the next line.
On the other hand, I understand the proponents of the first style as the indentation and starting symbol are also strong visual hints. So I have no strong opinion on the topic... :-)

Sometime, I wonder if replacing whitespace heuristics with an explicit continuation symbol wouldn't have been better... A bit more noisy, but after all, we don't split lines that often, are we?
Visual Basic uses an underscore at the end of a line to indicate continuation on the next line, but this symbol is already a bit too overloaded in Scala... ;-)

Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics


On Sun, Sep 4, 2011 at 1:06 PM, Daniel Duckworth <duckworthd [at] gmail [dot] com> wrote:
Hi all,

This is a simple feature request in response to an "unintended
feature" of Scala I just found after 4 hours of debugging.  It was
only by luck that I eventually stumbled upon it now.

Consider the following line of code:

val a = 1
   + 2
   - 4

My question is: Why would you ever write that?
 

In most people's minds, the result of this expression should be 7.  Of
course, it is not -- it is 1.  The reason being that "+" and "-" are
both binary and unary operators.  The rules of Scala dictate that
first the compiler check if either the preceding or following line is
invalid on its own before automatically assuming a line continuation
is desired.  Here, "val a = 1" and "+2" are both valid expressions, so
the "1.+(2)" is never considered.

Speaking from a language design point of view, that is perfectly
sensible.  Desirable even.  However, cases such as this highlight how
error prone this logic can be when both unary and binary operators
have the same method name.

I do not have a clear cut recommendation as to how this sort of
scenario should be avoided, but if not enforced via warnings in the
language, it should be brazenly noted in some sort of official
documentation.   Without luck and having encountered this logical
error before, I fear I never would have found this bug.



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics


2011/9/4 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>


On Sun, Sep 4, 2011 at 1:06 PM, Daniel Duckworth <duckworthd [at] gmail [dot] com> wrote:
Hi all,

This is a simple feature request in response to an "unintended
feature" of Scala I just found after 4 hours of debugging.  It was
only by luck that I eventually stumbled upon it now.

Consider the following line of code:

val a = 1
   + 2
   - 4

My question is: Why would you ever write that?


def smth(a: Int, b: Int, c: Int): Int =
               a
               + b
               - c

smth(1, 2, 4) == 1


However, if you use parens around it, it produces the right result.
 
 

In most people's minds, the result of this expression should be 7.  Of
course, it is not -- it is 1.  The reason being that "+" and "-" are
both binary and unary operators.  The rules of Scala dictate that
first the compiler check if either the preceding or following line is
invalid on its own before automatically assuming a line continuation
is desired.  Here, "val a = 1" and "+2" are both valid expressions, so
the "1.+(2)" is never considered.

Speaking from a language design point of view, that is perfectly
sensible.  Desirable even.  However, cases such as this highlight how
error prone this logic can be when both unary and binary operators
have the same method name.

I do not have a clear cut recommendation as to how this sort of
scenario should be avoided, but if not enforced via warnings in the
language, it should be brazenly noted in some sort of official
documentation.   Without luck and having encountered this logical
error before, I fear I never would have found this bug.



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang



--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
ARKBAN
Joined: 2011-08-11,
User offline. Last seen 42 years 45 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics


On 09/04/2011 09:12 AM, √iktor Ҡlang wrote:
CANPzfU_6Bqmv9qSaACnzB3pPOJtX0Gp0kcPgjpuYwYp07rxptA [at] mail [dot] gmail [dot] com" type="cite">

On Sun, Sep 4, 2011 at 1:06 PM, Daniel Duckworth <duckworthd [at] gmail [dot] com" rel="nofollow">duckworthd [at] gmail [dot] com> wrote:
Hi all,

This is a simple feature request in response to an "unintended
feature" of Scala I just found after 4 hours of debugging.  It was
only by luck that I eventually stumbled upon it now.

Consider the following line of code:

val a = 1
   + 2
   - 4

My question is: Why would you ever write that?

I have known some DBA's that prefer to write SQL with the binary operator leading each line. The reason is two-fold: it mimics the pattern of other statements where the first token in the line provides the most context (which is often true in Scala), and secondly it makes it easy to comment out a single line without having to modify other lines. Given SQL's syntax and that it works mostly with boolean operators this make a fair amount of sense:

-- requires 1 comment
SELECT A
FROM B
WHERE C = 1
-- AND D = 2

VS

-- requires 2 comments
SELECT A
FROM B
WHERE C = 1 -- AND
-- D = 2

CANPzfU_6Bqmv9qSaACnzB3pPOJtX0Gp0kcPgjpuYwYp07rxptA [at] mail [dot] gmail [dot] com" type="cite">

In most people's minds, the result of this expression should be 7.  Of
course, it is not -- it is 1.  The reason being that "+" and "-" are
both binary and unary operators.  The rules of Scala dictate that
first the compiler check if either the preceding or following line is
invalid on its own before automatically assuming a line continuation
is desired.  Here, "val a = 1" and "+2" are both valid expressions, so
the "1.+(2)" is never considered.

Speaking from a language design point of view, that is perfectly
sensible.  Desirable even.  However, cases such as this highlight how
error prone this logic can be when both unary and binary operators
have the same method name.

I do not have a clear cut recommendation as to how this sort of
scenario should be avoided, but if not enforced via warnings in the
language, it should be brazenly noted in some sort of official
documentation.   Without luck and having encountered this logical
error before, I fear I never would have found this bug.



--
Viktor Klang

Akka Tech Lead Typesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Personally I like having the operator at the beginning of the line because it matches most other statements (method definitions, method calls, variable declarations, etc.). I also find it faster to read: I can determine that the line continues by looking down a single line instead of having to scan the entire line to find the end character (which might be a variable distances away where the following line is a constant distance away). I consider it a kind of optical optimization, especially considering that when I read code I'm usually trying to find the one line I need to modify about long before I care about the details any particular line.

ARKBAN
dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Line Continuations for +/- Prefixed Numerics

On Sun, Sep 4, 2011 at 08:06, Daniel Duckworth wrote:
> Hi all,
>
> This is a simple feature request in response to an "unintended
> feature" of Scala I just found after 4 hours of debugging.  It was
> only by luck that I eventually stumbled upon it now.
>
> Consider the following line of code:
>
> val a = 1
>    + 2
>    - 4

val a = (
1
   + 2
   - 4
)

"Both binary and unary operators" is not relevant here. That's
semantics, which only enter the equation way past grammar. Solve the
*grammar* issue (appendix A of the Scala Reference, iirc), and you
stand a chance of getting it accepted.

>
> In most people's minds, the result of this expression should be 7.  Of
> course, it is not -- it is 1.  The reason being that "+" and "-" are
> both binary and unary operators.  The rules of Scala dictate that
> first the compiler check if either the preceding or following line is
> invalid on its own before automatically assuming a line continuation
> is desired.  Here, "val a = 1" and "+2" are both valid expressions, so
> the "1.+(2)" is never considered.
>
> Speaking from a language design point of view, that is perfectly
> sensible.  Desirable even.  However, cases such as this highlight how
> error prone this logic can be when both unary and binary operators
> have the same method name.
>
> I do not have a clear cut recommendation as to how this sort of
> scenario should be avoided, but if not enforced via warnings in the
> language, it should be brazenly noted in some sort of official
> documentation.   Without luck and having encountered this logical
> error before, I fear I never would have found this bug.

Pierce Wetter
Joined: 2011-09-01,
User offline. Last seen 42 years 45 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics


Another option would be for the compiler to hint that there is a possible ambiguity if the code is valid both with and without line continuation.


 +1 for more work for the compiler writer because any work by the compiler writer is multiplied the work of the compiler users, so you get a million to 1 effectiveness.
 I would say that its worth special casing the standard arithmetic operators so that + - * / output a warning in this case. So:
   + a would give a warning, while:
   plus a 
   Would not. 
Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics

On Sunday 04 September 2011, Daniel Duckworth wrote:
> Hi all,
>
> This is a simple feature request

It is not. It is only simple for you to state it.

> in response to an "unintended feature"

It is only your intent that is in play here.

> of Scala I just found after 4 hours of debugging.
> It was only by luck that I eventually stumbled upon it now.

It is only "luck" because you treat a programming language as something
that exists in nature without any specification.

> Consider the following line of code:
>
> val a = 1
> + 2
> - 4
>
> In most people's minds,

You do not know what is in most people's minds.
Nor do I. Nor does anyone.

> the result of this expression should be 7.

"Should be" is entirely subjective. It's what _you_ think "should be."

> Of course, it is not -- it is 1.

Well, you got one thing right. It is what it is.

> ...

Etc.

Scala is what it is. Use it for more than a week before suggesting
changes in its grammar. In fact, use it for more than a year before
doing so.

Randall Schulz

Andrew
Joined: 2011-03-14,
User offline. Last seen 42 years 45 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics

Hey all,

> > This is a simple feature request
>
> It is not. It is only simple for you to state it.
>

It would, indeed, be a difficult change to make, but there is an
easier option, which is making sure that people are aware that this
differs between Java and Scala. All it needs is to be pointed out
somewhere "official" (someone already mentioned the Tour), and then
fewer people would be tripped up by it.

>
> Scala is what it is. Use it for more than a week before suggesting
> changes in its grammar. In fact, use it for more than a year before
> doing so.
>

This is definitely a trap for young players, though. Back when I first
learned java, the layout that the OP used was the recommended style in
the java style guide we were given. I am not sure it is still the
case, but if many of the people trying out scala now are from a java
background, and this isn't pointed out to them, then lots of them will
hit this "bug".

Ta,
Andrew

duckworthd
Joined: 2011-09-04,
User offline. Last seen 1 year 7 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics
Please forgive me, I am unfamiliar with the implementation programming languages and the vocabulary used in speaking about their development.  I don't understand the difference between "semantics" and "grammar" -- are you alluding to the collection of rules used to parse the source code with the latter?
Daniel Duckworth

On Sun, Sep 4, 2011 at 8:47 AM, Daniel Sobral <dcsobral [at] gmail [dot] com> wrote:
On Sun, Sep 4, 2011 at 08:06, Daniel Duckworth <duckworthd [at] gmail [dot] com> wrote:
> Hi all,
>
> This is a simple feature request in response to an "unintended
> feature" of Scala I just found after 4 hours of debugging.  It was
> only by luck that I eventually stumbled upon it now.
>
> Consider the following line of code:
>
> val a = 1
>    + 2
>    - 4

val a = (
  1
   + 2
   - 4
)

"Both binary and unary operators" is not relevant here. That's
semantics, which only enter the equation way past grammar. Solve the
*grammar* issue (appendix A of the Scala Reference, iirc), and you
stand a chance of getting it accepted.


>
> In most people's minds, the result of this expression should be 7.  Of
> course, it is not -- it is 1.  The reason being that "+" and "-" are
> both binary and unary operators.  The rules of Scala dictate that
> first the compiler check if either the preceding or following line is
> invalid on its own before automatically assuming a line continuation
> is desired.  Here, "val a = 1" and "+2" are both valid expressions, so
> the "1.+(2)" is never considered.
>
> Speaking from a language design point of view, that is perfectly
> sensible.  Desirable even.  However, cases such as this highlight how
> error prone this logic can be when both unary and binary operators
> have the same method name.
>
> I do not have a clear cut recommendation as to how this sort of
> scenario should be avoided, but if not enforced via warnings in the
> language, it should be brazenly noted in some sort of official
> documentation.   Without luck and having encountered this logical
> error before, I fear I never would have found this bug.



--
Daniel C. Sobral

I travel to the future all the time.

Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics

On Sunday 04 September 2011, Daniel Duckworth wrote:
> Please forgive me, I am unfamiliar with the implementation
> programming languages and the vocabulary used in speaking about their
> development. I don't understand the difference between "semantics"
> and "grammar" -- are you alluding to the collection of rules used to
> parse the source code with the latter?

In a narrow sense, grammar refers to the rules that do nothing more than
say whether or not a given input is a valid "sentence" (program) in the
language.

Semantics is about assigning meaning to an input that is known to be
grammatical.

In practice, the two do not always separate cleanly, but the conceptual
distinction is still meaningful.

So I repeat my earlier admonition: Learn more before suggesting changes.

> Daniel Duckworth

Randall Schulz

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Line Continuations for +/- Prefixed Numerics

On Sun, Sep 4, 2011 at 19:43, Daniel Duckworth wrote:
> Please forgive me, I am unfamiliar with the implementation programming
> languages and the vocabulary used in speaking about their development.  I
> don't understand the difference between "semantics" and "grammar" -- are you
> alluding to the collection of rules used to parse the source code with the
> latter?

Yes.

> Daniel Duckworth
>
> On Sun, Sep 4, 2011 at 8:47 AM, Daniel Sobral wrote:
>>
>> On Sun, Sep 4, 2011 at 08:06, Daniel Duckworth
>> wrote:
>> > Hi all,
>> >
>> > This is a simple feature request in response to an "unintended
>> > feature" of Scala I just found after 4 hours of debugging.  It was
>> > only by luck that I eventually stumbled upon it now.
>> >
>> > Consider the following line of code:
>> >
>> > val a = 1
>> >    + 2
>> >    - 4
>>
>> val a = (
>>   1
>>    + 2
>>    - 4
>> )
>>
>> "Both binary and unary operators" is not relevant here. That's
>> semantics, which only enter the equation way past grammar. Solve the
>> *grammar* issue (appendix A of the Scala Reference, iirc), and you
>> stand a chance of getting it accepted.
>>
>>
>> >
>> > In most people's minds, the result of this expression should be 7.  Of
>> > course, it is not -- it is 1.  The reason being that "+" and "-" are
>> > both binary and unary operators.  The rules of Scala dictate that
>> > first the compiler check if either the preceding or following line is
>> > invalid on its own before automatically assuming a line continuation
>> > is desired.  Here, "val a = 1" and "+2" are both valid expressions, so
>> > the "1.+(2)" is never considered.
>> >
>> > Speaking from a language design point of view, that is perfectly
>> > sensible.  Desirable even.  However, cases such as this highlight how
>> > error prone this logic can be when both unary and binary operators
>> > have the same method name.
>> >
>> > I do not have a clear cut recommendation as to how this sort of
>> > scenario should be avoided, but if not enforced via warnings in the
>> > language, it should be brazenly noted in some sort of official
>> > documentation.   Without luck and having encountered this logical
>> > error before, I fear I never would have found this bug.
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>
>

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Line Continuations for +/- Prefixed Numerics

On 9/4/11 4:06 AM, Daniel Duckworth wrote:
> Consider the following line of code:
>
> val a = 1
> + 2
> - 4

Some of the comments in this thread have been, um, less than helpful.
To me it should not be controversial that if the compiler sees you doing
something useless, it should clue you in if it can.

% scala
Welcome to Scala version 2.10.0.r25608-b20110904171209 (Java HotSpot(TM)
64-Bit Server VM, Java 1.6.0_26).
Type in expressions to have them evaluated.
Type :help for more information.

scala> class A {
| val a = 1
| + 2
| - 4
| }
:9: warning: a pure expression does nothing in statement
position; you may be omitting necessary parentheses
+ 2
^
:10: warning: a pure expression does nothing in statement
position; you may be omitting necessary parentheses
- 4
^
defined class A

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics
On Sun, Sep 4, 2011 at 4:06 AM, Daniel Duckworth <duckworthd [at] gmail [dot] com> wrote:
Hi all,

This is a simple feature request in response to an "unintended
feature" of Scala I just found after 4 hours of debugging.  It was
only by luck that I eventually stumbled upon it now.

Consider the following line of code:

val a = 1
   + 2
   - 4

In most people's minds, the result of this expression should be 7.  Of
course, it is not -- it is 1.  The reason being that "+" and "-" are
both binary and unary operators.  The rules of Scala dictate that
first the compiler check if either the preceding or following line is
invalid on its own before automatically assuming a line continuation
is desired.  Here, "val a = 1" and "+2" are both valid expressions, so
the "1.+(2)" is never considered.


I sympathize with your frustration after spending so much time debugging, but I'm afraid this is just the price to be paid for the convenience and elegance of semicolon inference. I agree that a compiler warning would be desirable here, but I doubt much more can be done.

Actually, I consider the previous conventions you cite to be bogus. The line

val a = 1

is a complete statement. In order to continue the statement, it seems perfectly reasonable to me that you need some indication that the statement will continue. That means unclosed parens or a binary operator at the end of the line. The convention that says the operator should be put at the beginning of the next line is just plain bogus as far as I am concerned.

--Russ P.

--
http://RussP.us
duckworthd
Joined: 2011-09-04,
User offline. Last seen 1 year 7 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics
Hi Daniel, Paul, Russ,
Thanks for your input.  It's nice to know that my words don't fall on deaf ears!
Paul: Am I to understand that the REPL of the current Scala 2.10 build does alert you to these sorts of situations?  What is the reasoning for having it implemented there but not in the compiler?  Or am I just ignorant to the fact that it IS already implemented as a warning in the compiler as well?
Russ: I think you're absolutely right!  Each line is a complete statement, and as a general rule there's no reason the compiler should have to reconsider how these statements might be combined.  I can say that in all future endeavors I will be placing my operators (err, method calls) at the end of the line, but it's such an easy and difficult-to-find mistake to make for a Scala novice such as myself.  
If I were asked what I would want, it would just be a compiler warning.  Is this unreasonable?  
Daniel Duckworth
Electrical Engineering and Computer Science
University of California, Berkeley


On Sun, Sep 4, 2011 at 5:18 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
On Sun, Sep 4, 2011 at 4:06 AM, Daniel Duckworth <duckworthd [at] gmail [dot] com> wrote:
Hi all,

This is a simple feature request in response to an "unintended
feature" of Scala I just found after 4 hours of debugging.  It was
only by luck that I eventually stumbled upon it now.

Consider the following line of code:

val a = 1
   + 2
   - 4

In most people's minds, the result of this expression should be 7.  Of
course, it is not -- it is 1.  The reason being that "+" and "-" are
both binary and unary operators.  The rules of Scala dictate that
first the compiler check if either the preceding or following line is
invalid on its own before automatically assuming a line continuation
is desired.  Here, "val a = 1" and "+2" are both valid expressions, so
the "1.+(2)" is never considered.


I sympathize with your frustration after spending so much time debugging, but I'm afraid this is just the price to be paid for the convenience and elegance of semicolon inference. I agree that a compiler warning would be desirable here, but I doubt much more can be done.

Actually, I consider the previous conventions you cite to be bogus. The line

val a = 1

is a complete statement. In order to continue the statement, it seems perfectly reasonable to me that you need some indication that the statement will continue. That means unclosed parens or a binary operator at the end of the line. The convention that says the operator should be put at the beginning of the next line is just plain bogus as far as I am concerned.

--Russ P.

--
http://RussP.us

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Line Continuations for +/- Prefixed Numerics

On 9/4/11 5:34 PM, Daniel Duckworth wrote:
> Paul: Am I to understand that the REPL of the current Scala 2.10 build
> does alert you to these sorts of situations? What is the reasoning for
> having it implemented there but not in the compiler? Or am I just
> ignorant to the fact that it IS already implemented as a warning in the
> compiler as well?

You are instead to understand that I implemented it today, and used the
repl to demonstrate it.

John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics
A big thumbs up for that one! :-)

I wasn't aware that the scala compiler could distinguish pure expressions from non-pure ones. Given that it apparently does, this must be approach.

Thinking about pureness, is it possible (or would it be much work to add?) to enforce CQS[1] using this analysis? Not in the language spec, just as an option to the compiler.

[1] http://en.wikipedia.org/wiki/Command-query_separation

Or thinking even further is this a step towards contracts? [2]

[2] http://msdn.microsoft.com/en-us/devlabs/dd491992

BR,
John

On Mon, Sep 5, 2011 at 2:18 AM, Paul Phillips <paulp [at] improving [dot] org> wrote:
On 9/4/11 4:06 AM, Daniel Duckworth wrote:
Consider the following line of code:

val a = 1
    + 2
    - 4

Some of the comments in this thread have been, um, less than helpful. To me it should not be controversial that if the compiler sees you doing something useless, it should clue you in if it can.

% scala
Welcome to Scala version 2.10.0.r25608-b20110904171209 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_26).
Type in expressions to have them evaluated.
Type :help for more information.

scala> class A {
    | val a = 1
    |     + 2
    |     - 4
    | }
<console>:9: warning: a pure expression does nothing in statement position; you may be omitting necessary parentheses
          + 2
          ^
<console>:10: warning: a pure expression does nothing in statement position; you may be omitting necessary parentheses
          - 4
            ^
defined class A

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Line Continuations for +/- Prefixed Numerics

On Sun, Sep 4, 2011 at 22:01, John Nilsson wrote:
> A big thumbs up for that one! :-)
>
> I wasn't aware that the scala compiler could distinguish pure expressions
> from non-pure ones. Given that it apparently does, this must be approach.

This is the commit:
https://github.com/scala/scala/commit/784cdcbbf336785ebaab996606076423e4...

As you can see, it seems to be restricted to AnyVal. More useful
guarantees of pureness must wait for an effect system.

>
> Thinking about pureness, is it possible (or would it be much work to add?)
> to enforce CQS[1] using this analysis? Not in the language spec, just as an
> option to the compiler.
>
> [1] http://en.wikipedia.org/wiki/Command-query_separation
>
> Or thinking even further is this a step towards contracts? [2]
>
> [2] http://msdn.microsoft.com/en-us/devlabs/dd491992
>
> BR,
> John
>
> On Mon, Sep 5, 2011 at 2:18 AM, Paul Phillips wrote:
>>
>> On 9/4/11 4:06 AM, Daniel Duckworth wrote:
>>>
>>> Consider the following line of code:
>>>
>>> val a = 1
>>>     + 2
>>>     - 4
>>
>> Some of the comments in this thread have been, um, less than helpful. To
>> me it should not be controversial that if the compiler sees you doing
>> something useless, it should clue you in if it can.
>>
>> % scala
>> Welcome to Scala version 2.10.0.r25608-b20110904171209 (Java HotSpot(TM)
>> 64-Bit Server VM, Java 1.6.0_26).
>> Type in expressions to have them evaluated.
>> Type :help for more information.
>>
>> scala> class A {
>>     | val a = 1
>>     |     + 2
>>     |     - 4
>>     | }
>> :9: warning: a pure expression does nothing in statement
>> position; you may be omitting necessary parentheses
>>           + 2
>>           ^
>> :10: warning: a pure expression does nothing in statement
>> position; you may be omitting necessary parentheses
>>           - 4
>>             ^
>> defined class A
>
>

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Line Continuations for +/- Prefixed Numerics

On 9/4/11 6:35 PM, Daniel Sobral wrote:
> This is the commit:
> https://github.com/scala/scala/commit/784cdcbbf336785ebaab996606076423e4...
>
> As you can see, it seems to be restricted to AnyVal.

I cannot see. Six statements, six warnings, zero AnyVals.

class Parent {
val abc = "bippy"
}

object Bippy extends Parent {
abc
"bippy"
this
Bippy.this
null: AnyRef

{
val x = "bippy"
val y = "bippy"
}
}

% scalac ./a.scala
./a.scala:6: warning: a pure expression does nothing in statement position; you may be omitting necessary parentheses
abc
^
./a.scala:7: warning: a pure expression does nothing in statement position; you may be omitting necessary parentheses
"bippy"
^
./a.scala:8: warning: a pure expression does nothing in statement position; you may be omitting necessary parentheses
this
^
./a.scala:9: warning: a pure expression does nothing in statement position; you may be omitting necessary parentheses
Bippy.this
^
./a.scala:10: warning: a pure expression does nothing in statement position; you may be omitting necessary parentheses
null: AnyRef
^
./a.scala:12: warning: a pure expression does nothing in statement position; you may be omitting necessary parentheses
{
^
6 warnings found

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Line Continuations for +/- Prefixed Numerics

On 9/4/11 6:01 PM, John Nilsson wrote:
> I wasn't aware that the scala compiler could distinguish pure
> expressions from non-pure ones.

It can't, but it can recognize a selection of expressions which must be
pure. this is pure. 5 is pure. "5" is pure. x might even be pure.

Philippe Lhoste
Joined: 2010-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics

On 04/09/2011 20:03, Pierce Wetter wrote:
> I would say that its worth special casing the standard arithmetic
> operators so that + - * / output a warning in this case. So:
>
> + a would give a warning, while:
>
> plus a
>
> Would not.

But those loving this form will also write:

List( Foo
:: Bar
:: Baz
:: Nil)

too, and similar forms too.

Philippe Lhoste
Joined: 2010-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: Line Continuations for +/- Prefixed Numerics

On 05/09/2011 07:10, Philippe Lhoste wrote:
> List( Foo
> :: Bar
> :: Baz
> :: Nil)

Oops, just awaking...
That's

var list = Foo
:: Bar
:: Baz
:: Nil

of course. The open parentheses above would be a strong hint for the
compiler, anyway.

MattRussell
Joined: 2009-07-22,
User offline. Last seen 45 weeks 3 days ago.
Re: Re: Line Continuations for +/- Prefixed Numerics
On Sunday, September 4, 2011 2:05:54 PM UTC+1, John Nilsson wrote:
A third option would be to have the IDE hint at inferred line continuation with some symbol. Similar to how you can enable visual whitespace symbols.

The opposite recently got added to Eclipse:
   http://www.assembla.com/wiki/show/scala-ide/Show_Inferred_Semicolons 
-- Matt

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