Repository navigation
Preprocessor for handling JS/WASM targets in one repo #1533
Description
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?
Activity
dcodeIO commentedon Nov 9, 2020
There are no preprocessor macros like these, but AS has the option to rename/alias types utilizing the
--useoption (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 commentedon Nov 9, 2020
Probably only for simple examples, but usually we need
@inline@operator("*"),let sqrt = Math.sqrt()so on. Thanks.MaxGraey commentedon Nov 9, 2020
Regarding
let max = Math.max;andlet sqrt = Math.sqrt(). Built-in intrinsicmax<T>/min<T>already polymorphic for all ints and float types.sqrt<T>(x)polymorphic forf32/f64munrocket commentedon Nov 9, 2020
Yes, but syntax is slightly differ from JS/TS.
max<T>is polymorphic in AssemblyScript, butMath.max()only for f32 andMathf.max()for f64 as I know.MaxGraey commentedon Nov 9, 2020
Yes. Btw it may change in future and
Math.min / Math.maxwill be also polymorphicmunrocket commentedon Dec 13, 2020
Answer from dcodeIO about macros
#ifdef (assemblyscript) #else #endin #1003stale commentedon Jan 19, 2021
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 commentedon Feb 21, 2021
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 commentedon Feb 21, 2021
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 commentedon Feb 22, 2021
@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 commentedon Feb 22, 2021
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,Arcentities). 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 (Seeheap.allocandheap.free) and even completely turn off GC (see--runtime stub) which usually make sense for short-lived applicationsgithub-actions commentedon Jun 10, 2021
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!