-
Notifications
You must be signed in to change notification settings - Fork 437
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
[document] First stab at specifying validation #445
Conversation
All rules are given in two *equivalent* forms: | ||
|
||
1. In *prose*, describing the meaning in intuitive form. | ||
2. In *formal notation*, describing the rule in mathematical form. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we discussed this, we agreed that formal notation would be placed in an appendix, rather than being used within the main document itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having spent some time scanning over this on a few occasions now, I think I really like this current interleaved formatting, for a few reasons:
- it seems easier to keep the two precisely coherent and spot discrepancies when they are juxtaposed
- as a future frequent user of this document, I'll definitely benefit from having the formal rules right next to bulleted explanation
- with the mini-tutorial given in conventions.html#formal-notation, I expect anyone not already familiar with the notation could pick it up by first observing the basic style and then learning by example from reading a few rules
- there's a pretty minimal impact on readability even if you just want to skip over it
- the interleaved heading / summary / notation / explanation form matches the "Structure" section which I also really like as is; in general, I think this is a good high-level style to use throughout the doc
IIRC, this also matches @dherman's recommendation last time we discussed this organizational question. Happy to have any comments from you too Dave.
* Fix tests to reflect new NaN semantics * Test that `select` and `if` return specific NaN bitpatterns.
Overall, lgtm. I'm expecting we'll iterate more as everything comes together. |
…mbly#445) Load lane and store lane instructions added in WebAssembly#350.
Please see test rendering on https://webassembly.github.io/spec/