Statements as expressions [was Re: Undefined behaviour in C]

[BartC]

On 28/03/2016 01:54, Steven D'Aprano wrote:
> On Mon, 28 Mar 2016 03:58 am, BartC wrote:
>
>>> One of Guido's principles in designing Python was to keep it simple,
>>> even where that might mean people could make errors with it.  This part
>>> of the language is no different: any expression can be a statement.
>>
>> Yeah, but even simpler would be that any statement can also be an
>> expression! He didn't go that far though.
>
> People say that, but I don't believe it.

Well, some languages work like that. I think Lisp does. And so does the 
more 'normal'-looking Algol-68.

  What does it mean to say that any
> statement could also be an expression? If this statement is an expression:
>
>
> if condition:
>      print(1)
>      print(2)
> else:
>      print(3)
>      print(4)
>
>
> what value should it return? Justify your choice.

Each branch of the 'if-else' returns the value of the last 
statement/expression in each block. The if-statement as a whole returns 
one or the other.

Here, it might be the return value of print(); probably None.

> What should be the return value of this statement?
>
> while True:
>      x += 1
>      if condition: break

Many statements such as loops just returned 'void' in A68. The 
interesting statements were if, case-switch and block (where the value 
is that of the last statement/expression).

To make the best use of this, you really need a more free-format syntax 
than Python, and blocks need closure. A68 used the funny-looking 'fi' to 
close an if-statement, and 'od' for a loop:

  while c:=psource[n]; n+:=1; c!=etx do  ... od

  if c then a else b fi := 0      # also written (c|a|b):=0

  return case n in: 10,20,30 out: 90 esac

> I don't think that "every statement is an expression" is conceptually
> simpler at all. I think it is more difficult to understand. Nearly all
> human languages make a distinction between things and actions:
>
> * expressions return a value, which makes them a thing (noun);
>
> * statements do something, which makes them an action (verb).

Yet Python does allow any expression as a statement. Not even the 
potentially useful block statement, where you do x, y and z and then 
have a normal expression as its value.

And Python allows a for-loop inside a lisp-comprehension.

Python also has an if-else statement in the form of a conditional 
expression (which I won't show as I can never remember the syntax).

> It's easy to understand the concept of an expression where the result is
> dropped. "Hand me that hammer" and then you just drop the hammer on the
> floor.
>
> It's harder to understand the concept of functions (doing words, verbs) as
> values.

Huh? Functions do things then return results. Yet Python also allows 
procedure calls with no explicit return statement, to act as though they 
return a value:

  def p(): pass

  print (p())

It returns None, just like A68 uses 'void'.

So Python picks and chooses what it wants from the more general and 
conceptually simpler model of a language where expressions and 
statements are interchangeable. Python then is a little more complex 
because you have to consider what is allowed, and what isn't.

 >It's being a bit, what's the word
  "First class functions" take a bit of mental effort to understand,
> but the payoff it worth it.
>
> But it is even harder to understand what it might mean for a while loop to
> be a value, and the benefit of doing so seems significantly less than
> compelling. Maybe it is easier for non-English speakers with quite
> different linguistic models, but the benefit of adding statements as
> expressions seems to me to be well less than the extra difficulty it would
> produce.

(I've created several languages based on the Algol-68 model.

With more recent ones I've dropped that model, so that statements and 
expressions are different, and that is strictly enforced. This makes 
implementation simpler, and detects lots more errors.

The few statements that /were/ also useful as expressions, have 
separate, simplified, value-returning versions.)

-- 
Bartc