

An Alternative Operator Precedence Rule (2013) - bootload
http://wall.org/~lewis/2013/10/25/whitespace-precedence.html

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

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

------
codeflo
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.

------
vidarh
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...](https://en.wikipedia.org/wiki/Whitespace_\(programming_language\))

~~~
DonHopkins
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](http://www.stroustrup.com/whitespace98.pdf)

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

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

~~~
vlaube
Interesting, kind of like a code style checker.

------
ajanuary
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)

~~~
nhaehnle
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.

------
to3m
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.

~~~
vidarh
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.

~~~
to3m
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.

~~~
vidarh
> 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.

~~~
to3m
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 ;)

------
iokanuon
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](http://nim-
lang.org/docs/manual.html#syntax-strong-spaces)

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

------
vorg
> 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.

------
teknopaul
Is that article for real, or trolling?

------
teknopaul


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

~~~
piokuc
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.

~~~
Retra
It already is syntactically significant. It separates tokens.

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

