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
Justin du coeur
Joined: 2009-03-04,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Sun, Jun 6, 2010 at 3:02 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
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.

Do you understand that this is subjective?  Yes, I see that you consider the braces inaesthetic, and that's fine -- but you should also understand that there are plenty of us who disagree with you.
Putting a sharper point on it: from my POV, this is a waste of time.  I don't consider the indentation-oriented syntax to be clearer *or* more aesthetic; indeed, I find it actively worse from both perspectives, because of the side-effects it winds up imposing.  (For example, the {{ thing you proposed as a workaround earlier is *far* worse from my POV.)  Yes, there's room for disagreement -- but you don't seem to be leaving that room.  You're asserting that your way is more aesthetic without clear evidence that the users of Scala agree with you.
I mean, sure, I'm biased: I've spent many, many years in C-derivative languages, so braces are second nature to me.  But you are *also* quite clearly biased in the degree to which you are ardently advocating the Python view of the world.  Don't presume that your way is necessarily better...
Sean Corfield
Joined: 2009-10-25,
User offline. Last seen 2 years 9 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Sun, Jun 6, 2010 at 12:02 PM, Russ Paielli wrote:
> Aside from that, this is an opportunity to improve the aesthetics of the
> language.

I think that's very subjective. I've worked with a number of languages
over the years where whitespace is significant in one form or another
and I, personally, have always found it to be a royal PITA and a great
impediment to understanding code.

> 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.

I don't disagree with the aesthetics of optional semicolons
(JavaScript, ActionScript, Scala, Groovy - and Railo's implementation
of CFML - all allow semicolons to be omitted in nearly all cases). I
have some mixed feelings about parentheses in method calls - I like
the English-like way it can make the code read but I find there are
times when I think I can omit parentheses and Scala doesn't which
breaks the flow a bit.

I do not view braces as 'noise' like semicolons tho'. I find braces
and parentheses aid the eye in terms of grouping. I like indentation
to reinforce that - and to make multi-line statements look more
pleasing - but I don't like indentation alone to define the grouping.
When I'm refactoring, moving blocks of code around, I like to be able
to rely on the IDE to re-indent my code based on braces. I can't do
that when indentation itself represents blocks so it would get in my
way.

I'm not *strongly* against blocks based on indentation but I'm
certainly not in favor of it. I'm pretty sure, based on past
experience, that not only would I not use it but I would likely ban
any of my team from using it :)

Björn Herzig
Joined: 2010-05-18,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Jun 6, 2010, at 9:41 PM, Justin du coeur wrote:
>
> Putting a sharper point on it: from my POV, this is a waste of time. I don't consider the indentation-oriented syntax to be clearer *or* more aesthetic; indeed, I find it actively worse from both perspectives, because of the side-effects it winds up imposing. (For example, the {{ thing you proposed as a workaround earlier is *far* worse from my POV.) Yes, there's room for disagreement -- but you don't seem to be leaving that room. You're asserting that your way is more aesthetic without clear evidence that the users of Scala agree with you.

I totally agree with you on that point. I've been following this discussion for quite some time and I never really got the "why we need that", basically the only argument was "I like python syntax because I think it's cleaner" which is extremely subjective. Actually it is possible to avoid plenty of braces just by using a more functional coding style. I absolutely don't get the point why there should be put so much effort into
an enhancement that enables two fundamentally different coding styles (with possible unwanted side effects in existing code). From my POV this will lead to utter confusion among newcomers since some people will use braces others won't. To me as a newcomer that would feel pretty much like a kitchen sink language trying to satisfy every mindset out there.

On the other side I might be wrong and I'd happily admit that if someone writes an enhancement that proves that it can be done without breaking loads of code just because someone wants to impose his subjective views on clean code on everyone else.

I for myself tend to run into "possibly wrong indentation" error messages when playing around with haskell from time to time, and i find these situations very annoying.

Regards
raichoo

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

Björn Herzig wrote:
> I've been following this discussion for quite some time and I never really got the "why we need that",

This is precisely the question I, probably overly verbose, am also
wondering.

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

Russ Paielli wrote:
> On Sun, Jun 6, 2010 at 9:01 AM, Michael Campbell
> >
> 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.

Only if you let it. I can't say my experience is typical, but I haven't
manually adjusted indentation on code in probably 20 years, and I know
that that was available before then.

> 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.

I agree with you fully here, which is why I let my IDE; be that emacs,
eclipse, IntelliJ, etc.; format the code in the way that I've told it.
If it looks obviously wrong, or the IDE tells me it's wrong (too
many/few braces), I've done something wrong.

> Aside from that, this is an opportunity to improve the aesthetics of
> the language.
This is not an argument that be made with dispassion and I don't think
can be compromised for a mutually agreeable solution, as a rule. Emacs
> vi. 1TBS > "braces on their own lines". LISP > *. And so on.

> 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.
I'm not sure I agree here either. Choice is not necessarily good for
its own sake. Minimizing the mapping between what you say "print",
"print()", "print();" and what you mean is a bigger win in the long
run. This is a fence-rider for me though; I still like perl, and I like
some of what you can do in DSL terms with Scala, and not having these
choices would eliminate some of that.

>
> 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.

Instinctively I understand what you're saying, but from a pragmatic
point of view all you end up with this is having a variety of "code
styles" where most every coder has their preferred subset of what they
know or are familiar with. While I agree in the abstract "choice" is
nice, in programming languages it often leads to undesired outcomes.
PL/1, anyone?

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 2:00 PM, Michael Campbell <michael [dot] campbell [at] unixgeek [dot] com> wrote:

One problem is that the current syntax allows the indentation structure to be misleadingly inconsistent with the logical structure.


Only if you let it.  I can't say my experience is typical, but I haven't manually adjusted indentation on code in probably 20 years, and I know that that was available before then.
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.

I agree with you fully here, which is why I let my IDE; be that emacs, eclipse, IntelliJ, etc.; format the code in the way that I've told it.  If it looks obviously wrong, or the IDE tells me it's wrong (too many/few braces), I've done something wrong.

OK, I'll confess that I am weak on IDEs. I'd like to start using one someday, but I've been getting by with XEmacs up to now -- and it's not even configured for Scala (not sure it even can be yet). (For the record, I'm an aerospace engineer, and I often go days at a time without doing any programming or software-related work.)

My view is that neither an IDE nor any third-party software should have to make up for a deficiency of the language. If the language itself can guarantee that the logical structure and the indentation structure are consistent, I consider that far preferable to relying on third-party software for such a guarantee.

Just because you are familiar with a particular IDE, that does not mean that everyone is. Think about Scala beginners, students, or potential hobbyists. Many of them have a hard enough time just figuring out how to get Scala runnng, and the last thing they want is to have to select and set up some IDE or third-party program before they can get the full benefit of Scala.

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 12:41 PM, Justin du coeur <jducoeur [at] gmail [dot] com> wrote:
On Sun, Jun 6, 2010 at 3:02 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
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.

Do you understand that this is subjective?  Yes, I see that you consider the braces inaesthetic, and that's fine -- but you should also understand that there are plenty of us who disagree with you.
Putting a sharper point on it: from my POV, this is a waste of time.  I don't consider the indentation-oriented syntax to be clearer *or* more aesthetic; indeed, I find it actively worse from both perspectives, because of the side-effects it winds up imposing.  (For example, the {{ thing you proposed as a workaround earlier is *far* worse from my POV.)  Yes, there's room for disagreement -- but you don't seem to be leaving that room.  You're asserting that your way is more aesthetic without clear evidence that the users of Scala agree with you.
I mean, sure, I'm biased: I've spent many, many years in C-derivative languages, so braces are second nature to me.  But you are *also* quite clearly biased in the degree to which you are ardently advocating the Python view of the world.  Don't presume that your way is necessarily better...


I'm sure someone will correct me if I am wrong, but here's how I see it.

Semicolons and braces were introduced into programming languages way back in the early days of computing, when performance and storage capacity were a tiny fraction of what they are today. They simplified the job of the compiler writer and improved the performance of the compiler slightly. Back then, it made sense to put markers in the code and a small extra load on the human programmer to simplify the compiler and improve its speed, but in a modern language, that makes no sense anymore except for backward compatibility.

Braces and semicolons are not essential to specifying an algorithm. No one puts them in pseudocode. People like you are so used to them that you consider them perfectly acceptable, but I see them as unnecessary clutter on the algorithms that I wish to implement and develop. I say Scala should keep them for backward compatibility and as an option for those who want them, but please don't force everyone who wants to use Scala to clutter their elegant algorithms with them. Scala could be a great language. Let's not burden it with legacy cruft.

Russ P.

--
http://RussP.us
Sean Corfield
Joined: 2009-10-25,
User offline. Last seen 2 years 9 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Sun, Jun 6, 2010 at 5:15 PM, Russ Paielli wrote:
> My view is that neither an IDE nor any third-party software should have to
> make up for a deficiency of the language.

I think this sums up your position only too well :)

Most people these days believe an IDE saves them work and that's a
reasonable belief, in my opinion. We've moved on from setting switches
on an analog computer and we've moved on from plain ol' text editors.
Tools are meant to save us from the grudge work.

I have some sympathy with your position but I think it's really
extreme. As someone else in this thread said, you're not really
allowing for another point of view and you're continuing to argue that
we're all wrong and you're right...

The reality is that you're probably the only person on this list who
feels mandatory braces are a deficiency of the language.

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

On 06/06/2010 07:00 PM, Russ Paielli wrote:
> Braces and semicolons are not essential to specifying an algorithm. No
> one puts them in pseudocode.

Actually, I do.

> People like you are so used to them that
> you consider them perfectly acceptable, but I see them as unnecessary
> clutter on the algorithms that I wish to implement and develop. I say
> Scala should keep them for backward compatibility and as an option for
> those who want them, but please don't force everyone who wants to use
> Scala to clutter their elegant algorithms with them. Scala could be a
> great language. Let's not burden it with legacy cruft.

I think that implying that the use of braces is preventing Scala from
being a "great language" is a bit hyperbolic, no? Also, I may be reading
more into that paragraph than you intended, but the tone is somewhat
condescending.

Despite your assertion that braces are a purely synthetic construct
designed to lessen the burden on compiler writers, open/close symbols
have a very natural basis in written language (parenthetical statements,
for example). Braced scoping fits the way I describe and reason about
algorithms. Having done several years of light Python programming (by no
means am I an expert), I found that forced indentation didn't
significantly improve my code style because I already use indentation in
addition to braces, but I definitely found some places where it made
things feel a bit awkward.

In particular, when adjacent scopes differed by more than one or two
indents I found myself having to line up the spacing to make sure I knew
were I was. Contrast this to something like braces where I can see
exactly how many scopes I'm exiting simply by counting the closing
symbols. For me, at least, it's easier to count printable characters
than whitespace. This isn't an issue for everyone, but I found that it
definitely interrupted my flow when coding, debugging, etc.

If we're going to add complexity to scalac, I would strongly prefer that
it's for something that adds substantive capabilities, not something
that is essentially an aesthetic choice. This seems to be something more
worthy of a preprocessing script.

Derek

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 9:00 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Braces and semicolons are not essential to specifying an algorithm. No one puts them in pseudocode.

Grouping is essential to specifying an algorithm.  In mathematics, I usually use parentheses (occasionally brackets).  In pseudocode, I will use braces if it becomes too challenging to figure out what is going on with indentation, or if vertical space would be used poorly if I did not group items on one line.  If doing brainstorming, people often draw energetic circles around things they want to group. 

It's largely a matter of what's easiest given the tools available.  When you are working with pencil and paper, inventing all manner of interesting symbols is helpful--they are very clear, easy to draw, and convey great meaning.  With pre-defined character sets, however, this is a nightmare.  So, with a few notable exceptions (e.g. APL, Scalaz) we generally use a character set trivially accessible from the keyboard.

The thing is--braces are easy.  Whitespace is also easy.  Braces are more flexible--you need new lines to get whitespace, and there is ambiguity in the scope of expressions especially when you allow optional semicolons as well.  Whitespace looks cleaner.  I don't think either is particularly superior to the other in all regards.

I do, however, think that braces are an essential part of Scala's expressiveness (or some grouping symbol--one could use parens instead, but I like having the diversity to alert me to what I should expect).  Since we must have braces to enable stuff like
  a.map(b => { val c = f(b); (c,c.toString) })
in a compact and readable manner, then whitespace delimiters are necessarily something extra.

One of the biggest reasons why Python code looks clean and lovely is that you have essentially no choice but to have it look that way.  If Python were a mix of three or four different "clean" styles, the resulting amalgam would not be clean; it would be ugly.

So I think making Scala an amalgam of different styles is a net _drawback_ to the language unless it enables something very helpful.

Since editors can add whitespace for you based on braces, and since braces are more flexible and kind of have to be in there anyway, and you cannot do anything with syntactically important indentation that is not equally or more effectively done with braces, I have trouble classifying it as anything but a drawback.
   --Rex
Justin du coeur
Joined: 2009-03-04,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Sun, Jun 6, 2010 at 8:15 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
My view is that neither an IDE nor any third-party software should have to make up for a deficiency of the language. If the language itself can guarantee that the logical structure and the indentation structure are consistent, I consider that far preferable to relying on third-party software for such a guarantee. 

Perhaps -- but I consider the logical structure far more important. and I prefer to have language tools that help keep that logical structure consistent.  In a way, this is akin to the static/dynamic language argument.  You don't *need* static types in order to have a powerful programming language -- but I (and I suspect many who are attracted to Scala) like it because that rich type system means that the compiler helps enforce things, and has the power to notice when errors creep in.  Braces serve as a similar belt-and-suspenders error protection.
I particularly have to agree with the point that others have made: when refactoring, I've found braces invaluable over the years.  I refactor *constantly* -- many times a day -- and I can't see succeeding in *that* in an indentation-based language without major IDE support.  That is, in a brace-based language, I have enough buttressing against refactoring errors that I can do it by hand with at least *some* confidence that the compiler will usually tell me if I screw up; in an indentation-oriented one, I consider it likely that I would need to use more IDE-based tools to do so, because most refactoring errors would be syntactically legal.
So this particular argument cuts both ways -- indentation shoves around where an IDE is useful, but doesn't change the fact that modern tools are an important part of the engineer's toolbox, regardless of the language design.
> Braces and semicolons are not essential to specifying an algorithm. No one puts them in pseudocode.
Sorry, but you're overgeneralizing again.  I *always* put them in pseudocode.  When I'm drawing up an algorithm on the blackboard (my most common use of pseudocode), I consider the braces essential to clearly express my (typically pretty nested) code structure.
You're consistently treating braces as cruft intended to help the compiler, and I think you're missing the point that many of us consider them immensely useful for *coder* comprehension.  I mean, I don't even *see* indentation very clearly -- my eye tends to skip right over it unless it's pretty deep -- so I find the idea of banishing or deprecating hard delimiters somewhat distasteful, because I think it will actually hurt my own understanding of the code.
So again: you keep using words like "clutter" and "deficiency" -- highly pejorative and subjective terminology -- as if they were case-closed.  They're not: to some of us, delimiters are an important part of understanding the underlying algorithmic structures.  We're not arguing against you because we're defending obsolete compiler technology -- we're doing so because we actually *prefer* it.  That's not just habit, and it's not irrational, so please stop treating it as if it is...
Kris Nuttycombe
Joined: 2009-01-16,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Sun, Jun 6, 2010 at 10:20 PM, Rex Kerr wrote:
> On Sun, Jun 6, 2010 at 9:00 PM, Russ Paielli wrote:
>>
>> Braces and semicolons are not essential to specifying an algorithm. No one
>> puts them in pseudocode.
>
> Grouping is essential to specifying an algorithm.  In mathematics, I usually
> use parentheses (occasionally brackets).  In pseudocode, I will use braces
> if it becomes too challenging to figure out what is going on with
> indentation, or if vertical space would be used poorly if I did not group
> items on one line.  If doing brainstorming, people often draw energetic
> circles around things they want to group.
>
> It's largely a matter of what's easiest given the tools available.  When you
> are working with pencil and paper, inventing all manner of interesting
> symbols is helpful--they are very clear, easy to draw, and convey great
> meaning.  With pre-defined character sets, however, this is a nightmare.
> So, with a few notable exceptions (e.g. APL, Scalaz) we generally use a
> character set trivially accessible from the keyboard.
>
> The thing is--braces are easy.  Whitespace is also easy.  Braces are more
> flexible--you need new lines to get whitespace, and there is ambiguity in
> the scope of expressions especially when you allow optional semicolons as
> well.  Whitespace looks cleaner.  I don't think either is particularly
> superior to the other in all regards.
>
> I do, however, think that braces are an essential part of Scala's
> expressiveness (or some grouping symbol--one could use parens instead, but I
> like having the diversity to alert me to what I should expect).  Since we
> must have braces to enable stuff like
>   a.map(b => { val c = f(b); (c,c.toString) })

This is offtopic, but I like to use the Thrush combinator for this
sort of thing instead:

implicit def toThrush[A](a: A): Thrush[A] = new Thrush(a)
@serializable class Thrush[A](a: A) {
def ->*[B](f: A => B): B = f(a)
}

a.map(b => f(b) ->* (c => (c, c.toString)))

of course, the more functional way to do this is

def ts[T](t: T): (T, String) = (t, t.toString)

a.map((ts _) compose f)

I'm sure scalaz has a yet more elegant solution. :)

Kris

> in a compact and readable manner, then whitespace delimiters are necessarily
> something extra.
>
> One of the biggest reasons why Python code looks clean and lovely is that
> you have essentially no choice but to have it look that way.  If Python were
> a mix of three or four different "clean" styles, the resulting amalgam would
> not be clean; it would be ugly.
>
> So I think making Scala an amalgam of different styles is a net _drawback_
> to the language unless it enables something very helpful.
>
> Since editors can add whitespace for you based on braces, and since braces
> are more flexible and kind of have to be in there anyway, and you cannot do
> anything with syntactically important indentation that is not equally or
> more effectively done with braces, I have trouble classifying it as anything
> but a drawback.
>
>   --Rex
>

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

If braces help you to understand or clarify your algorithm, you would still be able to use them if I had my way. I am certainly not suggesting that braces should be eliminated from Scala.

Similarly, redundant (logically irrelevant) parentheses can sometimes help to clarify a mathematical expression. In that case, go ahead and use them. I think you will agree, however, that they should not be required. And I think you will also agree that mixing expressions with and without extra parentheses is not a problem. I think the same principle should apply to braces.

I think you need to be careful about what you claim about braces. They may be able to clarify your code if you use them correctly, but they can also make your code misleading if they are inconsistent with its logical structure due to an error on your part. If Scala enforced consistency between braces and indentation, that would be a step in the right direction as far as I am concerned. But it doesn't currently do that. (And please don't tell me that an IDE can do that. I don't care. We're talking about Scala, not IDEs.)

In any case, I am leaning toward using the colon as Martin suggested, or maybe "|" (if it does not conflict with anything). For example:

if (foo) |
    line 1
    line 2

def bar() = |
    line 1
    line 2

Yes, I realize it may appear strange at first glance, but once you get used to it, it will seem perfectly natural and elegant.

Russ P.


On Sun, Jun 6, 2010 at 9:20 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Sun, Jun 6, 2010 at 9:00 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Braces and semicolons are not essential to specifying an algorithm. No one puts them in pseudocode.

Grouping is essential to specifying an algorithm.  In mathematics, I usually use parentheses (occasionally brackets).  In pseudocode, I will use braces if it becomes too challenging to figure out what is going on with indentation, or if vertical space would be used poorly if I did not group items on one line.  If doing brainstorming, people often draw energetic circles around things they want to group. 

It's largely a matter of what's easiest given the tools available.  When you are working with pencil and paper, inventing all manner of interesting symbols is helpful--they are very clear, easy to draw, and convey great meaning.  With pre-defined character sets, however, this is a nightmare.  So, with a few notable exceptions (e.g. APL, Scalaz) we generally use a character set trivially accessible from the keyboard.

The thing is--braces are easy.  Whitespace is also easy.  Braces are more flexible--you need new lines to get whitespace, and there is ambiguity in the scope of expressions especially when you allow optional semicolons as well.  Whitespace looks cleaner.  I don't think either is particularly superior to the other in all regards.

I do, however, think that braces are an essential part of Scala's expressiveness (or some grouping symbol--one could use parens instead, but I like having the diversity to alert me to what I should expect).  Since we must have braces to enable stuff like
  a.map(b => { val c = f(b); (c,c.toString) })
in a compact and readable manner, then whitespace delimiters are necessarily something extra.

One of the biggest reasons why Python code looks clean and lovely is that you have essentially no choice but to have it look that way.  If Python were a mix of three or four different "clean" styles, the resulting amalgam would not be clean; it would be ugly.

So I think making Scala an amalgam of different styles is a net _drawback_ to the language unless it enables something very helpful.

Since editors can add whitespace for you based on braces, and since braces are more flexible and kind of have to be in there anyway, and you cannot do anything with syntactically important indentation that is not equally or more effectively done with braces, I have trouble classifying it as anything but a drawback.
   --Rex



--
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
I'd rather just use braces than to put a | in front of each line.

On Mon, Jun 7, 2010 at 1:47 PM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:
Not that I'm actually condoning this change, but if we're to find an alternative to braces then... Hey, why not go with a convention that we already have in the REPL, and stripMargin on Strings?

if (foo) |  line 1|  line 2
def bar() =|  line 1|  line 2

Make your code look like the syntax tree that we all know it really is :)


On 7 June 2010 21:40, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
Rex,

If braces help you to understand or clarify your algorithm, you would still be able to use them if I had my way. I am certainly not suggesting that braces should be eliminated from Scala.

Similarly, redundant (logically irrelevant) parentheses can sometimes help to clarify a mathematical expression. In that case, go ahead and use them. I think you will agree, however, that they should not be required. And I think you will also agree that mixing expressions with and without extra parentheses is not a problem. I think the same principle should apply to braces.

I think you need to be careful about what you claim about braces. They may be able to clarify your code if you use them correctly, but they can also make your code misleading if they are inconsistent with its logical structure due to an error on your part. If Scala enforced consistency between braces and indentation, that would be a step in the right direction as far as I am concerned. But it doesn't currently do that. (And please don't tell me that an IDE can do that. I don't care. We're talking about Scala, not IDEs.)

In any case, I am leaning toward using the colon as Martin suggested, or maybe "|" (if it does not conflict with anything). For example:

if (foo) |
    line 1
    line 2

def bar() = |
    line 1
    line 2

Yes, I realize it may appear strange at first glance, but once you get used to it, it will seem perfectly natural and elegant.

Russ P.


On Sun, Jun 6, 2010 at 9:20 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Sun, Jun 6, 2010 at 9:00 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Braces and semicolons are not essential to specifying an algorithm. No one puts them in pseudocode.

Grouping is essential to specifying an algorithm.  In mathematics, I usually use parentheses (occasionally brackets).  In pseudocode, I will use braces if it becomes too challenging to figure out what is going on with indentation, or if vertical space would be used poorly if I did not group items on one line.  If doing brainstorming, people often draw energetic circles around things they want to group. 

It's largely a matter of what's easiest given the tools available.  When you are working with pencil and paper, inventing all manner of interesting symbols is helpful--they are very clear, easy to draw, and convey great meaning.  With pre-defined character sets, however, this is a nightmare.  So, with a few notable exceptions (e.g. APL, Scalaz) we generally use a character set trivially accessible from the keyboard.

The thing is--braces are easy.  Whitespace is also easy.  Braces are more flexible--you need new lines to get whitespace, and there is ambiguity in the scope of expressions especially when you allow optional semicolons as well.  Whitespace looks cleaner.  I don't think either is particularly superior to the other in all regards.

I do, however, think that braces are an essential part of Scala's expressiveness (or some grouping symbol--one could use parens instead, but I like having the diversity to alert me to what I should expect).  Since we must have braces to enable stuff like
  a.map(b => { val c = f(b); (c,c.toString) })
in a compact and readable manner, then whitespace delimiters are necessarily something extra.

One of the biggest reasons why Python code looks clean and lovely is that you have essentially no choice but to have it look that way.  If Python were a mix of three or four different "clean" styles, the resulting amalgam would not be clean; it would be ugly.

So I think making Scala an amalgam of different styles is a net _drawback_ to the language unless it enables something very helpful.

Since editors can add whitespace for you based on braces, and since braces are more flexible and kind of have to be in there anyway, and you cannot do anything with syntactically important indentation that is not equally or more effectively done with braces, I have trouble classifying it as anything but a drawback.
   --Rex



--
http://RussP.us



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda




--
http://RussP.us
Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: suggestion for Scala syntax: implied braces
Not that I'm actually condoning this change, but if we're to find an alternative to braces then... Hey, why not go with a convention that we already have in the REPL, and stripMargin on Strings?

if (foo) |  line 1|  line 2
def bar() =|  line 1|  line 2

Make your code look like the syntax tree that we all know it really is :)


On 7 June 2010 21:40, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
Rex,

If braces help you to understand or clarify your algorithm, you would still be able to use them if I had my way. I am certainly not suggesting that braces should be eliminated from Scala.

Similarly, redundant (logically irrelevant) parentheses can sometimes help to clarify a mathematical expression. In that case, go ahead and use them. I think you will agree, however, that they should not be required. And I think you will also agree that mixing expressions with and without extra parentheses is not a problem. I think the same principle should apply to braces.

I think you need to be careful about what you claim about braces. They may be able to clarify your code if you use them correctly, but they can also make your code misleading if they are inconsistent with its logical structure due to an error on your part. If Scala enforced consistency between braces and indentation, that would be a step in the right direction as far as I am concerned. But it doesn't currently do that. (And please don't tell me that an IDE can do that. I don't care. We're talking about Scala, not IDEs.)

In any case, I am leaning toward using the colon as Martin suggested, or maybe "|" (if it does not conflict with anything). For example:

if (foo) |
    line 1
    line 2

def bar() = |
    line 1
    line 2

Yes, I realize it may appear strange at first glance, but once you get used to it, it will seem perfectly natural and elegant.

Russ P.


On Sun, Jun 6, 2010 at 9:20 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Sun, Jun 6, 2010 at 9:00 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Braces and semicolons are not essential to specifying an algorithm. No one puts them in pseudocode.

Grouping is essential to specifying an algorithm.  In mathematics, I usually use parentheses (occasionally brackets).  In pseudocode, I will use braces if it becomes too challenging to figure out what is going on with indentation, or if vertical space would be used poorly if I did not group items on one line.  If doing brainstorming, people often draw energetic circles around things they want to group. 

It's largely a matter of what's easiest given the tools available.  When you are working with pencil and paper, inventing all manner of interesting symbols is helpful--they are very clear, easy to draw, and convey great meaning.  With pre-defined character sets, however, this is a nightmare.  So, with a few notable exceptions (e.g. APL, Scalaz) we generally use a character set trivially accessible from the keyboard.

The thing is--braces are easy.  Whitespace is also easy.  Braces are more flexible--you need new lines to get whitespace, and there is ambiguity in the scope of expressions especially when you allow optional semicolons as well.  Whitespace looks cleaner.  I don't think either is particularly superior to the other in all regards.

I do, however, think that braces are an essential part of Scala's expressiveness (or some grouping symbol--one could use parens instead, but I like having the diversity to alert me to what I should expect).  Since we must have braces to enable stuff like
  a.map(b => { val c = f(b); (c,c.toString) })
in a compact and readable manner, then whitespace delimiters are necessarily something extra.

One of the biggest reasons why Python code looks clean and lovely is that you have essentially no choice but to have it look that way.  If Python were a mix of three or four different "clean" styles, the resulting amalgam would not be clean; it would be ugly.

So I think making Scala an amalgam of different styles is a net _drawback_ to the language unless it enables something very helpful.

Since editors can add whitespace for you based on braces, and since braces are more flexible and kind of have to be in there anyway, and you cannot do anything with syntactically important indentation that is not equally or more effectively done with braces, I have trouble classifying it as anything but a drawback.
   --Rex



--
http://RussP.us



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: suggestion for Scala syntax: implied braces
Isn't the real problem here that we're trying to represent a 3-dimensional model in 2-dimensional space?
How about if we could navigate the AST by going "deeper" into the code?

On Mon, Jun 7, 2010 at 10:53 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
I'd rather just use braces than to put a | in front of each line.

On Mon, Jun 7, 2010 at 1:47 PM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:
Not that I'm actually condoning this change, but if we're to find an alternative to braces then... Hey, why not go with a convention that we already have in the REPL, and stripMargin on Strings?

if (foo) |  line 1|  line 2
def bar() =|  line 1|  line 2

Make your code look like the syntax tree that we all know it really is :)


On 7 June 2010 21:40, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
Rex,

If braces help you to understand or clarify your algorithm, you would still be able to use them if I had my way. I am certainly not suggesting that braces should be eliminated from Scala.

Similarly, redundant (logically irrelevant) parentheses can sometimes help to clarify a mathematical expression. In that case, go ahead and use them. I think you will agree, however, that they should not be required. And I think you will also agree that mixing expressions with and without extra parentheses is not a problem. I think the same principle should apply to braces.

I think you need to be careful about what you claim about braces. They may be able to clarify your code if you use them correctly, but they can also make your code misleading if they are inconsistent with its logical structure due to an error on your part. If Scala enforced consistency between braces and indentation, that would be a step in the right direction as far as I am concerned. But it doesn't currently do that. (And please don't tell me that an IDE can do that. I don't care. We're talking about Scala, not IDEs.)

In any case, I am leaning toward using the colon as Martin suggested, or maybe "|" (if it does not conflict with anything). For example:

if (foo) |
    line 1
    line 2

def bar() = |
    line 1
    line 2

Yes, I realize it may appear strange at first glance, but once you get used to it, it will seem perfectly natural and elegant.

Russ P.


On Sun, Jun 6, 2010 at 9:20 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Sun, Jun 6, 2010 at 9:00 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Braces and semicolons are not essential to specifying an algorithm. No one puts them in pseudocode.

Grouping is essential to specifying an algorithm.  In mathematics, I usually use parentheses (occasionally brackets).  In pseudocode, I will use braces if it becomes too challenging to figure out what is going on with indentation, or if vertical space would be used poorly if I did not group items on one line.  If doing brainstorming, people often draw energetic circles around things they want to group. 

It's largely a matter of what's easiest given the tools available.  When you are working with pencil and paper, inventing all manner of interesting symbols is helpful--they are very clear, easy to draw, and convey great meaning.  With pre-defined character sets, however, this is a nightmare.  So, with a few notable exceptions (e.g. APL, Scalaz) we generally use a character set trivially accessible from the keyboard.

The thing is--braces are easy.  Whitespace is also easy.  Braces are more flexible--you need new lines to get whitespace, and there is ambiguity in the scope of expressions especially when you allow optional semicolons as well.  Whitespace looks cleaner.  I don't think either is particularly superior to the other in all regards.

I do, however, think that braces are an essential part of Scala's expressiveness (or some grouping symbol--one could use parens instead, but I like having the diversity to alert me to what I should expect).  Since we must have braces to enable stuff like
  a.map(b => { val c = f(b); (c,c.toString) })
in a compact and readable manner, then whitespace delimiters are necessarily something extra.

One of the biggest reasons why Python code looks clean and lovely is that you have essentially no choice but to have it look that way.  If Python were a mix of three or four different "clean" styles, the resulting amalgam would not be clean; it would be ugly.

So I think making Scala an amalgam of different styles is a net _drawback_ to the language unless it enables something very helpful.

Since editors can add whitespace for you based on braces, and since braces are more flexible and kind of have to be in there anyway, and you cannot do anything with syntactically important indentation that is not equally or more effectively done with braces, I have trouble classifying it as anything but a drawback.
   --Rex



--
http://RussP.us



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda




--
http://RussP.us



--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang
Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: suggestion for Scala syntax: implied braces
It would fix the issue of converting 'twixt spaces and tabs, not to mention issues with copying & pasting snippets from other projects! (I swear, they always seem to indent in multiples of 3 spaces)
Just determine block scope by counting the number of pipe characters, problem solved!



On 7 June 2010 21:53, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
I'd rather just use braces than to put a | in front of each line.

On Mon, Jun 7, 2010 at 1:47 PM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:
Not that I'm actually condoning this change, but if we're to find an alternative to braces then... Hey, why not go with a convention that we already have in the REPL, and stripMargin on Strings?

if (foo) |  line 1|  line 2
def bar() =|  line 1|  line 2

Make your code look like the syntax tree that we all know it really is :)


On 7 June 2010 21:40, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
Rex,

If braces help you to understand or clarify your algorithm, you would still be able to use them if I had my way. I am certainly not suggesting that braces should be eliminated from Scala.

Similarly, redundant (logically irrelevant) parentheses can sometimes help to clarify a mathematical expression. In that case, go ahead and use them. I think you will agree, however, that they should not be required. And I think you will also agree that mixing expressions with and without extra parentheses is not a problem. I think the same principle should apply to braces.

I think you need to be careful about what you claim about braces. They may be able to clarify your code if you use them correctly, but they can also make your code misleading if they are inconsistent with its logical structure due to an error on your part. If Scala enforced consistency between braces and indentation, that would be a step in the right direction as far as I am concerned. But it doesn't currently do that. (And please don't tell me that an IDE can do that. I don't care. We're talking about Scala, not IDEs.)

In any case, I am leaning toward using the colon as Martin suggested, or maybe "|" (if it does not conflict with anything). For example:

if (foo) |
    line 1
    line 2

def bar() = |
    line 1
    line 2

Yes, I realize it may appear strange at first glance, but once you get used to it, it will seem perfectly natural and elegant.

Russ P.


On Sun, Jun 6, 2010 at 9:20 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Sun, Jun 6, 2010 at 9:00 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Braces and semicolons are not essential to specifying an algorithm. No one puts them in pseudocode.

Grouping is essential to specifying an algorithm.  In mathematics, I usually use parentheses (occasionally brackets).  In pseudocode, I will use braces if it becomes too challenging to figure out what is going on with indentation, or if vertical space would be used poorly if I did not group items on one line.  If doing brainstorming, people often draw energetic circles around things they want to group. 

It's largely a matter of what's easiest given the tools available.  When you are working with pencil and paper, inventing all manner of interesting symbols is helpful--they are very clear, easy to draw, and convey great meaning.  With pre-defined character sets, however, this is a nightmare.  So, with a few notable exceptions (e.g. APL, Scalaz) we generally use a character set trivially accessible from the keyboard.

The thing is--braces are easy.  Whitespace is also easy.  Braces are more flexible--you need new lines to get whitespace, and there is ambiguity in the scope of expressions especially when you allow optional semicolons as well.  Whitespace looks cleaner.  I don't think either is particularly superior to the other in all regards.

I do, however, think that braces are an essential part of Scala's expressiveness (or some grouping symbol--one could use parens instead, but I like having the diversity to alert me to what I should expect).  Since we must have braces to enable stuff like
  a.map(b => { val c = f(b); (c,c.toString) })
in a compact and readable manner, then whitespace delimiters are necessarily something extra.

One of the biggest reasons why Python code looks clean and lovely is that you have essentially no choice but to have it look that way.  If Python were a mix of three or four different "clean" styles, the resulting amalgam would not be clean; it would be ugly.

So I think making Scala an amalgam of different styles is a net _drawback_ to the language unless it enables something very helpful.

Since editors can add whitespace for you based on braces, and since braces are more flexible and kind of have to be in there anyway, and you cannot do anything with syntactically important indentation that is not equally or more effectively done with braces, I have trouble classifying it as anything but a drawback.
   --Rex



--
http://RussP.us



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda




--
http://RussP.us



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: suggestion for Scala syntax: implied braces
SCID - Source Code In Database
The idea's been around for years.  It's never (to my knowledge) been fully realised, though we do have some aspects in the form of syntax trees in our IDEs.  So expanding/collapsing is a form of moving into this third dimension.
It's not a bad idea either, to actually *store* code in this representation.  can you image how much easier life would be if diff tools understood method boundaries?  My suspicion is that many were scared off after seeing big corps, UML code generation, SAP ABAP and other "4GL" languages take on the worse parts of the concept, that and an irrational deep-seated love of regexes, and the number of existing tools that would be broken :)



On 7 June 2010 22:06, Viktor Klang <viktor [dot] klang [at] gmail [dot] com> wrote:
Isn't the real problem here that we're trying to represent a 3-dimensional model in 2-dimensional space?
How about if we could navigate the AST by going "deeper" into the code?

On Mon, Jun 7, 2010 at 10:53 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
I'd rather just use braces than to put a | in front of each line.

On Mon, Jun 7, 2010 at 1:47 PM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:
Not that I'm actually condoning this change, but if we're to find an alternative to braces then... Hey, why not go with a convention that we already have in the REPL, and stripMargin on Strings?

if (foo) |  line 1|  line 2
def bar() =|  line 1|  line 2

Make your code look like the syntax tree that we all know it really is :)


On 7 June 2010 21:40, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
Rex,

If braces help you to understand or clarify your algorithm, you would still be able to use them if I had my way. I am certainly not suggesting that braces should be eliminated from Scala.

Similarly, redundant (logically irrelevant) parentheses can sometimes help to clarify a mathematical expression. In that case, go ahead and use them. I think you will agree, however, that they should not be required. And I think you will also agree that mixing expressions with and without extra parentheses is not a problem. I think the same principle should apply to braces.

I think you need to be careful about what you claim about braces. They may be able to clarify your code if you use them correctly, but they can also make your code misleading if they are inconsistent with its logical structure due to an error on your part. If Scala enforced consistency between braces and indentation, that would be a step in the right direction as far as I am concerned. But it doesn't currently do that. (And please don't tell me that an IDE can do that. I don't care. We're talking about Scala, not IDEs.)

In any case, I am leaning toward using the colon as Martin suggested, or maybe "|" (if it does not conflict with anything). For example:

if (foo) |
    line 1
    line 2

def bar() = |
    line 1
    line 2

Yes, I realize it may appear strange at first glance, but once you get used to it, it will seem perfectly natural and elegant.

Russ P.


On Sun, Jun 6, 2010 at 9:20 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Sun, Jun 6, 2010 at 9:00 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Braces and semicolons are not essential to specifying an algorithm. No one puts them in pseudocode.

Grouping is essential to specifying an algorithm.  In mathematics, I usually use parentheses (occasionally brackets).  In pseudocode, I will use braces if it becomes too challenging to figure out what is going on with indentation, or if vertical space would be used poorly if I did not group items on one line.  If doing brainstorming, people often draw energetic circles around things they want to group. 

It's largely a matter of what's easiest given the tools available.  When you are working with pencil and paper, inventing all manner of interesting symbols is helpful--they are very clear, easy to draw, and convey great meaning.  With pre-defined character sets, however, this is a nightmare.  So, with a few notable exceptions (e.g. APL, Scalaz) we generally use a character set trivially accessible from the keyboard.

The thing is--braces are easy.  Whitespace is also easy.  Braces are more flexible--you need new lines to get whitespace, and there is ambiguity in the scope of expressions especially when you allow optional semicolons as well.  Whitespace looks cleaner.  I don't think either is particularly superior to the other in all regards.

I do, however, think that braces are an essential part of Scala's expressiveness (or some grouping symbol--one could use parens instead, but I like having the diversity to alert me to what I should expect).  Since we must have braces to enable stuff like
  a.map(b => { val c = f(b); (c,c.toString) })
in a compact and readable manner, then whitespace delimiters are necessarily something extra.

One of the biggest reasons why Python code looks clean and lovely is that you have essentially no choice but to have it look that way.  If Python were a mix of three or four different "clean" styles, the resulting amalgam would not be clean; it would be ugly.

So I think making Scala an amalgam of different styles is a net _drawback_ to the language unless it enables something very helpful.

Since editors can add whitespace for you based on braces, and since braces are more flexible and kind of have to be in there anyway, and you cannot do anything with syntactically important indentation that is not equally or more effectively done with braces, I have trouble classifying it as anything but a drawback.
   --Rex



--
http://RussP.us



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda




--
http://RussP.us



--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

bmjsmith
Joined: 2010-03-12,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces
Code bubbles perhaps?
http://www.cs.brown.edu/people/acb/codebubbles_site.htm

On 7 June 2010 22:33, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:
SCID - Source Code In Database
The idea's been around for years.  It's never (to my knowledge) been fully realised, though we do have some aspects in the form of syntax trees in our IDEs.  So expanding/collapsing is a form of moving into this third dimension.
It's not a bad idea either, to actually *store* code in this representation.  can you image how much easier life would be if diff tools understood method boundaries?  My suspicion is that many were scared off after seeing big corps, UML code generation, SAP ABAP and other "4GL" languages take on the worse parts of the concept, that and an irrational deep-seated love of regexes, and the number of existing tools that would be broken :)



On 7 June 2010 22:06, Viktor Klang <viktor [dot] klang [at] gmail [dot] com> wrote:
Isn't the real problem here that we're trying to represent a 3-dimensional model in 2-dimensional space?
How about if we could navigate the AST by going "deeper" into the code?

On Mon, Jun 7, 2010 at 10:53 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
I'd rather just use braces than to put a | in front of each line.

On Mon, Jun 7, 2010 at 1:47 PM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:
Not that I'm actually condoning this change, but if we're to find an alternative to braces then... Hey, why not go with a convention that we already have in the REPL, and stripMargin on Strings?

if (foo) |  line 1|  line 2
def bar() =|  line 1|  line 2

Make your code look like the syntax tree that we all know it really is :)


On 7 June 2010 21:40, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
Rex,

If braces help you to understand or clarify your algorithm, you would still be able to use them if I had my way. I am certainly not suggesting that braces should be eliminated from Scala.

Similarly, redundant (logically irrelevant) parentheses can sometimes help to clarify a mathematical expression. In that case, go ahead and use them. I think you will agree, however, that they should not be required. And I think you will also agree that mixing expressions with and without extra parentheses is not a problem. I think the same principle should apply to braces.

I think you need to be careful about what you claim about braces. They may be able to clarify your code if you use them correctly, but they can also make your code misleading if they are inconsistent with its logical structure due to an error on your part. If Scala enforced consistency between braces and indentation, that would be a step in the right direction as far as I am concerned. But it doesn't currently do that. (And please don't tell me that an IDE can do that. I don't care. We're talking about Scala, not IDEs.)

In any case, I am leaning toward using the colon as Martin suggested, or maybe "|" (if it does not conflict with anything). For example:

if (foo) |
    line 1
    line 2

def bar() = |
    line 1
    line 2

Yes, I realize it may appear strange at first glance, but once you get used to it, it will seem perfectly natural and elegant.

Russ P.


On Sun, Jun 6, 2010 at 9:20 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Sun, Jun 6, 2010 at 9:00 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Braces and semicolons are not essential to specifying an algorithm. No one puts them in pseudocode.

Grouping is essential to specifying an algorithm.  In mathematics, I usually use parentheses (occasionally brackets).  In pseudocode, I will use braces if it becomes too challenging to figure out what is going on with indentation, or if vertical space would be used poorly if I did not group items on one line.  If doing brainstorming, people often draw energetic circles around things they want to group. 

It's largely a matter of what's easiest given the tools available.  When you are working with pencil and paper, inventing all manner of interesting symbols is helpful--they are very clear, easy to draw, and convey great meaning.  With pre-defined character sets, however, this is a nightmare.  So, with a few notable exceptions (e.g. APL, Scalaz) we generally use a character set trivially accessible from the keyboard.

The thing is--braces are easy.  Whitespace is also easy.  Braces are more flexible--you need new lines to get whitespace, and there is ambiguity in the scope of expressions especially when you allow optional semicolons as well.  Whitespace looks cleaner.  I don't think either is particularly superior to the other in all regards.

I do, however, think that braces are an essential part of Scala's expressiveness (or some grouping symbol--one could use parens instead, but I like having the diversity to alert me to what I should expect).  Since we must have braces to enable stuff like
  a.map(b => { val c = f(b); (c,c.toString) })
in a compact and readable manner, then whitespace delimiters are necessarily something extra.

One of the biggest reasons why Python code looks clean and lovely is that you have essentially no choice but to have it look that way.  If Python were a mix of three or four different "clean" styles, the resulting amalgam would not be clean; it would be ugly.

So I think making Scala an amalgam of different styles is a net _drawback_ to the language unless it enables something very helpful.

Since editors can add whitespace for you based on braces, and since braces are more flexible and kind of have to be in there anyway, and you cannot do anything with syntactically important indentation that is not equally or more effectively done with braces, I have trouble classifying it as anything but a drawback.
   --Rex



--
http://RussP.us



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda




--
http://RussP.us



--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda


Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: suggestion for Scala syntax: implied braces
I'm ignoring *them* until they acknowledge my beta request :P

On 7 June 2010 23:29, Brian Smith <bmjsmith [at] gmail [dot] com> wrote:
Code bubbles perhaps?
http://www.cs.brown.edu/people/acb/codebubbles_site.htm

On 7 June 2010 22:33, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:
SCID - Source Code In Database
The idea's been around for years.  It's never (to my knowledge) been fully realised, though we do have some aspects in the form of syntax trees in our IDEs.  So expanding/collapsing is a form of moving into this third dimension.
It's not a bad idea either, to actually *store* code in this representation.  can you image how much easier life would be if diff tools understood method boundaries?  My suspicion is that many were scared off after seeing big corps, UML code generation, SAP ABAP and other "4GL" languages take on the worse parts of the concept, that and an irrational deep-seated love of regexes, and the number of existing tools that would be broken :)



On 7 June 2010 22:06, Viktor Klang <viktor [dot] klang [at] gmail [dot] com> wrote:
Isn't the real problem here that we're trying to represent a 3-dimensional model in 2-dimensional space?
How about if we could navigate the AST by going "deeper" into the code?

On Mon, Jun 7, 2010 at 10:53 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
I'd rather just use braces than to put a | in front of each line.

On Mon, Jun 7, 2010 at 1:47 PM, Kevin Wright <kev [dot] lee [dot] wright [at] gmail [dot] com> wrote:
Not that I'm actually condoning this change, but if we're to find an alternative to braces then... Hey, why not go with a convention that we already have in the REPL, and stripMargin on Strings?

if (foo) |  line 1|  line 2
def bar() =|  line 1|  line 2

Make your code look like the syntax tree that we all know it really is :)


On 7 June 2010 21:40, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
Rex,

If braces help you to understand or clarify your algorithm, you would still be able to use them if I had my way. I am certainly not suggesting that braces should be eliminated from Scala.

Similarly, redundant (logically irrelevant) parentheses can sometimes help to clarify a mathematical expression. In that case, go ahead and use them. I think you will agree, however, that they should not be required. And I think you will also agree that mixing expressions with and without extra parentheses is not a problem. I think the same principle should apply to braces.

I think you need to be careful about what you claim about braces. They may be able to clarify your code if you use them correctly, but they can also make your code misleading if they are inconsistent with its logical structure due to an error on your part. If Scala enforced consistency between braces and indentation, that would be a step in the right direction as far as I am concerned. But it doesn't currently do that. (And please don't tell me that an IDE can do that. I don't care. We're talking about Scala, not IDEs.)

In any case, I am leaning toward using the colon as Martin suggested, or maybe "|" (if it does not conflict with anything). For example:

if (foo) |
    line 1
    line 2

def bar() = |
    line 1
    line 2

Yes, I realize it may appear strange at first glance, but once you get used to it, it will seem perfectly natural and elegant.

Russ P.


On Sun, Jun 6, 2010 at 9:20 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Sun, Jun 6, 2010 at 9:00 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Braces and semicolons are not essential to specifying an algorithm. No one puts them in pseudocode.

Grouping is essential to specifying an algorithm.  In mathematics, I usually use parentheses (occasionally brackets).  In pseudocode, I will use braces if it becomes too challenging to figure out what is going on with indentation, or if vertical space would be used poorly if I did not group items on one line.  If doing brainstorming, people often draw energetic circles around things they want to group. 

It's largely a matter of what's easiest given the tools available.  When you are working with pencil and paper, inventing all manner of interesting symbols is helpful--they are very clear, easy to draw, and convey great meaning.  With pre-defined character sets, however, this is a nightmare.  So, with a few notable exceptions (e.g. APL, Scalaz) we generally use a character set trivially accessible from the keyboard.

The thing is--braces are easy.  Whitespace is also easy.  Braces are more flexible--you need new lines to get whitespace, and there is ambiguity in the scope of expressions especially when you allow optional semicolons as well.  Whitespace looks cleaner.  I don't think either is particularly superior to the other in all regards.

I do, however, think that braces are an essential part of Scala's expressiveness (or some grouping symbol--one could use parens instead, but I like having the diversity to alert me to what I should expect).  Since we must have braces to enable stuff like
  a.map(b => { val c = f(b); (c,c.toString) })
in a compact and readable manner, then whitespace delimiters are necessarily something extra.

One of the biggest reasons why Python code looks clean and lovely is that you have essentially no choice but to have it look that way.  If Python were a mix of three or four different "clean" styles, the resulting amalgam would not be clean; it would be ugly.

So I think making Scala an amalgam of different styles is a net _drawback_ to the language unless it enables something very helpful.

Since editors can add whitespace for you based on braces, and since braces are more flexible and kind of have to be in there anyway, and you cannot do anything with syntactically important indentation that is not equally or more effectively done with braces, I have trouble classifying it as anything but a drawback.
   --Rex



--
http://RussP.us



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda




--
http://RussP.us



--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang



--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda





--
Kevin Wright

mail/google talk: kev [dot] lee [dot] wright [at] gmail [dot] com
wave: kev [dot] lee [dot] wright [at] googlewave [dot] com
skype: kev.lee.wright
twitter: @thecoda

Chris Marshall
Joined: 2009-06-17,
User offline. Last seen 44 weeks 3 days ago.
RE: suggestion for Scala syntax: implied braces
On the basis of this discussion, I've changed my syntax highlighting so as to make braces only just visible on the background from the argument that they are just clutter. It's certainly a cleaner look to the code but I can't say I'm won over to the idea of significant whitespace.
Chris
Date: Mon, 7 Jun 2010 13:53:52 -0700
Subject: Re: [scala-debate] suggestion for Scala syntax: implied braces
From: russ [dot] paielli [at] gmail [dot] com

I'd rather just use braces than to put a | in front of each line.



Get a new e-mail account with Hotmail - Free. Sign-up now.
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Wed, Jun 9, 2010 at 8:09 AM, christopher marshall <oxbow_lakes [at] hotmail [dot] com> wrote:
On the basis of this discussion, I've changed my syntax highlighting so as to make braces only just visible on the background from the argument that they are just clutter. It's certainly a cleaner look to the code but I can't say I'm won over to the idea of significant whitespace.

But whitespace *is* significant -- for readability. Does anyone intentionally write Scala code that is not indented properly (i.e., is not indented consistently with the braces)? Why would anyone do that? To save on storage space? Yeah, right!

Here's what I suggest. The next major release after 2.8 should enforce consistency between indentation and braces. That will eliminate a whole class of bugs relatively easily. I would like to see Scala accepted for use in safety-critical systems (e.g., ATC, so I am not stuck with C++, Java, or Ada), and I contend that this easy opportunity to make the language less prone to error should be taken.

For example, something like

if (foo)
    line 1
    line 2

is likely to be a bug and should not compile. To get it to compile, either braces could be added or, as per Martin's suggestion, a colon could be used:

if (foo):
    line 1
    line 2

The problem here is that, as Martin pointed out,

def foo() = :
    line 1
    line 2

doesn't look look quite right. Maybe it just takes some getting used to. I think

def foo() = |
    line 1
    line 2

looks better, but the colon looks better for the "if" block. Both symbols could be allowed, but that sacrifices consistency. Maybe the "|" should be used only after an "=" but a colon should be used after a closing paren for an "if" or "for". In any case, I'm sure that Martin and his team will make the right choice.

Russ P.

http://RussP.us
Justin du coeur
Joined: 2009-03-04,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Wed, Jun 9, 2010 at 3:12 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
But whitespace *is* significant -- for readability. Does anyone intentionally write Scala code that is not indented properly (i.e., is not indented consistently with the braces)? Why would anyone do that? To save on storage space? Yeah, right! 

Well, I should point out that it is quite common to use braces in non-new-line situations, so that a block can occur on a single line with other code.  This is less necessary in Scala than some languages (due to other ways to accomplish similar goals), but I don't believe it's been entirely eliminated.  So at least in that simple case -- yes, I do, and yes, this is a feature that should not be touched.  
Here's what I suggest. The next major release after 2.8 should enforce consistency between indentation and braces.

No, sorry -- this is the wrong way to go about it.  If you want this, you first need to come up with an *optional* compiler plugin that does this enforcement.  *If* you do this, and *if* this proves popular, *then* it might be appropriate to enforce this by default in the following version.  But you're still living in unproven-hypothesis land until then.
(The definition of "enforce" is also a bit vague.  This should probably be implemented as a warning, with an optional strict variation to actually act as an error.  Certainly it *can't* be more than a warning for at least a full release, since lots of existing code won't pass.  Moreover, there are stylistic issues to be wrestled with -- not everyone uses braces identically, so enforcement is fairly complex.)
Seriously: you're still coming across as rather pushy, and so far aren't showing obvious willingness to do the hard work yourself.  None of this is ever likely to happen unless you (and possibly other people who share your enthusiasm for this subject) take the bull by the horns and start actually *doing* this stuff.  Without that, this is mostly just noise.  The onus is on you to *demonstrate* that your ideas are better, rather than just claiming it...
ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Wed, Jun 9, 2010 at 3:12 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Here's what I suggest. The next major release after 2.8 should enforce consistency between indentation and braces. That will eliminate a whole class of bugs relatively easily. I would like to see Scala accepted for use in safety-critical systems (e.g., ATC, so I am not stuck with C++, Java, or Ada), and I contend that this easy opportunity to make the language less prone to error should be taken.

Can you please cite a source that indicates (hopefully with data as well as rhetoric) that enforced consistent indentation makes users of that language less prone to error?

  --Rex

Jeremy Bell
Joined: 2010-04-08,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces
I have worked in both python and other languages which do not enforce consistent indentation (C++, java, C#, perl, and now scala), and my own personal opinion is that not only is the problem it is trying to solve a non-issue, but the solution is worse than the problem.
In my day job, which mostly consists of C++ development on a "mature" code base, I see a lot of inconsistent indentation, which leads to readability issues. Almost every time I come across code with inconsistent indentation, I can fix it by simply selecting it and using my IDE's code formatter, or I could tell it to format the entire file. After that there is no ambiguity, even with if statements without braces. The following is no longer possible:
if (..)    statement1    statement2 // formatter fixes this indentation

nor is this possible:
if(..) statement1     if(...) statement2 // formatter fixes this indentation
And that is just with the basic code formatter included in my IDE, which isn't even that great. 
One problem I find in reasonably complex python code is that it discourages the use of blank lines to separate logical sections of sequential code - say, a set of fields/methods related to a certain feature - because the more blank lines you have in a single indented block the less it appears a particular indented block is part of the same block. In other words, when I see a blank line, my brain is half trained to look for the start of a new block. Plus, any syntax you add to try to alleviate this issue, namely colons or bars or forward slashes at the end of each line, just add more noise than the original braces you are trying to eliminate.
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces


On Wed, Jun 9, 2010 at 12:40 PM, Justin du coeur <jducoeur [at] gmail [dot] com> wrote:
On Wed, Jun 9, 2010 at 3:12 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
But whitespace *is* significant -- for readability. Does anyone intentionally write Scala code that is not indented properly (i.e., is not indented consistently with the braces)? Why would anyone do that? To save on storage space? Yeah, right! 

Well, I should point out that it is quite common to use braces in non-new-line situations, so that a block can occur on a single line with other code.  This is less necessary in Scala than some languages (due to other ways to accomplish similar goals), but I don't believe it's been entirely eliminated.  So at least in that simple case -- yes, I do, and yes, this is a feature that should not be touched.  


A brace-delimited block on a single line is NOT an "inconsistent" use of indentation. Therefore, my proposal would not prohibit it.

 
Here's what I suggest. The next major release after 2.8 should enforce consistency between indentation and braces.

No, sorry -- this is the wrong way to go about it.  If you want this, you first need to come up with an *optional* compiler plugin that does this enforcement.  *If* you do this, and *if* this proves popular, *then* it might be appropriate to enforce this by default in the following version.  But you're still living in unproven-hypothesis land until then.

I don't think you need to worry about the Scala team being too aggressive in implementing my suggestions. Yes, of course this proposal needs to be tested properly before it is implemented. When I wrote "the next major release," I simply meant a release in which some small violation of backward compatibility may be allowed. Note that any new violations in this context would be caught by the compiler and could be corrected easily. You wouldn't need to worry about any subtle changes that would go unnoticed.

 
(The definition of "enforce" is also a bit vague.  This should probably be implemented as a warning, with an optional strict variation to actually act as an error.  Certainly it *can't* be more than a warning for at least a full release, since lots of existing code won't pass.  Moreover, there are stylistic issues to be wrestled with -- not everyone uses braces identically, so enforcement is fairly complex.)
Seriously: you're still coming across as rather pushy, and so far aren't showing obvious willingness to do the hard work yourself.  None of this is ever likely to happen unless you (and possibly other people who share your enthusiasm for this subject) take the bull by the horns and start actually *doing* this stuff.  Without that, this is mostly just noise.  The onus is on you to *demonstrate* that your ideas are better, rather than just claiming it...


I am just a user making suggestions for improving the language for my particular domain. I don't have the skills needed to implement them myself without spending excessive time. My time will be used much more efficiently using Scala for developing new concepts and algorithms for ATC.

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 Wed, Jun 9, 2010 at 12:51 PM, Jeremy Bell <bell [dot] jeremy [at] gmail [dot] com> wrote:
I have worked in both python and other languages which do not enforce consistent indentation (C++, java, C#, perl, and now scala), and my own personal opinion is that not only is the problem it is trying to solve a non-issue, but the solution is worse than the problem.
In my day job, which mostly consists of C++ development on a "mature" code base, I see a lot of inconsistent indentation, which leads to readability issues. Almost every time I come across code with inconsistent indentation, I can fix it by simply selecting it and using my IDE's code formatter, or I could tell it to format the entire file. After that there is no ambiguity, even with if statements without braces. The following is no longer possible:

Here we go with the IDE thing again. As I see it, your IDE is compensating for a deficiency of the language. Why not just make the language more robust, so I don't even need an IDE to get this feature?

Seriously, folks. Think about programming beginners, students, hobbyists, or even scientists and engineers who are not software experts per se but who just want to get something accomplished. Think about the additional overhead and time involved with

1) selecting an IDE
2) installing it
3) learning to use it
4) tolerating network lags for telecommuting, etc.

One problem I find in reasonably complex python code is that it discourages the use of blank lines to separate logical sections of sequential code - say, a set of fields/methods related to a certain feature - because the more blank lines you have in a single indented block the less it appears a particular indented block is part of the same block. In other words, when I see a blank line, my brain is half trained to look for the start of a new block. Plus, any syntax you add to try to alleviate this issue, namely colons or bars or forward slashes at the end of each line, just add more noise than the original braces you are trying to eliminate.


I use blank lines all over the place in Python, and it never even occurred to me that it doesn't look right.

Russ P.

--
http://RussP.us
Björn Herzig
Joined: 2010-05-18,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

On Jun 9, 2010, at 9:12 PM, Russ Paielli wrote:

>
> The problem here is that, as Martin pointed out,
>
> def foo() = :
> line 1
> line 2
>
> doesn't look look quite right. Maybe it just takes some getting used to. I think
>
> def foo() = |
> line 1
> line 2
>
> looks better, but the colon looks better for the "if" block. Both symbols could be allowed, but that sacrifices consistency. Maybe the "|" should be used only after an "=" but a colon should be used after a closing paren for an "if" or "for". In any case, I'm sure that Martin and his team will make the right choice.
>
> Russ P.
>
> http://RussP.us

So you are actually suggesting two different approaches to end a line to replace something consistent? Right now we are introducing a block just with braces (plus the possibility to leave them out if the following statement is just a single line or a combination of functions), your approach has two different ways to introduce a block. I fail to see where this is going to help anyone. Sorry, but you seem rather rabid about getting rid of braces without really listening to others. You just seem to see your special "edge-case" where leaving them out seems like a great idea.

On the other hand you happily are trying to make other people implement your suggestions. I really don't see so much positive feedback when it comes to the topic, most people seem to like their braces. If you really want that study to happen: implement it yourself or pay a developer to do so.

I didn't see any valid arguments that show that blocks through indentation are superior opposed to just using braces, and this discussion is going on for how long now? A week?

The whole topic reminds me of a statement Bjarne Stroustrup brought up: "People tend to argue a lot about things that are actually pointless because it's easy to have an opinion on them, but when it comes to tough stuff they are usually silent".

Seriously: Stop arguing that your approach is better. Show some examples and start a project for a compiler project that implements that feature. If you are not able to do it, find someone and pay that person (if needed)

Regards,
raichoo

Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Wed, Jun 9, 2010 at 12:46 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
On Wed, Jun 9, 2010 at 3:12 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:

Here's what I suggest. The next major release after 2.8 should enforce consistency between indentation and braces. That will eliminate a whole class of bugs relatively easily. I would like to see Scala accepted for use in safety-critical systems (e.g., ATC, so I am not stuck with C++, Java, or Ada), and I contend that this easy opportunity to make the language less prone to error should be taken.

Can you please cite a source that indicates (hopefully with data as well as rhetoric) that enforced consistent indentation makes users of that language less prone to error?


Why do you need a "source" for that claim? Do you believe that no programmer has ever inadvertently left the braces off of a multi-line block and had it compile with no error or warning? Well, every such error would be automatically caught by enforced consistency. That's an entire class of bugs zapped.

I don't know about your line of work, but in mine, bugs can be disastrous, not to mention annoying. Could 500 people die instantly some day due to such a bug? How about a $500 million satellite launch disaster? Extremely unlikely, perhaps -- but I'd prefer not to take the chance. I'm funny that way.

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

Russ Paielli schrieb:
> On Wed, Jun 9, 2010 at 12:46 PM, Rex Kerr > wrote:
>
> On Wed, Jun 9, 2010 at 3:12 PM, Russ Paielli
> > wrote:
>
>
> Here's what I suggest. The next major release after 2.8 should
> enforce consistency between indentation and braces. That will
> eliminate a whole class of bugs relatively easily. I would
> like to see Scala accepted for use in safety-critical systems
> (e.g., ATC, so I am not stuck with C++, Java, or Ada), and I
> contend that this easy opportunity to make the language less
> prone to error should be taken.
>
>
> Can you please cite a source that indicates (hopefully with data
> as well as rhetoric) that enforced consistent indentation makes
> users of that language less prone to error?
>
>
> Why do you need a "source" for that claim? Do you believe that no
> programmer has ever inadvertently left the braces off of a multi-line
> block and had it compile with no error or warning? Well, every such
> error would be automatically caught by enforced consistency. That's an
> entire class of bugs zapped.
>
> I don't know about your line of work, but in mine, bugs can be
> disastrous, not to mention annoying. Could 500 people die instantly
> some day due to such a bug? How about a $500 million satellite launch
> disaster? Extremely unlikely, perhaps -- but I'd prefer not to take
> the chance. I'm funny that way.
>
> 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 Wed, Jun 9, 2010 at 1:14 PM, Björn Herzig <raichoo [at] googlemail [dot] com> wrote:

I didn't see any valid arguments that show that blocks through indentation are superior opposed to just using braces, and this discussion is going on for how long now? A week?


Let me summarize. If Scala starts to enforce consistency between braces and indentation, then the "braces" issue becomes merely aesthetic. But if it doesn't, then the Python approach of letting indentation define scope becomes more than merely an aesthetic issue. I've already explained why. Basically, the Python approach guarantees consistency between indentation and logical structure.

 
The whole topic reminds me of a statement Bjarne Stroustrup brought up: "People tend to argue a lot about things that are actually pointless because it's easy to have an opinion on them, but when it comes to tough stuff they are usually silent".


This whole topic reminds me of what happened a year or two ago when I proposed that default arguments and argument keywords be added to Scala. I'm not sure, but I may have been the first to suggest those features. As far as I am concerned, any high-level language without them is deficient. As I I recall, I got all kinds of flak in return. Exactly the sorts of things you are saying now. But those features were eventually added, of course.

Patrik Andersson
Joined: 2009-11-16,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Wed, Jun 9, 2010 at 11:13 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
On Wed, Jun 9, 2010 at 1:14 PM, Björn Herzig <raichoo [at] googlemail [dot] com> wrote:

I didn't see any valid arguments that show that blocks through indentation are superior opposed to just using braces, and this discussion is going on for how long now? A week?


Let me summarize. If Scala starts to enforce consistency between braces and indentation, then the "braces" issue becomes merely aesthetic. But if it doesn't, then the Python approach of letting indentation define scope becomes more than merely an aesthetic issue. I've already explained why. Basically, the Python approach guarantees consistency between indentation and logical structure.

 
The whole topic reminds me of a statement Bjarne Stroustrup brought up: "People tend to argue a lot about things that are actually pointless because it's easy to have an opinion on them, but when it comes to tough stuff they are usually silent".


This whole topic reminds me of what happened a year or two ago when I proposed that default arguments and argument keywords be added to Scala. I'm not sure, but I may have been the first to suggest those features. As far as I am concerned, any high-level language without them is deficient. As I I recall, I got all kinds of flak in return. Exactly the sorts of things you are saying now. But those features were eventually added, of course.


Jeremy Bell
Joined: 2010-04-08,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces

 
Here we go with the IDE thing again. As I see it, your IDE is compensating for a deficiency of the language. Why not just make the language more robust, so I don't even need an IDE to get this feature?

Because I have come to terms with the fact that I may need more sophisticated tools at my disposal than notepad can offer (or emacs, or vi, if you prefer). In this particular case, you don't even need an IDE. I happen to use one, and it happens to have a code formatter included. I could have used a command line code formatter on code I wrote in notepad, if I really wanted to. I could even use my IDE's formatter from the command line.  
Seriously, folks. Think about programming beginners, students, hobbyists, or even scientists and engineers who are not software experts per se but who just want to get something accomplished. Think about the additional overhead and time involved with

1) selecting an IDE
2) installing it
3) learning to use it

Very few projects can get by without some automated build system, be that a command line one like Ant, make, sake, or an IDE. In some cases, the ide uses the same project structure/format as the command line version. 
Plus, I've taught 10 year olds how to use eclipse in a single day. I don't buy the "IDE's are hard" argument. You only need to know enough to get you going (which is usually very little), and you learn the rest as you go.  
4) tolerating network lags for telecommuting, etc.

Local repository. Batched checkins. Problem solved.
I use blank lines all over the place in Python, and it never even occurred to me that it doesn't look right.

I'm happy for you, but that doesn't make my experience any better.
This whole topic reminds me of what happened a year or two ago when I proposed that default arguments and argument keywords be added to Scala. I'm not sure, but I may have been the first to suggest those features. As far as I am concerned, any high-level language without them is deficient. As I I recall, I got all kinds of flak in return. Exactly the sorts of things you are saying now. But those features were eventually added, of course. 

This whole topic reminds me of the time I proposed non-allocating value types be added to scala, as they exist in C# on .net, which I made several seemingly compelling arguments for. In the end I did some benchmarks with escape analysis enabled and found out that typical gain was only around 4%. And, if escape analysis is added to tools like proguard, you'd probably have to try really hard to measure any gain at all.
I don't think we should actively discourage anyone from submitting ideas - I've submitted a few half-baked ideas in my time too. Some of them have merit and are worth considering, and some suggestions are simply not worth the effort to implement. If you disagree with the community's judgement of"not worth the effort", then either put forth the effort yourself, or make it worth someone else's effort by paying them as has been previously suggested.
ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Wed, Jun 9, 2010 at 4:48 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
On Wed, Jun 9, 2010 at 12:46 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:
Can you please cite a source that indicates (hopefully with data as well as rhetoric) that enforced consistent indentation makes users of that language less prone to error?


Why do you need a "source" for that claim?

Because I don't believe that claim.  It is contrary to my personal experience with Python.  It is irrelevant visually given the capabilities of lots of editors.  It contradicts the opinions of a bunch of people who have responded to this thread.

But I'm willing to be convinced otherwise if you have evidence, not just heartfelt opinion.
 
Do you believe that no programmer has ever inadvertently left the braces off of a multi-line block and had it compile with no error or warning?

Of course they have.  Do you believe that no programmer has ever inadvertently mis-indented the last line of a block in Python and had it work in the outer block instead?

You have to make an argument about the _relative importance of the two types of errors_.

And you have to do it _in the context of available IDEs_.  IDEs that can _fix your broken indentation for you_ if you use braces but _are helpless_ if you use whitespace.  Seems to me that you ought not want Scala to do away with braces--rather, it should add consistent indentation as a requirement _without_ taking away braces.  (Or, you should have some external validation tool that flags all lines that don't have matching indentation.)

Otherwise, it seems to me that you are putting your aesthetic preferences ahead of some of our aesthetic preferences, and ahead of safety.
 
I don't know about your line of work, but in mine, bugs can be disastrous, not to mention annoying. Could 500 people die instantly some day due to such a bug? How about a $500 million satellite launch disaster? Extremely unlikely, perhaps -- but I'd prefer not to take the chance. I'm funny that way.

Do you also use the best available IDEs to format your code for you?

I would be funny that way, too.

(Not to mention extensive unit testing, code review by a partner, and everything else that has been demonstrated to reduce bug rates.)

  --Rex

Jeremy Bell
Joined: 2010-04-08,
User offline. Last seen 42 years 45 weeks ago.
Re: suggestion for Scala syntax: implied braces
You could also try plugging the following input as a .net 4.0 sentient DSL (http://channel9.msdn.com/shows/10-4/10-4-Episode-14-Sentient-DSLs/):
"I want a scala compiler that forces a consistent bracing style like python, which everyone likes and doesn't break anything"
Archontophoenix
Joined: 2010-02-04,
User offline. Last seen 2 years 35 weeks ago.
RE: suggestion for Scala syntax: implied braces
In response to almost any type of argument that begins, "Nobody would be so dumb as to...", may I humbly present myself as living counterexample?

It isn't hard to misalign code by one space, and it looks almost right:

  if (a):    // 2 spaces
   if (b):   // 3 spaces, not intended 4
      blah
      blah
      blah
    if (c): // 4 spaces
      yada
      yada
      yada
  and after that  // 2 spaces

If I understand the Python rules correctly, this puts "if (c)" inside "if (b)", which is not the intention.

And yes, I have accidentally indented code this way.

So I'm not enthusiastic about the Python-style indentation rule. But I suppose I could live with it, as I live with other sources of error like mismatched braces, if tab characters were illegal in indentation -- making invisible changes significant is just begging for trouble.

On the other hand, for the belt-and-suspenders folks, I like the idea of a compiler switch that warns when your indentation is inconsistent with the location of your braces. I'd use it, if it were available.

As for the argument that the IDE will do all the work, I don't use one. Even if I did, I want to use a language that's easily understood even without an IDE. For example, it should be possible to read code examples in a printed book, or write snippets of code and send them in an email, without involving an IDE.

A

Date: Wed, 9 Jun 2010 23:19:00 +0200
Subject: Re: [scala-debate] suggestion for Scala syntax: implied braces
From: pandersson [at] gmail [dot] com
To: russ [dot] paielli [at] gmail [dot] com
CC: raichoo [at] googlemail [dot] com; scala-debate [at] listes [dot] epfl [dot] ch

Russ: People don't get indentation wrong. Seriously. They don't. So your gain is one line per block (and the right-brace that's on it). Is your harddrive feeling tight around your forehead?

On Wed, Jun 9, 2010 at 11:13 PM, Russ Paielli <russ [dot] paielli [at] gmail [dot] com> wrote:
On Wed, Jun 9, 2010 at 1:14 PM, Björn Herzig <raichoo [at] googlemail [dot] com> wrote:

I didn't see any valid arguments that show that blocks through indentation are superior opposed to just using braces, and this discussion is going on for how long now? A week?


Let me summarize. If Scala starts to enforce consistency between braces and indentation, then the "braces" issue becomes merely aesthetic. But if it doesn't, then the Python approach of letting indentation define scope becomes more than merely an aesthetic issue. I've already explained why. Basically, the Python approach guarantees consistency between indentation and logical structure.

 
The whole topic reminds me of a statement Bjarne Stroustrup brought up: "People tend to argue a lot about things that are actually pointless because it's easy to have an opinion on them, but when it comes to tough stuff they are usually silent".


This whole topic reminds me of what happened a year or two ago when I proposed that default arguments and argument keywords be added to Scala. I'm not sure, but I may have been the first to suggest those features. As far as I am concerned, any high-level language without them is deficient. As I I recall, I got all kinds of flak in return. Exactly the sorts of things you are saying now. But those features were eventually added, of course.



Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. See how.
Russ P.
Joined: 2009-01-31,
User offline. Last seen 1 year 26 weeks ago.
Re: suggestion for Scala syntax: implied braces
On Wed, Jun 9, 2010 at 3:31 PM, adriaN kinG <ceroxylon [at] hotmail [dot] com> wrote:
In response to almost any type of argument that begins, "Nobody would be so dumb as to...", may I humbly present myself as living counterexample?

It isn't hard to misalign code by one space, and it looks almost right:

  if (a):    // 2 spaces
   if (b):   // 3 spaces, not intended 4
      blah
      blah
      blah
    if (c): // 4 spaces
      yada
      yada
      yada
  and after that  // 2 spaces

If I understand the Python rules correctly, this puts "if (c)" inside "if (b)", which is not the intention.

And yes, I have accidentally indented code this way.


Interesting example. I hadn't thought of that. I'd say that the minimum valid block indentation should be two spaces. Or maybe even three, but definitely at least two.
 
So I'm not enthusiastic about the Python-style indentation rule. But I suppose I could live with it, as I live with other sources of error like mismatched braces, if tab characters were illegal in indentation -- making invisible changes significant is just begging for trouble.


Yes, I'd say that tabs should not be allowed in any indentation that a compiler will recognize as relevant to the block definition, regardless of language. I realize Python doesn't do that, and I consider that a mistake, but one that hasn't bit me yet.

 
On the other hand, for the belt-and-suspenders folks, I like the idea of a compiler switch that warns when your indentation is inconsistent with the location of your braces. I'd use it, if it were available.


As would I.
 

As for the argument that the IDE will do all the work, I don't use one. Even if I did, I want to use a language that's easily understood even without an IDE. For example, it should be possible to read code examples in a printed book, or write snippets of code and send them in an email, without involving an IDE.


I agree.

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