confusing error message about unmatched closing brace

Could you explain better what's happening?

On Sat, Sep 4, 2010 at 3:46 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I am converting some Python files to Scala, so I need to add braces. Several times now I have gotten a confusing error message about an unmatched closing brace. Apparently the message points to the first line in the file with a closing brace even if the extra closing brace is way down in the file. The first time this happened, I was baffled for something like a half hour trying to figure out what the problem was. A more accurate error message, if possible, would save developers some time.

Russ P.

--
http://RussP.us

On Sun, Sep 5, 2010 at 8:07 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Could you explain better what's happening?

Sure. Take one of your non-trivial Scala source files and insert an extra closing brace somewhere near the end of the file (or at least after the first correct closing brace). The compiler will tell you that you have an unmatched closing brace, but it will point you to the line with the first closing brace in the file (not the first *unmatched* closing brace, which is what it *should* point to). If you are unaware of this bug, you'll tentatively conclude that either (1) you're losing your marbles, or (2) the compiler seems to have a severe bug that renders it essentially unusable. After trying various experiments, you'll eventually realize that the problem is just a misleading error message, and you'll be out a non-trivial amount of time.

Russ P.

 

On Sat, Sep 4, 2010 at 3:46 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I am converting some Python files to Scala, so I need to add braces. Several times now I have gotten a confusing error message about an unmatched closing brace. Apparently the message points to the first line in the file with a closing brace even if the extra closing brace is way down in the file. The first time this happened, I was baffled for something like a half hour trying to figure out what the problem was. A more accurate error message, if possible, would save developers some time.

Russ P.

--
http://RussP.us

--
http://RussP.us

 I recall having this same sort of thing countless times in C++ and Java, so Scala's hardly unique in that respect.  I agree though, it's probably a good thing to have a better compile error for.
Ken

On 6 September 2010 14:21, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sun, Sep 5, 2010 at 8:07 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Could you explain better what's happening?

Sure. Take one of your non-trivial Scala source files and insert an extra closing brace somewhere near the end of the file (or at least after the first correct closing brace). The compiler will tell you that you have an unmatched closing brace, but it will point you to the line with the first closing brace in the file (not the first *unmatched* closing brace, which is what it *should* point to). If you are unaware of this bug, you'll tentatively conclude that either (1) you're losing your marbles, or (2) the compiler seems to have a severe bug that renders it essentially unusable. After trying various experiments, you'll eventually realize that the problem is just a misleading error message, and you'll be out a non-trivial amount of time.

Russ P.

 

On Sat, Sep 4, 2010 at 3:46 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I am converting some Python files to Scala, so I need to add braces. Several times now I have gotten a confusing error message about an unmatched closing brace. Apparently the message points to the first line in the file with a closing brace even if the extra closing brace is way down in the file. The first time this happened, I was baffled for something like a half hour trying to figure out what the problem was. A more accurate error message, if possible, would save developers some time.

Russ P.

--
http://RussP.us

--
http://RussP.us

Well, that's a matter of opinion isn't it?

What if I were to change your instructions slightly:

"Take one of your non-trivial Scala source files and insert an extra closing brace somewhere before an existing correctly matched closing brace"

In this case the compiler error you are complaining about would correctly point to the first closing brace.

In a badly formed source file it would be too ambiguous to decide which is the problem - is the unmatched brace the first one or the last one? Non-trivial I'd say.

Ishaaq

On 6 September 2010 14:21, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sun, Sep 5, 2010 at 8:07 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Could you explain better what's happening?

Sure. Take one of your non-trivial Scala source files and insert an extra closing brace somewhere near the end of the file (or at least after the first correct closing brace). The compiler will tell you that you have an unmatched closing brace, but it will point you to the line with the first closing brace in the file (not the first *unmatched* closing brace, which is what it *should* point to). If you are unaware of this bug, you'll tentatively conclude that either (1) you're losing your marbles, or (2) the compiler seems to have a severe bug that renders it essentially unusable. After trying various experiments, you'll eventually realize that the problem is just a misleading error message, and you'll be out a non-trivial amount of time.

Russ P.

 

On Sat, Sep 4, 2010 at 3:46 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I am converting some Python files to Scala, so I need to add braces. Several times now I have gotten a confusing error message about an unmatched closing brace. Apparently the message points to the first line in the file with a closing brace even if the extra closing brace is way down in the file. The first time this happened, I was baffled for something like a half hour trying to figure out what the problem was. A more accurate error message, if possible, would save developers some time.

Russ P.

--
http://RussP.us

--
http://RussP.us

ususally, a good ide helps here. from my experience, an evil brace will either be found right away (in most cases intellij idea gets it right when parsing java code), or everything below the evil brace will be highlighted in red, so i know where to begin to search.

Am 06.09.2010 07:39, schrieb Ishaaq Chandy:

orKQ6QsNn1RRnU2+afNvLcXu-RdgXsBwNdG38 [at] mail [dot] gmail [dot] com" type="cite">Well, that's a matter of opinion isn't it?

What if I were to change your instructions slightly:

"Take one of your non-trivial Scala source files and insert an extra closing brace somewhere before an existing correctly matched closing brace"

In this case the compiler error you are complaining about would correctly point to the first closing brace.

In a badly formed source file it would be too ambiguous to decide which is the problem - is the unmatched brace the first one or the last one? Non-trivial I'd say.

Ishaaq

On 6 September 2010 14:21, Russ Paielli <russ [dot] paielli [at] gmail [dot] com" rel="nofollow">russ.paielli@gmail.com> wrote:

On Sun, Sep 5, 2010 at 8:07 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com" target="_blank" rel="nofollow">naftoligug@gmail.com> wrote:

Could you explain better what's happening?

Sure. Take one of your non-trivial Scala source files and insert an extra closing brace somewhere near the end of the file (or at least after the first correct closing brace). The compiler will tell you that you have an unmatched closing brace, but it will point you to the line with the first closing brace in the file (not the first *unmatched* closing brace, which is what it *should* point to). If you are unaware of this bug, you'll tentatively conclude that either (1) you're losing your marbles, or (2) the compiler seems to have a severe bug that renders it essentially unusable. After trying various experiments, you'll eventually realize that the problem is just a misleading error message, and you'll be out a non-trivial amount of time.

Russ P.

 

On Sat, Sep 4, 2010 at 3:46 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com" target="_blank" rel="nofollow">russ.paielli@gmail.com> wrote:

I am converting some Python files to Scala, so I need to add braces. Several times now I have gotten a confusing error message about an unmatched closing brace. Apparently the message points to the first line in the file with a closing brace even if the extra closing brace is way down in the file. The first time this happened, I was baffled for something like a half hour trying to figure out what the problem was. A more accurate error message, if possible, would save developers some time.

Russ P.

--
http://RussP.us

--
http://RussP.us

On 06/09/2010 07:39, Ishaaq Chandy wrote:
> In a badly formed source file it would be too ambiguous to decide which is the problem -
> is the unmatched brace the first one or the last one? Non-trivial I'd say.

Sure, this reminds me of a quote of Martin Odersky, saw somewhere on the Internet, which I
would paraphrase approximatively as: "Parsing valid code is almost trivial, emitting
sensible error messages on incorrect code is much harder", particularly if the errors are
multiple and even can cancel each other (missing one soft brace here, having an extra one
there...).

I found out that the "free flow" style of Scala, where we omit semi-colons (99% of the
time...), can lead to reporting errors tens of lines below the culprit, at least in the
case of a missing closing parenthesis...
Frustrating, but I can't really blame the compiler.
As said, IDEs can help, but even a simple but good text editor highlighting pairs of
braces, brackets and parentheses (with even primitive syntax awareness, skipping comments
and text) can go a long way in finding out such errors.

I won't start a flame war, but in my personal taste, I still think that aligning braces
helps too! (along with consistent indenting, something that some coders, particularly
beginners, often neglect). I also tend to add them almost systematically (not for a simple
return, or, in Scala, for one expression defs).

Although, for the anecdote, it bit me in Kojo, where the code is run by the interpreter:
Kojo has a repeat (n) definition which works fine with my brace style, /except/ if I use a
var in the code; apparently the interpreter then goes in a line-per-line mode (no idea
why) and seeing a repeat (5) in a single line (the opening brace being on the next line),
thinks I wanted to make a partial function...

I won't start a flame war, but in my personal taste, I still think that aligning braces helps too! (along with consistent indenting, something that some coders, particularly beginners, often neglect). I also tend to add them almost systematically (not for a simple return, or, in Scala, for one expression defs).

As I've said before, I'd like to see the compiler reject (or at least warn of) inconsistent indentation, as in

if (foo)
    bar 1
    bar 2

[And please note that I would consider

if (foo) bar

perfectly acceptable.]

If the compiler paid more attention to indentation, it would also have a much better chance of determining the location of a missing or extra closing brace.

Russ P.

--
http://RussP.us

Is someone volunteering to contribute the code? :)

On Mon, Sep 6, 2010 at 2:40 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

I won't start a flame war, but in my personal taste, I still think that aligning braces helps too! (along with consistent indenting, something that some coders, particularly beginners, often neglect). I also tend to add them almost systematically (not for a simple return, or, in Scala, for one expression defs).

As I've said before, I'd like to see the compiler reject (or at least warn of) inconsistent indentation, as in

if (foo)
    bar 1
    bar 2

[And please note that I would consider

if (foo) bar

perfectly acceptable.]

If the compiler paid more attention to indentation, it would also have a much better chance of determining the location of a missing or extra closing brace.

Russ P.

--
http://RussP.us

On 06/09/2010 20:40, Russ Paielli wrote:
> As I've said before, I'd like to see the compiler reject (or at least
> warn of) inconsistent indentation, as in
>
> if (foo)
> bar 1
> bar 2
[...]
> If the compiler paid more attention to indentation, it would also have a
> much better chance of determining the location of a missing or extra
> closing brace.

Mmm, looks more like a task for an IDE than for a compiler! Unless you
want to make a language like Python, where indentation is semantically
significant.
Actually, such warning could be generated by a complementary tool, a
kind of lint.

Yes, since Scala (like most languages that have C in their ancestry) doesn't consider indentation as semantically significant I would agree that the compiler is the wrong place to enforce this.

When dealing with Java code I rely on checkstyle to warn me about stuff like this. It would be awesome if someone came up with a Scala equivalent to checkstyle.

Ishaaq

On 8 September 2010 15:30, Philippe Lhoste <PhiLho@gmx.net> wrote:

On 06/09/2010 20:40, Russ Paielli wrote:

As I've said before, I'd like to see the compiler reject (or at least
warn of) inconsistent indentation, as in

if (foo)
    bar 1
    bar 2

[...]

If the compiler paid more attention to indentation, it would also have a
much better chance of determining the location of a missing or extra
closing brace.

Mmm, looks more like a task for an IDE than for a compiler! Unless you want to make a language like Python, where indentation is semantically significant.
Actually, such warning could be generated by a complementary tool, a kind of lint.

On Tue, Sep 7, 2010 at 11:57 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Yes, since Scala (like most languages that have C in their ancestry) doesn't consider indentation as semantically significant I would agree that the compiler is the wrong place to enforce this.

I consider that fact to be one of many design flaws of C. Is there one competent C developer anywhere who does not consider proper indentation essential to readable and maintainable code?

A major benefit of Python is that you can be sure that the logical structure of the code is consistent with the indentation (assuming that the code runs, of course).

Yes, that consistency can be enforced by an IDE, but why not just make it part of the language? If every IDE has to reinvent this feature, that tells me it belongs in the language itself. (You can always add a compiler option to disable it in the rare case that someone does not want it.)

I am certainly not claiming that enforced indentation consistency should be a high priority, but in the long term it would be a definite plus. I have no doubt that it would reduce errors and development time. It would make the language ever slightly more reliable, and every bit counts in that regard.

Russ P.

--
http://RussP.us

I guess this is one of those irresolvable religious wars in language
design but the Python/Haskell approach is not all roses either.

On Wed, Sep 8, 2010 at 11:12 AM, Russ Paielli wrote:
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).

Of course, There's only one perfect indentation style.
That is, naturally, the way I do it.  Even if I use a different rule in two different files then they are BOTH perfect, and anything else would be quite obviously wrong.
Given that nobody could possibly write a set of rules that would consistently match my aesthetic preferences, it therefore follows that all enforced indentation styles are flawed.

:)


On 8 September 2010 19:19, Miles Egan <milesegan@gmail.com> wrote:

I guess this is one of those irresolvable religious wars in language
design but the Python/Haskell approach is not all roses either.

On Wed, Sep 8, 2010 at 11:12 AM, Russ Paielli <russ.paielli@gmail.com> wrote:
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).

--
miles

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

I have moved this over to scala-debate.

I think your sarcasm misses the point. If you look at the Python indentation rules, I think you will find that every valid "style" is allowed. The issue is correctness, not style.

If your style is like this:

if (foo)
   bar 1
   bar 2

then I think you have a problem.

Russ P.


On Wed, Sep 8, 2010 at 11:27 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Of course, There's only one perfect indentation style.
That is, naturally, the way I do it.  Even if I use a different rule in two different files then they are BOTH perfect, and anything else would be quite obviously wrong.
Given that nobody could possibly write a set of rules that would consistently match my aesthetic preferences, it therefore follows that all enforced indentation styles are flawed.

:)


On 8 September 2010 19:19, Miles Egan <milesegan@gmail.com> wrote:

I guess this is one of those irresolvable religious wars in language
design but the Python/Haskell approach is not all roses either.

On Wed, Sep 8, 2010 at 11:12 AM, Russ Paielli <russ.paielli@gmail.com> wrote:
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).

--
miles

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
http://RussP.us

"Proper indentation" is highly subjective, which is why tools like
checkstyle and IDE code formatters have so many configuration options.
Consistency across a single codebase is one thing, but enforcing it at
the language level would be deal-breaker for many programmers.

On 09/08/2010 11:12 AM, Russ Paielli wrote:
> On Tue, Sep 7, 2010 at 11:57 PM, Ishaaq Chandy wrote:
>
>> Yes, since Scala (like most languages that have C in their ancestry)
>> doesn't consider indentation as semantically significant I would agree that
>> the compiler is the wrong place to enforce this.
>>
>>
> I consider that fact to be one of many design flaws of C. Is there one
> competent C developer anywhere who does not consider proper indentation
> essential to readable and maintainable code?
>
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).
>
> Yes, that consistency can be enforced by an IDE, but why not just make it
> part of the language? If every IDE has to reinvent this feature, that tells
> me it belongs in the language itself. (You can always add a compiler option
> to disable it in the rare case that someone does not want it.)
>
> I am certainly not claiming that enforced indentation consistency should be
> a high priority, but in the long term it would be a definite plus. I have no
> doubt that it would reduce errors and development time. It would make the
> language ever slightly more reliable, and every bit counts in that regard.
>
> Russ P.
>

I agree that there is more than one valid indentation style, but there is a fairly clear distinction between correct and incorrect indentation. I think the Python rules capture that distinction well. Scala could adopt those rules almost verbatim and still keep the braces.

Russ P.

On Wed, Sep 8, 2010 at 11:38 AM, Aaron Novstrup <anovstrup@stottlerhenke.com> wrote:

"Proper indentation" is highly subjective, which is why tools like
checkstyle and IDE code formatters have so many configuration options.
Consistency across a single codebase is one thing, but enforcing it at
the language level would be deal-breaker for many programmers.

On 09/08/2010 11:12 AM, Russ Paielli wrote:
> On Tue, Sep 7, 2010 at 11:57 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:
>
>> Yes, since Scala (like most languages that have C in their ancestry)
>> doesn't consider indentation as semantically significant I would agree that
>> the compiler is the wrong place to enforce this.
>>
>>
> I consider that fact to be one of many design flaws of C. Is there one
> competent C developer anywhere who does not consider proper indentation
> essential to readable and maintainable code?
>
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).
>
> Yes, that consistency can be enforced by an IDE, but why not just make it
> part of the language? If every IDE has to reinvent this feature, that tells
> me it belongs in the language itself. (You can always add a compiler option
> to disable it in the rare case that someone does not want it.)
>
> I am certainly not claiming that enforced indentation consistency should be
> a high priority, but in the long term it would be a definite plus. I have no
> doubt that it would reduce errors and development time. It would make the
> language ever slightly more reliable, and every bit counts in that regard.
>
> Russ P.
>

--
http://RussP.us

It has been pointed out that this is equivalent to a religious issue, whence follows that everyone should be free to practice his/her belief.
BTW: "I don't like your indentation style." That statement is completely independent of whatever your indentation style might be, and it is always true.
Here's something to think about: If I wanted to worry about Whitespace I'd use that programming language.
Regards,
Roland
PS: when moving a thread it helps not to copy the old list anymore...
On Sep 8, 2010, at 20:40 , Russ Paielli wrote:

I have moved this over to scala-debate.

I think your sarcasm misses the point. If you look at the Python indentation rules, I think you will find that every valid "style" is allowed. The issue is correctness, not style.

If your style is like this:

if (foo)
   bar 1
   bar 2

then I think you have a problem.

Russ P.


On Wed, Sep 8, 2010 at 11:27 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Of course, There's only one perfect indentation style.
That is, naturally, the way I do it.  Even if I use a different rule in two different files then they are BOTH perfect, and anything else would be quite obviously wrong.
Given that nobody could possibly write a set of rules that would consistently match my aesthetic preferences, it therefore follows that all enforced indentation styles are flawed.

:)


On 8 September 2010 19:19, Miles Egan <milesegan@gmail.com> wrote:

I guess this is one of those irresolvable religious wars in language
design but the Python/Haskell approach is not all roses either.

On Wed, Sep 8, 2010 at 11:12 AM, Russ Paielli <russ.paielli@gmail.com> wrote:
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).

--
miles

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
http://RussP.us

--[scala-debate on 2009/10/2]
Viktor Klang: When will the days of numerical overflow be gone?
Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January 2038

I have moved this over to scala-debate.

I think your sarcasm misses the point. If you look at the Python indentation rules, I think you will find that every valid "style" is allowed. The issue is correctness, not style.

If your style is like this:

if (foo)
   bar 1
   bar 2

then I think you have a problem.

Russ P.


On Wed, Sep 8, 2010 at 11:27 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Of course, There's only one perfect indentation style.
That is, naturally, the way I do it.  Even if I use a different rule in two different files then they are BOTH perfect, and anything else would be quite obviously wrong.
Given that nobody could possibly write a set of rules that would consistently match my aesthetic preferences, it therefore follows that all enforced indentation styles are flawed.

:)


On 8 September 2010 19:19, Miles Egan <milesegan@gmail.com> wrote:

I guess this is one of those irresolvable religious wars in language
design but the Python/Haskell approach is not all roses either.

On Wed, Sep 8, 2010 at 11:12 AM, Russ Paielli <russ.paielli@gmail.com> wrote:
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).

--
miles

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
http://RussP.us

Sarcasm aside...
If your example is actually:
<tab>if(foo)<tab><tab>bar 1<spc><spc><spc><spc>bar2

Under 2-space tabs it'll become:
  if(foo)    bar 1    bar 2
But under 4-space tabs (as originally written), it formats as:
    if(foo)        bar 1    bar 2
The problem is that there's an entire ecosystem of tools and practices based on the fact that tabs/spaces are essentially interchangable. With the best will in the world, that's one VERY tough nut to crack.

On 8 September 2010 19:40, Russ Paielli <russ.paielli@gmail.com> wrote:

I have moved this over to scala-debate.

I think your sarcasm misses the point. If you look at the Python indentation rules, I think you will find that every valid "style" is allowed. The issue is correctness, not style.

If your style is like this:

if (foo)
   bar 1
   bar 2

then I think you have a problem.

Russ P.


On Wed, Sep 8, 2010 at 11:27 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Of course, There's only one perfect indentation style.
That is, naturally, the way I do it.  Even if I use a different rule in two different files then they are BOTH perfect, and anything else would be quite obviously wrong.
Given that nobody could possibly write a set of rules that would consistently match my aesthetic preferences, it therefore follows that all enforced indentation styles are flawed.

:)


On 8 September 2010 19:19, Miles Egan <milesegan@gmail.com> wrote:

I guess this is one of those irresolvable religious wars in language
design but the Python/Haskell approach is not all roses either.

On Wed, Sep 8, 2010 at 11:12 AM, Russ Paielli <russ.paielli@gmail.com> wrote:
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).

--
miles

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
http://RussP.us

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Sarcasm aside...
If your example is actually:
<tab>if(foo)<tab><tab>bar 1<spc><spc><spc><spc>bar2

Under 2-space tabs it'll become:
  if(foo)    bar 1    bar 2
But under 4-space tabs (as originally written), it formats as:
    if(foo)        bar 1    bar 2
The problem is that there's an entire ecosystem of tools and practices based on the fact that tabs/spaces are essentially interchangable. With the best will in the world, that's one VERY tough nut to crack.

On 8 September 2010 19:40, Russ Paielli <russ.paielli@gmail.com> wrote:

I have moved this over to scala-debate.

I think your sarcasm misses the point. If you look at the Python indentation rules, I think you will find that every valid "style" is allowed. The issue is correctness, not style.

If your style is like this:

if (foo)
   bar 1
   bar 2

then I think you have a problem.

Russ P.


On Wed, Sep 8, 2010 at 11:27 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Of course, There's only one perfect indentation style.
That is, naturally, the way I do it.  Even if I use a different rule in two different files then they are BOTH perfect, and anything else would be quite obviously wrong.
Given that nobody could possibly write a set of rules that would consistently match my aesthetic preferences, it therefore follows that all enforced indentation styles are flawed.

:)


On 8 September 2010 19:19, Miles Egan <milesegan@gmail.com> wrote:

I guess this is one of those irresolvable religious wars in language
design but the Python/Haskell approach is not all roses either.

On Wed, Sep 8, 2010 at 11:12 AM, Russ Paielli <russ.paielli@gmail.com> wrote:
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).

--
miles

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
http://RussP.us

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

I agree that there is more than one valid indentation style, but there is a fairly clear distinction between correct and incorrect indentation. I think the Python rules capture that distinction well. Scala could adopt those rules almost verbatim and still keep the braces.

Russ P.

On Wed, Sep 8, 2010 at 11:38 AM, Aaron Novstrup <anovstrup@stottlerhenke.com> wrote:

"Proper indentation" is highly subjective, which is why tools like
checkstyle and IDE code formatters have so many configuration options.
Consistency across a single codebase is one thing, but enforcing it at
the language level would be deal-breaker for many programmers.

On 09/08/2010 11:12 AM, Russ Paielli wrote:
> On Tue, Sep 7, 2010 at 11:57 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:
>
>> Yes, since Scala (like most languages that have C in their ancestry)
>> doesn't consider indentation as semantically significant I would agree that
>> the compiler is the wrong place to enforce this.
>>
>>
> I consider that fact to be one of many design flaws of C. Is there one
> competent C developer anywhere who does not consider proper indentation
> essential to readable and maintainable code?
>
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).
>
> Yes, that consistency can be enforced by an IDE, but why not just make it
> part of the language? If every IDE has to reinvent this feature, that tells
> me it belongs in the language itself. (You can always add a compiler option
> to disable it in the rare case that someone does not want it.)
>
> I am certainly not claiming that enforced indentation consistency should be
> a high priority, but in the long term it would be a definite plus. I have no
> doubt that it would reduce errors and development time. It would make the
> language ever slightly more reliable, and every bit counts in that regard.
>
> Russ P.
>

--
http://RussP.us

Nothing wrong with whitespace, it's a good solid programming language!
Though I do feel they could have achieved a richer syntax by exploring non-latin sections of the unicode character set.

On 8 September 2010 19:54, Roland Kuhn <rk@rkuhn.info> wrote:

It has been pointed out that this is equivalent to a religious issue, whence follows that everyone should be free to practice his/her belief.
BTW: "I don't like your indentation style." That statement is completely independent of whatever your indentation style might be, and it is always true.
Here's something to think about: If I wanted to worry about Whitespace I'd use that programming language.
Regards,
Roland
PS: when moving a thread it helps not to copy the old list anymore...
On Sep 8, 2010, at 20:40 , Russ Paielli wrote:

I have moved this over to scala-debate.

I think your sarcasm misses the point. If you look at the Python indentation rules, I think you will find that every valid "style" is allowed. The issue is correctness, not style.

If your style is like this:

if (foo)
   bar 1
   bar 2

then I think you have a problem.

Russ P.


On Wed, Sep 8, 2010 at 11:27 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Of course, There's only one perfect indentation style.
That is, naturally, the way I do it.  Even if I use a different rule in two different files then they are BOTH perfect, and anything else would be quite obviously wrong.
Given that nobody could possibly write a set of rules that would consistently match my aesthetic preferences, it therefore follows that all enforced indentation styles are flawed.

:)


On 8 September 2010 19:19, Miles Egan <milesegan@gmail.com> wrote:

I guess this is one of those irresolvable religious wars in language
design but the Python/Haskell approach is not all roses either.

On Wed, Sep 8, 2010 at 11:12 AM, Russ Paielli <russ.paielli@gmail.com> wrote:
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).

--
miles

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
http://RussP.us

--[scala-debate on 2009/10/2]
Viktor Klang: When will the days of numerical overflow be gone?
Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January 2038

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Now you're talking about mixing tabs and spaces. To be honest, I don't even know how Python deals with that issue, but I assume it has something reasonable. If it were up to me, I would either:

1. disallow tabs altogether, or
2. disallow mixing tabs and spaces for indentation in the same block

It's not a difficult problem to overcome.

By the way, here's another bad indentation "style":

if (foo) {
   bar 1
   bar 2

bar 3
bar 4
}

This type of thing is, of course, usually not done intentionally. It's usually a bug. That's why I think the compiler should reject it.

For me, this whole issue comes down to the advantage of static checking and verification of code. I would think that Scala users would come down in favor of static checking by the compiler. That certainly seems to be the philosophy when it comes to, say, type checking. I don't hear people arguing that we should just leave type checking to an IDE or to the run-time environment.


Russ P.


On Wed, Sep 8, 2010 at 11:49 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Sarcasm aside...
If your example is actually:
<tab>if(foo)<tab><tab>bar 1<spc><spc><spc><spc>bar2

Under 2-space tabs it'll become:
  if(foo)    bar 1    bar 2
But under 4-space tabs (as originally written), it formats as:
    if(foo)        bar 1    bar 2
The problem is that there's an entire ecosystem of tools and practices based on the fact that tabs/spaces are essentially interchangable. With the best will in the world, that's one VERY tough nut to crack.

On 8 September 2010 19:40, Russ Paielli <russ.paielli@gmail.com> wrote:

I have moved this over to scala-debate.

I think your sarcasm misses the point. If you look at the Python indentation rules, I think you will find that every valid "style" is allowed. The issue is correctness, not style.

If your style is like this:

if (foo)
   bar 1
   bar 2

then I think you have a problem.

Russ P.


On Wed, Sep 8, 2010 at 11:27 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Of course, There's only one perfect indentation style.
That is, naturally, the way I do it.  Even if I use a different rule in two different files then they are BOTH perfect, and anything else would be quite obviously wrong.
Given that nobody could possibly write a set of rules that would consistently match my aesthetic preferences, it therefore follows that all enforced indentation styles are flawed.

:)


On 8 September 2010 19:19, Miles Egan <milesegan@gmail.com> wrote:

I guess this is one of those irresolvable religious wars in language
design but the Python/Haskell approach is not all roses either.

On Wed, Sep 8, 2010 at 11:12 AM, Russ Paielli <russ.paielli@gmail.com> wrote:
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).

--
miles

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
http://RussP.us

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
http://RussP.us

> Though I do feel they could have achieved a richer syntax by exploring non-latin sections of the unicode character set.

That's why my favorite programming language is ѬՖਐໃ.

A

Date: Wed, 8 Sep 2010 19:57:15 +0100
Subject: Re: [scala-debate] Re: [scala-user] Re: confusing error message about unmatched closing brace
From: kev.lee.wright@gmail.com
To: rk@rkuhn.info
CC: russ.paielli@gmail.com; scala-debate@listes.epfl.ch

Nothing wrong with whitespace, it's a good solid programming language!
Though I do feel they could have achieved a richer syntax by exploring non-latin sections of the unicode character set.

On 8 September 2010 19:54, Roland Kuhn <rk@rkuhn.info> wrote:

It has been pointed out that this is equivalent to a religious issue, whence follows that everyone should be free to practice his/her belief.
BTW: "I don't like your indentation style." That statement is completely independent of whatever your indentation style might be, and it is always true.
Here's something to think about: If I wanted to worry about Whitespace I'd use that programming language.
Regards,
Roland
PS: when moving a thread it helps not to copy the old list anymore...
On Sep 8, 2010, at 20:40 , Russ Paielli wrote:

I have moved this over to scala-debate.

I think your sarcasm misses the point. If you look at the Python indentation rules, I think you will find that every valid "style" is allowed. The issue is correctness, not style.

If your style is like this:

if (foo)
   bar 1
   bar 2

then I think you have a problem.

Russ P.


On Wed, Sep 8, 2010 at 11:27 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Of course, There's only one perfect indentation style.
That is, naturally, the way I do it.  Even if I use a different rule in two different files then they are BOTH perfect, and anything else would be quite obviously wrong.
Given that nobody could possibly write a set of rules that would consistently match my aesthetic preferences, it therefore follows that all enforced indentation styles are flawed.

:)


On 8 September 2010 19:19, Miles Egan <milesegan@gmail.com> wrote:

I guess this is one of those irresolvable religious wars in language
design but the Python/Haskell approach is not all roses either.

On Wed, Sep 8, 2010 at 11:12 AM, Russ Paielli <russ.paielli@gmail.com> wrote:
> A major benefit of Python is that you can be sure that the logical structure
> of the code is consistent with the indentation (assuming that the code runs,
> of course).

--
miles

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
http://RussP.us

--[scala-debate on 2009/10/2]
Viktor Klang: When will the days of numerical overflow be gone?
Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January 2038

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Hi Russ,

On Sep 8, 2010, at 21:13 , Russ Paielli wrote:

> Now you're talking about mixing tabs and spaces. To be honest, I don't even know how Python deals with that issue, but I assume it has something reasonable. If it were up to me, I would either:
>
> 1. disallow tabs altogether, or
> 2. disallow mixing tabs and spaces for indentation in the same block
>
> It's not a difficult problem to overcome.
>
Think editing an existing file with a different editor from a different account or on a different operating system. You don't want to take away my freedom to use ed without contortions, do you?

> By the way, here's another bad indentation "style":
>
> if (foo) {
> bar 1
> bar 2
>
> bar 3
> bar 4
> }
>
> This type of thing is, of course, usually not done intentionally. It's usually a bug. That's why I think the compiler should reject it.
>
No, it's perfectly valid code, no doubt about it. If I want pretty code, I can still get that by running my indentation-magic-Perl-script later.

> For me, this whole issue comes down to the advantage of static checking and verification of code. I would think that Scala users would come down in favor of static checking by the compiler. That certainly seems to be the philosophy when it comes to, say, type checking. I don't hear people arguing that we should just leave type checking to an IDE or to the run-time environment.
>
You are seriously confused. Types are about correctness, indentation is about personal taste or priorities (or project needs).

Write a code-checker based on indentation, advertise it and see how many downloads or how much positive feedback you get. I bet you'll mostly get feature requests for making it more flexible.

Regards,

Roland

--
[scala-debate on 2009/10/2]
Viktor Klang: When will the days of numerical overflow be gone?
Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January 2038

On Wed, Sep 8, 2010 at 12:26 PM, Roland Kuhn <rk@rkuhn.info> wrote:

Hi Russ,

On Sep 8, 2010, at 21:13 , Russ Paielli wrote:

> Now you're talking about mixing tabs and spaces. To be honest, I don't even know how Python deals with that issue, but I assume it has something reasonable. If it were up to me, I would either:
>
> 1. disallow tabs altogether, or
> 2. disallow mixing tabs and spaces for indentation in the same block
>
> It's not a difficult problem to overcome.
>
Think editing an existing file with a different editor from a different account or on a different operating system. You don't want to take away my freedom to use ed without contortions, do you?

> By the way, here's another bad indentation "style":
>
> if (foo) {
>    bar 1
>    bar 2
>
> bar 3
> bar 4
> }
>
> This type of thing is, of course, usually not done intentionally. It's usually a bug. That's why I think the compiler should reject it.
>
No, it's perfectly valid code, no doubt about it. If I want pretty code, I can still get that by running my indentation-magic-Perl-script later.

> For me, this whole issue comes down to the advantage of static checking and verification of code. I would think that Scala users would come down in favor of static checking by the compiler. That certainly seems to be the philosophy when it comes to, say, type checking. I don't hear people arguing that we should just leave type checking to an IDE or to the run-time environment.
>
You are seriously confused. Types are about correctness, indentation is about personal taste or priorities (or project needs).

With all due respect, I think you are the one who is seriously confused. As I have said several times now, there are "styles" of correct indentation, and there is incorrect indentation. There are "styles" of driving too, but running red lights is not a valid one. You want to leave the indentation checking to an IDE or a script, but I think that static checking by the compiler is perfectly consistent with the general philosophy of Scala.

I'm probably more sensitive to this issue since I am converting some Python code to Scala. Trust me, in a large file, the braces are very easy to get wrong. The indentation is much easier to follow by eyeball than the logical structure based on the braces. If the two are guaranteed to be consistent, then your code is much less likely to mislead you.

Russ P.

 

Write a code-checker based on indentation, advertise it and see how many downloads or how much positive feedback you get. I bet you'll mostly get feature requests for making it more flexible.

Regards,

Roland

--
[scala-debate on 2009/10/2]
Viktor Klang: When will the days of numerical overflow be gone?
Ricky Clarkson: One second after 03:14:07 UTC on Tuesday, 19 January 2038

--
http://RussP.us

I think it's entirely reasonable for Scala to emit warnings about mismatched parens based on information from whitespace.  If someone wanted to modify the compiler to do that, I'd support it and appreciate its inclusion.  (I would appreciate many other things much more, but still....)

I don't think it's reasonable for Scala to use whitespace as grouping syntax, for reasons discussed last time this topic came up.

I also recommend to people who are converting from Python to Scala that, if they leave the code intact instead of rewriting from scratch, they write a ten-line Python or Scala program that inserts parens around the appropriate code blocks so they don't have to do it by hand.

If they're writing it by hand, well, they're learning.  They should expect to take some time to get used to the differences, including how to quickly and painlessly find where parens are mismatched.  I had problems with this for the first few months after I switched from Modula-2 to C++.  Then I got over it.

  --Rex

P.S. The atypical style of
  if (condition)
  {
    something
    something_else
  }
makes paren-matching especially easy.  I used to write my C/C++ that way for improved understanding of the logical block structure when I had a screen with plenty of vertical lines of space (mounted in portrait mode).

> Is there one competent C developer anywhere who does not consider proper
> indentation essential to readable and maintainable code?

On a human aesthetic level (which I consider more than nice-to-have!)
yes. On a technical machine level, no.

While I was attracted by Pythons pure syntax first, it wasn't long
to recognize that it can be annoying that you are obliged to obey it
in any circumstance. E.g. on unix piping through a perl -e script was
easy, same for any other indentation free script. Not so for Python.

As I work with an Model Driven approach in enterprise development, what means
heavy code generation, I am more than thankful that our target languages are
indentation agnostic and can be automatically reformatted (say: "butified") when
and where useful.

> A major benefit of Python is that you can be sure that the logical
> structure of the code is consistent with the indentation (assuming that
> the code runs, of course).

But you can't be sure the indentation is consistent with the intention.
So the way from intention to logical structure is one step too far.
Wrong Editor settings on one site (different tab with, not replacing
tab with space, or replacing space with tab but not like intented) corrupted
a program on another site way too often for me, so no WYSIWYG.

"Maintainable" by "Readable" for me means that I am able to "read"
(= see) all significant characters. This is not true for different
whitespaces, which are by nature indistinguishable, if not made explicitly
visible, what OTOH is even more annoying in editing code.

> Yes, that consistency can be enforced by an IDE, but why not just make
> it part of the language? If every IDE has to reinvent this feature,
> that tells me it belongs in the language itself.

Then I would vote for making syntax highlighting an integral part of
the language. If a word is green, than it is a variable. If it is
red, than it is a method. Comments are grey without the need for extra
characters.
Why should every IDE reinvent syntax highlighting again and again and
even more, come to different color solutions?
That tells me it belongs in the language itself. :-)

(I'm not too serious here as I think that this is a non-topic for
Scala either at this stage of development).

KR
Det

On 08/09/2010 20:49, Kevin Wright wrote:
> if(foo)
> bar 1
> bar2

Although I prefer tabs, I am relatively neutral in the tabs vs. spaces debate and use
spaces when working on a project using them. Will do when starting to code in Python, and
must do when pasting my code in a Web browser (they default to 8 spaces and apparently
there is no way to change that).

But, frankly, mixing tabs and spaces is confusing and really asking for disaster... I see
that in Java API source code and I cringe because it is unreadable, and I won't change my
settings to fit those of Sun, which are not explicit anyway. Actually, if I look, for
example, at JComponent (its constructor, the paint method), it seems quite random.
I am guessing that Sun engineers doesn't follow coding rules (I suppose they had some...)
and forgot to set their editor (or just used some Notepad for a quick fix?).
That's where "intelligent" editors analyzing the start of code to switch automatically to
the existing style are useful.
Tools like CheckStyle or VCS filters can help too.

And, hey, systematically using soft braces around blocks, avoiding the given, admittedly
confusing example given by Russ of:

if (foo)
doThis
doThat

(can trick somebody doing a quick, casual code reading) can help too.

At worst, style

if (foo) doThis
doThat

is usable for short lines.

Spaces aren't necessarily better for consistency, if one sets her editor to 2 spaces
instead of the 3 requested by the code rule (as I correct often in our own code...), and
merge tools might mix up closing braces, automatically bringing chaos like:

if( nId1 > nId2 )
{
return 1;
}
else
{
if( nId1 < nId2 )
{
return -1;
}
else
{
return 0;
}
}

I mentioned VCS filters, an intelligent one could reject a commit until code is fixed and
consistent indenting is applied...
Or, as Russ suggested, an option to the compiler asking it to stop with an error if it
finds an inconsistency...

I moved this discussion over to scala-debate. More below.

On Thu, Sep 9, 2010 at 12:57 AM, Detering Dirk <Dirk.Detering@bitmarck.de> wrote:

> Is there one competent C developer anywhere who does not consider proper
> indentation essential to readable and maintainable code?

On a human aesthetic level (which I consider more than nice-to-have!)
yes. On a technical machine level, no.

While I was attracted by Pythons pure syntax first, it wasn't long
to recognize that it can be annoying that you are obliged to obey it
in any circumstance. E.g. on unix piping through a perl -e script was
easy, same for any other indentation free script. Not so for Python.

As I work with an Model Driven approach in enterprise development, what means
heavy code generation, I am more than thankful that our target languages are
indentation agnostic and can be automatically reformatted (say: "butified") when
and where useful.

As I said, a compiler option could be provided to suppress indentation checking. I'd even be happy if the option was to activate indentation checking, leaving if off by default.
 

> A major benefit of Python is that you can be sure that the logical
> structure of the code is consistent with the indentation (assuming that
> the code runs, of course).

But you can't be sure the indentation is consistent with the intention.
So the way from intention to logical structure is one step too far.
Wrong Editor settings on one site (different tab with, not replacing
tab with space, or replacing space with tab but not like intented) corrupted
a program on another site way too often for me, so no WYSIWYG.

"Maintainable" by "Readable" for me means that I am able to "read"
(= see) all significant characters. This is not true for different
whitespaces, which are by nature indistinguishable, if not made explicitly
visible, what OTOH is even more annoying in editing code.

> Yes, that consistency can be enforced by an IDE, but why not just make
> it part of the language? If every IDE has to reinvent this feature,
> that tells me it belongs in the language itself.

Then I would vote for making syntax highlighting an integral part of
the language. If a word is green, than it is a variable. If it is
red, than it is a method. Comments are grey without the need for extra
characters.
Why should every IDE reinvent syntax highlighting again and again and
even more, come to different color solutions?
That tells me it belongs in the language itself.  :-)

You sarcasm misses the point. Color highlighting of code is not part of the code itself. Indentation is. If every IDE checks for indentation, then why not just have the compiler do it?

Not every programmer uses an IDE. We've been over this before. For example, someone who is just starting to learn programming on their own is not likely to immediately use an IDE (unless one is specifically recommended and provided by an associate). Scientists and engineers who "dabble" in programming also often do not use an IDE.

Russ P.

 

(I'm not too serious here as I think that this is a non-topic for
Scala either at this stage of development).

KR
Det

--
http://RussP.us

On 08/09/2010 20:49, Kevin Wright wrote:
> if(foo)
> bar 1
> bar2

Although I prefer tabs, I am relatively neutral in the tabs vs. spaces debate and use
spaces when working on a project using them. Will do when starting to code in Python, and
must do when pasting my code in a Web browser (they default to 8 spaces and apparently
there is no way to change that).

But, frankly, mixing tabs and spaces is confusing and really asking for disaster... I see
that in Java API source code and I cringe because it is unreadable, and I won't change my
settings to fit those of Sun, which are not explicit anyway. Actually, if I look, for
example, at JComponent (its constructor, the paint method), it seems quite random.
I am guessing that Sun engineers doesn't follow coding rules (I suppose they had some...)
and forgot to set their editor (or just used some Notepad for a quick fix?).
That's where "intelligent" editors analyzing the start of code to switch automatically to
the existing style are useful.
Tools like CheckStyle or VCS filters can help too.

And, hey, systematically using soft braces around blocks, avoiding the given, admittedly
confusing example given by Russ of:

if (foo)
doThis
doThat

(can trick somebody doing a quick, casual code reading) can help too.

At worst, style

if (foo) doThis
doThat

is usable for short lines.

Spaces aren't necessarily better for consistency, if one sets her editor to 2 spaces
instead of the 3 requested by the code rule (as I correct often in our own code...), and
merge tools might mix up closing braces, automatically bringing chaos like:

if( nId1 > nId2 )
{
return 1;
}
else
{
if( nId1 < nId2 )
{
return -1;
}
else
{
return 0;
}
}

I mentioned VCS filters, an intelligent one could reject a commit until code is fixed and
consistent indenting is applied...
Or, as Russ suggested, an option to the compiler asking it to stop with an error if it
finds an inconsistency...