Comment by azakai | Hacker News Reader

Comment by azakai | Hacker News Reader

Here's the part about numerics differing between the VM and dart2js:

> A numeric literal is either a decimal or hexadecimal integer of arbitrary size, or a decimal double [..] In principle, the range of integers supported by a Dart implementations is unlimited. In practice, it is limited by available memory. Implementations may also be limited by other considerations. For example, implementations may choose to limit the range to facilitate efficient compilation to Javascript. These limitations should be relaxed as soon as technologically feasible.

So in principle Dart has bignums and doubles, but does not specify anything about how "big" the bignums are supposed to be, so a conformant implementation can simply not implement bignums (i.e. they are the size of the integers that fit in doubles).

This technically makes dart2js conformant, even though it in practice has different numeric types than the VM. That's fairly clever from a spec perspective, but worrying from a practical point of view.

Anyone know what the status of bignums in JS is? The spec says this will be fixed when "technologically feasible", but I can't find information about (1) what overhead dart2js currently suffers when it does implement bignums, and (2) when this is expected to become feasible, and how. I know some dart VM people are active in the comments here - is there any public info on those two issues?

Disclaimer: I work on dart2js.

Dart2js is not conformant. You could, maybe, twist the meaning of the spec this way, but it goes against the spirit of the sentence and the spec.

Tbh we never implemented a fully compliant dart2js backend. We have seen how slow the output is when some of our optimizations don't trigger (i.e. when we have bugs) and numbers are not correctly inferred.

Eventually we would like to give it a try, but there are much more important and useful issues we want to fix first.

In practice, numbers are a surprisingly small problem. Programmers have learned to look out for big numbers, and, while a nuisance, they are rarely the source for bugs.

Thanks for the info!

So there's not an urgency to make dart2js conformant, it sounds? I can understand if there's lots of other stuff to do, yeah - I suppose I am only surprised because the language is at version 1.5 and has a full spec, which could be my fault for assuming that meant it was more "finished" (by some vague meaning of the term).

I am still worried about numbers, though. Yes, programmers mostly know about this stuff, but rare and hard to debug issues are the concern when you have different numeric types than expected, in my experience (for example, in pyjamas, emscripten, etc.).

edit: clarified what I meant by "finished".

With the exception of numbers we should be conformant (and if we aren't please file a bug). A fully compliant dart2js would be theoretically nice, but practically mostly useless (because of its speed).

The Dart language and its spec are independent of dart2js (which is just an implementation striving to implement the spec). Clearly there is a huge connection between both (same team, ...), but in the end we decided to accept the non-conformance for the benefit of a better language. On the server Dart developers can already enjoy the more complete number-hierarchy, and, even if it takes time, I still have the hope that client-side we will eventually be able to enjoy Dart VMs everywhere. (Call me "optimist" ;)

Wrt debugging: the VM has a mode where it detects incompatibilities. For example when a number exceeds the 53bits of JS. This should reduce the difficulties in developing cross-platform tremendously.

How much slower would you expect it to be? (You said "mostly useless", but I'm curious if you have a ballpark estimate.)

I agree the VM debug mode will help a lot.

I prefer not to give any numbers (not even ballpark). It is extremely dependent on the benchmark, the JS engine, execution order (which function is optimized first, and/or inlined, ...).

Things get more complex if you want to implement the double/integer distinction that exists in Dart. That would either require to box integers or doubles, or to come up with some kind of tagging.

Reply on news.ycombinator.com