Scala 3 significant indentation

No. The indentation syntax has always been called “optional braces” (by analogy with scala’s existing optional semicolons support): https://dotty.epfl.ch/docs/reference/other-new-features/indentation.html

I think the name “optional braces” is a bit misleading, because it might be read as making all braces optional. But actually, the proposal only makes some braces optional, while other braces are still required.

I’d be willing to endorse the rubric “some optional braces”, if we also advertised “some optional semi-colons”, because not all semis are optional. Depending, as some wise person must have said, on context.

2 Likes

Oh ok thanks, I guess I missed that. In that case what’s the long-term plan or motivation for this experiment? Is it that if i works out well and is favoured for many years, that braces might go away in 4.0 or something? Is the long-term vision whitespace default, braces optional like it will in 3.0+ and then one day the Scala stops calling it experimental? Is it literally just an experiment to see where it leads, no long-term vision in mind? Maybe it’s just me but I’d appreciate a bit more context to understand this better.

4 Likes

Yes, maybe “Sometimes optional semicolons” is more accurate.

On the other hand, it is different in practical terms. Your example with the +17 is a bit strained, because the +17 serves no purpose.

In my code, I’m not sure if I have even a single semicolon, but there are plenty of places that cannot be written without braces, for example I have methods that look like this:

def m(f: A => B)(g: C => D): R = ...

and then are typically called like this:

val result = m { a =>
...
}{ c =>
...
}

and as far as I know, the above call cannot be written without braces.

I guess they can do the recursive Fibonacci numbers in CS 101 without braces, but I don’t think that should be the standard.

3 Likes

Braces would never go away, just like they never went away in Haskell and just like semicolons never went away in Scala. If the syntax is released as part of Scala 3 it won’t be experimental, it will be the default recommended way to do things.

1 Like

As the original proponent of a Scala whitespace-delimited syntax (https://github.com/lihaoyi/Scalite, circa 2014), I agree with @curoli that the standard that needs to be reached is “zero required braces”.

To me, “sometimes optional braces” to me is significantly worse than “never optional braces”. Imagine if Scala code had a mix of required and non-required semi-colons, or if Python had a mix of indentation syntax and require curly braces. Either would be awful.

I don’t even think it would be that hard to get to “zero required braces”. For example, my original Scalite prototype handles this as such:

val result = m do a =>
...
do c =>
...
}

Where the do keyword is a stand-in to open a block in all scenarios, which is closed on a decrease in indentation. You can look at the linked Scalite repo above to see many examples of it working.

Hang-ups over an arbitrary specific english meaning of do aside (that anyway doesn’t really apply to programming languages, e.g. haskell or coffeescript), having a specific, unambiguous indentation-block-start delimiter has a very large number of advantages. As a bonus do is currently an almost-unused keyword, and any existing usages of do{...}while(...) can be mechanically substituted with while({...; ...})(); (it looks even prettier with indentation syntax, as Scalite shows).

do could also be in addition to :, rather than replacing it. If we’re ok with having multiple keywords open indentation-based blocks in difference scenarios, adding another one to elegantly handle the multi-line lambda scenario doesn’t seem like a big deal.

4 Likes

With -Yindent-colons you can write this as

val result = m:
  a =>
    ...
:
  c =>
    ...

As long as there is an option to turn off this feature and maintain good ol’ bruce syntax, I don’t see a problem here. Well, as long as there’s a no-brainer way/tool to convert from one syntax to another. Copy-pasting code is still very useful.

Speaking of indentation, scalafmt and codebase migrations, it’s just so happen that at my current place of employment, we wish to move to scalafamt. Alas, most of our code has a tab size of 4 spaces, and scalafmt doesn’t support anything other than 2 spaces. This is intentional “as it is recommended in official Scala guide”.

I would hate it if we end up with a significant-indentation oriented tooling and ecosystem without enough support to maintain the current syntax.

3 Likes

Just my two cents. I tried optional braces syntax, and to my suprise, I really like it. I think it’s due to the combination of:

  • higher “signal-to-noise” ratio
  • saves a line with single }, allowing for more compact vertical formatting
  • { and } are a bit clunky to type (on a Norwegian keyboard)

Isn’t this exactly the same for optional semicolons? (There are places where you need them, unless you change the layout of the code.) Yet, we still call them optional semicolons.

2 Likes

As long as there is an option to turn off this feature and maintain good ol’ bruce syntax, I don’t see a problem here.

I do : introducing new people to scala.

lets start with the basics: scope, so a scope is defined by indentation, unless the project you are working on has disabled it so make sure to check the build config. Oh and of course as you navigate through the source code of libraries which the project use you might encounter brace using libraries in particular in scala 2 which doesn’t support significant whitespace notation. Also the current convention is to use braces here and here and here but not use braces here and here and oh yeah there is this : variant you may encounter once in a while but that’s not really used much outside of this specific part of the library ecosystem so you will be just fine.

And I can imagine project switching from one model to the other as a maintainer change leaving half the code using braces and the other half using significant whitespace.

Isn’t this exactly the same for optional semicolons?

Semicolon usage in existing codebases is almost zero except for extreme conciseness and I have yet to encounter someone actively defending using semicolons everywhere.

My personnal preference is for braces but I woud still take brace-less significant whitespace over a configurable mix of both without thinking twice.

3 Likes

Great, there is a possibility to write such code without braces. But at what cost?

  • Scala 3 now has at least three different syntaxes to be picked from via compiler options? That’s absolutely horrible.

  • It also horrifies me that all those type ascriptions where the type goes to a new line look like blocks now.

  • And note that the braceless version of my example actually has more lines and a line with a lonely colon. I thought the argument against brace syntax was that we want to save lines by avoiding lines with lonely close-braces?

So, we are looking for the best block start marker. Should it be colon? Or do? Come on, there is one block start marker that every programmer immediately understands, and it is free and unambiguous: open-brace. {.

That close-braces by convention take up a whole line on their own bothers me, too. But that could be solved by simply changing the convention.

7 Likes

Don’t forget <code> :smile:

Sounds like optional closing braces solves all problems.

If in all cases where changing the layout would mean you can remove the braces, calling them optional would be less controversial, I’m sure.

1 Like

Indeed.

But, the biggest mistake in my opinion was inherited by Scala and that was putting the opening brace at the end of the previous line. In my view this was a syntactic abomination. If the opening brace was at the beginning of the first line of the block and the closing brace at the end of the last line of the block then the braces wouldn’t add to file length.

I suspect the costs of optional braces will prove high, as the costs of option semi colons were not inconsiderable, leaving us at least for a while with the ugly compromise of hanging operators. Maybe I’m at fault but I’m still not clear what the specification for the compiler continuing a statement / expression vs starting a new one is.

I feel part of the problem in this debate (or lack of debate) is not acknowledging the importance of aesthetic. its totally reasonable that we as programmers care about the syntactic aesthetic of our code. That we don’t need to justify our aesthetic preferences, purely by reference to performative claims of comprehensibility, space, error rates, etc. Virtually all of us here give a large part of out lives to coding. so its not unreasonable that we should care about the presentation of our creations.

I can understand that some people really want to code using (much greater) significant white space and are willing to pay a significant cost to enable that, but I feel that can lead them to underplay those costs. I am willing to take some things on trust. Notably the Scala dot calculus. I’m willing to trust that this allows testing of type system soundness. When it comes to syntax, I see no evidence for trust in the soundness of the syntax overall.

2 Likes

I suspect very few Scala programmers would be willing to give up optional semicolons though.

I also don’t really understand the sudden obsession with file length (as in line count) in this thread. Sorry but you’ll never convince me that less lines is always better. Definitely not if your motivating example is

def foo =
  {...
  ...
  ...}

By the way, every Scala program can be written without a single newline…

6 Likes

Most of these points should have been raised, discussed, and addressed in an SIP before significant effort was put into implementing it. They were not because there was no SIP, which is the core problem. It’s been almost a year since these concerns were last raised, so what @odersky is working on now isn’t really relevant. We appreciate the work he’s doing, we’re annoyed at how this has been handled, both these things are true.

Now we’re in a situation where, not only has significant work been put into a feature that can be charitably called “incomplete”, but it’s having cascading impacts on other features, like “asless givens” - a term that I originally misread, causing quite a chuckle, so my thanks for that :smile:.

I don’t particularly like significant whitespace, however I would still be very uncomfortable if something I liked was handled the way this has been.

2 Likes

I prefer this:

def foo = {
// empty line
  ...
  ...
}

And that’s why I like what @RichType said:

its totally reasonable that we as programmers care about the syntactic aesthetic of our code. That we don’t need to justify our aesthetic preferences, purely by reference to performative claims of comprehensibility, space, error rates, etc.

With sufficient enough tooling, most styles could be enforced (in a given codebase). I’m not sure what’s the effort estimation for this kind of tooling though.

3 Likes