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.

[jerrygreen]

@MaxGraey actually on a second thought I now think it might be indeed a weird property. asmjs appeared as a minimum subset of javascript in the first place, minimum enough to be able to create any logic and any program yet without any cool features and human-readable concepts, - ideal for a machine, while working in existing browsers, I know that. But I initially thought it's kinda neat idea to make a language that compiles into this subset, like a continuation, evolution, js -> ts -> as. But again I now think you're right that it just conceptually can't support every feature because some of them rely too much on runtime, while Assemblyscript goal is to be as much as possible in compile time, - which is absolutely great. I actually like Assemblyscript as it is right now. I'm not even sure from docs why Assemblyscript team wants garbage collector even, - it might allow making some interesting structures in code, but it's a runtime feature, contradicts to goals of Assemblyscript, Rust doesn't have gc. So why would Assemblyscript team want it? They also thought "but it's kinda neat"? 😂 Or am I missing something, like maybe it's some compile-time non-typical weird gc with very limited capabilities or something?

[MaxGraey]

Rust hasn't GC but it hasn't fully automated memory management. Rust required lifetime hints (which often required setup manually), move semantics and sophisticated checker (borrow checker). Also it still required reference counting sometimes (see Rc, Arc entities). Also all of this doesn't guarantee memory leak free. So GC memory management is a trade-off between usability / simplicity and performance. But in AS you still can use manual memory model (See heap.alloc and heap.free) and even completely turn off GC (see --runtime stub) which usually make sense for short-lived applications

[github-actions]

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