Scala: Consider syntax with significant indentation

Having just moved to my first Scala team, I would really really not like this to be in the language. Given 5 ways to do something, a large organization is going do something all 5 ways.

Scala is a fun language, but consistency is not one of its ecosystem's strengths.

Grain of salt: again, I'm new to Scala, but I'd hate to think of it as a language that can only be good once you're Stockholm'd.

In a previous project I spent a lot of time thinking about significant indentation (http://akkartik.name/post/wart), so I'm glad to see it getting more mind-share. However, the end comments are absolutely insane. Here's a counter-proposal: if you want optional end delimiters, make them not look like comments. Then the relevant examples in OP would look like this:

  def f =
    def g =
      ...
      (long code sequence)
      ...
  end f  // optional

  while
    println("z")
    true
  do
    println("x")
    println("y")
  end while  // optional

  package p with
    object o with
      class C extends Object
                 with Serializable with
        val x = new C with
            def y = 3

        val result =
          if x == x then
            println("yes")
            true
          else
            println("no")
            false
      end C  // optional
    end o  // you guessed it: optional

Folks commenting on the willingness to make breaking changes in 'Scala' should note that this is Dotty, an upcoming very eventual breaking replacement for Scala (think Python 3 or perhaps even Perl 6 but less radical than the latter).

For now, to quote the authors, it's a: 'Research platform for new language concepts and compiler technologies for Scala'

So this is exactly the right place to test this sort of concept.

I use Scala as my primary development language since 2010. My first reaction to this change was "well, this is the end of it" -- as I can't read or write anything in Python because of that.

But I looked more carefully and the proposal is more balanced. It looks more like Haskell than Python -- and Haskell's syntax is one of the best ever invented, in my opinion (too bad I am not yet that smart to casually emit production-grade Haskell code).

So, I'm fine with that.

Lovely thread to read, these guys are so analytical, well mannered and mutually respectful. Each comment is well thought, constructive, detailed, clear and down to the point. But most of all they are proof reading before submitting. I don't do it all the times.

I spent two or three years heavily using Scala. During that time, I more than once got to the point where I literally couldn't casually read code I'd written less than a week before.

This seems like yet another great way to make that worse.

1. If you're going to make indentation significant, implement it in a way that makes tab/space confusion impossible. Python 2.7 does this. The check for indent ambiguity between two strings is:

- Remove the common leading whitespace of both strings.

- The remaining parts of both strings must be all tabs, all spaces, or empty.

This is the least restrictive rule which catches all indent ambiguities.

2. Indent-based syntax is great for imperative languages, but not so good for functional languages with very long expressions. It's not clear how to indent stuff like "a.b(x).c(y).d.e(z)", where a-e x-z may be long expressions. In LISP, the all-parenthesis syntax was so simple, and so hard for humans to parse without help, that indentation was nailed into EMACS and everybody did it that way. The indentation wasn't significant, but it was standardized.

Here's word wrap in Rust:

    s.lines()
            .map(|bline| UnicodeSegmentation::graphemes(bline, true)    // yields vec of graphemes (&str)
                .collect::<Vec<&str>>())
            .map(|line| wordwrapline(&line, maxline, maxword))
            .collect::<Vec<String>>()        
    .join("\n") 

One advantage of significant whitespace is that it may enable a very concise (G)ADT notation:

    enum Tree[T]
      Branch(t: Tree[T])
      Leaf(t: T)

    sealed trait Tree[T]
    case class Branch(t: Tree[T]) extends Tree[T]
    case class Leaf(t: T) extends Tree[T]

I have to say I don't know of any other language where the maintainers have such a cavalier attitude towards making breaking changes. It makes the common analogy between Scala and C++ a bit ironic.

Not that that's necessarily a bad thing; it's good to have some popular languages that follow a less conservative approach, if only to get some real-world experience with different strategies for dealing with the tradeoffs between keeping a language modern and maintaining backwards compatibility with legacy code.

I thought Scala was supposed to be following a route where the amount of "stuff" they include is getting reduced?

The language is idiosyncratic and multiparadigm enough as it is, I'd say.

Reminds me of the difference between JavaScript and CoffeeScript.

CoffeeScript attempts to become more concise by removing delimiters and making things more implicit. I don't think that actually adds much value.

In a sense, it was the equivalent of trying to simplify traffic by removing lane delimiters and street signaling. You could somehow imagine they're there, but it's better if you can see them.

The one significant effect of indentation-based syntax is that it makes copy-pasting code from places like books or Stack Overflow somewhat harder and error prone. I've been hit by this few times when learning Python, I can imagine it would cause some frustration for Scala users too.

I'm working on a text editor that automatically formats the code, it will have trouble with significant whitespace if the code is valid both with and without white-space, and even compiles, and even runs with or without, although with a possible hidden bug. I've never worked with a language with significant whitespace so I'm wondering, does it create bugs!? In my experience, bad formatting can cause bugs, or is annoying, eg. syntax errors like "missing bracket" and you got no idea where it's missing, which is why my editor does the indentation automatically and enforce it (you can't change it).

A non-backwards compatible syntax would lower the barrier to all breaking changes.

Language spec [1], replacing the standard library [2], etc.

[1] Disallow implicit conversions between unrelated types https://github.com/lampepfl/dotty/pull/2060

[2] Remove parallel collections from scala-library https://github.com/scala/scala/pull/5603

This is a big change to make to an existing language. Even if you really, really, really like indentation-based syntax, I doubt that the benefit of the new syntax would match the cost of change.

The benefit being...? Making it more complex?

I love scala, but scala already has some of the more confusing syntactic decisions, not sure if this is gonna help.

What does the literature say?

Is it known (as in quantitatively) if significant indentation is a good thing, or a bad thing?

The key flaw with indentation comes when you try to use it with printing. If your function extends across a page-break, such as in a book or a printout, it is not possible to resolve the indentation by eye.

Just no.

Sigh. Why are the people with the worst ideas most vocal about it?

If you like significant invisible characters, use Python. No need to introduce this into other languages.