example of why i suspect i don't like semicolon inference as-is

Could you explain?

On Wed, Jul 21, 2010 at 5:31 PM, Raoul Duke <raould@gmail.com> wrote:

try { val tag1v1 = new ID3v1_1( randomAccessFile ); } catch { case e
=> println(e) }

vs.

try { val tag1v1 = new ID3v1_1( randomAccessFile ) } catch { case e =>
println(e) }

:-(

On Wed, Jul 21, 2010 at 3:14 PM, Naftoli Gugenheim wrote:
> Could you explain?

sorry, should have been less terse.

when i try them in scala 2.7.3 final, the 2nd one (without the ";")
gives a compilation error. as an end-user i would prefer such ascii
inference to not have what appear to be edge-cases i have to bump
into.

sincerely.

I don't understand. Have you tried it on more recent versions? And what is the compiler error?

On Wed, Jul 21, 2010 at 6:19 PM, Raoul Duke <raould@gmail.com> wrote:

On Wed, Jul 21, 2010 at 3:14 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:
> Could you explain?

sorry, should have been less terse.

when i try them in scala 2.7.3 final, the 2nd one (without the ";")
gives a compilation error. as an end-user i would prefer such ascii
inference to not have what appear to be edge-cases i have to bump
into.

sincerely.

On Wed, Jul 21, 2010 at 3:22 PM, Naftoli Gugenheim wrote:
> I don't understand. Have you tried it on more recent versions?

nope. i guess that's uncouth of me? ugh, trying to keep up with the
jonses is hard, but i take the point. i will try to make the effort to
try it on 2.8 now.

> And what is
> the compiler error?

error: block must end in result expression, not in definition

sincerely.

I just tested similar code on 2.8.0 and both versions are accepted.

On Wed, Jul 21, 2010 at 3:19 PM, Raoul Duke wrote:
> On Wed, Jul 21, 2010 at 3:14 PM, Naftoli Gugenheim wrote:
>> Could you explain?
>
> sorry, should have been less terse.
>
> when i try them in scala 2.7.3 final, the 2nd one (without the ";")
> gives a compilation error. as an end-user i would prefer such ascii
> inference to not have what appear to be edge-cases i have to bump
> into.

On Wednesday July 21 2010, Raoul Duke wrote:
> On Wed, Jul 21, 2010 at 3:22 PM, Naftoli Gugenheim
wrote:
> > I don't understand. Have you tried it on more recent versions?
>
> nope. i guess that's uncouth of me? ugh, trying to keep up with the
> jonses is hard, but i take the point. i will try to make the effort
> to try it on 2.8 now.
>
> > And what is
> > the compiler error?
>
> error: block must end in result expression, not in definition
>
> sincerely.

That is not purely a syntactic thing. The presense of the semicolon
means there's a (trivial) expression of type Unit at the end of the
block and that makes the method semantically acceptable. The reason
it's OK in Scala 2.8 without the semicolon is not due to a change in
the syntax per se, but because the rules about declarations appearing
in final position of a block has been relaxed. Now such blocks are
acceptable and have type Unit.

Randall Schulz

How come they were relaxed?

On Wed, Jul 21, 2010 at 7:27 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Wednesday July 21 2010, Raoul Duke wrote:
> On Wed, Jul 21, 2010 at 3:22 PM, Naftoli Gugenheim
<naftoligug@gmail.com> wrote:
> > I don't understand. Have you tried it on more recent versions?
>
> nope. i guess that's uncouth of me? ugh, trying to keep up with the
> jonses is hard, but i take the point. i will try to make the effort
> to try it on 2.8 now.
>
> > And what is
> > the compiler error?
>
> error: block must end in result expression, not in definition
>
> sincerely.

That is not purely a syntactic thing. The presense of the semicolon
means there's a (trivial) expression of type Unit at the end of the
block and that makes the method semantically acceptable. The reason
it's OK in Scala 2.8 without the semicolon is not due to a change in
the syntax per se, but because the rules about declarations appearing
in final position of a block has been relaxed. Now such blocks are
acceptable and have type Unit.


Randall Schulz

Some people complained about it, and Martin thought that it was an unnecessary restriction. You do know how he is about unnecessary constraints on the programmers, don't you?

On Wed, Jul 21, 2010 at 10:24 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

How come they were relaxed?

On Wed, Jul 21, 2010 at 7:27 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Wednesday July 21 2010, Raoul Duke wrote:
> On Wed, Jul 21, 2010 at 3:22 PM, Naftoli Gugenheim
<naftoligug@gmail.com> wrote:
> > I don't understand. Have you tried it on more recent versions?
>
> nope. i guess that's uncouth of me? ugh, trying to keep up with the
> jonses is hard, but i take the point. i will try to make the effort
> to try it on 2.8 now.
>
> > And what is
> > the compiler error?
>
> error: block must end in result expression, not in definition
>
> sincerely.

That is not purely a syntactic thing. The presense of the semicolon
means there's a (trivial) expression of type Unit at the end of the
block and that makes the method semantically acceptable. The reason
it's OK in Scala 2.8 without the semicolon is not due to a change in
the syntax per se, but because the rules about declarations appearing
in final position of a block has been relaxed. Now such blocks are
acceptable and have type Unit.


Randall Schulz

--
Daniel C. Sobral

I travel to the future all the time.

On Wednesday July 21 2010, Naftoli Gugenheim wrote:
> How come they were relaxed?

Dunno'

Probably people grumbled enough. Possibly a good argument was made.
I think you could find it in the mailing list archives.

Randall Schulz

Yeah, the last unnecessary constraint still can't use its left arm....

In any case, Scala tends to prefer "expression oriented" code.   i.e. your blocks should end with expressions that are returned as a result.   2.7.x tended to force you into this more due to requiring () at the end of imperative blocks more so than 2.8 does.   I'm somewhat happy this restriction was relaxed, but I'd encourage you to still strive for expression oriented code.   You'll find yourself understanding blocks easier as time goes on, and it drastically reduces clutter in algorithms.

- Josh

On Wed, Jul 21, 2010 at 9:38 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

Some people complained about it, and Martin thought that it was an unnecessary restriction. You do know how he is about unnecessary constraints on the programmers, don't you?

On Wed, Jul 21, 2010 at 10:24 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

How come they were relaxed?

On Wed, Jul 21, 2010 at 7:27 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Wednesday July 21 2010, Raoul Duke wrote:
> On Wed, Jul 21, 2010 at 3:22 PM, Naftoli Gugenheim
<naftoligug@gmail.com> wrote:
> > I don't understand. Have you tried it on more recent versions?
>
> nope. i guess that's uncouth of me? ugh, trying to keep up with the
> jonses is hard, but i take the point. i will try to make the effort
> to try it on 2.8 now.
>
> > And what is
> > the compiler error?
>
> error: block must end in result expression, not in definition
>
> sincerely.

That is not purely a syntactic thing. The presense of the semicolon
means there's a (trivial) expression of type Unit at the end of the
block and that makes the method semantically acceptable. The reason
it's OK in Scala 2.8 without the semicolon is not due to a change in
the syntax per se, but because the rules about declarations appearing
in final position of a block has been relaxed. Now such blocks are
acceptable and have type Unit.


Randall Schulz

--
Daniel C. Sobral

I travel to the future all the time.

Not to be a tight a... but readability in code is much more important
then compactness imho. Your example is a perfect example where
compactness clutters code and doesn't improve readablity.
So please add a few newlines and the semicolon inference problem goes
away and people can actually skim the code more easily.

-Stefan

2010/7/21 Raoul Duke :
> try { val tag1v1 = new ID3v1_1( randomAccessFile ); } catch { case e
> => println(e) }
>
> vs.
>
> try { val tag1v1 = new ID3v1_1( randomAccessFile ) } catch { case e =>
> println(e) }
>
> :-(
>

On Thu, Jul 22, 2010 at 12:36 AM, Stefan Langer
wrote:
> Not to be a tight a... but readability in code is much more important
> then compactness imho.

it depends.

:)

On Thursday July 22 2010, Raoul Duke wrote:
> On Thu, Jul 22, 2010 at 12:36 AM, Stefan Langer
>
> wrote:
> > Not to be a tight a... but readability in code is much more
> > important then compactness imho.
>
> it depends.
>
> :)

If a compact presentation serves readability and comprehensibility, it's
justified and positive. If not, it's not.

Nothing is intrinsically served by fitting more code in less space other
than fitting more code in less space.

Of course, none of this addresses the subjectivity of "readability,"
while compactness probably admits an objective metric.

Randall Schulz

On Thu, Jul 22, 2010 at 10:57 AM, Randall R Schulz wrote:
>> it depends.
> Of course, none of this addresses the subjectivity of "readability,"
> while compactness probably admits an objective metric.

yes, the subjectivity of it is the point.

My new rubric for readability is "a single expression should map to a single sentence of thought". So,

list map { e => /* some simple expression of e */ }

is a much more readable rendering of "translate the list elements as XYZ" than the Java equivalent

List<SomeType> newList = new List<SomeType>();
for(l : originalList) {
  newList.add(
    //...some simple expression of l
  );
}

You might be able to diagnose unreadable code as the result of a couple different pathologies. In one direction, your code expression doesn't encode an intuitively easy to understand thought; in the other direction, your code expression encodes a way too complex thought, which really should be broken up in to several simpler expressions to be more understandable.

Brian Maso

On Thu, Jul 22, 2010 at 11:12 AM, Raoul Duke <raould@gmail.com> wrote:

On Thu, Jul 22, 2010 at 10:57 AM, Randall R Schulz <rschulz@sonic.net> wrote:
>> it depends.
> Of course, none of this addresses the subjectivity of "readability,"
> while compactness probably admits an objective metric.

yes, the subjectivity of it is the point.

On Thu, Jul 22, 2010 at 11:33 AM, Brian Maso wrote:
> My new rubric for readability is "a single expression should map to a single
> sentence of thought". So,

yeah.

but. :-)

(now getting quite OT)

the main problem i have with this is that the *tools freaking suck*.
as a responsible software developer, i have to know how the debugger
works, and write my code to make it actually understandable and
investigable and visible and clear in the debugger, which means i have
to do things in jvm languages (and i saw similar issues in the .net
world) along the lines of:

final boolean ba = testA();
final boolean bb = testB();
return ba && bb;

instead of

return testA() && testB();

sincerely.

i always prefer to write methods that have no side effects. this way,
the second solution would still be debuggable

Raoul Duke schrieb:
> On Thu, Jul 22, 2010 at 11:33 AM, Brian Maso wrote:
>
>> My new rubric for readability is "a single expression should map to a single
>> sentence of thought". So,
>>
>
> yeah.
>
> but. :-)
>
> (now getting quite OT)
>
> the main problem i have with this is that the *tools freaking suck*.
> as a responsible software developer, i have to know how the debugger
> works, and write my code to make it actually understandable and
> investigable and visible and clear in the debugger, which means i have
> to do things in jvm languages (and i saw similar issues in the .net
> world) along the lines of:
>
> final boolean ba = testA();
> final boolean bb = testB();
> return ba && bb;
>
> instead of
>
> return testA() && testB();
>
> sincerely.
>
>

If I were able to boil the ocean, I would immediate make it a "standard" function for all debuggers to be able to split apart compound expressions so that I could debug portions of them. Seems kind of like it would be easy relatively easy to implement since on the bytecode level each expression gets individually executed and the result is pushed on to the stack. (Though I must admit I don't have time to make a prototype or experiment with this myself.)

Brian Maso

On Thu, Jul 22, 2010 at 12:33 PM, HamsterofDeath <h-star@gmx.de> wrote:

i always prefer to write methods that have no side effects. this way,
the second solution would still be debuggable

Raoul Duke schrieb:
> On Thu, Jul 22, 2010 at 11:33 AM, Brian Maso <brian@blumenfeld-maso.com> wrote:
>
>> My new rubric for readability is "a single expression should map to a single
>> sentence of thought". So,
>>
>
> yeah.
>
> but. :-)
>
> (now getting quite OT)
>
> the main problem i have with this is that the *tools freaking suck*.
> as a responsible software developer, i have to know how the debugger
> works, and write my code to make it actually understandable and
> investigable and visible and clear in the debugger, which means i have
> to do things in jvm languages (and i saw similar issues in the .net
> world) along the lines of:
>
>    final boolean ba = testA();
>    final boolean bb = testB();
>    return ba && bb;
>
> instead of
>
>    return testA() && testB();
>
> sincerely.
>
>

True, but how does the debugger know which characters correspond to which instruction? The .class file only contains line numbers.

On Thu, Jul 22, 2010 at 3:43 PM, Brian Maso <brian@blumenfeld-maso.com> wrote:

If I were able to boil the ocean, I would immediate make it a "standard" function for all debuggers to be able to split apart compound expressions so that I could debug portions of them. Seems kind of like it would be easy relatively easy to implement since on the bytecode level each expression gets individually executed and the result is pushed on to the stack. (Though I must admit I don't have time to make a prototype or experiment with this myself.)

Brian Maso

On Thu, Jul 22, 2010 at 12:33 PM, HamsterofDeath <h-star@gmx.de> wrote:

i always prefer to write methods that have no side effects. this way,
the second solution would still be debuggable

Raoul Duke schrieb:
> On Thu, Jul 22, 2010 at 11:33 AM, Brian Maso <brian@blumenfeld-maso.com> wrote:
>
>> My new rubric for readability is "a single expression should map to a single
>> sentence of thought". So,
>>
>
> yeah.
>
> but. :-)
>
> (now getting quite OT)
>
> the main problem i have with this is that the *tools freaking suck*.
> as a responsible software developer, i have to know how the debugger
> works, and write my code to make it actually understandable and
> investigable and visible and clear in the debugger, which means i have
> to do things in jvm languages (and i saw similar issues in the .net
> world) along the lines of:
>
>    final boolean ba = testA();
>    final boolean bb = testB();
>    return ba && bb;
>
> instead of
>
>    return testA() && testB();
>
> sincerely.
>
>

In all but the most complicated and pathological of classfiles, you can use automated processes to reconstruct Java expression trees from bytecode. You can at least deduce the expression tree and present the expression tree to the user for each line, letting the user put breakpoints within the expression tree. In theory, anyway...

Brian Maso

Sent via BlackBerry by AT&T

From: Naftoli Gugenheim <naftoligug@gmail.com> Date: Thu, 22 Jul 2010 19:56:01 -0400To: Brian Maso<brian@blumenfeld-maso.com>Cc: HamsterofDeath<h-star@gmx.de>; Raoul Duke<raould@gmail.com>; scala-user<scala-user@listes.epfl.ch>Subject: Re: [scala-user] example of why i suspect i don't like semicolon inference as-is
True, but how does the debugger know which characters correspond to which instruction? The .class file only contains line numbers.

On Thu, Jul 22, 2010 at 3:43 PM, Brian Maso <brian@blumenfeld-maso.com> wrote:

If I were able to boil the ocean, I would immediate make it a "standard" function for all debuggers to be able to split apart compound expressions so that I could debug portions of them. Seems kind of like it would be easy relatively easy to implement since on the bytecode level each expression gets individually executed and the result is pushed on to the stack. (Though I must admit I don't have time to make a prototype or experiment with this myself.)

Brian Maso

On Thu, Jul 22, 2010 at 12:33 PM, HamsterofDeath <h-star@gmx.de> wrote:

i always prefer to write methods that have no side effects. this way,
the second solution would still be debuggable

Raoul Duke schrieb:
> On Thu, Jul 22, 2010 at 11:33 AM, Brian Maso <brian@blumenfeld-maso.com> wrote:
>
>> My new rubric for readability is "a single expression should map to a single
>> sentence of thought". So,
>>
>
> yeah.
>
> but. :-)
>
> (now getting quite OT)
>
> the main problem i have with this is that the *tools freaking suck*.
> as a responsible software developer, i have to know how the debugger
> works, and write my code to make it actually understandable and
> investigable and visible and clear in the debugger, which means i have
> to do things in jvm languages (and i saw similar issues in the .net
> world) along the lines of:
>
>    final boolean ba = testA();
>    final boolean bb = testB();
>    return ba && bb;
>
> instead of
>
>    return testA() && testB();
>
> sincerely.
>
>

That's true.

On Thu, Jul 22, 2010 at 7:56 PM, <brian@blumenfeld-maso.com> wrote:

In all but the most complicated and pathological of classfiles, you can use automated processes to reconstruct Java expression trees from bytecode. You can at least deduce the expression tree and present the expression tree to the user for each line, letting the user put breakpoints within the expression tree. In theory, anyway...

Brian Maso

Sent via BlackBerry by AT&T

From: Naftoli Gugenheim <naftoligug@gmail.com> Date: Thu, 22 Jul 2010 19:56:01 -0400To: Brian Maso<brian@blumenfeld-maso.com>Cc: HamsterofDeath<h-star@gmx.de>; Raoul Duke<raould@gmail.com>; scala-user<scala-user@listes.epfl.ch> Subject: Re: [scala-user] example of why i suspect i don't like semicolon inference as-is
True, but how does the debugger know which characters correspond to which instruction? The .class file only contains line numbers.

On Thu, Jul 22, 2010 at 3:43 PM, Brian Maso <brian@blumenfeld-maso.com> wrote:

If I were able to boil the ocean, I would immediate make it a "standard" function for all debuggers to be able to split apart compound expressions so that I could debug portions of them. Seems kind of like it would be easy relatively easy to implement since on the bytecode level each expression gets individually executed and the result is pushed on to the stack. (Though I must admit I don't have time to make a prototype or experiment with this myself.)

Brian Maso

On Thu, Jul 22, 2010 at 12:33 PM, HamsterofDeath <h-star@gmx.de> wrote:

i always prefer to write methods that have no side effects. this way,
the second solution would still be debuggable

Raoul Duke schrieb:
> On Thu, Jul 22, 2010 at 11:33 AM, Brian Maso <brian@blumenfeld-maso.com> wrote:
>
>> My new rubric for readability is "a single expression should map to a single
>> sentence of thought". So,
>>
>
> yeah.
>
> but. :-)
>
> (now getting quite OT)
>
> the main problem i have with this is that the *tools freaking suck*.
> as a responsible software developer, i have to know how the debugger
> works, and write my code to make it actually understandable and
> investigable and visible and clear in the debugger, which means i have
> to do things in jvm languages (and i saw similar issues in the .net
> world) along the lines of:
>
>    final boolean ba = testA();
>    final boolean bb = testB();
>    return ba && bb;
>
> instead of
>
>    return testA() && testB();
>
> sincerely.
>
>

I generally agree with your statement but
try { ... } catch { ... } is not a single thought so it does not
belong on one line imho of course.
The reason for try catch is to separate error handling from the work
code. So we have two lines of thoughts
1. the actuall working code
2. the error handling code

-Stefan

2010/7/22 Brian Maso :
> My new rubric for readability is "a single expression should map to a single
> sentence of thought". So,
>
> list map { e => /* some simple expression of e */ }
>
> is a much more readable rendering of "translate the list elements as XYZ"
> than the Java equivalent
>
> List newList = new List();
> for(l : originalList) {
>   newList.add(
>     //...some simple expression of l
>   );
> }
>
> You might be able to diagnose unreadable code as the result of a couple
> different pathologies. In one direction, your code expression doesn't encode
> an intuitively easy to understand thought; in the other direction, your code
> expression encodes a way too complex thought, which really should be broken
> up in to several simpler expressions to be more understandable.
>
> Brian Maso
>
> On Thu, Jul 22, 2010 at 11:12 AM, Raoul Duke wrote:
>>
>> On Thu, Jul 22, 2010 at 10:57 AM, Randall R Schulz
>> wrote:
>> >> it depends.
>> > Of course, none of this addresses the subjectivity of "readability,"
>> > while compactness probably admits an objective metric.
>>
>> yes, the subjectivity of it is the point.
>
>

Usually, I agree. But, for instance:
try { Some(s.toInt) } catch { case _ => None }
To me, that belongs in a single line. 

On Fri, Jul 23, 2010 at 5:29 AM, Stefan Langer <mailtolanger@googlemail.com> wrote:

I generally agree with your statement but
try { ... } catch { ... } is not a single thought so it does not
belong on one line imho of course.
The reason for try catch is to separate error handling from the work
code. So we have two lines of thoughts
1. the actuall working code
2. the error handling code

-Stefan

2010/7/22 Brian Maso <brian@blumenfeld-maso.com>:
> My new rubric for readability is "a single expression should map to a single
> sentence of thought". So,
>
> list map { e => /* some simple expression of e */ }
>
> is a much more readable rendering of "translate the list elements as XYZ"
> than the Java equivalent
>
> List<SomeType> newList = new List<SomeType>();
> for(l : originalList) {
>   newList.add(
>     //...some simple expression of l
>   );
> }
>
> You might be able to diagnose unreadable code as the result of a couple
> different pathologies. In one direction, your code expression doesn't encode
> an intuitively easy to understand thought; in the other direction, your code
> expression encodes a way too complex thought, which really should be broken
> up in to several simpler expressions to be more understandable.
>
> Brian Maso
>
> On Thu, Jul 22, 2010 at 11:12 AM, Raoul Duke <raould@gmail.com> wrote:
>>
>> On Thu, Jul 22, 2010 at 10:57 AM, Randall R Schulz <rschulz@sonic.net>
>> wrote:
>> >> it depends.
>> > Of course, none of this addresses the subjectivity of "readability,"
>> > while compactness probably admits an objective metric.
>>
>> yes, the subjectivity of it is the point.
>
>

--
Daniel C. Sobral

I travel to the future all the time.

I'd argue that try{...} catch{...} is pretty clearly expressing the separation of action and error.
To do the above, I think scala.util.control.Exception provides better ways to express yourself, eg:
catching(classOf[IOException]) opt (/*something that might throw an IOException*/)
expresses the same thing better.
On Fri, Jul 23, 2010 at 4:35 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

Usually, I agree. But, for instance:
try { Some(s.toInt) } catch { case _ => None }
To me, that belongs in a single line. 

On Fri, Jul 23, 2010 at 5:29 AM, Stefan Langer <mailtolanger@googlemail.com> wrote:

I generally agree with your statement but
try { ... } catch { ... } is not a single thought so it does not
belong on one line imho of course.
The reason for try catch is to separate error handling from the work
code. So we have two lines of thoughts
1. the actuall working code
2. the error handling code

-Stefan

2010/7/22 Brian Maso <brian@blumenfeld-maso.com>:
> My new rubric for readability is "a single expression should map to a single
> sentence of thought". So,
>
> list map { e => /* some simple expression of e */ }
>
> is a much more readable rendering of "translate the list elements as XYZ"
> than the Java equivalent
>
> List<SomeType> newList = new List<SomeType>();
> for(l : originalList) {
>   newList.add(
>     //...some simple expression of l
>   );
> }
>
> You might be able to diagnose unreadable code as the result of a couple
> different pathologies. In one direction, your code expression doesn't encode
> an intuitively easy to understand thought; in the other direction, your code
> expression encodes a way too complex thought, which really should be broken
> up in to several simpler expressions to be more understandable.
>
> Brian Maso
>
> On Thu, Jul 22, 2010 at 11:12 AM, Raoul Duke <raould@gmail.com> wrote:
>>
>> On Thu, Jul 22, 2010 at 10:57 AM, Randall R Schulz <rschulz@sonic.net>
>> wrote:
>> >> it depends.
>> > Of course, none of this addresses the subjectivity of "readability,"
>> > while compactness probably admits an objective metric.
>>
>> yes, the subjectivity of it is the point.
>
>

--
Daniel C. Sobral

I travel to the future all the time.