Lambda the Ultimate

As for horizontal rules, I guess I would fall back on the philosophy of Smalltalk - which is that all messages have equal precedence. Introducing precedence into languages causes all sorts of complications - not to mention inconsistencies between built-in functions and user-defined functions.

Although some might argue that having precedence rules for math operators makes it more consistent with algebra, I'm not convinced that programs look (or even feel like) algebraic equations. Any time there is reason to even worry about operator precedence (or chaining), a judicious use of parenthesis is usually a better method of resolution.

Chris, I seem to remember you had something to do with RPG, how does that influence your views on this subject?!

The nice thing about indentation is that it groups together lines - it works a lot better when you have several lines all at the same indentation than it does when every line is at a different level. Adding spaces for precedence won't work because the spaces don't accumulate in the same way to give a strong visual effect.

I think it is crucial to distinguish language rules (syntax, semantics) from language use (this also relates to what I posted on 'empirical results').

The nice thing about identation, is that I can use it above the language sntax to clarify the code. This is style. The overall identation style should (naturaly) be uniform, but there may be cases where I might find it clearer to use specific layout clues to clarify a small part of the code.

This is even more true when it comes to horizontal spacing. If there are several related expressions, it amy be worthwhile to use layout to emphesize the connection.

    A:= B             + C;
    G:= F(B)          + F(C);
    H:= F1(B)+F2(B)   + F1(C)+F2(C);

Chris Rathman writes:
# I personally like languages that use the rule (Python, ML, Haskell) but I am a firm believer that tab characters should be stripped out of files.
Sure, at refuse tabs unless their size is precized (via command-line or a pragma in the code). Really the emacs mode should have (setq indent-tabs-mode nil)

# Introducing precedence into languages causes all sorts of complications - not to mention inconsistencies between built-in functions and user-definedfunctions.
Any good example of such inconsistencies?

As for me, i rather like operator priorities, otherwise i would lisp (non-)syntax ;p The operator priorities or kind of well defined and approximately the same in most languages. I'm kind of surprised when gcc tells me "suggest parentheses around && within ||". When will it starts saying "suggest parentheses around * within +" :'-(

[...]

Brian writes:
# Sugar is something I use on Scheme code to make it more legible.
kind of funny, the guy you wrote it seats 10m away from me :) He talked to me about it, and for sure i like it. Now if only there were something more than prefix operators...

[...]

andrew cooke writes:
# [This article never made it to the front page - was that intentional?]
nope, fixed.
# The nice thing about indentation is that it groups together lines - it works a lot better when you have several lines all at the same indentation than it does when every line is at a differentlevel. Adding spaces for precedence won't work because the spaces don't accumulate in the same wayto give a strong visual effect.
I agree that the visual effect is not as strong as for indentation.

[...]

# Struck me last night - spaces don't nest. So you couldn't replace nested parentheses with spaces (unless you started counting spaces - ouch!).
Of course it's one level only. But i still think the value of it is not null.

Ehud Lamm writes:
# This is even more true when it comes to horizontal spacing. If there are several related expressions, it amy be worthwhile to use layout to emphesize the connection.

A:= B             + C; 
G:= F(B)          + F(C); 
H:= F1(B)+F2(B)   + F1(C)+F2(C);

A:=B             + C;
G:=F(B)          + F(C);
H:=F1(B)+F2(B)   + F1(C)+F2(C);

? i think it would fool the reader. Just as 1+2 * 3 is strange and should NOT mean "1 + (2*3)".

To sum up, i think this horizontal layout stuff would lower the need to know the priorities of operators. This is not a "replace all parentheses" solution as the indentation grouping is for braces. This is only a neat solution for sub-expressions in a big one:

set_uposition(max(0, $X + ($Wi - $wi) / 2), max(0, $Y + ($He - $he) / 2))

set_uposition(max(0, $X + $Wi-$wi / 2), max(0, $Y + $He-$he / 2))

Is it less readable? less writable? less reliable? i think it helps them all!

Chris, I seem to remember you had something to do with RPG, how does that influence your views on this subject?!

One problem with RPG is that it has been changed dramatically over the years. RPGII code written on a System-36 was heavily reliant on the cycle and indicators. RPGIV code for the AS-400 is almost capable of generating structured programs. Problem is that most applications I saw had been developed over a span of 20 years and contained code written in many different styles based on the state of the RPG compiler at the time it was written.

It was not until RPG-ILE (post RPGIV) that IBM finally got around to doing a freer form compute syntax. So, in most of the RPG code you didn't mix add and multiply operations - they were assembly type instructions of ADD THISV THATV. The ILE syntax did introduce the capability to actually say THISV + THATV. Heck, it even introduced a module system.

Anyhow, RPG hasn't really influenced me along these lines so much as my experience with Smalltalk.