What should the snowman be? (Proposal renaming)

[jgravelle-google]

In the talk at the CG Meeting the idea of :snowman:-bindings was proposed, with the intention being that it was a new as-yet-unnamed thing.

What should we name it? We need to name the proposal itself, the new types we're specifying, the operators the convert to+from wasm types and :snowman: types, and the set of values that can produce. A reasonable naming scheme fits the pattern of x-bindings, x-types, x-operators, and x-values.

One option is to call the proposal wasm-bindings, and then have binding-types, binding-operators, and binding-values. A problem here is that referring to "binding" is ambiguous, the term isn't precise enough to disambiguate from a binding expression, to the stubs an engine would generate between modules, to the verb of the act of binding itself. This proposal is potentially very abstract, and having concrete names for the components of it should facilitate discussion.

An idea that @lukewagner came up with offline was "WebAssembly External Bindings" for the proposal itself. This implies "external binding [types|operators|values]". This is precise, but verbose. For ease of communication, I think we can abbreviate that in most contexts to EBTypes, EBOperators, and EBValues.

Are there naming considerations I'm missing? Wildly better naming ideas?

[binji]

First thing that pops into my mind: https://en.wikipedia.org/wiki/E._B._Farnum

Yes, I did watch the Deadwood Movie recently, why do you ask?

[ttraenkler]

I find simple, self-explanatory names helpful that facilitate understanding and spreading the idea. Developers I talk to about Webassembly have a hard time following, even language experts.

From my perspective the gist of this proposal is a standard to convert or adapt the interface of one module, that is using a (language, compiler, ...) specific standard to another using a different standard.

What about module interface adapter (for short just adapter)? The model I have in mind is a plug adapter, which adapts/maps/translates/converts between two interface standards.

[sendilkumarn]

External Binding is (~) precise. If you feel name is longer we can also call it ExBind.

[sunfishcode]

X-Bindings. With X-Types, X-Operators, and X-Values. X for eXternal 😎.

[PoignardAzur]

I'm partial to OCAP bindings.

[jgravelle-google]

X-Bindings. With X-Types, X-Operators, and X-Values. X for eXternal 😎.

I'm... kind of legitimately okay with this. X for eXternal is almost identical to EB for External Bindings. It's a less awkward abbreviation. One less syllable to pronounce.

... Also this might be the 90s kid in me but it's X-tremely cool. 😎

Could also go with ExBindings/ExTypes/ExOperators if we wanted to be slightly less edgy. Though it does remind me of Windows-style APIs (e.g. GetVersionEx)

[lukewagner]

X seems a bit too mysterious or experimental-sound to my ear. E.g., for a while all the experimental HTTP Response headers were X-prefixed.

[fgmccabe]

I am experimenting (sic) with the term "Web Interoperability Bindings". With associated concepts of "Web Interoperability Interface Definition Language".

On Tue, Jul 16, 2019 at 4:29 PM Luke Wagner notifications@github.com wrote:

X seems a bit too mysterious or experimental-sound to my ear. E.g., for a while all the experimental HTTP Response headers https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers were X- prefixed.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/WebAssembly/webidl-bindings/issues/47?email_source=notifications&email_token=AAQAXUBQ2OXCPCRMHOZMFN3P7ZKUBA5CNFSM4IAGZ4U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2CRYEY#issuecomment-512039955, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQAXUBMV7P7T4Z3U2KSINLP7ZKUBANCNFSM4IAGZ4UQ .

-- Francis McCabe SWE

[Hywan]

I also sometimes call them WebAssembly Boundary Bindings, instead of External Bindings. A boundary can be crossed in both ways (with incoming or outgoing values), whilst “External” refers to the outer world without the notion of going outside or inside. Also it clearly expressed the “borders” of a Wasm module, and can represent all usages of bindings: From module to host, or from module to module.

I would not be in favor of “X-…” (x-bindings, x-types, x-operators) since X is too vague.

Wasm Boundary Bindings can be shorten to b-bindings, b-types, b-operators, where “b” can mean boundary or bindings (or beta, which is classy: β-types, β-operators, β-bindings).

Thoughts?

[fgmccabe]

I kind of like boundary; it speaks to the most salient aspect of this work. Would be open to a shorter noun.

On Wed, Jul 17, 2019 at 2:23 AM Ivan Enderlin notifications@github.com wrote:

I also sometimes call them WebAssembly Boundary Bindings, instead of External Bindings. A boundary can be crossed in both ways (with incoming or outgoing values), whilst “External” refers to the outer world without the notion of going outside or inside. Also it clearly expressed the “borders” of a Wasm module, and can represent all usages of bindings: From module to host, or from module to module.

I would not be in favor of “X-…” (x-bindings, x-types, x-operators) since X is too vague.

Wasm Boundary Bindings can be shorten to b-bindings, b-types, b-operators, where “b” can mean boundary or bindings (or beta, which is classy: β-types, β-operators, β-bindings).

Thoughts?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/WebAssembly/webidl-bindings/issues/47?email_source=notifications&email_token=AAQAXUCXNQBP77LZC7DDXSDP73QHPA5CNFSM4IAGZ4U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2DS4VQ#issuecomment-512175702, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQAXUHM4ZP3632S62KTNNDP73QHPANCNFSM4IAGZ4UQ .

-- Francis McCabe SWE

[tlively]

SNO (shared-nothing object) bindings ❄️

[KronicDeth]

@tlively I suggested ❄️ bindings to @lukewagner at the in-person too because it looks really close, but not exactly like 🕸. Just like how these are really close, but not exactly WebIDL bindings. Also, now I just find it funny if we get an emoji character in the name of a standard.

[titzer]

+1 for a real name here. I have been confused for weeks as to what the heck the snowman is for. (finally had it explained to me--snowman is more real than a strawman ??)

[tlively]

To be clear, I don't think the snowflake emoji should be part of the name. The names would be SNO-bindings, SNO-types, SNO-operators, and SNO-values. The advantage is that it is a meaningful acronym and maintains a bit of history. It also invokes an image of a snowflake, which describes the structure of the bindings.

Or if that's too cute, how about "edge bindings". Edge is a nice monosyllable that sounds similar to "X" but actually describes what these are all about without backronyming anything.

[binji]

Why don't we call it "Web And Shared-nothing Module Bindings" or wasm-bindings for short. :clown_face:

[jgravelle-google]

I like boundary but it's too long. Edge has a similar connotation. The notion of having an abbreviation probably helps decouple the length from the precision. β is really classy, though maybe harder to type. But I do like β-bindings better than b-bindings or B-bindings. I don't think it clashes with the idea of lambda calculus' β-reductions?

FWIW another thing that's neat about X is the "cross" reading (e.g. "railroad X-ing"), so we have cross-module bindings, or x-module bindings, or x-bindings.

On the topic of naming and shared-nothing-linking, I've been using the term SNL (pronounced "snail", emoji'd :snail: ) for a Shared-Nothing-Library (e.g. zlib.snl, ala zlib.dll). I don't know if we want to bake the shared-nothing connotation in to the overall proposal, because there still is space for the host-binding use (although conceptually it's still share-nothing). I've been holding off on trying to push the name SNL because 1) connotations of slow (can be overridden by connotations of a protective shell?), and 2) maybe a better name comes up after we pin down the proposal's name.

[PoignardAzur]

or wasm-bindings for short

Web-Enhanced Bindings Administering Shared-State-Enabling Module Binary Linking for You.

[ttraenkler]

module interface bindings?

[PoignardAzur]

Names considered so far (and their abbreviation):

• snowperson-bindings (☃)
• wasm-bindings
• external-bindings (x, ex)
• boundary-bindings (b, β)
• shared-nothing-object-bindings (sno, ❄)
• edge-bindings (e)
• module-bindings (m)

Personally, I am very much in favor of having an ASCII-compatible abbreviation. Emojis are fun and all until you want to type the name 15 times on a keyboard without copy-pasting it every time.

I like edge bindings and module bindings in particular; they're short, non-pretentious, and describe the intended purpose well enough.

[ttraenkler]

module bindings communicate best imho

[sendilkumarn]

Let us vote 🗳

👀 - snowperson-bindings (☃) 🚀 - wasm-bindings ❤️ - ex-bindings | x-bindings (External Bindings) 😕 - boundary-bindings (b, β) 🎉 - shared-nothing-object-bindings (sno, ❄) 😄 - edge-bindings (e) 👍 - module-bindings (m)

Note: the emoji is ordered reversely and has no connection with the expression provided against the name. (I did not use 👎 for obvious reason)

[lukewagner]

Based on some feedback and discussion with @rossberg, it seems like a root problem here is that "binding" is just too overloaded a term, and that's why none of these prospsective ☃ sound right. In particular, "binding" classically refers to both:

• mapping of names to values or locations (e.g., in JS)
• currying (e.g., in JS, func.bind(x))

Taking a step back, the proposal fundamentally does two things:

• Define a new set of high-level types that can only be used at interface boundaries
• Define how a wasm module can adapt its interface to use these new types

Based on this and after discussion with my co-champion and others at the last meeting, we'd like to rename the proposal to WebAssembly Interface Types (along with the name of the new set of types being introduced), and use the word adapter to replace "binding" elsewhere. To help visualize how all the concepts are now named, I created this diagram. If this sits well, I'll take the action item to turn the diagram into an SVG and update the explainer to reflect the new terminology and scope (as presented at the last CG f2f).

[ttraenkler]

More precisely this proposal seems to be about the module interface boundary as interfaces internal to a module (functions neither imported nor exported) are out of scope if I understand correctly. It will communicate the idea more clearly if we use the term module explicitly.

[Hywan]

@lukewagner During my holidays, I had a very similar thought. I'm happy with the new naming!

[Hywan]

Should we also update the custom section name from webidl-bindings to interface-types, or something?

[lukewagner]

Great to hear! I think definitely the custom section name should change. In general, the explainer needs to be more-or-less rewritten to take into account a number changes (including naming) in the design since it was originally written, and to also synchronize it with the more-formal spec we've started writing.

[pchickey]

Closed as resolved.