Comments (7)
On Thu, Nov 19, 2015 at 7:19 PM, jcbeyler [email protected] wrote:
When reading the design document, I saw two things:
A) The if, br, br_if, case, and return constructs do not yield values.
B) A case node consists of an expression
Now, when looking at the testsuite, I saw this:
labels.wast contains:
(case $0 (i32.const 5))Which seems to go against (A).
And:
(case $3 (set_local $j (i32.sub (i32.const 0) (get_local $i))) (br 0))which seems to go against (B) if we are pedantic that an expression is
different to a list of expressions.My questions are the following:
A) should we fix this in the design or the spec?
B) should we fix this in the design or the spec?I can do both if you wish (though again my Ocaml is a bit rusty but I can
try :)); I just would need to know what we want for each. My thoughts are:A) I like that case can return a value, I think there are little gains to
not doing it and forcing a br thereCases can't return values, except the last one, because we've defined
fall-through semantics.B) I think that a case should respect the design document and only have
one expression, if you want to have more complex things, add a block nodeCase is already defined to take a single subexpression.
Opinions?
—
Reply to this email directly or view it on GitHub
#186.
from spec.
On Thu, Nov 19, 2015 at 7:19 PM, jcbeyler [email protected] wrote:
When reading the design document, I saw two things:
A) The if, br, br_if, case, and return constructs do not yield values.
That is true; they don't produce a value that flows to the enclosing
expression. For br and br_if, the value flows to the exit point of the
block or loop which they reference. For return, the value flows out of
(i.e. is returned by) the function. If cannot produce a value since it only
has one arm (i.e. no else clause).B) A case node consists of an expression
Now, when looking at the testsuite, I saw this:
labels.wast contains:
(case $0 (i32.const 5))Which seems to go against (A).
And:
(case $3 (set_local $j (i32.sub (i32.const 0) (get_local $i))) (br 0))which seems to go against (B) if we are pedantic that an expression is
different to a list of expressions.My questions are the following:
A) should we fix this in the design or the spec?
B) should we fix this in the design or the spec?I can do both if you wish (though again my Ocaml is a bit rusty but I can
try :)); I just would need to know what we want for each. My thoughts are:A) I like that case can return a value, I think there are little gains to
not doing it and forcing a br there
B) I think that a case should respect the design document and only have
one expression, if you want to have more complex things, add a block nodeOpinions?
—
Reply to this email directly or view it on GitHub
#186.
from spec.
Ok for (A) then but I still have a problem with:
(case $3 (set_local $j (i32.sub (i32.const 0) (get_local $i))) (br 0))
which has two subexpressions (This is from switch.wast).
I also have another issue (also from switch.wast):
(tableswitch $l (i32.const 0)
(table (br $l)) (case $default)
(case $default (set_local $x (i32.add (get_local $x) (i32.const 1))))
)
(tableswitch $l (i32.const 1)
(table (case $0)) (br $l)
(case $0 (set_local $x (i32.add (get_local $x) (i32.const 2))))
)
This code defines twice the label $l. Should this be allowed?
from spec.
On Thu, Nov 19, 2015 at 9:19 PM, jcbeyler [email protected] wrote:
Ok for (A) then but I still have a problem with:
(case $3 (set_local $j (i32.sub (i32.const 0) (get_local $i))) (br 0))
which has two subexpressions (This is from switch.wast).
I also have another issue (also from switch.wast):
(tableswitch $l (i32.const 0)
(table (br $l)) (case $default)
(case $default (set_local $x (i32.add (get_local $x) (i32.const 1))))
)
(tableswitch $l (i32.const 1)
(table (case $0)) (br $l)
(case $0 (set_local $x (i32.add (get_local $x) (i32.const 2))))
)This code defines twice the label $l. Should this be allowed?
Labels are always scoped to be only referencable from their children, so
yes, this is valid.—
Reply to this email directly or view it on GitHub
#186 (comment).
from spec.
Ok for (A) then but I still have a problem with:
(case $3 (set_local $j (i32.sub (i32.const 0) (get_local $i))) (br 0))
which has two subexpressions (This is from switch.wast).
There were a few cases of control operators where it wasn't super clear from the design doc at the time whether they should allow sequences of expressions, or whether explicit blocks should be required. So I opted on the side of allowing implicit blocks as sugar in most cases; of those, loop
, case
, and func
still remain.
Should we make them all unary? It would be a simplification.
from spec.
I think I don't mind, it just is another small inconsistency between the design doc and the spec repo.
I think being consistent just makes more sense and putting block won't change much but at least will be explicit, no?
On the other hand, I could argue that we can just imply that loop, case, and func just start with an unmentioned block.
This issue is simply to state an inconsistent state that we should rectifty: either put in the design document that there is an implicit block for these three cases, or we do the opposite and fix the testsuite and spec.
from spec.
Obsoleted by br_table.
from spec.
Related Issues (20)
- test case `as-load-operand` have an error HOT 1
- branching on function name HOT 7
- [interpreter] Source locations are broken since menhir switch HOT 2
- SIMD test optimization? HOT 3
- [core] SIMD Compare instructions link to the wrong "execution"/"validation" sections HOT 1
- Add a note indicating that section ids and section ordering do not correspond HOT 2
- Missing ability to access built older versions of the WebAssembly specification in archivable form HOT 2
- [JS API] 'run a host function' and 'create a host function' don't consistently handle completion records HOT 1
- Wording of README in proposals directory is misleading. HOT 6
- Test extreme alignments HOT 2
- Tests seem to cause side effects that other tests depend on HOT 2
- A question about max table size HOT 5
- Time to delete the old `master` branches? HOT 5
- Missing LICENSE file in the document directory HOT 1
- A question about the order of exports HOT 4
- [bikeshed] Some potential issues in js-api spec HOT 1
- [js-api] Bikeshed issues on wasm-3.0 branch HOT 2
- Fix CSS so the specification shows on narrow viewports without horizontal scrolling. HOT 7
- Possibly incorrect encoding in WAST->JS conversion for elem.wast in wasm-3.0 branch HOT 2
- [reference-types] behavior of out-of-bound in table.fill HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spec.