You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a CG call a few weeks back, I mentioned that having the ability to have test-local variables in .wast files would be useful.
In particular, many tests that use reference types, mostly in proposals right now (such as function-references and gc use tables internal to a module and an initializer. These tests would be shorter, easier to write, and easier to debug (a key productivity boost for engine implementers) if the test itself could bind variables.
That would remove the need for tables, but the issue of needing to create objects/functions inside a module (because types and decls live in modules) remains.
The text was updated successfully, but these errors were encountered:
I agree writing tests in terms of table indices makes them hard to understand and modify. Would using exported globals give a similar DevX? I suppose that you can't initialize an exported global with the result of a function call, but maybe it would be ok to keep the init() function pattern the test currently use.
I was about to suggest the same -- fwiw, the wast script language already has a (get "name") action for accessing exported globals.
There is a gap though, namely, that invoke can only take constants as arguments. I think what we need first and foremost is to beef up the syntax of these script "actions" and turn them into a tiny expression language of nested calls and global reads.
In addition, we could introduce new forms of top-level definitions, like @titzer suggests. However, that is inherently limited by the inability to refer to types, not having arbitrary instructions, etc.. So the added value over module globals is likely small.
In a CG call a few weeks back, I mentioned that having the ability to have test-local variables in
.wast
files would be useful.In particular, many tests that use reference types, mostly in proposals right now (such as
function-references
andgc
use tables internal to a module and an initializer. These tests would be shorter, easier to write, and easier to debug (a key productivity boost for engine implementers) if the test itself could bind variables.Exact details of syntax and semantics TBD.
Sketch:
That would remove the need for tables, but the issue of needing to create objects/functions inside a module (because types and decls live in modules) remains.
The text was updated successfully, but these errors were encountered: