Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No Semicolons Needed

terts.dev

Post reply on HN
Print view View original

71–80 of 92 posts

Re: No Semicolons Needed

#71

Post by lelanthran »

xigoi wrote: post #66
lelanthran wrote: post #65

Earlier quoted context omitted.

Your example remains valid after the indentation is stripped, because it has markers to delineate the list and sub list items.

It doesn’t need to; that’s just the section numbering. In a biology textbook, you could have something like (made up names) Arabateciae Arabaticopoda Arabaticoquasicae Bidoroca Pseudobidoroca Superbidoroca Superduperbidoroca and the hierarchy is still clear.

No one is saying that indentation can not be used to display lists/sublists, I'm saying that markers remove ambiguity even across movement of blocks of texts.

Indentation is fragile.

Re: No Semicolons Needed

#73

Post by Blikkentrekker »

XorNot wrote: post #44
Blikkentrekker wrote: post #32

Earlier quoted context omitted.

The issue is that you find you very often want to break those roles. Python basically has `elif` because `else if` would make each branch nest one level deeper which isn't what one wants, except Python uses exceptions for flow control so you find yourself having to use `except ... try` as an analogue to `else if` but not `excetry` exists to do the same and stop the indentation. There are many other examples. It exist…

I'm very okay with elif though because it makes it clear that the conditional is part of the chained block and not a brand new one.

The issue is that it's a special case that acknowledges where there are cases where the indentation level it logically requires isn't what programmers find pleasant, there are many more, that just don't have that special case, so it forces indentation that's unpleasant and unintuitive.

Re: No Semicolons Needed

#74

Post by em-bee »

sheept wrote: post #8

> I would love to see a language try to implement a rule where only an indented line is considered part of the previous expression. Elm does this (so maybe Haskell too). For example x = "hello " ++ "world" y = "hello " ++ "world" -- problem

how to handle expressions that need more than two lines?

Re: No Semicolons Needed

#75

Post by notepad0x90 »

xigoi wrote: post #58
notepad0x90 wrote: post #52

Earlier quoted context omitted.

we don't even use indents that way in natural language. We use things like bullet points, we need specific markers. space is for spacing, tabs are for tabulation, they are not in any human language I know of used as terminators of statements. You know what is the equivalent of an indent or a semicolon in english? a period. We have paragraph breaks just like this to delimit blocks of english statements. A semi-colon i…

> we don't even use indents that way in natural language. Have you never seen a nested table of contents? 1. Introduction 2. Fruit 2.1 Apples 2.1.1 Red apples 2.1.2 Green apples 2.2 Oranges 3. Vegetables 3.1 Carrots

with apples in that list for example, you used '2.1' to indicate a new item, the space is cosmetic, the functional indicator is '2.1'

This wouldn't look right:

Introduction

  Fruit

    Apples

      Red apples

      Green apples
I'm sure you can work it out, but it doesn't feel natural, or ideal. (i can't get hn to format it without making it all one line so i used double new line).

Re: No Semicolons Needed

#76

Post by notepad0x90 »

xigoi wrote: post #66
lelanthran wrote: post #65

Earlier quoted context omitted.

Your example remains valid after the indentation is stripped, because it has markers to delineate the list and sub list items.

It doesn’t need to; that’s just the section numbering. In a biology textbook, you could have something like (made up names) Arabateciae Arabaticopoda Arabaticoquasicae Bidoroca Pseudobidoroca Superbidoroca Superduperbidoroca and the hierarchy is still clear.

it would look better still with a dash or a bullet point for every sub-entry. We're not arguing that it is possible to do that, we're arguing what is ideal for readability.

In that list you can naturally guess what that ordering is, but if the items were not so interrelated it can be confusing. if the top level item is 'Ham' and the indented item under it is 'sandwich' are you wrapping the same phrase 'Ham Sandwich' , because indentation (even in python) is used when wrapping lines, or is sandwich under ham as one of the things done with ham. it is thus error-prone and more confusing, clear and specific punctuation alongside indentation makes it easier to read.

Re: No Semicolons Needed

#78

Post by dfawcus »

Animats wrote: post #7

Classic mistakes in language design that have to be fixed later. - "We don't need any attributes", like "const" or "mut". This eventually gets retrofitted, as it was to C, but by then there is too much code without attributes in use. Defaulting to the less restrictive option gives trouble for decades. - "We don't need a Boolean type". Just use integers. This tends to give trouble if the language has either implicit c…

Attribute (qualifier), or storage class?

https://www.airs.com/blog/archives/428

The use of 'const' in C is very much a mixed blessing; I certainly have experience of the 'const poisoning' issue. Possibly it would have been better as a storage class.

For bool, yes it was a useful addition. Especially for the cases where old code would have something like:

    #define FLAG_A 1u
    #define FLAG_B 2u
    int has_flag_B (something *some) { return some->field & FLAG_B; }
and that was then combined with logic expecting 'true' to be 1; which could sneak in over time.

Re: No Semicolons Needed

#79

Post by estebank »

bmandale wrote: post #13

> I would love to see a language try to implement a rule where only an indented line is considered part of the previous expression. After python, it seems like every language decided that making parsing depend on indents was a bad idea. A shame, because humans pretty much only go by indents. An example I've frequently run into is where I forget a closing curly brace. The error is reported at the end of the file, and…

rustc does exactly that keeping the indent level of every unbalanced curly brace. It works OK, but it isn't perfect by any stretch. More heuristics are needed.

Re: No Semicolons Needed

#80

Post by estebank »

duped wrote: post #36
lightingthedark wrote: post #29

It's interesting seeing all of the different ways language designers have approached this problem. I have to say that my takeaway is that this seems like a pretty strong argument for explicit end of statements. There is enough complexity inherent in the code, adding more in order to avoid typing a semicolon doesn't seem like a worthwhile tradeoff. I'm definitely biased by my preferences though, which are that I can a…

Start from the perspective of the user seeing effectively: > error: expected the character ';' at this exact location The user wonders, "if the parser is smart enough to tell me this, why do I need to add it at all?" The answer to that question "it's annoying to write the code to handle this correctly" is thoroughly lazy and boring. "My parser generator requires the grammar to be LR(1)" is even lazier. Human language…

I used to hate semicolons. Then I started working in parser recovery for rustc. I now love semicolons.

Removing redundancy from syntax should be a non-goal, an anti-goal even. The more redundancy there is, the higher the likelihood of making a mistake while writing, but the higher the ability for humans and machines to understand the developer's intent unambiguously.

Having "flagposts" in the code lets people skim code ("I'm only looking at every pub fn") and the parser have a fighting chance of recovering ("found a parse error inside of a function def, consume everything until the first unmatched } which would correspond to the fn body start and mark the whole body as having failed parsing, let the rest of the compiler run"). Semicolons allow for that kind of recovery. And the same logic that you would use for automatic semicolon insertion can be used to tell the user where they forgot a semicolon. That way you get the ergonomics of writting code in a slightly less principled way while still being able to read principled code after you're done.

Post reply on HN