Skip to content
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

branching on function name #1719

Open
zapashcanon opened this issue Jan 16, 2024 · 7 comments
Open

branching on function name #1719

zapashcanon opened this issue Jan 16, 2024 · 7 comments

Comments

@zapashcanon
Copy link
Contributor

Hi,

Consider the following module:

(module
  (func $f
    br $f)
  (start $f))

Running the interpreter gives:

$ wasm
label.wat:3.8-3.10: syntax error: unknown label  $f

Whereas the following module succeeds:

(module
  (func $f
    br 0)
  (start $f))

I'm wondering what was the reason for forbidding using the function name directly ?

@tlively
Copy link
Member

tlively commented Jan 22, 2024

The namespace of functions is different from the namespace of labels and (func $f ... only adds $f to the function namespace, not the label namespace. There is no way to give a label name to the top-level function scope AFAIK.

@zapashcanon
Copy link
Contributor Author

zapashcanon commented Jan 22, 2024

My question was rather if there was a reason to forbid it as I believe it should be easy to support (as I wrote an alternative semantics which allows it).

My understanding is that in the current semantics, nothing prevents it and only the text format support is missing.

I'm not familiar with the formal description of the text format but it seems it could be possible by adding a new label entry containing the function's identifier in this rule. I'm not sure to fully understand this rule for now so I may be wrong.

@tlively
Copy link
Member

tlively commented Jan 23, 2024

Yes, that's true. It would certainly be technically possible to extend the text format to allow the function name to be used as a label. Besides the fact that we don't have any other names that are usable in more than one namespace, I can't think of any other reason to forbid this. @rossberg, what do you think? This might be a nice quality of life improvement in the text format.

@rossberg
Copy link
Member

Yes, that would be relatively easy to add. It would even be a non-breaking change, since we allow shadowing of labels, so existing code like

(func $f (block $f ...))

would continue to be legal.

@tlively
Copy link
Member

tlively commented Jan 29, 2024

@rossberg, if we want to make this change, perhaps you can publicize it briefly at an upcoming CG meeting and then make the change via PR? I doubt anyone would insist on a more heavyweight process here.

@rossberg
Copy link
Member

Given that he proposed it, I'd suggest @zapashcanon also presents it. Happy to review a PR as well. :)

@zapashcanon
Copy link
Contributor Author

Fine with me for the CG meeting. I can do the PR for the interpreter, and I'll try my best for updating the semantics (the current format is not as easy to understand as spectec :-))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants