Clear up confusion about statements as expressions

[jemc]

Issue #440 was discussed in today's sync call. I mentioned there that I think it's least confusing to just avoid saying "these are not statements" while still saying positively that "these are all expressions".

Resolves #440.

[EpicEric]

Shouldn't the section title "Everything is an expression" also be changed?

[rhagenson]

The issue has not been resolved in my opinion. This PR addresses the immediate point of clarifying the language of "Everything is an expression" but it does not address the more widely reaching intent of the issue which was consistent clarity on the point of statement versus expression.

Sean had my thinking correct on Sync yesterday in that the issue was written from the point-of-view that (paraphrasing) "statements do not return values, expressions return values". I see no issue with the idea that expressions can be statements, but want clarity in the tutorial so that a new user can differentiate, for example, if as a statement and if as an expression. The only use case I can think of in my head for when this would matter during learning is when using an if block as the last expression in a function block and any resulting confusion on why that function is returning None (the implicit else return).

class A
  var value: I8

  new create() =>
    value = 0
  fun ref add1() =>
    value = value + 1
  fun get(): I8 =>
    if value == -1 then 
      value
    end

Playground link which shows the error in this code: https://playground.ponylang.io/?gist=a6302e798f6940cf8051c3160a59ae50

As a newcomer, I do not think it would be clear that the last expression/return here is the if block, not the value inside the if block.

Any rebuttals to having a clear expression/statement terminology along the lines of return value/no return value?

[jemc]

Basically, my thinking on this is to suggest that "all expressions are statements, but not all statements are expressions", with expressions being the subclass of statements that do have a result value.

I'm happy to retract this PR if you want to address this part of a text in a different way.

[rhagenson]

I take no issue with merging this PR as long as there is an understanding that I will review the expression/statement terminology usage across the Tutorial to meet our agreed upon understanding of their relation to one another being that one is a subclass of the other.

[jemc]

Sure, we can iterate as needed with whatever improvements you see fit.

[SeanTAllen]

We are going to merge this, Ryan if there are specifics you would like to improve further, please create an issue so we don't end up losing track of them.

[rhagenson]

Certainly can do. That was my intention if I reach another larger conversation point; otherwise I was going to make smaller edits for the other places I mentioned in the original issue to reflect our shared understanding of statement versus expression in the tutorial.