5 ms·

I can't help myself, the required semicolon at the end of each line in Dart programs keep hurting after writing for many years in Python, JS, Kotlin and Swift.

I can't help myself, the required semicolon at the end of each line in Dart programs keep hurting after writing for many years in Python, JS, Kotlin and Swift. I grew up semicolon-less with QBasic and learned semicolon since Delphi 1.0 and Java 1.0 but today, wanting as few noise on the screen as possible, they are hurting in my eyes.

seanmcdirmid 7y ago
Semicolons are just extra signal to humans and compilers, they shouldn’t hurt eyes like the use of fixed width fonts do.
- jakear 7y ago
  It’s not that they hurt the eyes for me as much as they introduce tons of micro delays and extra keystrokes when editing. For instance, any “X to end of line” (cut, copy, etc), you now need to think about what the destination is and whether you should include the semi, change the selection, go back and delete the semi later, etc. It sounds slight, but it really builds up over time. Once you get used to “powerediting” without them it’s hard to go back.
  - seanmcdirmid 7y ago
    End of line inference algorithms are incredibly fragile, both by the compiler and by the human reader, having a semi-colon can make things clearer in the absence of another secondary signal (like indentation). There are so many type errors in scala or typescript that can be solved by adding a semicolon somewhere to eliminate some idiotic ambiguity.
    - tom_ 7y ago
      Why not infer the end of a line when finding the end of a line? ;) This is what most BASICs and assemblers did. (I think QBasic had a line continuation character? - or maybe that came with Visual BASIC. I don't remember. But, anyway, if you wanted, it was possible to continue a source line past a line break, it just wasn't the default.)
      - seanmcdirmid 7y ago
        I’m all for that option also, and we can always add an anti semi colon to write a multi line statement.
    - jackewiehose 7y ago
      Only-EOL like python is fine and always-semicolon like C is fine. Sometimes-optional but sometimes-required semicolon like Javascript is bad in my experience. Javascripts C-like syntax doesn't cope well with missing semicolons
    - saagarjha 7y ago
      > End of line inference algorithms are incredibly fragile I am working on a language right now with optional semicolons (that is, newlines terminate statements unless there is a semicolon, which does the same early) and it’s not really that hard. The only change is that instead of looking for a newline character for statement termination I often also need to look for a semicolon.
      - jakear 7y ago
        I think the issue is more when the new line doesn’t terminate the statement. Like in JS: const a = doThing() (() => throw Error)
        saagarjha 7y ago
        JavaScript for some reason chose a very strange way to have its newlines work; a number of other languages have it figured out: Swift, for example.
      - lioeters 7y ago
        > newlines terminate statements unless there is a semicolon, which does the same early Since I'm writing a toy language with optional semicolons, I'm curious - how are you solving ambiguities in multi-line expressions? For example: 1 -1 Does your language not allow multi-line expressions, treating the above as two statements? Or, perhaps they must be explicitly an expression, like: (1 -1) I agree with you on another comment, that JavaScript's automatic semicolon insertion is complicated - so I'd like know if there's a sensible solution for languages without semicolons.
        jakear 7y ago
        Python behaves "sensibly" with regard to this. Semicolons are statement breaks. Endlines are statement breaks, unless theres some reason for them not to be, such as being in a open brace state.
        saagarjha 7y ago
        In this language, there's very few multi-line expressions. However, for your specific case: yes, I would consider that two statements. 1 - 1 would be one: putting a binary operator by itself in one line would cause the parser to keep looking.
munificent 7y ago
I'm the author of the post and work on the Dart language. I spent a bunch of time last year trying to figure out a good way to make semicolons optional in Dart without breaking a lot of stuff. Because of a handful of syntax quirks particular to Dart, it's really difficult. Most other languages that have optional semicolons were designed from the start to make them optional. Dart was not. On top of that it: * Uses C-style variable declarations which means there's no keyword to indicate the start of a variable declaration. * Likewise uses C syntax for function and even local function declarations. Again no keyword marking the beginning of a function. * Has complex syntax for things like function types which means a type annotation can be arbitarily long and may split over multiple lines. * Has lots of "contextual keywords" that are not true reserved words but behave like them only in certain contexts. * Has a rich syntax that overloads a lot of tokens to mean different things in different contexts. "{}" can be an empty map, empty set, empty block, empty function body, or empty lambda body. All of that makes optional semicolons just really difficult. I haven't given up entirely. We have a thing now called "language versioning" that lets different Dart libraries target different specific versions of the language. That lets us evolve the language in nominally "breaking" ways without actually breaking existing code. (For example, this is how we will migrate the world to non-nullable types.) That may give us a way to make other grammar simplifications that would then also let us make semicolons optional. But syntax changes like this are always difficult. People have very strong opinions about you changing their existing syntax under them, and the value proposition in return isn't super compelling. There's an old saying, the best time to plant a tree is twenty years ago. The second best time is today. Language syntax isn't always like that because the migration cost once you have a lot of extant code (and users) can just be too painful. The best time to make semicolons optional was twenty years ago. The next best time may be today, but it may just be never.
- chubot 7y ago
  Could Dart use this solution, which Python uses and Oil shell now uses? 1. Newlines are significant tokens and they behave like semicolons (this is how shell is) 2. Within () [] {}, newlines are suppressed. The lexer has to recognize the matching pairs. (Oil added an expression language to shell which does this) This means that var x = 1 + 2 is not valid because there's a statement terminator after +, but var x = f(1 + 2) is valid. I feel like this captures the fast majority of cases where you want to break a statement over lines. I don't know Dart, but since it seems to have JavaScript-like syntax, I don't see why that wouldn't work? JavaScript has some weird rules, the common gotcha seems to be is: return { } // oops this does not return a dictionary like I thought With those rules you would write: return { } and hopefully the former is a syntax error, not a mis-parsed program. ---- edit: OK my guess is that Dart probably doesn't want to enforce a brace style like Go (and Oil) do? That is in Go only if (x) { } is valid, rather than if (x) { } which is pretty much like the 'return' example. I have been using that brace style for so long that I forgot other people don't :)
pansa2 7y ago
There are benefits to unambiguously marking the end of each statement with a semicolon rather than just using a newline. Is there a good algorithm for determining whether or not a newline actually represents the end of a statement? JavaScript gets this wrong in both directions, sometimes unexpectedly ending a statement (e.g. in `return \n 0`) and sometimes unexpectedly not ending one (e.g. when a new line begins with an open-parenthesis). Python's method (newline always ends a statement unless it's inside (), [] or {}) is straightforward, but makes the language syntax strictly line-based. This matches Python's significant indentation, but can it work in a language without it? Another option I've seen is for all newlines to end statements, unless they follow a token that cannot end a statement. Unfortunately that means that the following two assignments have different behavior: foo = bar + baz foo = bar + baz The first is a sum, the second only assigns `bar`, followed by a standalone unary `+` expression. Go works this way, but considers the second form to be an error ("+baz evaluated but not used"). Python considers both of these to be errors.
- throwaway_pdp09 7y ago
  > There are benefits to... True, and these kinds of bikeshedding discussions about tiny details are infuriating because they're so irrelevant. I wish we could all rise above them to discuss the next level of expressibility. We let the little stuff suck up so much of or time.

seanmcdirmid 7y ago

Semicolons are just extra signal to humans and compilers, they shouldn’t hurt eyes like the use of fixed width fonts do.

jakear 7y ago
It’s not that they hurt the eyes for me as much as they introduce tons of micro delays and extra keystrokes when editing. For instance, any “X to end of line” (cut, copy, etc), you now need to think about what the destination is and whether you should include the semi, change the selection, go back and delete the semi later, etc. It sounds slight, but it really builds up over time. Once you get used to “powerediting” without them it’s hard to go back.
- seanmcdirmid 7y ago
  End of line inference algorithms are incredibly fragile, both by the compiler and by the human reader, having a semi-colon can make things clearer in the absence of another secondary signal (like indentation). There are so many type errors in scala or typescript that can be solved by adding a semicolon somewhere to eliminate some idiotic ambiguity.
  - tom_ 7y ago
    Why not infer the end of a line when finding the end of a line? ;) This is what most BASICs and assemblers did. (I think QBasic had a line continuation character? - or maybe that came with Visual BASIC. I don't remember. But, anyway, if you wanted, it was possible to continue a source line past a line break, it just wasn't the default.)
    - seanmcdirmid 7y ago
      I’m all for that option also, and we can always add an anti semi colon to write a multi line statement.
  - jackewiehose 7y ago
    Only-EOL like python is fine and always-semicolon like C is fine. Sometimes-optional but sometimes-required semicolon like Javascript is bad in my experience. Javascripts C-like syntax doesn't cope well with missing semicolons
  - saagarjha 7y ago
    > End of line inference algorithms are incredibly fragile I am working on a language right now with optional semicolons (that is, newlines terminate statements unless there is a semicolon, which does the same early) and it’s not really that hard. The only change is that instead of looking for a newline character for statement termination I often also need to look for a semicolon.
    - jakear 7y ago
      I think the issue is more when the new line doesn’t terminate the statement. Like in JS: const a = doThing() (() => throw Error)
      - saagarjha 7y ago
        JavaScript for some reason chose a very strange way to have its newlines work; a number of other languages have it figured out: Swift, for example.
    - lioeters 7y ago
      > newlines terminate statements unless there is a semicolon, which does the same early Since I'm writing a toy language with optional semicolons, I'm curious - how are you solving ambiguities in multi-line expressions? For example: 1 -1 Does your language not allow multi-line expressions, treating the above as two statements? Or, perhaps they must be explicitly an expression, like: (1 -1) I agree with you on another comment, that JavaScript's automatic semicolon insertion is complicated - so I'd like know if there's a sensible solution for languages without semicolons.
      - jakear 7y ago
        Python behaves "sensibly" with regard to this. Semicolons are statement breaks. Endlines are statement breaks, unless theres some reason for them not to be, such as being in a open brace state.
      - saagarjha 7y ago
        In this language, there's very few multi-line expressions. However, for your specific case: yes, I would consider that two statements. 1 - 1 would be one: putting a binary operator by itself in one line would cause the parser to keep looking.

munificent 7y ago

I'm the author of the post and work on the Dart language. I spent a bunch of time last year trying to figure out a good way to make semicolons optional in Dart without breaking a lot of stuff. Because of a handful of syntax quirks particular to Dart, it's really difficult. Most other languages that have optional semicolons were designed from the start to make them optional. Dart was not. On top of that it: * Uses C-style variable declarations which means there's no keyword to indicate the start of a variable declaration. * Likewise uses C syntax for function and even local function declarations. Again no keyword marking the beginning of a function. * Has complex syntax for things like function types which means a type annotation can be arbitarily long and may split over multiple lines. * Has lots of "contextual keywords" that are not true reserved words but behave like them only in certain contexts. * Has a rich syntax that overloads a lot of tokens to mean different things in different contexts. "{}" can be an empty map, empty set, empty block, empty function body, or empty lambda body. All of that makes optional semicolons just really difficult. I haven't given up entirely. We have a thing now called "language versioning" that lets different Dart libraries target different specific versions of the language. That lets us evolve the language in nominally "breaking" ways without actually breaking existing code. (For example, this is how we will migrate the world to non-nullable types.) That may give us a way to make other grammar simplifications that would then also let us make semicolons optional. But syntax changes like this are always difficult. People have very strong opinions about you changing their existing syntax under them, and the value proposition in return isn't super compelling. There's an old saying, the best time to plant a tree is twenty years ago. The second best time is today. Language syntax isn't always like that because the migration cost once you have a lot of extant code (and users) can just be too painful. The best time to make semicolons optional was twenty years ago. The next best time may be today, but it may just be never.

chubot 7y ago
Could Dart use this solution, which Python uses and Oil shell now uses? 1. Newlines are significant tokens and they behave like semicolons (this is how shell is) 2. Within () [] {}, newlines are suppressed. The lexer has to recognize the matching pairs. (Oil added an expression language to shell which does this) This means that var x = 1 + 2 is not valid because there's a statement terminator after +, but var x = f(1 + 2) is valid. I feel like this captures the fast majority of cases where you want to break a statement over lines. I don't know Dart, but since it seems to have JavaScript-like syntax, I don't see why that wouldn't work? JavaScript has some weird rules, the common gotcha seems to be is: return { } // oops this does not return a dictionary like I thought With those rules you would write: return { } and hopefully the former is a syntax error, not a mis-parsed program. ---- edit: OK my guess is that Dart probably doesn't want to enforce a brace style like Go (and Oil) do? That is in Go only if (x) { } is valid, rather than if (x) { } which is pretty much like the 'return' example. I have been using that brace style for so long that I forgot other people don't :)

pansa2 7y ago

There are benefits to unambiguously marking the end of each statement with a semicolon rather than just using a newline. Is there a good algorithm for determining whether or not a newline actually represents the end of a statement? JavaScript gets this wrong in both directions, sometimes unexpectedly ending a statement (e.g. in `return \n 0`) and sometimes unexpectedly not ending one (e.g. when a new line begins with an open-parenthesis). Python's method (newline always ends a statement unless it's inside (), [] or {}) is straightforward, but makes the language syntax strictly line-based. This matches Python's significant indentation, but can it work in a language without it? Another option I've seen is for all newlines to end statements, unless they follow a token that cannot end a statement. Unfortunately that means that the following two assignments have different behavior: foo = bar + baz foo = bar + baz The first is a sum, the second only assigns `bar`, followed by a standalone unary `+` expression. Go works this way, but considers the second form to be an error ("+baz evaluated but not used"). Python considers both of these to be errors.

throwaway_pdp09 7y ago
> There are benefits to... True, and these kinds of bikeshedding discussions about tiny details are infuriating because they're so irrelevant. I wish we could all rise above them to discuss the next level of expressibility. We let the little stuff suck up so much of or time.