Assemblyscript: Consider adding platform flags (E.g --browser, --wasi) / Easier defaults for newcomers

[torch2424]

Hello!

So I have seen more than a handful of issues that creep up in multiple places (the latest being https://github.com/bytecodealliance/lucet/issues/436 but I can definitely find more examples), that cause headaches for people because they happened to miss something in the docs.

As more "platforms" for wasm start coming around, I think it'd be nice to have some alias flags for certain envioronments.

Like for example, on all of my wasi applications (like as-echo), I always have to take the extra step of adding: --use wasi_abort from as-wasis wasi_abort

Maybe it'd be a good idea for as different platforms require different things, we can add some default alises for said platform? Or maybe another solution works?

Just wanted to hear some thoughts on this. And I totally think I can open a PR for this one whatever we decide to do :smile:

[dcodeIO]

Hm, yeah, the abort (and trace) functions have been introduced due to the lack of (standardized) alternatives, which WASI now provides. Potential soltutions:

• Add a compiler flag (that also automatically sets up a global Wasi?)
• Move the abort implementation to stdlib and make it detect isDefined(SomeGlobalWasiSymbol) which would be true if import "bindings/wasi_something" is used, and conditionally compile matching abort logic? Requires that a user imports the wasi interface somewhere.

Not sure what's more user-friendly.

[torch2424]

Hm, yeah, the abort (and trace) functions have been introduced due to the lack of (standardized) alternatives, which WASI now provides.

Ah that makes sense! :) So what about abort in the browser case? I remember I needed it for WasmBoy, which has no WASI. And it seems like in the issue I linked, they also were not using WASI? :thinking:

Add a compiler flag (that also automatically sets up a global Wasi?)
Move the abort implementation to stdlib and make it detect isDefined(SomeGlobalWasiSymbol) which would be true if import "bindings/wasi_something" is used, and conditionally compile matching abort logic? Requires that a user imports the wasi interface somewhere.

Would it be too much to ask for a combination of these actually? :smile:

Like if we detect they are using WASI. Default to adding the --use=abort ... for WASI, and if not one for the browser. But still allow the user to override and provide their own? :smile:

And yeah, I think it'd be good if we had an abort like built into the stdlib (if that means you don't have to manually import the one that as-wasi provides :joy: )

Thanks! :smile: And again, down to look into getting my feet (more) wet with the compiler for this one :smile:

[torch2424]

Also, this came up in the beginners channel int he discord recently. @MaxGraey and I were helping someone, and gave some feedback here I thought was useful to this issue :smile:

the loader example literally says { /* Your imports if needed */ } I now suspect the lack of index and env was what what caused the syntax error, but since the comment says 'if needed', it's reasonable for a newcomer to assume NO imports are needed.

This has to mostly do with the JS side of things. But I don't think we need to expect this imports in these cases really if we provide them :smile:

[dcodeIO]

When using the loader, there is no need to specify an abort import as the loader ships one already and fills it in. As such, the example there is correct, with /* Your imports if needed */ being user-defined imports exclusively. Reading through the discussion there, I guess what we'd need is an easily usable version of the loader for the browser, so everyone can just use it without bundling / worrying about details?

[torch2424]

@dcodeIO Ah! I didn't know that was the issue. Personally, I never used the loader, outside of wrapping it for as-bind (which in that case I have) :joy:

But now that I know the loader provides this, I think it's probably more about improving the docs on this one section? :thinking: It's hard to assume what someone new may think when playing with it :cry:

[dcodeIO]

Initial implementions to make WASI modules "just work": https://github.com/AssemblyScript/assemblyscript/pull/1159

[dcodeIO]

Closing this issue as part of 2020 vacuum since the new import "wasi" functionality has landed meanwhile, and seems to sufficiently cover the issue. Feel free to open a new issue if there are problems with the new mechanism.