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

[Stephen Horne]

On Wed, 5 Mar 2003 17:11:57 +0100, Thomas Wouters <thomas at xs4all.net>
wrote:

>On Wed, Mar 05, 2003 at 02:45:53PM +0000, Stephen Horne wrote:
>
>> 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
>
>> 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.
>
>Well, you can add whitespace between the statement and the newline... does
>that make whitespace an 'optional terminator' too ? :-)

Nope - you can add whitespace anywhere, not just after a statement. If
the semicolon is there you know the statement has ended.

> It might seem as a
>silly semantic issue, but there is definately a difference between a ';' in
>C and Perl et al, and in Python.

Absolutely - no argument there.

> I see the final ';' above more as a
>consistency feature (which is important in Python, at least to me.) And
>having an "optional terminator" is just silly, it either terminates or it
>doesn't, and if it's optional it doesn't really terminate :)

Not really - it means you can spell 'end-of-statement' three ways - a
semicolon on its own, a NEWLINE on its own, or a semicolon followed by
a NEWLINE. It's optional in the sense that there are other choices.

The last of those three choices is pretty pointless, of course, but it
does no harm.

>No, sorry. In C, the semicolon is a terminator, not a separator. For
>instance:

Yes - my mistake, as explained elsewhere.

>  i++
>  +j;

Though this is irrelevant as you have no separator *or* terminator,
and no-one was proposing that the compiler should mind-read to
separate one statement from another.

When I was saying that optionalness of the semicolon makes the
difference between separation and termination, I was saying that
(forgive me if my Pascal is rusty) the following are equally clear...

  { example 1 - termination }
  begin
    a := b;
    c := d;
  end

  { example 2 - separation }
  begin
    a := b;
    c := d
  end

Note that there is always a semicolon between the 'a := b' and the 'c
:= d' because this is how Pascal knows it is dealing with two separate
statements, but when the 'end' terminates the block the semicolon can
(depending on the language) be considered redundant.

>I've seen worse. One project I'm involved in had a function to open a
>directory and read the entries looking for all files fulfilling a requirement.
>As usual, it skipped files with leading dots. However, something must have
>gone wrong, because the entire function was #if 0'd out, and replaced by a
>function that popen()'d a perl process to do exactly the same thing. Now
>this wasn't a terribly frequent operation, but still frequent enough for me
>to be scared about executing perl each time :) So I tried to figure out what
>was wrong with the disabled, pure C code, and found it after a single pass
>of indent. This was the code before the indent:
>
>    if (line[0] == '.');
>        continue;

<big grin>

The trouble with this is that the semicolon is often DELIBERATELY used
to terminate a block structure early like that. Not with if, but often
with while or for.

A fairly common would be something like...

  void strcpy_alike (char *p_Dest, char *p_Src)
  {
    while ((*p_Dest++ = *p_Src++) != 0);
  }

<loud retching noises>

Anyway, newbies can see things like this and start thinking that the
'while (condition)' is a kind of statement in itself, and think it
always needs a semicolon - and the compiler is, of course, perfectly
happy with this!

>I've heard maybe one compelling reason not to use indentation,
>embedding code into other markup

There is this, to a point. But at the end of the day, source code is
for people to read and write.

>No, an alternative to solve the problem that would otherwise be solved by
>not making indentation mark blocks. E.g. issues with embedding the code into
>other markup. I would rather solve that in the embedding than in the
>language.

I see - I think I mentioned having a library for manipulating source
(and preserving intended semantics) in another post somewhere, so this
does make sense to me.

>Just look at how strained the ternary operator
>proposals all look; the idea comes from C and Perl (for many people, at
>least) and so the tendency is to make the syntax look like C -- and all
>other syntactic suggestions look odd. (Or is that just me ? :)

In my mindset, I like unary (prefix or postfix) and binary (infix)
operators. Outside of that, I start getting nervous - I prefer more
function-like syntaxes even if there is shortcircuiting, and I
certainly want a leading keyword to tell me that a conditional
operator is coming.

The C ternary operator always seemed somehow wrong to me anyway.

I still haven't voted on PEP308 because I'm having some trouble
picking. One near-favorite is...

  if c then x else y

...though that still falls foul of the 'no more than binary' rule.

The other is something like...

  select ( c1 : x, c2 : y, z )

...or even just...

  if (c, x, y)

... but I don't think any of those is an official option anyway, so
they're *very* unlikely to win.

I've seen languages where no operators could shortcircuit, and I've
seen plenty of languages where functions use lazy evaluation. In
Python, I'd be surprised if the expression '0 * x' was shortcircuited
even though it uses an operator and the right-hand-side is redundant.
Therefore, in my view, the idea that function calls imply no
shortcircuiting whereas operators imply shortcircuiting is simply
wrong.

But yes, you are right - even the options that I like feel strange in
one way or another. Only the if function seems completely natural
(because I've used it so much in spreadsheets, mainly - and yes, they
shortcircuit it), but that annoys quite a few others.

-- 
steve at ninereeds dot fsnet dot co dot uk