-
Notifications
You must be signed in to change notification settings - Fork 21
Text format: new abbreviation for inline data? #29
Comments
Yes, makes a lot of sense to me. However, I think the syntax ought to be
Reason: The index type is part of the memory type, not the data. Inline data (or inline elem) only modifies the preceding syntax of memory (or table) definitions in so far that their limits are omitted. |
I agree that syntax would make more sense, but it would mean that a parser that doesn't expand abbreviations wouldn't know from looking at the idxtype token whether to parse a memtype or an idxtype followed by data. That's not a huge problem, but it is a little annoying. |
@tlively, I guess I'm willing to live with that small annoyance. :) The analogous shorthand for tables already works that way, although the order is different there, so the annoyance doesn't come up, I suppose. |
Switch order of load/store immediates in binary format
The current version of the spec already supports the syntax from this comment, and at least wasm-tools has implemented it. Also, I recall from a discussion with @tlively in Pittsburgh that naive expansion of abbreviations in the text format was already not viable because of existing things in the spec. Is there anything else to do on this issue or could it be closed? |
I'm happy to close it without adding an abbreviation if everyone else is happy to close it. @sbc100? |
Yes, I believe the syntax from #29 (comment) is already supported and tested in test/core/float_memory64.wast and test/core/memory64.wast. |
The current spec gives this abbreviation for specifying data inline in a memory definition:
The memory limits are inferred from the size of the data string. For back compat, this abbreviation needs to continue specifying a 32-bit memory, but should we add a similar abbreviation for 64-bit memories? As an example:
We could also choose not to provide such an abbreviation.
The text was updated successfully, but these errors were encountered: