Hi, On Thu, 16 Mar 2017, Mattias Gaertner wrote:
> > which was basically striped down Javascript with some integer/pointer > > type tagging. As far as I know, the main problem with JS from a > > computing point of view, that it handles all numbers as floats for > > "simplicity", but with some code in other languages, this can have > > real side effects (for example some integers cannot be exactly > > expressed as floats, > > JS uses Double, which can express integers correctly from > -$10000000000000 to $fffffffffffff. > That should be enough for most browser programs, don't you think? No, to be honest, I don't think so. I already tracked down bugs in native client side software caused by this, because of stupid NodeJS backends. Because someone thought it will be "good enough". It wasn't. Not to mention the cases I got "NaN" string as value in an integer field, but that's just JS in general for fun. Although NodeJS wasn't running in the browser, admittedly. But I think the more complex apps you bring to the web, on top of JS, the more such issues will appear, and the harder it will be to track it down. Bottom line: It's not good enough if you want to guarantee the same results as on other platforms, for all integer arithmetics with all standard types, including 64bit ones. Which is a must for any self respecting multiplatform compiler, IMO. (There are ways to do it nevertheless even w/o WebAssembly, but with a clear performance hit.) But I guess this is drifting away from the WebAssembly target itself, so we should continue on fpc-other. :) Charlie _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
