-
-
Notifications
You must be signed in to change notification settings - Fork 667
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support labeled statements #2889
Comments
If it's decided to move ahead with this, I was curious and had some ideas and questions I've been digging into the codebase around parser, complier and how AST implementation looks like when I came across this issue and wanted to see if the potential implementation approaches make sense:
and some followup questions: Thanks. |
That's funny, I've also encounter this when implementing a parser. I do know that in some code-bases, like the Linux kernel, they use labeled statements to avoid having to execute certain instructions for performance reasons. For example to jump directly to the error handling logic or return statement. However you need full Maybe AssemblyScript can reinterpret an if statement with the function example() {
if (true) break ending;
ending: console.log('LOL')
} But I don't know the further implications of this hack or even claim this is a good idea, just an idea I had when thinking about this issue. |
I would love to see this implemented. Would help solve a lot of my headaches with https://github.com/JairusSW/as-json The support is there--built into wasm itself, so it shouldn't be that hard to get a POC going |
In theory, it is not so hard to do it. |
You can probably just do this right now, with the disadvantage of requiring you wrap the code in a block: export function example(): void {
do {
console.log("Hey")
if (true) break;
console.log("skipped")
} while (0)
console.log('LOL')
} I don't think adding more syntax differences between AS and JS is a good idea. As an aside: in JS, you can use a labeled block and a labeled break instead of the As for labeled statements...there's probably enough infrastructure to support labeled breaks in the |
This requires an additional field to Flow that maps user-defined statement labels to the internal Binaryen labels passed to module.br(). Thanks to the existing logic to handle unlabeled break/continue, adding support for labeled break/continue is a breeze. Fixes AssemblyScript#2889.
This requires an additional field to Flow that maps user-defined statement labels to the internal Binaryen labels passed to module.br(). Thanks to the existing logic to handle unlabeled break/continue, adding support for labeled break/continue is a breeze. Fixes AssemblyScript#2889.
This requires an additional field to Flow that maps user-defined statement labels to the internal Binaryen labels passed to module.br(). Thanks to the existing logic to handle unlabeled break/continue, adding support for labeled break/continue is a breeze. Fixes AssemblyScript#2889.
This requires an additional field to Flow that maps user-defined statement labels to the internal Binaryen labels passed to module.br(). Thanks to the existing logic to handle unlabeled break/continue, adding support for labeled break/continue is a breeze. Fixes AssemblyScript#2889.
Feature suggestion
Labeled statements can come in handy when implementing complex control flow with multiple nested loops and if statements.
Currently parser will complain
The text was updated successfully, but these errors were encountered: