Waffling (was Re: single-line terinary operators considered harmful)

[Stephen Horne]

On Wed, 5 Mar 2003 12:43:05 +0100, Thomas Wouters <thomas at xs4all.net>
wrote:

>On Wed, Mar 05, 2003 at 11:06:46AM +0000, Stephen Horne wrote:
>> just as Guido kept ';' as an optional statement terminator.
>
>';' is more of a statement separator than a terminator. From the Grammar
>file:
>
>simple_stmt: small_stmt (';' small_stmt)* [';'] NEWLINE
>
>and it should really only be used to seperate small statements (literally :)

Hmmm - that final [';'] looks like an optional terminator, even for
the final statement in the line, to me ;-) Of course, I really
wouldn't expect to see it used.

Once it's optional, the separator-or-terminator distinction really
doesn't make much difference though. IIRC the semicolon is a separator
rather than a terminator even in C. For instance...

  if (condition)
  {
    statement;
    /* there is an implicit null statement here */
  }

... but it doesn't necessarily mean people *think* of it as a
separator e.g. they always put it at the end of the statement.

I remember an article about Ada, from back when it had the working
title of 'Green'. One of the famous algorithm guys (Dijkstra? - my
memory is straining) ripped apart their rationale for using
terminators rather than separators. They didn't change, though - and
he didn't make any particularly compelling argument for separators
that I remeber - he mostly just thought their rationale was bogus.

It was probably a little unfair, too. Ada was designed by committee,
and someone probably decided that every decision must have a written
rationale - a rationale like "it makes no real difference either way
so what the hell, I rolled I dice" probably wouldn't make it through a
review - unless it was late Friday afternoon after a pub lunch and
everyone wanted to get home early ;-)

In reality, most multilingual programmers aren't even aware that
semicolons are doing subtly different things in C and Ada.

>> I suspect that even Guido might be tempted if he were rewriting
>> Python, not so much to put an else on the same line but because a lot
>> of people complain about structuring by indentation from time to time.
>> Yes - there are even people (though emphatically NOT me) who see all
>> structuring by indentation as a wart.
>
>I somewhat doubt it.

Perhaps - I certainly doubt it would get into Python 3000 ;-)

> He may have other reasons for doing that (in the
>hypothetical case) but not because of people complaining about the whitespace.
>Allowing the use of braces while still enforcing indentation wouldn't seem
>too much of an improvement to those people

Proper indentation is good coding style in any block structured
language, whether it's enforced or not. Even where the compiler
doesn't use or enforce it, anyone who has to read or maintain your
source code is likely to bite your head off if the indentation is
confusing or misleading. I've seen cases where this almost literally
came true. Once or twice it was only the zits and greasy hair that
stopped me doing it myself ;-)

Yet the indentation issue is not just one that total newbie
programmers raise - experienced programmers sometimes raise it, and
some even continue to raise it when they are familiar with Python.

Some people really seem to miss the explicit '{' and '}' (or 'begin'
and 'end' or whatever). I've never quite understood why, but having
seen the debate run a couple of times I have accepted that to be a
failing of my imagination.

Maybe it's just familiarity - sometimes a surprisingly strong force.
For example, I kind of miss the '++' and '--' operators from C as a
convenient increment statement (though certainly not when used in
expressions), and I was very happy when '+=' and '-=' were added. But
the '*=', "/=", '&=', "|=" (and especially the "%=" and "**=") are
less frequently used and therefore less familiar, and sometimes seem
like a wart - even though they follow exactly the same principle.

I've usually been left with the feeling that there was a more
substantial point, though, even if I didn't quite get it.

>If I ever were to design my own language, I certainly would not use block
>delimiters unless I really really had to, and even then I'd try to find an
>alternative.

I'm not sure I understand what you mean by finding an alternative. An
alternative to '{' and '}'? Or a wider alternative avoiding any
explicit delimiting tokens, yet different to indentation?

If the former, I actually think ANSI BASIC has some nice features.
It's delimiters are almost full-fledged statements in themselves - for
example, a loop can optionally have either (or both) a precondition
and a postcondition using the same basic structure...

  do [while condition]
    ...
  loop [until condition]

This handles quite a few otherwise awkward cases without resorting to
'break', 'continue' or the Ada 'exit when condition;'.

Ada also has a nice feature in that you can say what you think your
ending (the procedure or function name, or just 'end while' or 'end
if') and the compiler checks whether you're right.

If you'd look for a non-delimiter solution, the only real alternative
I can think of is a continuation-based system - like using '\' to
continue statements over multiple lines. Which leads me to say -
"yuck!!!". I find multiline statements generally get that way by
containing big expressions, so I use extra brackets to avoid the '\' -
which brings us back, in principle, to delimiters!

Delimiters aren't really bad in principle, or else they wouldn't have
lasted this long in so many different languages. It's just that
indentation is usually even better - or else it wouldn't be considered
good style in languages that already require delimiters.

-- 
steve at ninereeds dot fsnet dot co dot uk