Update AstSemantics.md

[titzer]

This is mostly some wordsmithing on AstSemantics.md and a bit of moving some sentences to a more logical flow.

[sunfishcode]

Polyfill considerations were specifically moved out to a separate document.

[titzer]

On Thu, Jun 18, 2015 at 3:58 PM, Dan Gohman notifications@github.com
wrote:

In AstSemantics.md
#200 (comment):

@@ -198,12 +200,11 @@ is why it isn't the specified default.)

Out of bounds

-The ideal semantics is for out-of-bounds accesses to trap. A module may
-optionally define that "out of bounds" includes low-memory accesses.
+The ideal semantics is for out-of-bounds accesses to trap, but the performance
+implications and ability to polyfill to JS are not yet fully clear.

Polyfill considerations were specifically moved out to a separate document
http://Polyfill.md.

That's fine. It just read funny previously. "The ideal semantics is for
XXX." And then a bulleted list of other potential things, leaving the
reader wondering why. Thus, a one sentence justification.

—
Reply to this email directly or view it on GitHub
https://github.com/WebAssembly/design/pull/200/files#r32787666.

[sunfishcode]

I agree. I think your rewording is fine if you take out "and ability to polyfill to JS".

[titzer]

On Thu, Jun 18, 2015 at 7:08 PM, Dan Gohman notifications@github.com
wrote:

In AstSemantics.md
#200 (comment):

@@ -198,12 +200,11 @@ is why it isn't the specified default.)

Out of bounds

-The ideal semantics is for out-of-bounds accesses to trap. A module may
-optionally define that "out of bounds" includes low-memory accesses.
+The ideal semantics is for out-of-bounds accesses to trap, but the performance
+implications and ability to polyfill to JS are not yet fully clear.

I agree. I think your rewording is fine if you take out "and ability to
polyfill to JS".

Done.

—
Reply to this email directly or view it on GitHub
https://github.com/WebAssembly/design/pull/200/files#r32796589.

[sunfishcode]

lgtm

[jfbastien]

Could you explain why there's a division between statement/expression, but functions only have a single statement? Explaining that there's a division, but just on statement doesn't contribute much explanation IMO.

[kg]

Do we even need a division between statements and expressions in the first place? It might be a nice simplification for our only polymorphic-ish node type to be the expression, and in cases where an expression yields no meaningful value we can just define it to have a void type (since functions can already have a void type anyway.)

Most of the things I can think of where the statement/expression difference would matter are JS/source language things that are erased by the time you encode down to wasm.

[titzer]

On Fri, Jun 19, 2015 at 11:28 AM, Katelyn Gadd notifications@github.com
wrote:

In AstSemantics.md
#200 (comment):

@@ -1,28 +1,31 @@

Abstract Syntax Tree Semantics

-The Abstract Syntax Tree (AST) has a basic division between statements and
-expressions. Expressions are typed; validation consists of simple, bottom-up,
-O(1) type checking.
+WebAssembly code is represented as an abstract syntax tree
+that has a basic division between statements and
+expressions. Each function body consists of exactly one statement.

Do we even need a division between statements and expressions in the first
place? It might be a nice simplification for our only polymorphic-ish node
type to be the expression, and in cases where an expression yields no
meaningful value we can just define it to have a void type (since functions
can already have a void type anyway.)

Good question. In my decoder it's tempting to just allow an expression be
the entire body of a function, and with the comma operator, one can
basically express a list of imperative statements followed by a
value-producing expression. But early returns, breaks, continues, etc. kind
of mess up the works. It'd be weird to allow them to be expressions, and
forcing producers to rewrite early returns to a block + break may be
inconvenient.

Most of the things I can think of where the statement/expression
difference would matter are JS/source language things that are erased by
the time you encode down to wasm.

—
Reply to this email directly or view it on GitHub
https://github.com/WebAssembly/design/pull/200/files#r32814070.

[jfbastien]

lgtm

[qwertie]

Yes, if possible I think all executable code (if not more of the system) should be expression-based. But what about control flow? I haven't thought much about it but

• Each function is just a single expression.
• If void (unit, ()) is understood as a proper data type, then if and do_while can be seen as expressions that return void, and if-else can be seen as equivalent to the conditional operator ?:
• forever can be seen as an expression whose arguments are the statements inside the loop, and break could include a 'return value', which will be the value of an enclosing forever loop.
• Under this idea, return is not needed; return values mid-function can be simulated by enclosing the function in a forever that uses break to specify the return value.

[titzer]

What about continue? If's with one branch? What about discarding the value of a side-effecting expression or call?

While there is an attractive elegance to making everything an expression, the analogy gets strained in imperative-style code which is prevalent in the Algol branch of languages (C, C++, Java, JavaScript, C#, etc). We could bridge the gap with "void" or "unit" type that is the result of expressions that don't have a normal return value, which would otherwise be statements, I think this will result in a lot of confusion and an "impedance mismatch" for the very popular languages while giving on a very marginal benefit to much less popular functional languages. In short, it doesn't serve either master well.

[titzer]

Since this PR is mostly wordsmithing and not changing semantics, I'll merge this later today if there are no objections.

[qwertie]

@titzer: continue simply returns to an earlier location, so I don't see any problem with it. ifs with one branch would return void. Side effects can occur inside an expression, and the comma operator provides sequences. Everyone is already familiar with this effect in C, e.g. (x = y * y, (x += y) + 5). Discarding a value happens naturally whenever one operation (whose result you want to discard) is followed by any other operation. However if the operation whose result you want to discard is the last operation in a block, you have to add a dummy 'void': (foo(), bar(), void)

I would stress that merging statements and expressions into a single concept called 'expressions' seems to produce a strict superset of the current plan. I think it will be a simpler and more capable model than what is currently proposed, and it won't substantially alter code generation for the Algol branch of languages (if it turns out that it does, perhaps the language could be tweaked until it doesn't.) The translation to asm.js could be more complicated, admittedly, but remember that this is a short-term problem--we won't use a polyfill forever.

I am already accustomed to thinking this way, since I designed Enhanced C# as an expression-based language which is a strict superset of C#.

[titzer]

On Wed, Jun 24, 2015 at 5:54 PM, qwertie notifications@github.com wrote:

@titzer https://github.com/titzer: continue simply returns to an
earlier location, so I don't see any problem with it. ifs with one branch
would return void. Side effects can occur inside an expression, and the
comma operator provides sequences. Everyone is already familiar with this
effect in C, e.g. (x = y * y, (x += y) + 5)

I would stress that merging statements and expressions into a single
concept called 'expressions' seems to produce a strict superset of the
current plan. I think it will be a simpler and more capable model than what
is currently proposed, and it won't substantially alter code generation for
the Algol branch of languages.

I am already accustomed to thinking this way, since I designed Enhanced C#
as an expression-based language which is a strict superset of C#.

I've filed #223 for the
expression/statement discussion, since this PR is tailored toward simply
revising text.

—
Reply to this email directly or view it on GitHub
#200 (comment).