Rename `grow_memory` and `memory_size`?

[binji]

--bikeshed warning--

As discussed here, we will likely add a suite of new memory operations, mem.init, mem.clear, mem.copy, etc.

We could follow the current naming scheme and call these init_memory, clear_memory, copy_memory (or move_memory), but the mem. syntax is kind of nice, and mimics the style of other instructions. But then we have a bit of a naming wart with grow_memory and memory_size. Should we rename these to mem.grow and mem.size?

[eholk]

I like mem.grow and mem.size better, and I think it's more consistent with our other names, like i32.add.

Will many things break if we change it?

[binji]

The names are referenced in the spec, and exposed to users in the text format. Browser's debuggers display these names too.

But I'm guessing most things won't break because most users and tools don't consume or produce the text format.

[eholk]

I'm guessing it's not a huge problem. But, one option is to prefer `mem.size` and `mem.grow` as the canonical name, but continue to accept the current names as aliases.

…

On Mon, Dec 18, 2017 at 2:36 PM Ben Smith ***@***.***> wrote: The names are referenced in the spec <http://webassembly.github.io/spec/core/syntax/instructions.html#memory-instructions>, and exposed to users in the text format <http://webassembly.github.io/spec/core/text/instructions.html#memory-instructions>. Browser's debuggers display these names too. But I'm guessing most things won't break because most users and tools don't consume or produce the text format. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#627 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGdJnKfqt0-266y7HAPfRrLoJ-EnN_eks5tBuj-gaJpZM4RGAcS> .

[jfbastien]

While we're here: mem versus memory?

[binji]

I prefer mem, but memory is fine too.

[rossberg]

+1. If we do this before 1.0 is official we can get away with it.

FWIW, I also prefer mem.

[jfbastien]

What have we shortened in the spec, versus spelled out fully? I think we should be consistent and choose mem versus memory accordingly.

[rossberg]

@jfbastien, at least the core spec abbreviates to "mem" everywhere else.

[jfbastien]

In long names we have Memory, Table, Global, reinterpret, call_indirect, etc.

In shortened names we have varuint32, i32.const, eq / ne / lt / etc, clz, mul, div, rem, trunc.

So we've been quite inconsistent! I don't care which way we go, but we should be consistent. We spell it "Memory" in the current spec, I'd expect memory operations to be spelled the same, but we could decide that all ops need to be abbreviated while object need to be spelled out fully?

This is the tiniest of bikeshed anyways, I don't really care which way we go, but consistency seems missing and that's kind of embarrassing for a Standard (granted, we just accreted things over time and are just stamping them into the standard!).

[eholk]

It seems like we've had a preference towards long names on the JS side of things, where there seems to be more of a culture of that anyway. For the instruction names, we've tended more towards abbreviations where there are well-known ones, so `eq` for equal but not `rntrprt` for reinterpret. Assembly languages also have a long history of using abbreviations in their instructions. In the context of assembly instructions, `mem` should be perfectly recognizable, so it seems like going with `mem` over `memory` follows the general rule of using abbreviations where they are well known.

…

On Tue, Dec 19, 2017 at 9:04 AM JF Bastien ***@***.***> wrote: In long names we have Memory, Table, Global, reinterpret, call_indirect, etc. In shortened names we have varuint32, i32.const, eq / ne / lt / etc, clz, mul, div, rem, trunc. So we've been quite inconsistent! I don't care which way we go, but we should be consistent. We spell it "Memory" in the current spec, I'd expect memory operations to be spelled the same, but we could decide that all ops need to be abbreviated while object need to be spelled out fully? This is the tiniest of bikeshed anyways, I don't really care which way we go, but consistency seems missing and that's kind of embarrassing for a Standard (granted, we just accreted things over time and are just stamping them into the standard!). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#627 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGdJo0yJetmwsGDGYA4-7olOxRz1hYbks5tB-y1gaJpZM4RGAcS> .

[jfbastien]

In the context of assembly instructions, mem should be perfectly
recognizable, so it seems like going with mem over memory follows the
general rule of using abbreviations where they are well known.

Sure, but the text format already uses memory. Granted it's not an instruction. I think we shouldn't be inconsistent.

[eholk]

Good point. Also, the current instructions are `grow_memory` and `memory_size`, so in that light `memory.grow` and `memory.size` is closer to what we've been doing.

…

On Tue, Dec 19, 2017 at 10:32 AM JF Bastien ***@***.***> wrote: In the context of assembly instructions, mem should be perfectly recognizable, so it seems like going with mem over memory follows the general rule of using abbreviations where they are well known. Sure, but the text format already uses memory. Granted it's not an instruction. I think we shouldn't be inconsistent. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#627 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGdJmmAhySNp8eWKIuMltFMLnu82lGgks5tCAFAgaJpZM4RGAcS> .

[sunfishcode]

These names are also exposed to users in various tools; clang has an intrinsic function named __builtin_wasm_grow_memory, LLVM has @llvm.wasm.grow.memory, and Rust and others will likely expose them as well. These tools don't have to reflect the official names, but it's advantageous if they do. So there is value in resolving this sooner rather than later.

The only outstanding issue here is memory vs mem, with most people preferring mem. The arguments against mem are:

• consistency with "Memory" in the JS API
• consistency with the text format already using "memory"
• "memory" is what the current instructions use.

As a way to move forward, I propose observing:

• the text format already has func, a short name, in a similar role as mem (both have corresponding module index spaces), so there's consistency to be had there
• the rename is a text format change, so other text format changes may be considered at the same time
• the original names are being replaced, so they're not great examples for new names :-)

So the changes can be:

• mem.grow and mem.size.
• rename (memory ...) to (mem ...) in the text format to match
• tools may continue to accept the old names, as needed, for compatibility

How does this sound?