[HN Gopher] Design Note: Implicit Semicolons (2017)
___________________________________________________________________
Design Note: Implicit Semicolons (2017)
Author : tosh
Score : 18 points
Date : 2020-11-12 03:34 UTC (1 days ago)
(HTM) web link (www.craftinginterpreters.com)
(TXT) w3m dump (www.craftinginterpreters.com)
| klodolph wrote:
| I think _of the different approaches available_ you can make a
| language workable & convenient with (1) explicit semicolons,
| like C/Java (2) implicit semicolons, like JS/Go/Haskell and (3)
| no semicolons like Python/Lua. JS's specific implementation is
| definitely the odd one out, like the article says.
|
| One of the funny things about Go's automatic semicolons is that
| you can easily trip up gofmt if you type sloppy code and expect
| gofmt to clean it up for you. For example, let's say you type
| this: func foo() { if x < 3 {
| return 1 } return 2 }
|
| You think, "Oh, I missed the enter key when I was typing it but
| gofmt will fix it for me." No, it will not. Syntax error.
| beeforpork wrote:
| In my opinion, a little redundancy is good to avoid rockets
| falling out of the sky, so I vote for a layout rule plus
| redundant semicolons. The semicolon is hardwired in many
| programmers hands anyway. I don't think it should be a design
| goal to get rid of it. Instead, the compiler's/interpreter's job
| is to help the programmer to avoid bugs, and with a little
| syntactic redundancy, the parser can already help out with a few
| syntax errors. I love gcc's -Werror=misleading-indentation.
| melling wrote:
| I unhardwired myself using Swift.
|
| It is painful when I need to use them in another language.
|
| After coding for decades, I'm glad to have one less thing to
| type.
| secondcoming wrote:
| BASIC had the 'End' keyword instead of a delimiter.
| Forge36 wrote:
| VB6 used "End X", such as "End Function" and "End If"
| toolslive wrote:
| Semantics were different. End ended the program.
| https://www.c64-wiki.com/wiki/END
|
| Pascal however used BEGIN and END to denote the beginning and
| the end of blocks. Maybe your memory got garbled.
| bobbylarrybobby wrote:
| Given how capable our editors are today, it seems reasonable to
| both require semicolons at the end of statements and expect users
| to configure their editor/formatter to insert these semicolons
| for them wherever possible. The inability of the editor/formatter
| to automatically infer the locations of semicolons would be
| tantamount to a syntax error.
| Someone wrote:
| If your editor can do that, so could the compiler.
|
| So, why require them? The only reason I can think of would be
| readability, but I haven't seen a language where that is a
| serious concern (scala gets close with its "there must be a
| blank line here" at times)
|
| I think "no semicolons" nowadays is the option to go for.
| ketralnis wrote:
| > If your editor can do that, so could the compiler. So, why
| require them?
|
| So that there's a step in between where the human can check
| the result
| Rusky wrote:
| Editors can get away with things compilers can't- they are
| inherently interactive. If your editor gets it wrong, you can
| just fix it. If your compiler gets it wrong, you might get an
| error message, or weird behavior.
|
| This is, for example, a major philosophy behind Rust's well-
| regarded error messages. The compiler _rarely_ makes this
| kind of choice behind your back- instead, in reports an error
| message with a suggested fix-up for what it _thinks_ you mean
| (and editor integration can apply those automatically).
|
| Then the program source remains unambiguous and clear, there
| are fewer ways to confuse readers, but you still get all the
| benefits of "if your editor can do that, so could the
| compiler."
| sammorrowdrums wrote:
| Certainly in enjoy Prettier (in spite of its foibles) for JS
| because of this sort of stuff. It removes whole classes of lint
| errors and adds semi-colons and doesn't care how I format the
| code as I wrote it.
|
| Far too much thought and angst goes into things that should not
| need to be a concern. I used to feel more dubious about such
| tools, but after gofmt I tried Prettier and always use it now.
|
| It's just one more bit of cognitive load that is gone. Indeed,
| if it doesn't reformat my code as expected I know I've made an
| error, so it's even quicker for me at noticing some bugs than
| ESLint messages which are already pretty excellent these days.
| klodolph wrote:
| I agree. I have autoformatting turned on for everything and I
| just don't care what my code looks like because it's
| consistent and I can get used to it.
|
| I used to spend time configuring formatting settings to be
| exactly right, but nowadays I'm moving towards defaults.
|
| My only problem with gofmt is that since Go standardized on
| tabs, I've encountered problems with noisy commits because
| people rewrap comments, and the comments will wrap
| differently depending on the individual's tab width setting.
| toolslive wrote:
| you don't semicolons, but they can be handy. One way of looking
| at them is as an infix operator (a monad if you want).
|
| Another remark is that Python parsing can be hard as a single
| newline can actually end multiple blocks. Lexers are not designed
| to have a single char denote multiple tokens.
___________________________________________________________________
(page generated 2020-11-13 23:01 UTC)