Preprocessor for handling JS/WASM targets in one repo

[munrocket]

I found that sometimes it is useful to store pure typescript and assemblyscript in one file. Of course this feature can be implemented in custom plugin for your bundler but you will depend on exact bundler (rollup/webpack/parcel/esbuild). So here a form that will be legit typescript superset.

//@as-if
//type float = f64;
//type int = i32;
//@as-else
type float = number;
type int = number;
let max = Math.max;
//@as-endif

One can implement this plugin right now. But this preprocessor can be a part of AS itself. What do you think?

[dcodeIO]

There are no preprocessor macros like these, but AS has the option to rename/alias types utilizing the --use option (e.g. --use float=f64). In this scenario, the code compiled to JS would be the ground truth, and types are reconfigured before compiling to Wasm. Would that help?

[munrocket]

Probably only for simple examples, but usually we need @inline @operator("*"), let sqrt = Math.sqrt() so on. Thanks.

[MaxGraey]

Regarding let max = Math.max; and let sqrt = Math.sqrt(). Built-in intrinsic max<T> / min<T> already polymorphic for all ints and float types. sqrt<T>(x) polymorphic for f32 / f64

[munrocket]

Yes, but syntax is slightly differ from JS/TS.
max<T> is polymorphic in AssemblyScript, but Math.max() only for f32 and Mathf.max() for f64 as I know.

[MaxGraey]

max is polymorphic in AssemblyScript, but Math.max() only for f32 and Mathf.max() for f64 as I know.

Yes. Btw it may change in future and Math.min / Math.max will be also polymorphic

[munrocket]

Answer from dcodeIO about macros #ifdef (assemblyscript) #else #end in #1003

There are no macros like these, but in case it helps, in AS code there is a constant ASC_TARGET that is 1 when compiling to Wasm, respectively 0 when compiling to JS with the portable stdlib included. When not including the portable stdlib, it's not defined when compiling to JS. Where that's not enough, what I typically do is to add varying entry files. The compiler for example adds glue/js respectively glue/wasm depending on the target. (I also like the idea of falling back to .ts eventually, though.)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jerrygreen]

I hardly believe that such a little hack with integers and floats would be enough to make assemblyscript a legit superset of typescript...

I.e. literally any typescript code would’ve been valid assemblyscript (as much as any JavaScript is valid typescript, therefore any javascript would be also valid assemblyscript).

Anyway, I still would really like to see some substantial support into making assemblyscript indeed this kind of superset. Then I would freely fell in love with assemblyscript 😃

Is it even possible, anyone? Because I’m not completely sure if it’s “nearly there and at some point we will become the superset!” case, or it’s a complete dream and “wtf you’re talking about, it’s impossible” case.

[MaxGraey]

I.e. literally any typescript code would’ve been valid assemblyscript (as much as any JavaScript is valid typescript, therefore any javascript would be also valid assemblyscript).

If any JS code were valid TypeSctipt then there would be no need for DefenitelyTyped and accompanying definition files, would there? But in fact, migration from JS to TS often requires refactoring, since most of the code is written in ES5 with prototypes and is not very well ported into TS paradigms with OOP, interfaces, enums and etc.

But suppose AssemblyScript fully supports TypeScript. How does this help us? After all, most typescript projects in npm are distributed as javascript (.js) + type definitions (.d.ts). That is, we don't have access to real typescript sources. Ultimately we only have the same javascript + some meta-information, which is not enough for a full-fledged AOT compilation. Therefore, in any case, we would not be able to compile an arbitrary npm module that is not adapted for AssemblyScript. At the same time, JS / TS code carries a lot of ineffective solutions and workarounds, for example, due to the lack of i64 / u64 types or popcnt and other low-level operations that AssemblyScript has.