Statically rule out "weird" incoming binding expression about interface-types

[fgmccabe]

This structuring was already in mind.

…

On Fri, Jun 14, 2019 at 1:09 PM Alex Crichton ***@***.***> wrote: In a recent large refactoring <rustwasm/wasm-bindgen#1594> of wasm-bindgen I ended up writing what amounts to translating an incoming webidl binding expression to a JS shim. In doing so I found that some incoming binding expressions don't really make much sense, for example: (alloc-utf8-str "malloc" (alloc-utf8-str "malloc" (get 1))) or things like: (field "foo" (as i32 (get 1))) I was wondering if perhaps it'd be better to split incoming binding expression into two forms of expressions? One form of expression would be actually acquiring a value, and the second would be converting that value to WebAssembly. The idea here would be that while there's some bindings that are tree-like in reality each binding at the top level is a conversion from a value to wasm values, but once you get wasm values it seems odd to do more transformations that are otherwise expecting WebIDL-like values. A strawman proposal for this would be: *in-value-expr* Operator Immediates Children *get* idx *field* field‑idx *in‑value-expr* *in-expr* Operator Immediates Children *as* wasm‑type *in‑value-expr* *alloc‑utf8‑str* alloc‑func‑name *in‑value-expr* *alloc‑copy* alloc‑func‑name *in‑value-expr* *enum‑to‑i32* webidl‑type *in‑value-expr* *bind‑import* wasm‑type binding *in‑value-expr* — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQAXUHF2ROMOEIFZP3IIJLP2P3IHANCNFSM4HYMZSJA> .

-- Francis McCabe SWE

[lukewagner]

Yup, me too; I think this is the role of the type system in validating binding expressions.

[alexcrichton]

Oh sorry I should have clarified that my intention here wasn't necessarily to add more typechecking but moreso not rely on typechecking for this sort of validation, but rather the staitc structure. I don't think it's possible to typecheck where get or field is a top-level expression, nor can any of the other in-expr above show up as an input to another in-expr, so I was curious to just reflect this in the static structure of the section as opposed to relying on typechecking to figure it out.

[fgmccabe]

It seems to me that you must rely on type checking. But then, personally I am not afraid of type checkers :)\

…

On Tue, Jun 18, 2019 at 9:42 AM Alex Crichton ***@***.***> wrote: Oh sorry I should have clarified that my intention here wasn't necessarily to add more typechecking but moreso not rely on typechecking for this sort of validation, but rather the staitc structure. I don't think it's possible to typecheck where get or field is a top-level expression, nor can any of the other *in-expr* above show up as an input to another *in-expr*, so I was curious to just reflect this in the static structure of the section as opposed to relying on typechecking to figure it out. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#37>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQAXUFGU6C64NXAV5EWDJTP3EF6DANCNFSM4HYMZSJA> .

-- Francis McCabe SWE

[fitzgen]

I am also in favor of pushing static constraints from the (so far, unspecified) validation algorithm, to the grammar itself, when possible. It means that you we can do less validation work after parsing, since if something parsed and the grammar enforces a certain property, then we know that the relevant property is upheld without doing another validation pass.

This is obviously not possible for every property, but in the case of the straw proposal in the OP, it is possible and makes sense to me.

[pchickey]

Closing as out-of-date: the proposal has evolved and no longer involves binding expressions as described here. A validation algorithm still needs to be specified, see #29