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

suggestion for Scala syntax: implied braces

87 replies
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
I like Scala a lot. I am making a major investment of time and effort into it, and I hope it soon becomes wildly popular. I'd like to see it eventually become an accepted language for safety-critical systems in my field of air traffic management.

Scala has many advanced features, but one of my favorite features is implied semi-colons. I really appreciate not having to litter my code with a semi-colon after each statement. When I first became aware of that feature, I knew I was going to like Scala.

I would like to suggest a similar feature that would make Scala syntax even more elegant: implied braces, or block delimiting by indentation, without braces, as in Python.

What about backward compatibility? That problem can be solved by simply making braces optional. Where braces are used, they override the indentation structure (just as semi-colons override the line structure when used explicitly). All currently working code will still work exactly the same. But if you leave out the braces on a particular block, the indentation structure delimits the block, exactly as in Python. In any particular block, either method could be used, and both methods could be used arbitrarily in the same file.

Not only would implied braces make code cleaner, but I think it would be clearer too. To my way of thinking, the indentation structure is easier to follow visually than braces. I've been bitten more than once by a block where I mistakenly left off the braces, and it compiled just fine but didn't do what I was expecting. That sort of error is much less likely if the indentation structure defines the logical structure and is therefore guaranteed to be consistent with it.

Russ P.

--
http://RussP.us
David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces
Sorry, but...
Emacs is better than vi.
One must eat one's eggs starting at the small end (yes, I'm a little endian).

On Thu, Jun 3, 2010 at 4:53 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
I like Scala a lot. I am making a major investment of time and effort into it, and I hope it soon becomes wildly popular. I'd like to see it eventually become an accepted language for safety-critical systems in my field of air traffic management.

Scala has many advanced features, but one of my favorite features is implied semi-colons. I really appreciate not having to litter my code with a semi-colon after each statement. When I first became aware of that feature, I knew I was going to like Scala.

I would like to suggest a similar feature that would make Scala syntax even more elegant: implied braces, or block delimiting by indentation, without braces, as in Python.

What about backward compatibility? That problem can be solved by simply making braces optional. Where braces are used, they override the indentation structure (just as semi-colons override the line structure when used explicitly). All currently working code will still work exactly the same. But if you leave out the braces on a particular block, the indentation structure delimits the block, exactly as in Python. In any particular block, either method could be used, and both methods could be used arbitrarily in the same file.

Not only would implied braces make code cleaner, but I think it would be clearer too. To my way of thinking, the indentation structure is easier to follow visually than braces. I've been bitten more than once by a block where I mistakenly left off the braces, and it compiled just fine but didn't do what I was expecting. That sort of error is much less likely if the indentation structure defines the logical structure and is therefore guaranteed to be consistent with it.

Russ P.

--
http://RussP.us



--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics
Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Thursday June 3 2010, David Pollak wrote:
> Sorry, but...
>
> Emacs is better than vi.

And springy clothespins are better than that other kind.

RRS

Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Thursday June 3 2010, Russ Paielli wrote:
> On Thu, Jun 3, 2010 at 4:56 PM, David Pollak
>
> wrote:
> > Sorry, but...
> >
> > Emacs is better than vi.
>
> No argument there. ...
>
> What do you think about my suggestion?

An abomination unto the FSM.

RRS

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Thu, Jun 3, 2010 at 4:56 PM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:
Sorry, but...
Emacs is better than vi.

No argument there. I've been using XEmacs for many years. I can save a file by hitting a single key (the F2 key), whereas vi requires at least two keystrokes to save a file. Case closed.

What do you think about my suggestion?

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces


On Thu, Jun 3, 2010 at 5:13 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
On Thursday June 3 2010, Russ Paielli wrote:
> On Thu, Jun 3, 2010 at 4:56 PM, David Pollak
>
> <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com>wrote:
> > Sorry, but...
> >
> > Emacs is better than vi.
>
> No argument there. ...
>
> What do you think about my suggestion?

An abomination unto the FSM.

 Let's leave presidential politics out of it.

Do you think the same thing about implied semi-colons?

--
http://RussP.us
Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Thursday June 3 2010, Russ Paielli wrote:
> I can appreciate a bit of levity, but I hope you don't think that my
> suggestion is trivial in terms of the effect it could have on the
> popularity of Scala. I think it could have a major effect. And
> eliminating a source of bugs is nothing to sneeze at.

Eliminating? Quite the opposite, clearly.

It sure better be meant as humor. It is quite funny.

RRS

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces
I can appreciate a bit of levity, but I hope you don't think that my suggestion is trivial in terms of the effect it could have on the popularity of Scala. I think it could have a major effect. And eliminating a source of bugs is nothing to sneeze at.

On Thu, Jun 3, 2010 at 5:07 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
On Thursday June 3 2010, David Pollak wrote:
> Sorry, but...
>
> Emacs is better than vi.

And springy clothespins are better than that other kind.


RRS



--
http://RussP.us
Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Thursday June 3 2010, Russ Paielli wrote:
> ...
>
> Do you think the same thing about implied semi-colons?

They're a double-edged sword. Scala's aren't as bad as Groovy's.

Randall Schulz

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces


On Thu, Jun 3, 2010 at 5:21 PM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:

More broadly, having some kind of language syntax fracture where some Scala code is curly and other Scala code is indented means that moving between code bases gets harder (if Lift is curly and Akka is indented, then it means that it's harder for me to contribute to Akka and it's harder for Jonas to contribute to Lift.)

Well, thanks for the reply, but as you probably anticipated, I respectfully disagree. There would be no problem mixing code that uses both styles. And if you want a uniform style, simple require it, or someone could fairly easily write a converter.

According to your argument, implied semi-colons should be a problem, because one person might use explicit semi-colons and another might not. It doesn't matter. Eventually, people would realize that the indentation method is superior for the reasons I explained, and it would become the standard.

Russ P.

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: suggestion for Scala syntax: implied braces
Most of us prefer to use disrespectful disagreement.  You see, this way there's more "dis-"-ing to do.

I've just started using some python at work, and I'm on the fence regarding syntax.   You haven't really clarified how one would *open* a scope.  

Would you rather see

if(foo)
  something...
// This comment here could really hose the inferencer... especially if I added a space above...
else
  something else


You see... by combining the two, explicit syntax defined blocks with implicit indentation defined, you need to work around issues to try to put together something greater then the individual pieces.   And python lovers will never be happy with it, because it won't quite be indentation based.   Java/C language lovers won't be happy because sometimes their indentation will cause strange bugs.

I think if you want to make a suggestion like this come across as more than "wow, that would be nice", you should try to back it up with logical arguments to all the potential issues you may cause.   Especially with a change this large.   You should try to show corner cases and how to deal with them, along with *every possible block* you could create today, and how it would look with indentation-based inference.

- Josh

On Thu, Jun 3, 2010 at 8:28 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:


On Thu, Jun 3, 2010 at 5:21 PM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:

More broadly, having some kind of language syntax fracture where some Scala code is curly and other Scala code is indented means that moving between code bases gets harder (if Lift is curly and Akka is indented, then it means that it's harder for me to contribute to Akka and it's harder for Jonas to contribute to Lift.)

Well, thanks for the reply, but as you probably anticipated, I respectfully disagree. There would be no problem mixing code that uses both styles. And if you want a uniform style, simple require it, or someone could fairly easily write a converter.

According to your argument, implied semi-colons should be a problem, because one person might use explicit semi-colons and another might not. It doesn't matter. Eventually, people would realize that the indentation method is superior for the reasons I explained, and it would become the standard.

Russ P.


David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces


On Thu, Jun 3, 2010 at 5:13 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
I can appreciate a bit of levity, but I hope you don't think that my suggestion is trivial in terms of the effect it could have on the popularity of Scala. I think it could have a major effect. And eliminating a source of bugs is nothing to sneeze at.

I come from a C background and personally despise Python's use of whitespace to denote blocks.  Other people have other opinions, but if there was one clearly better way, every language would have adopted it by now.  Thus the emacs vs. vi comment.
More broadly, having some kind of language syntax fracture where some Scala code is curly and other Scala code is indented means that moving between code bases gets harder (if Lift is curly and Akka is indented, then it means that it's harder for me to contribute to Akka and it's harder for Jonas to contribute to Lift.)
There are syntactic changes I'd like to see in Scala, but it's too late now... and until Scala 3000 in 5 or 10 or 15 years, I doubt that there's going to be any material syntax changes to the language.  


On Thu, Jun 3, 2010 at 5:07 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
On Thursday June 3 2010, David Pollak wrote:
> Sorry, but...
>
> Emacs is better than vi.

And springy clothespins are better than that other kind.


RRS



--
http://RussP.us



--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces


On Thu, Jun 3, 2010 at 5:25 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
On Thursday June 3 2010, Russ Paielli wrote:
> I can appreciate a bit of levity, but I hope you don't think that my
> suggestion is trivial in terms of the effect it could have on the
> popularity of Scala. I think it could have a major effect. And
> eliminating a source of bugs is nothing to sneeze at.

Eliminating? Quite the opposite, clearly.

It sure better be meant as humor. It is quite funny.

 I have done extensive programming in Python, and a substantial but not huge amount in Scala. I have never had a bug directly attributable to misunderstanding where a block ended in Python, but I have had more than one such bug in Scala.

Please explain to me how Python's indentation rules can cause a bug? (Yes, I realize that mixing tabs and spaces can cause problems, but I would suggest that tabs simply be prohibited for indentation.)

Russ P.



extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: suggestion for Scala syntax: implied braces

On Thu, Jun 03, 2010 at 05:13:48PM -0700, Russ Paielli wrote:
> I can appreciate a bit of levity, but I hope you don't think that my
> suggestion is trivial in terms of the effect it could have on the
> popularity of Scala. I think it could have a major effect.

I am 100% in agreement.

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Thu, Jun 3, 2010 at 5:28 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
On Thu, Jun 03, 2010 at 05:13:48PM -0700, Russ Paielli wrote:
> I can appreciate a bit of levity, but I hope you don't think that my
> suggestion is trivial in terms of the effect it could have on the
> popularity of Scala. I think it could have a major effect.

I am 100% in agreement.

 Great! Let's get started.

Oh, wait... you aren't being a smart-ass are you?


Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces


On Thu, Jun 3, 2010 at 5:36 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
Most of us prefer to use disrespectful disagreement.  You see, this way there's more "dis-"-ing to do.

I've just started using some python at work, and I'm on the fence regarding syntax.   You haven't really clarified how one would *open* a scope.  

Would you rather see

if(foo)
  something...
// This comment here could really hose the inferencer... especially if I added a space above...
else
  something else


You see... by combining the two, explicit syntax defined blocks with implicit indentation defined, you need to work around issues to try to put together something greater then the individual pieces.   And python lovers will never be happy with it, because it won't quite be indentation based.   Java/C language lovers won't be happy because sometimes their indentation will cause strange bugs.

I think if you want to make a suggestion like this come across as more than "wow, that would be nice", you should try to back it up with logical arguments to all the potential issues you may cause.   Especially with a change this large.   You should try to show corner cases and how to deal with them, along with *every possible block* you could create today, and how it would look with indentation-based inference.

 You are absolutely right. I don't claim to have considered every possible problem with this idea. But I fail to see the problem with your code snippet above. I believe that Python completely ignores all comment lines are far as indentation structure is concerned. Comments are completely irrelevant in that regard. Ditto for blank lines. I'll bet Python's rules can handle 99.99% of cases, and the remaining cases will need to be addressed. But first we need to identify them. Let me know if you can think of any.

Now that you mention it, I do see a potential problem for existing code if the indentation structure is inconsistent with the logical structure, as in

if (foo)
    first line of code
    second line of code

In this case, with current conventions only the first line of code is in the if block. The second line is indented misleadingly. If the second line is really not supposed to be in the if block, then this code will work differently when my idea is implemented. That's a legitimate concern ... but then again, this code is misleading and should be corrected anyway. And I would hope it is very rare.

Russ P.

Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Thursday June 3 2010, Russ Paielli wrote:
> ...
> (... I would suggest that tabs simply be prohibited for indentation.)

You can have my tabs when you pry them from my cold, dead hands.

> Russ P.

RRS

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Thu, Jun 3, 2010 at 5:57 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
On Thursday June 3 2010, Russ Paielli wrote:
> ...
> (... I would suggest that tabs simply be prohibited for indentation.)

You can have my tabs when you pry them from my cold, dead hands.


I believe that Python allows tabs and spaces to be mixed for indentation. I'm not sure exactly what the rules are, and I don't care much, because I don't use tabs. I have my XEmacs tab key set to insert four spaces. I suspect that mixing tabs and spaces is just asking for trouble, since they can be displayed differently in different editors or even the same editor with a different configuration. That is why my inclination would be to just sidestep the issue by prohibiting tabs for indentation in Scala. But that would only apply for blocks that are using implied braces. For blocks that use explicit braces, tabs are perfectly fine.

Russ P.

Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: suggestion for Scala syntax: implied braces
I love Python and its syntax with all of my heart, but I don't think it would work for Scala without completely changing the syntax.
I think you'd have to create an entirely new syntax...and I have a feeling that would be very hard to do while maintaining compatibility with many Scala DSLs.
So you could try.  I bet it wouldn't be that hard to plug a new syntax into the Scala compiler, or you could always just transform it to Scala and then feed it in that way.

On Thu, Jun 3, 2010 at 7:53 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
I like Scala a lot. I am making a major investment of time and effort into it, and I hope it soon becomes wildly popular. I'd like to see it eventually become an accepted language for safety-critical systems in my field of air traffic management.

Scala has many advanced features, but one of my favorite features is implied semi-colons. I really appreciate not having to litter my code with a semi-colon after each statement. When I first became aware of that feature, I knew I was going to like Scala.

I would like to suggest a similar feature that would make Scala syntax even more elegant: implied braces, or block delimiting by indentation, without braces, as in Python.

What about backward compatibility? That problem can be solved by simply making braces optional. Where braces are used, they override the indentation structure (just as semi-colons override the line structure when used explicitly). All currently working code will still work exactly the same. But if you leave out the braces on a particular block, the indentation structure delimits the block, exactly as in Python. In any particular block, either method could be used, and both methods could be used arbitrarily in the same file.

Not only would implied braces make code cleaner, but I think it would be clearer too. To my way of thinking, the indentation structure is easier to follow visually than braces. I've been bitten more than once by a block where I mistakenly left off the braces, and it compiled just fine but didn't do what I was expecting. That sort of error is much less likely if the indentation structure defines the logical structure and is therefore guaranteed to be consistent with it.

Russ P.

--
http://RussP.us



--
http://erikengbrecht.blogspot.com/
dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: suggestion for Scala syntax: implied braces
It might be a reference that the thing most hated about Python is the use of identation to delimit blocks. It's not hated by Pythonistas, of course, but the most common cause for people to dislike Python seems to be that. I also hear some complain about lack of true multithreading, but it often sound like rationalization for the dislike.

On Thu, Jun 3, 2010 at 9:36 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

On Thu, Jun 3, 2010 at 5:28 PM, Paul Phillips <paulp [at] improving [dot] org> wrote:
On Thu, Jun 03, 2010 at 05:13:48PM -0700, Russ Paielli wrote:
> I can appreciate a bit of levity, but I hope you don't think that my
> suggestion is trivial in terms of the effect it could have on the
> popularity of Scala. I think it could have a major effect.

I am 100% in agreement.

 Great! Let's get started.

Oh, wait... you aren't being a smart-ass are you?





--
Daniel C. Sobral

I travel to the future all the time.
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces


On Thu, Jun 3, 2010 at 7:06 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com> wrote:
I love Python and its syntax with all of my heart, but I don't think it would work for Scala without completely changing the syntax.

I don't understand why you think that. I see it as a minor change to the syntax. I consider it the next logical extension of the idea behind implied semi-colons: the idea of  removing extraneous crap from the syntax to realize a cleaner language.

Years ago, when I was reading up on Ada and considering using it for my work (never did), I suggested on the Ada usenet group that the need for a semi-colon after every statement be eliminated. Man, did I get flak over that! Oh, it would ruin the language, make it unrecognizable, cause all kinds of dangerous bugs, etc., etc. After trying for days to reason with people, shooting down many ridiculous arguments for semi-colons, and enduring just about every insult you can imagine, I eventually realized that Ada programmers were used to seeing semi-colons everywhere, and they just felt insecure without them.

I could be wrong, but I suspect I am facing a similar irrational psychological barrier on the Scala braces. I was happy to see that the Scala designers agree with me on the semi-colon issue, and I am hoping they will eventually come around on braces too and realize that they don't need that little crutch to feel secure.

 
I think you'd have to create an entirely new syntax...and I have a feeling that would be very hard to do while maintaining compatibility with many Scala DSLs.
So you could try.  I bet it wouldn't be that hard to plug a new syntax into the Scala compiler, or you could always just transform it to Scala and then feed it in that way.

Yes, I might try to write my own little pre-processor just for kicks if I ever find the time. But guaranteeing that it works for every possible corner case could be difficult, and making practical use of it for real work could be a challenge.

Russ P.
 

Archontophoenix
Joined: 2010-02-04,
User offline. Last seen 2 years 35 weeks ago.
RE: suggestion for Scala syntax: implied braces
I suspect that whether you love or hate Python-style indentation depends on whether you uniformly avoid Python code that contains tabs, or avoid tools that display tabs in a way that differs from Python's conventions.

There is an important difference between making semicolons optional and making indentation significant: semicolons are universally treated as printing characters, so no matter what tool you use to examine Scala code with, the presence or absence of a semicolon is always visible. Tabs, on the other hand, are utterly baffling to many widely used pieces of software that display text, and if you don't avoid those tools, you have no idea how a given piece of Python is indented.

Having been bitten by this in my own very, very short Python career, I say: never again.

A

Date: Thu, 3 Jun 2010 18:10:24 -0700
Subject: Re: [scala-debate] suggestion for Scala syntax: implied braces
From: russ [dot] paielli [at] gmail [dot] com
To: scala-debate [at] listes [dot] epfl [dot] ch

On Thu, Jun 3, 2010 at 5:57 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
On Thursday June 3 2010, Russ Paielli wrote:
> ...
> (... I would suggest that tabs simply be prohibited for indentation.)

You can have my tabs when you pry them from my cold, dead hands.


I believe that Python allows tabs and spaces to be mixed for indentation. I'm not sure exactly what the rules are, and I don't care much, because I don't use tabs. I have my XEmacs tab key set to insert four spaces. I suspect that mixing tabs and spaces is just asking for trouble, since they can be displayed differently in different editors or even the same editor with a different configuration. That is why my inclination would be to just sidestep the issue by prohibiting tabs for indentation in Scala. But that would only apply for blocks that are using implied braces. For blocks that use explicit braces, tabs are perfectly fine.

Russ P.


The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. Get busy.
Johannes Rudolph 2
Joined: 2010-02-12,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

Despite that I never really used Python for any substantial amount of
code, I liked how Python code looks like. Of course, I cannot really
comment on real problems people have with that feature, since I
haven't used it enough. However, I'm pretty sure, there would be
difficult and non-obvious edge cases in Scala where one would
experience problems, especially with any "migration strategy" which
allows both syntaxes.

If you really want to propose such a change, you should try to
implement it yourself. It's just a change to Scala's scanner and
parser, if it is as easy as you think it would be, the change
shouldn't be too difficult either. Then all the people would have
something to play around with and could try to annoy you with real
edge cases.

Here's another idea: I find, that much need for curly braces comes
from local variable definitions. If we could have a variable (val,
var) definition _expression_ instead of a statement (like in "val x =
5 in ") one could remove braces in short snippets of code where they
are most ugly IMO. I'm pretty sure someone thought about that before
and didn't like it for some reason. Is it just for the creation of
another keyword?

Johannes

On Fri, Jun 4, 2010 at 7:21 AM, adriaN kinG wrote:
> I suspect that whether you love or hate Python-style indentation depends on
> whether you uniformly avoid Python code that contains tabs, or avoid tools
> that display tabs in a way that differs from Python's conventions.
>
> There is an important difference between making semicolons optional and
> making indentation significant: semicolons are universally treated as
> printing characters, so no matter what tool you use to examine Scala code
> with, the presence or absence of a semicolon is always visible. Tabs, on the
> other hand, are utterly baffling to many widely used pieces of software that
> display text, and if you don't avoid those tools, you have no idea how a
> given piece of Python is indented.
>
> Having been bitten by this in my own very, very short Python career, I say:
> never again.
>
> A
>
> ________________________________
> Date: Thu, 3 Jun 2010 18:10:24 -0700
> Subject: Re: [scala-debate] suggestion for Scala syntax: implied braces
> From: russ [dot] paielli [at] gmail [dot] com
> To: scala-debate [at] listes [dot] epfl [dot] ch
>
> On Thu, Jun 3, 2010 at 5:57 PM, Randall R Schulz wrote:
>
> On Thursday June 3 2010, Russ Paielli wrote:
>> ...
>> (... I would suggest that tabs simply be prohibited for indentation.)
>
> You can have my tabs when you pry them from my cold, dead hands.
>
>
> I believe that Python allows tabs and spaces to be mixed for indentation.
> I'm not sure exactly what the rules are, and I don't care much, because I
> don't use tabs. I have my XEmacs tab key set to insert four spaces. I
> suspect that mixing tabs and spaces is just asking for trouble, since they
> can be displayed differently in different editors or even the same editor
> with a different configuration. That is why my inclination would be to just
> sidestep the issue by prohibiting tabs for indentation in Scala. But that
> would only apply for blocks that are using implied braces. For blocks that
> use explicit braces, tabs are perfectly fine.
>
> Russ P.
>
>
> ________________________________
> The New Busy is not the too busy. Combine all your e-mail accounts with
> Hotmail. Get busy.

H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: suggestion for Scala syntax: implied braces

after thinking a bit, i don't see a reason to enhance the language this way. it would be possible, yes, maybe even not that hard, but you wouldn't save many braces compared to semicolons.
however, i see a reason NOT to enhance scala this way. imagine you have a rather complex method made of several blocks. now imaginge 4 or 5 of these methods inside a class. if you remove a brace now, you'll quickly find the missing one. however, mess with the tabs or spaces, and you'll totally mess everything up without necessarily producing a compilation error.

-------- Original-Nachricht --------
> Datum: Thu, 3 Jun 2010 21:50:03 -0700
> Von: Russ Paielli
> An: scala-debate [at] listes [dot] epfl [dot] ch
> Betreff: Re: [scala-debate] suggestion for Scala syntax: implied braces

> On Thu, Jun 3, 2010 at 7:06 PM, Erik Engbrecht
> wrote:
>
> > I love Python and its syntax with all of my heart, but I don't think it
> > would work for Scala without completely changing the syntax.
> >
> >
> I don't understand why you think that. I see it as a minor change to the
> syntax. I consider it the next logical extension of the idea behind
> implied
> semi-colons: the idea of removing extraneous crap from the syntax to
> realize a cleaner language.
>
> Years ago, when I was reading up on Ada and considering using it for my
> work
> (never did), I suggested on the Ada usenet group that the need for a
> semi-colon after every statement be eliminated. Man, did I get flak over
> that! Oh, it would ruin the language, make it unrecognizable, cause all
> kinds of dangerous bugs, etc., etc. After trying for days to reason with
> people, shooting down many ridiculous arguments for semi-colons, and
> enduring just about every insult you can imagine, I eventually realized
> that
> Ada programmers were used to seeing semi-colons everywhere, and they just
> felt insecure without them.
>
> I could be wrong, but I suspect I am facing a similar irrational
> psychological barrier on the Scala braces. I was happy to see that the
> Scala
> designers agree with me on the semi-colon issue, and I am hoping they will
> eventually come around on braces too and realize that they don't need that
> little crutch to feel secure.
>
>
>
> > I think you'd have to create an entirely new syntax...and I have a
> feeling
> > that would be very hard to do while maintaining compatibility with many
> > Scala DSLs.
> >
> > So you could try. I bet it wouldn't be that hard to plug a new syntax
> into
> > the Scala compiler, or you could always just transform it to Scala and
> then
> > feed it in that way.
> >
> >
> Yes, I might try to write my own little pre-processor just for kicks if I
> ever find the time. But guaranteeing that it works for every possible
> corner
> case could be difficult, and making practical use of it for real work
> could
> be a challenge.
>
> Russ P.

Johannes Rudolph 2
Joined: 2010-02-12,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Fri, Jun 4, 2010 at 12:29 PM, Johannes Rudolph
wrote:
> Here's the patch to make that idea work reusing the 'yield' keyword:
Just wanted to note that the use of 'yield' is rather arbitrary and
just to demonstrate the syntax without having to introduce another
keyword.

Johannes Rudolph 2
Joined: 2010-02-12,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Fri, Jun 4, 2010 at 11:07 AM, Johannes Rudolph
wrote:
> Here's another idea: I find, that much need for curly braces comes
> from local variable definitions. If we could have a variable (val,
> var) definition _expression_ instead of a statement (like in "val x =
> 5 in ") one could remove braces in short snippets of code where they
> are most ugly IMO. I'm pretty sure someone thought about that before
> and didn't like it for some reason. Is it just for the creation of
> another keyword?

Here's the patch to make that idea work reusing the 'yield' keyword:

diff --git a/src/compiler/scala/tools/nsc/ast/parser/Parsers.scala
b/src/compiler/scala/tools/nsc/ast/parser/Parsers.scala
index 8c3fa71..1330644 100644

Ruediger Keller
Joined: 2010-04-11,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

Sorry, but I somewhat fail to see the benefit of your proposal. All
your examples can be written more concisely with the currently
available syntax.

Can you show a better example?

Regards,
Ruediger

2010/6/4 Johannes Rudolph :
> On Fri, Jun 4, 2010 at 12:29 PM, Johannes Rudolph
> wrote:
>> Here's the patch to make that idea work reusing the 'yield' keyword:
> Just wanted to note that the use of 'yield' is rather arbitrary and
> just to demonstrate the syntax without having to introduce another
> keyword.
>
> --
> Johannes
>
> -----------------------------------------------
> Johannes Rudolph
> http://virtual-void.net
>

Johannes Rudolph 2
Joined: 2010-02-12,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

For example:

object Test {
def someExpensiveOperation: Int = { println("Starting");
Thread.sleep(5000); println("Finished"); 12 }
val result =
val tmp = someExpensiveOperation yield
tmp + tmp
}

scala> Test.result
Starting
Finished
res0: Int = 24

instead of

val result = { val tmp = someExpensiveOperation; tmp + tmp }

With the proposed syntax (and doing the same for defining functions
with 'def') you could write side-effect free code almost without
braces. For code with side-effect braces are ok because you need some
kind of syntax which encloses the sequence of operations anyway. Many
other functional languages have the 'let ... in ...' syntax to
introduce bindings.

On Fri, Jun 4, 2010 at 1:16 PM, Ruediger Keller wrote:
> Sorry, but I somewhat fail to see the benefit of your proposal. All
> your examples can be written more concisely with the currently
> available syntax.
>
> Can you show a better example?
>
> Regards,
> Ruediger
>
>
> 2010/6/4 Johannes Rudolph :
>> On Fri, Jun 4, 2010 at 12:29 PM, Johannes Rudolph
>> wrote:
>>> Here's the patch to make that idea work reusing the 'yield' keyword:
>> Just wanted to note that the use of 'yield' is rather arbitrary and
>> just to demonstrate the syntax without having to introduce another
>> keyword.
>>
>> --
>> Johannes
>>
>> -----------------------------------------------
>> Johannes Rudolph
>> http://virtual-void.net
>>
>

Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: suggestion for Scala syntax: implied braces
In Python parenthesis are always require for function/method arguments.  In Scala they are optional in many circumstances.  Python relies and parenthesis and other delimiters ([] for lists, {} for dictionaries) in handling multi-line statements.  My Python programs usually don't have a lot of multi-line statements (usually just an occasional big list comprehension), but my Scala code is full of multi-line statements and expressions.  Many Scala constructs rely on the fact that parenthesis are optional to be remain aesthetically pleasing.  Scala also has things like multiply argument lists and implicit parameters and default parameters that make this more complicated.
Also note that sometimes semicolon inference fails in Scala.  Not often, but it happens, and can create confusing results.  I have a feeling delimiting blocks using indentation would make this worse.
I think Python...hmmm...strongly guides programmers into a certain style.  Scala does not, and it is very apparent when looking at the Scala code from different people.
So while I think someone could probably make it work for trivial cases, I think it would end up creating a lot of confusion when it interacts with other Scala constructs.
On Fri, Jun 4, 2010 at 12:50 AM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:


On Thu, Jun 3, 2010 at 7:06 PM, Erik Engbrecht <erik [dot] engbrecht [at] gmail [dot] com> wrote:
I love Python and its syntax with all of my heart, but I don't think it would work for Scala without completely changing the syntax.

I don't understand why you think that. I see it as a minor change to the syntax. I consider it the next logical extension of the idea behind implied semi-colons: the idea of  removing extraneous crap from the syntax to realize a cleaner language.

Years ago, when I was reading up on Ada and considering using it for my work (never did), I suggested on the Ada usenet group that the need for a semi-colon after every statement be eliminated. Man, did I get flak over that! Oh, it would ruin the language, make it unrecognizable, cause all kinds of dangerous bugs, etc., etc. After trying for days to reason with people, shooting down many ridiculous arguments for semi-colons, and enduring just about every insult you can imagine, I eventually realized that Ada programmers were used to seeing semi-colons everywhere, and they just felt insecure without them.

I could be wrong, but I suspect I am facing a similar irrational psychological barrier on the Scala braces. I was happy to see that the Scala designers agree with me on the semi-colon issue, and I am hoping they will eventually come around on braces too and realize that they don't need that little crutch to feel secure.

 
I think you'd have to create an entirely new syntax...and I have a feeling that would be very hard to do while maintaining compatibility with many Scala DSLs.
So you could try.  I bet it wouldn't be that hard to plug a new syntax into the Scala compiler, or you could always just transform it to Scala and then feed it in that way.

Yes, I might try to write my own little pre-processor just for kicks if I ever find the time. But guaranteeing that it works for every possible corner case could be difficult, and making practical use of it for real work could be a challenge.

Russ P.
 




--
http://erikengbrecht.blogspot.com/
Ruediger Keller
Joined: 2010-04-11,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

Ah, ok, i see. I agree that's really useful sometimes.

Regards,
Ruediger

2010/6/4 Johannes Rudolph :
> For example:
>
> object Test {
>  def someExpensiveOperation: Int = { println("Starting");
> Thread.sleep(5000); println("Finished"); 12 }
>  val result =
>     val tmp = someExpensiveOperation yield
>        tmp + tmp
> }
>
> scala> Test.result
> Starting
> Finished
> res0: Int = 24
>
> instead of
>
> val result = { val tmp = someExpensiveOperation; tmp + tmp }
>
> With the proposed syntax (and doing the same for defining functions
> with 'def') you could write side-effect free code almost without
> braces. For code with side-effect braces are ok because you need some
> kind of syntax which encloses the sequence of operations anyway. Many
> other functional languages have the 'let ... in ...' syntax to
> introduce bindings.
>
> On Fri, Jun 4, 2010 at 1:16 PM, Ruediger Keller wrote:
>> Sorry, but I somewhat fail to see the benefit of your proposal. All
>> your examples can be written more concisely with the currently
>> available syntax.
>>
>> Can you show a better example?
>>
>> Regards,
>> Ruediger
>>
>>
>> 2010/6/4 Johannes Rudolph :
>>> On Fri, Jun 4, 2010 at 12:29 PM, Johannes Rudolph
>>> wrote:
>>>> Here's the patch to make that idea work reusing the 'yield' keyword:
>>> Just wanted to note that the use of 'yield' is rather arbitrary and
>>> just to demonstrate the syntax without having to introduce another
>>> keyword.
>>>
>>> --
>>> Johannes
>>>
>>> -----------------------------------------------
>>> Johannes Rudolph
>>> http://virtual-void.net
>>>
>>
>
>
>
> --
> Johannes
>
> -----------------------------------------------
> Johannes Rudolph
> http://virtual-void.net
>

Ruediger Keller
Joined: 2010-04-11,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

But wouldn't we need another syntax change to allow multiple vals to
participte in such a construct?

like this:

val a = calcA(), b = calcB(), c = calcC() yield sqrt(a*a + b*b + c*c)

Regards,
Ruediger

2010/6/4 Johannes Rudolph :
> For example:
>
> object Test {
>  def someExpensiveOperation: Int = { println("Starting");
> Thread.sleep(5000); println("Finished"); 12 }
>  val result =
>     val tmp = someExpensiveOperation yield
>        tmp + tmp
> }
>
> scala> Test.result
> Starting
> Finished
> res0: Int = 24
>
> instead of
>
> val result = { val tmp = someExpensiveOperation; tmp + tmp }
>
> With the proposed syntax (and doing the same for defining functions
> with 'def') you could write side-effect free code almost without
> braces. For code with side-effect braces are ok because you need some
> kind of syntax which encloses the sequence of operations anyway. Many
> other functional languages have the 'let ... in ...' syntax to
> introduce bindings.
>
> On Fri, Jun 4, 2010 at 1:16 PM, Ruediger Keller wrote:
>> Sorry, but I somewhat fail to see the benefit of your proposal. All
>> your examples can be written more concisely with the currently
>> available syntax.
>>
>> Can you show a better example?
>>
>> Regards,
>> Ruediger
>>
>>
>> 2010/6/4 Johannes Rudolph :
>>> On Fri, Jun 4, 2010 at 12:29 PM, Johannes Rudolph
>>> wrote:
>>>> Here's the patch to make that idea work reusing the 'yield' keyword:
>>> Just wanted to note that the use of 'yield' is rather arbitrary and
>>> just to demonstrate the syntax without having to introduce another
>>> keyword.
>>>
>>> --
>>> Johannes
>>>
>>> -----------------------------------------------
>>> Johannes Rudolph
>>> http://virtual-void.net
>>>
>>
>
>
>
> --
> Johannes
>
> -----------------------------------------------
> Johannes Rudolph
> http://virtual-void.net
>

Johannes Rudolph 2
Joined: 2010-02-12,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Fri, Jun 4, 2010 at 2:40 PM, Ruediger Keller wrote:
> But wouldn't we need another syntax change to allow multiple vals to
> participte in such a construct?
>
> like this:
>
> val a = calcA(), b = calcB(), c = calcC() yield sqrt(a*a + b*b + c*c)

I would see that as a separate issue, because you can just nest those
"val .. whatever ..." expressions.

Arthur Peters 2
Joined: 2009-01-10,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

I have another reason I generally prefer brace delimited blocks. And honestly I'm suprised no one have mentioned this.

It is easier to change braces than indentation because with braces you can just change the brace characters and let the indenter fix all the white space. I find that this is much easier to get right than indenting or deindenting code blocks. For one thing its more explicit and I think that is good for a construct that is so fundimental to the syntax.

I have done quite a lot of programming in python and I like it, but honestly I would not miss white space delimted if it were removed. I think it is a blessing and a curse and I generally prefer curly braces.

-Arthur (sent from phone)

On Jun 4, 2010 8:30 AM, "Erik Engbrecht" <erik [dot] engbrecht [at] gmail [dot] com> wrote:

In Python parenthesis are always require for function/method arguments.  In Scala they are optional in many circumstances.  Python relies and parenthesis and other delimiters ([] for lists, {} for dictionaries) in handling multi-line statements.  My Python programs usually don't have a lot of multi-line statements (usually just an occasional big list comprehension), but my Scala code is full of multi-line statements and expressions.  Many Scala constructs rely on the fact that parenthesis are optional to be remain aesthetically pleasing.  Scala also has things like multiply argument lists and implicit parameters and default parameters that make this more complicated.
Also note that sometimes semicolon inference fails in Scala.  Not often, but it happens, and can create confusing results.  I have a feeling delimiting blocks using indentation would make this worse.
I think Python...hmmm...strongly guides programmers into a certain style.  Scala does not, and it is very apparent when looking at the Scala code from different people.
So while I think someone could probably make it work for trivial cases, I think it would end up creating a lot of confusion when it interacts with other Scala constructs.



On Fri, Jun 4, 2010 at 12:50 AM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
>
>
>
> On Thu, Jun ...

Grey
Joined: 2009-01-03,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces
Russ,
Sorry you got a bit dissed on the list.  Perfectly reasonable question AFAICT.
It is interesting that some on the "that's not worth even discussing on scala-discuss" side of the debate were also at one time rather pro with regards of removing brackets for match case and using implied indentation.   Maybe opinions have shifted... don't know.   But I do seem to recall many arguments on the merit for dropping brackets for match/case as centered around point of elegance, cleaner more readable code, less noise, etc.  Maybe, I suspect that the overall argument is that the dropping of brackets from a syntax is purely a situational one.  Braces here, here but not there.
You'll find similar on historical debates regarding the dropping parens and periods.  e.g.,  obj.doThis (x) -> obj doThis xAgain most of the pro group argued based on "DSL support", cleaner more readable syntax etc.  Most also feel similarly with regard to semicolons.
Not sure why suggesting a possible alternate layout approach is a non-debatable issue.
I view Haskell as the reference standard here as opposed to Python.   Haskell syntax is very much defined as chock full of braces and semis as Java  However, one very rarely actually sees "true" Haskell syntax.   Most Haskell programmers prefer to leverage the implied layout capabilities of the lexer/parser and drop braces and semis whenever and where ever possible.
Personally, I believe Haskell's syntax from its layout rules offers the finest syntax of any computer language I have or ever expect to see.  I mean tears in my eyes beautiful.  Someone should hirer a calligrapher to write out programming pearls of Haskell code on bright-white heavy bond paper with black india ink and sell them framed.    I'd but a couple for my office.
I suspect there will always be some who believe a Haskell program would be "improved" getting rid of all that layout whitespace indentation nonsense from Haskell and putting back the braces and semis, ie. only allowing "true" Haskell syntax.
Concerning the pragmatic aspect of actually removing braces from Scala.  I suspect it's pretty hard to actually find a way on  how to actually do it in a way that is consistent and "works".  i.e. Its HARD to find one.   IF one were to find a workable layout syntax then the Scala compiler is pretty modular and writing a parser ain't all that hard.  A determined group hell bent on demonstrating braceless Scala could no doubt do it.  IF the end result was a Haskell-syntax like for Scala that worked, adopters will occur.  I'd certainly try it in my source code files.
Camlp4 for Ocaml is a good example of allowing for syntax extension in Ocaml.  Ocaml didn't fragment into a polyglot mess.  Various scheme systems such as Racket (ex-PLT Scheme) support ML-like, infix, java-like etc syntaxs as well as alternate base scheme syntaxes such as module.  I think its pretty much required that the first "meta" statement in a Racket source file defines what "language" to use.  Guile supports alternate syntaxes to the point of completely independent languages.  For example the latest version of Guile supports Scheme, ECMAScript (javascript), BrainFuck, AND ELisp syntax.
Back to Scala.   Its not that hard to imagine using a 
@syntax layout 
annotation at the top of a scala source file telling the lexer to use layout convention -for that source file only-. 
So Russ, I doubt the EFPL people, who are frying far larger fish, will put syntax layout as a top priority.  On the other hand IF a person or a group did it, did it well, and the syntax did appear to be noticeably "improved" who knows how far and to what degree it will be adopted?

On Thu, Jun 3, 2010 at 7:53 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
I like Scala a lot. I am making a major investment of time and effort into it, and I hope it soon becomes wildly popular. I'd like to see it eventually become an accepted language for safety-critical systems in my field of air traffic management.

Scala has many advanced features, but one of my favorite features is implied semi-colons. I really appreciate not having to litter my code with a semi-colon after each statement. When I first became aware of that feature, I knew I was going to like Scala.

I would like to suggest a similar feature that would make Scala syntax even more elegant: implied braces, or block delimiting by indentation, without braces, as in Python.

What about backward compatibility? That problem can be solved by simply making braces optional. Where braces are used, they override the indentation structure (just as semi-colons override the line structure when used explicitly). All currently working code will still work exactly the same. But if you leave out the braces on a particular block, the indentation structure delimits the block, exactly as in Python. In any particular block, either method could be used, and both methods could be used arbitrarily in the same file.

Not only would implied braces make code cleaner, but I think it would be clearer too. To my way of thinking, the indentation structure is easier to follow visually than braces. I've been bitten more than once by a block where I mistakenly left off the braces, and it compiled just fine but didn't do what I was expecting. That sort of error is much less likely if the indentation structure defines the logical structure and is therefore guaranteed to be consistent with it.

Russ P.

--
http://RussP.us



--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: suggestion for Scala syntax: implied braces

On Fri, Jun 04, 2010 at 11:08:21AM -0400, Ray Racine wrote:
> It is interesting that some on the "that's not worth even discussing
> on scala-discuss" side of the debate were also at one time rather pro
> with regards of removing brackets for match case and using implied
> indentation. Maybe opinions have shifted... don't know.

I don't know what discussion that was, but it's specious to compare
braces on cases with significant whitespace. There is zero ambiguity
possible by removing the braces around those blocks. And there is no
"implied indentation", you can indent however you want. Maybe you mean
an implied block.

I'm a tad skeptical any of the participants in this discussion have the
least intention of implementing any such change in syntax (including the
spectacular burden of dealing with the secondary effects) and I'm almost
certain that the people who could do it have no interest in it, so in
case anyone imagined this discussion was anything more than a way to
waste some time when they could be doing useful things like helping
flush out the major remaining bugs in 2.8, I think it is otherwise.

Grey
Joined: 2009-01-03,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Fri, Jun 4, 2010 at 11:19 AM, Paul Phillips <paulp [at] improving [dot] org> wrote:
On Fri, Jun 04, 2010 at 11:08:21AM -0400, Ray Racine wrote:
> It is interesting that some on the "that's not worth even discussing
> on scala-discuss" side of the debate were also at one time rather pro
> with regards of removing brackets for match case and using implied
> indentation. Maybe opinions have shifted... don't know.

I don't know what discussion that was, but it's specious to compare
braces on cases with significant whitespace.  

My intent was to compare braces pro/con on cases vs. braces pro/con taken to the extremum of a syntax generalization for a (the) language as a whole.
There is zero ambiguity
possible by removing the braces around those blocks.  
And there is no
"implied indentation", you can indent however you want.  Maybe you mean
an implied block.

My intent was to clearly point out it would be HARD to do to find a workable solution.  Probably not possible without significant deviation from what one would consider Scala syntax.  However since I am unaware of any effort to "give it a try" I am unwilling to say that 'it's just silly'.   I did try and say a dedicated person or two who believed in the idea "might" be able to pull it off.  

I'm a tad skeptical any of the participants in this discussion have the
least intention of implementing any such change in syntax (including the
spectacular burden of dealing with the secondary effects)

Who knows, and your probably correct.   But it never hurts to hold out on the possibility. 
and I'm almost
certain that the people who could do it have no interest in it, so in

I did offer counter examples of where people who could do it, have done it in other language ecosystems.  
case anyone imagined this discussion was anything more than a way to 
waste some time when they could be doing useful things like helping

A topic of debate can be one man's waste of time, another's enjoyable yet idle debate, and maybe for a few the gestation of a committed goal.  
flush out the major remaining bugs in 2.8, I think it is otherwise.


As of yesterday I've run 10 billion price calculations from ~10 million external invocations over a gig-E network against a Scala application instance running RC3 on a 16 core HP server using a 12 gig heap at a sustained utilization of 65-70% cpu.  That is for a single node.  As the test is against a 3 node cluster that aggragate numbers are 3x.  At this very instant a full cross system, in-situ integration load test is running since early this morning and will run for ~ 12 hrs.
The scala code uses Actors performing remote msg sending for low volume intra-cluster communication.  
Scala RC3.  Code was compiled on with -optimize with specialization disabled.  Hope to do a comparison test soon with specialzation enable.
Maybe a small performance gain over RC2, certainly no major performance regression evident.  Haven't gotten into the detail numbers yet as the tests are still underway.
Currently RC2 has been in production for several weeks without restart at a much lower volume.   RC3 will be in production on Jun 12.
IF the core Scala team finds this sort of information useful I and maybe others are more than happy to provide it.  I've personally have not seen a request for it.  If there is something of particular aspect  the core team would like to see exercised, I have some mechanism, means and yes some time to "waste" that otherwise tends to be devoted to idle debates of modest interest.
Otherwise happy to report NO BUGS FOUND.   (Special thanks for your dedicated and much appreciated quashing efforts.)
--
Paul Phillips      | On two occasions, I have been asked, 'Mr. Babbage, if you
Imperfectionist    | put into the machine wrong figures, will the right answers
Empiricist         | come out?' I am not able to rightly apprehend the kind of
pull his pi pal!   | confusion of ideas that could provoke such a question.



--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: suggestion for Scala syntax: implied braces

On Fri, Jun 04, 2010 at 12:14:32PM -0400, Ray Racine wrote:
> As of yesterday I've run 10 billion price calculations from ~10
> million external invocations over a gig-E network against a Scala
> application instance running RC3 on a 16 core HP server using a 12 gig
> heap at a sustained utilization of 65-70% cpu.

In case it gave the wrong impression: I did not mean to imply that you
personally are deficient in the contribution department. Only that some
times are a lot better than others to initiate and pursue such idle
debate. It'd be nice to say it only applies a time drag on the
interested parties, but we all know the reality isn't like that.

Super glad to hear that positive report, thanks.

Seth Tisue
Joined: 2008-12-16,
User offline. Last seen 34 weeks 3 days ago.
Re: suggestion for Scala syntax: implied braces

>>>>> "Paul" == Paul Phillips writes:

Paul> On Fri, Jun 04, 2010 at 12:14:32PM -0400, Ray Racine wrote:
>> As of yesterday I've run 10 billion price calculations from ~10
>> million external invocations over a gig-E network against a Scala
>> application instance running RC3 on a 16 core HP server using a 12
>> gig heap at a sustained utilization of 65-70% cpu.

Paul> In case it gave the wrong impression: I did not mean to imply
Paul> that you personally are deficient in the contribution department.
Paul> Only that some times are a lot better than others to initiate and
Paul> pursue such idle debate. It'd be nice to say it only applies a
Paul> time drag on the interested parties, but we all know the reality
Paul> isn't like that.

Loose lips sink ships?

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: suggestion for Scala syntax: implied braces
Just my two cents on this. I am always intrigued by indentation layout but I also worry about the downside. In particular, refactoring seems to be easier and safer if you have explicit braces. It might be less of a problem in a statically typed language than in Python, or not.

If we want to do it, I'd suppose we need to have a simple to understand convention that tells you were the offside layout rule applies. And it needs to work uniformly for standard syntax and for DSLs. using Python's `:' is the most esteticaly pleasing, I believe. Something like




I don't


On Fri, Jun 4, 2010 at 6:39 PM, Seth Tisue <seth [at] tisue [dot] net> wrote:
>>>>> "Paul" == Paul Phillips <paulp [at] improving [dot] org> writes:

 Paul> On Fri, Jun 04, 2010 at 12:14:32PM -0400, Ray Racine wrote:
 >> As of yesterday I've run 10 billion price calculations from ~10
 >> million external invocations over a gig-E network against a Scala
 >> application instance running RC3 on a 16 core HP server using a 12
 >> gig heap at a sustained utilization of 65-70% cpu.

 Paul> In case it gave the wrong impression: I did not mean to imply
 Paul> that you personally are deficient in the contribution department.
 Paul> Only that some times are a lot better than others to initiate and
 Paul> pursue such idle debate.  It'd be nice to say it only applies a
 Paul> time drag on the interested parties, but we all know the reality
 Paul> isn't like that.

Loose lips sink ships?

--
Seth Tisue @ Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: suggestion for Scala syntax: implied braces
... I accidentally hit send to early. Here comes the whole message:

Just my two cents on this. I am always intrigued by indentation layout but I also worry about the downside. In particular, refactoring seems to be easier and safer if you have explicit braces. It might be less of a problem in a statically typed language than in Python, or not.

If we want to do it, I'd suppose we need to have a simple to understand convention that tells you where the offside layout rule applies. And it needs to work uniformly for standard syntax and for DSLs. Using Python's `:' is the most esthetically pleasing, I believe. Something like

  expr match:
     case P1 => A1
     ...
     case Pn => An

I.e. `:' followed by new line means { ... } inserted by offside rule. The only code this would break is
if you write a type annotation like this:

  val x:
     Int

It's not very likely people would trip up on this. As an added precaution we might want to turn indentation off if the leading package clause does not end in a colon. That means, with indentation you'd start your source file like this

    package org.project.module:

Without, you'd follow the package clause with a semicolon or a newline. Note that the  package clause followed by `:' is the analogue of a brace package clause

    package org.project.module { ... }

which already exists in Scala.

In addition, we would probably need to say that indentation always applies after an `=', because writing

    def foo(): Int =:  

just looks wrong.

So, yes, it's feasible. Do we want to do it? Certainly not before Scala 3.0. And, as I said, there are many caveats on indentation based syntax, it's not clear to me it's a net win, and we do not exactly have a lack of syntax options in Scala already. So, I believe we will certainly not pursue this right now, and might never do it. But it's probably worth an experiment if somebody wants to do that.

Cheers

 -- Martin


Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Fri, Jun 4, 2010 at 3:29 AM, Dennis Haupt <h-star [at] gmx [dot] de> wrote:
after thinking a bit, i don't see a reason to enhance the language this way. it would be possible, yes, maybe even not that hard, but you wouldn't save many braces compared to semicolons.
however, i see a reason NOT to enhance scala this way. imagine you have a rather complex method made of several blocks. now imaginge 4 or 5 of these methods inside a class. if you remove a brace now, you'll quickly find the missing one. however, mess with the tabs or spaces, and you'll totally mess everything up without necessarily producing a compilation error.

 That is contrary to my experience. I recently converted some of my Python code to Scala. The code needed some work, but I just tried to do as straight a conversion as  possible. In one particularly knarly file, I had a very hard time keeping track of the braces I had inserted into the converted Python code. After eyeballing the code for quite a while I was still missing a closing brace, but I couldn't figure out where. I looked and looked. I found that I could just add a brace at the end of the file to get it to compile, but I knew that wasn't where it belonged. In fact, that is what initially got me wishing that I didn't need to add the braces. After using a "divide and conquer" approach, I finally found where the brace was missing.

The bottom line is that, in that particular case, getting the braces to match produced something that compiled but was inconsistent with the intended logical structure as defined by the indentation. The indentation made the structure of the code clear, but the braces did not. Now, my code may have been crap, but at least the indentation made the structure clear.

Russ P.
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Fri, Jun 4, 2010 at 8:08 AM, Ray Racine <ray [dot] racine [at] gmail [dot] com> wrote:
Russ,
Sorry you got a bit dissed on the list.  Perfectly reasonable question AFAICT.

Thanks, Ray. I've been through worse, and I have the scars to prove it.
 
Personally, I believe Haskell's syntax from its layout rules offers the finest syntax of any computer language I have or ever expect to see.  I mean tears in my eyes beautiful.  Someone should hirer a calligrapher to write out programming pearls of Haskell code on bright-white heavy bond paper with black india ink and sell them framed.    I'd but a couple for my office.

LOL! I can see that you place great value on the aesthetic quality of software!
 
So Russ, I doubt the EFPL people, who are frying far larger fish, will put syntax layout as a top priority.  On the other hand IF a person or a group did it, did it well, and the syntax did appear to be noticeably "improved" who knows how far and to what degree it will be adopted?
 Yeah, I didn't expect it to be a top priority. Thanks for taking the time to share your insights.

Russ P.
Justin du coeur
Joined: 2009-03-04,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Fri, Jun 4, 2010 at 5:55 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
That is contrary to my experience. I recently converted some of my Python code to Scala. The code needed some work, but I just tried to do as straight a conversion as  possible. In one particularly knarly file, I had a very hard time keeping track of the braces I had inserted into the converted Python code. After eyeballing the code for quite a while I was still missing a closing brace, but I couldn't figure out where. I looked and looked. I found that I could just add a brace at the end of the file to get it to compile, but I knew that wasn't where it belonged. In fact, that is what initially got me wishing that I didn't need to add the braces. After using a "divide and conquer" approach, I finally found where the brace was missing.

But that's a sign of IDE weakness, not language weakness.  I haven't checked the current state of the Eclipse plugin lately, so it may still be catching up on features, but modern IDEs usually put in a lot of strong support *based* on braces -- highlight-matching of the braces, pretty-print indenting based on them, and so on.
Seriously, this is the sort of problem that usually doesn't take 20 seconds to track down in a brace-based language with a really up-to-date IDE...
dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: suggestion for Scala syntax: implied braces
Just something I think it's worth pointing out, regarding this statement:
I.e. `:' followed by new line means { ... } inserted by offside rule. The only code this would break is
if you write a type annotation like this:

  val x:
     Int

There's one case where I have written code like this. Usually, in this situation:
def func  [long list of type parameters -- think new collections]  (list of arguments)  (list of implicit arguments):  return type =...
On Fri, Jun 4, 2010 at 2:32 PM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
... I accidentally hit send to early. Here comes the whole message:

Just my two cents on this. I am always intrigued by indentation layout but I also worry about the downside. In particular, refactoring seems to be easier and safer if you have explicit braces. It might be less of a problem in a statically typed language than in Python, or not.

If we want to do it, I'd suppose we need to have a simple to understand convention that tells you where the offside layout rule applies. And it needs to work uniformly for standard syntax and for DSLs. Using Python's `:' is the most esthetically pleasing, I believe. Something like

  expr match:
     case P1 => A1
     ...
     case Pn => An

I.e. `:' followed by new line means { ... } inserted by offside rule. The only code this would break is
if you write a type annotation like this:

  val x:
     Int

It's not very likely people would trip up on this. As an added precaution we might want to turn indentation off if the leading package clause does not end in a colon. That means, with indentation you'd start your source file like this

    package org.project.module:

Without, you'd follow the package clause with a semicolon or a newline. Note that the  package clause followed by `:' is the analogue of a brace package clause

    package org.project.module { ... }

which already exists in Scala.

In addition, we would probably need to say that indentation always applies after an `=', because writing

    def foo(): Int =:  

just looks wrong.

So, yes, it's feasible. Do we want to do it? Certainly not before Scala 3.0. And, as I said, there are many caveats on indentation based syntax, it's not clear to me it's a net win, and we do not exactly have a lack of syntax options in Scala already. So, I believe we will certainly not pursue this right now, and might never do it. But it's probably worth an experiment if somebody wants to do that.

Cheers

 -- Martin





--
Daniel C. Sobral

I travel to the future all the time.
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Fri, Jun 4, 2010 at 10:32 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
... I accidentally hit send to early. Here comes the whole message:

Just my two cents on this. I am always intrigued by indentation layout but I also worry about the downside. In particular, refactoring seems to be easier and safer if you have explicit braces. It might be less of a problem in a statically typed language than in Python, or not.


Thanks for the reply. I am thrilled to see that you are willing to consider implied braces for the long-term future of Scala.
 
If we want to do it, I'd suppose we need to have a simple to understand convention that tells you where the offside layout rule applies. And it needs to work uniformly for standard syntax and for DSLs. Using Python's `:' is the most esthetically pleasing, I believe. Something like

  expr match:
     case P1 => A1
     ...
     case Pn => An


I'll show my ignorance here and ask what the purpose is of the colon. Does it have something to do with DSLs? (I know nothing about DSLs.) For standard syntax, why can't the compiler just detect the indented line following "match" and insert an opening brace, then insert a closing brace when it detects the next dedent? Ditto for

if (foo)
    line1
    line2

def bar() =
    line1
    line2

Yes, I realize that you need to properly handle multi-line defs and other variations of def, and I don't want to get into the details here, but it seems doable, perhaps with a few relatively simple new rules that are unlikely to cramp anyone's style.

Russ P.

--
http://RussP.us
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: suggestion for Scala syntax: implied braces


On Sat, Jun 5, 2010 at 3:10 AM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
On Fri, Jun 4, 2010 at 10:32 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
... I accidentally hit send to early. Here comes the whole message:

Just my two cents on this. I am always intrigued by indentation layout but I also worry about the downside. In particular, refactoring seems to be easier and safer if you have explicit braces. It might be less of a problem in a statically typed language than in Python, or not.


Thanks for the reply. I am thrilled to see that you are willing to consider implied braces for the long-term future of Scala.
 
If we want to do it, I'd suppose we need to have a simple to understand convention that tells you where the offside layout rule applies. And it needs to work uniformly for standard syntax and for DSLs. Using Python's `:' is the most esthetically pleasing, I believe. Something like

  expr match:
     case P1 => A1
     ...
     case Pn => An


I'll show my ignorance here and ask what the purpose is of the colon.

Because simply inferring braces by indentation would be too risky and would also break too many programs. So we need a marker that tells us unambiguously. I think colon is not bad for that.

Yes, I realize that you need to properly handle multi-line defs and other variations of def, and I don't want to get into the details here, but it seems doable, perhaps with a few relatively simple new rules that are unlikely to cramp anyone's style.

I am skeptical this will hold true, but am ready to be proven wrong if someone will try it.

Cheers

 -- Martin

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Sat, Jun 5, 2010 at 12:16 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
 
If we want to do it, I'd suppose we need to have a simple to understand convention that tells you where the offside layout rule applies. And it needs to work uniformly for standard syntax and for DSLs. Using Python's `:' is the most esthetically pleasing, I believe. Something like

  expr match:
     case P1 => A1
     ...
     case Pn => An


I'll show my ignorance here and ask what the purpose is of the colon.

Because simply inferring braces by indentation would be too risky and would also break too many programs. So we need a marker that tells us unambiguously. I think colon is not bad for that.


Yes, I see. As a Python programmer, the colon looks fine to me, although I agree with you that it doesn't quite seem right in

def foo() =:
    line 1
    line 2

You could always use some other symbol, such as

def foo() = |
    line 1
    line 2

But then you get into a consistency issue. You should probably use the same symbol in all cases. How about this:

def foo() = {{
    line 1
    line 2

or, if you are running out space on the line,

def foo() =
    {{
    line 1
    line 2

You don't save any typing or characters, but you save that darn dangling "}" (and the separate line it usually appears on) at the end of each block. After thinking about it a bit, I think I like this alternative.

Another variation would be to use {\ or some other combination instead of {{.

The other alternative is to just not worry about breaking a few programs. The only thing I can think of that would break are misleadingly formatted blocks, such as

if (bar)
    line 1
    line 2

This sort of thing is probably a bug anyway, where the programmer forgot the braces. Heck, you'd probably correct more bugs than you'd add if you just used implied braces for these cases!

Regards,
Russ P.
--
http://RussP.us
ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Sun, Jun 6, 2010 at 1:30 AM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

def foo() = {{
    line 1
    line 2


For someone who is used to visually balancing parens, this is probably the most jarring and misleading thing you could possibly do to them, save for simply making closing braces optional.

( [ { < all invite closing on the other side, so they should not be used unless you are using them to draw a picture.  Really--what's wrong with the Python : syntax (if we want to go braceless at all--I am still skeptical that this is a good idea, but am open to persuasion).

  --Rex

Michael Campbell
Joined: 2009-03-17,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

Rex Kerr wrote:
> For someone who is used to visually balancing parens, this is probably
> the most jarring and misleading thing you could possibly do to them,
> save for simply making closing braces optional.

I'm probably late out of the gate here, but what problem is "implied
braces" in a braces-oriented language intending to solve? More
specifically, what is the VALUE of problem solved versus the work
involved in making it happen?

It seems to me that (a) language should have this as a central
tenet/theme like python, or it shouldn't. Trying to mix, or switch from
one to the other strikes me as... less worthwhile than most things.
Reasonable people can disagree of course, but I haven't heard much about
the "why" compared to the "how" yet.

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Sun, Jun 6, 2010 at 9:01 AM, Michael Campbell <michael [dot] campbell [at] unixgeek [dot] com> wrote:

I'm probably late out of the gate here, but what problem is "implied braces" in a braces-oriented language intending to solve?  More specifically, what is the VALUE of problem solved versus the work involved in making it happen?
It seems to me that (a) language should have this as a central tenet/theme like python, or it shouldn't.  Trying to mix, or switch from one to the other strikes me as... less worthwhile than most things.   Reasonable people can disagree of course, but I haven't heard much about the "why" compared to the "how" yet.


One problem is that the current syntax allows the indentation structure to be misleadingly inconsistent with the logical structure. The compiler is very good at understanding the logical structure based on the braces, but the human eye tends to pay more attention to the indentation and can easily miss braces in complex code.

Aside from that, this is an opportunity to improve the aesthetics of the language. The same was true for implied semi-colons and the alternative syntaxes for invoking methods. The aesthetic improvement may seem small, but it applies to every block written, so it adds up to a lot.

If implied braces turn out to be horribly complicated to implement, or if they cause serious potential problems, then I agree they should be abandoned, but I have a hard time imagining that will be the case.

As for allowing for both braceless and "braced" code to co-exist, I don't see that as a negative. You need to continue supporting braces for backward compatibility, of course. But beyond that, there is something to be said for giving people a choice of styles.

Russ P.

--
http://RussP.us
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Sun, Jun 6, 2010 at 6:10 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Sun, Jun 6, 2010 at 1:30 AM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

def foo() = {{
    line 1
    line 2


For someone who is used to visually balancing parens, this is probably the most jarring and misleading thing you could possibly do to them, save for simply making closing braces optional.

( [ { < all invite closing on the other side, so they should not be used unless you are using them to draw a picture.  Really--what's wrong with the Python : syntax (if we want to go braceless at all--I am still skeptical that this is a good idea, but am open to persuasion).


Well, I am certainly not insisting that this is the way to go, but I think it worth considering. Think of "{{" as a new token, completely separate from  "{", just as "//" is separate from "/". To my way of thinking, the fact that it resembles an opening brace is what gives it it's aesthetic appeal. However, any unique token will work, including the colon.

Russ P.
 --
http://RussP.us

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