An Alternative Operator Precedence Rule (2013) | Hacker News Reader

An Alternative Operator Precedence Rule (2013)

wall.org

18 pointsbootload25 comments

A better rule is that hard-to-rememeber precedence rules should require brackets.

   a = b & 0xFF << 8; // Compilation error

   a = (b & 0xFF) << 8; // Compiles

This breaks down as soon as your expressions are slightly more complicated than single-letter variables:

    account.Balance -= order.Amount*order.Item.Price - order.Rebate;

is not readable at all, which is why many coding standards require whitespace around binary operators.

Overloading whitespace as syntax to avoid parentheses is truly twisted...

And I thought significant indentation was horrific enough...

Perhaps the author would appreciate the language Whitespace:

https://en.wikipedia.org/wiki/Whitespace_(programming_langua...

C++ has supported overloading whitespace since April 1, 1998.

    Generalizing Overloading for C++2000
    Bjarne Stroustrup
    AT&T Labs, Florham Park, NJ, USA

http://www.stroustrup.com/whitespace98.pdf

Compromise: use significant whitespace to detect precedence errors due to faulty assumptions.

    a+b * c
        ^ Warning: precedence/whitespace mismatch.

Interesting, kind of like a code style checker.

It breaks down as soon as you reach a single layer of nesting.

    (a + b) / ((c + d) * e)

would be (with pure whitespace)

    a+b  /  c+d * e

you'd probably end up mix-and-matching

    a+b / (c+d * e)

I would argue that your last version is actually the most readable. Obviously, opinions are going to differ as they always do, but my preference among your examples is 3 over 1 over 2 (I cannot imagine preferring 2, because the difference in whitespace amount is easy to miss at a glance).

There's bound to be some resistance and an "awkward feeling" at first, but this does seem like a nice suggestion.

Unfortunately, it's not a change that you can just apply to an existing programming language, but perhaps it would be reasonable to start by warning and eventually erroring where whitespace does not fit the existing precedence rules.

> It breaks down as soon as you reach a single layer of nesting

Then restrict it to a single nesting level, which aligns with the idea of making easy things easy (i.e. single-level precedence), and harder things possible (i.e. parens for more than two levels).

I liked this comment: ``Good programmers already pad looser operators more often than tighter operators.''. I liked it because I have never done this, and don't recall working with any code that does. Most I've seen is unary operators having no space, e.g., x + y * -z. (Though it's always possible I'm misremembering, of course. Naturally, good programmers know to just ignore the spaces, in case they're misleading.)

As time goes on, I imagine more and more text editors will format your code in a fixed way, making this sort of thing impractical anyway. Not just automatic indentation, I mean, but adding spaces in around operators and ensuring brackets are in the desired place and removing blank lines and so on.

GFA BASIC did this sort of thing on the Atari ST in the early 1990s, as did Visual BASIC, I think, in a few years later. Visual Studio has done this for C# since VS2008, more recent versions of Visual Studio will do this for C/C++ too, and there's a long tradition of command line-driven formatters for C-like languages that you could also use. Go's large - but not comprehensive - collection of features beginning with `g' includes gofmt, and I've no doubt Java IDEs will do this sort of thing for you too. And this autoformatting trend is bound to continue, because... well, why wouldn't it? But it does mean - if it's to be done properly, and in some way that won't mean you have to reach for regular expressions to search for even the simplest snippet - that you can't leave spacing decisions up to the programmer.

The only way you'll get enforced formatting to work across the board, is if the editor can safely roundtrip between the "official" format and the developers preferred format.

There's no round trip in the editors I've used. You have the standard formatting, and that's it. What you type in will get rearranged in situ so it's in the right format. If you prefer something else - well, good luck with that, because you can type it in, and it will compile, but you run the risk of somebody doing something that will cause the file to be reformatted and you'll end up with the standard layout anyway. Best get used to it now. (As I understand it, gofmt is very similar.)

This functionality is actually a benefit, because you can type in something like this:

    public Fred(int[]x):base(x){
    UpdateStuff();}

and the editor sorts it out, something like this:

    public Fred(int[] x)
        :base(x)
    {
        UpdateStuff();
    }

No need to wear out your space bar and/or Return key putting the formatting in. Visual Studio has got a fair idea of what sort of stuff might have been formatted thet way deliberately, too, so single-statement controlled statements won't get their own line by default, and when opening and closing braces are on the same line the code is left that way. It pretty much always just works. (C/C++ isn't quite as good - maybe 85% of the way there.)

I don't really have a problem with automatically making everybody's code look pretty much the same.

> There's no round trip in the editors I've used.

My point exactly. It's an incredibly hard problem.

> You have the standard formatting, and that's it.

Which is why I don't use any of those editors, and won't ever do so.

> This functionality is actually a benefit, because you can type in something like this:

Every editor I've used in the last 20-30 years or so has been able to do that, but none of them have forced me into a specific formatting that I can't override. That's the difference.

> I don't really have a problem with automatically making everybody's code look pretty much the same.

Well, I do, and enough people I've worked with do (EDIT: The issue is not making everybody's code the same; the issue is that I'm not willing to have a specific format dictated to me and so unless everyone will format their code like me I won't use tools that attempt to force a single style), and so any attempt to standardise tooling like that just ensures that environment/language has one more barrier against adoption. There's plenty of people like me that avoid Python "just" over significant indenting for example.

Well I did say that I expect fixed formatting will become more common over time. Having to press the space bar less is one reason. Discussions such as this one are another ;)

If someone wants to try it, the Nim language already has that implemented, you only need to enable it. The manual calls it "strong spaces".

http://nim-lang.org/docs/manual.html#syntax-strong-spaces

The article doesn't mention line breaks. I have no guess as to how a line break should be interpreted!

> The only situation I can see this being a real problem is with the combination of addition and multiplication, because people are taught that multiplication has tighter precedence than addition as early as elementary school.

A primary reason programming languages using infix ops and f(x) call notation are still more popular than lisp style syntax is because people learn these math notations at school. So doing anything to the syntax that requires people to learn something unusual short of turning it into s-expressions isn't a good idea.

Is that article for real, or trolling?

Deleted comment

Non-solution to non-issue. Just learn the precedence table, seriously.

This is all truly a non-issue if you program in a Lisp. You don't need any precedence table if you write S-expressions.

Seriously, making white space syntactically significant is a horrible idea.

It already is syntactically significant. It separates tokens.

Yeah, OK, but separating tokens is enough...

' FORTH /PostScript or

"Just don't make mistakes." ;(

Reply on news.ycombinator.com