3 ms·
They shouldn't use tools like this one, though. This is purely a research project and not industrially usable. In any case, the purpose is to specify what Javas
by CHY872 11y ago
They shouldn't use tools like this one, though. This is purely a research project and not industrially usable. In any case, the purpose is to specify what Javascript is supposed to do, and not what Javascript engines actually do.
The interpreter was as easily as not an afternoon project; they probably got one for free.
There's been some interesting discussion about this for the C language - useful yet undefined behaviours that are relied upon by many pieces of software, where a formal semantics such as this project may fall flat and lead to being overly restrictive.
https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-survey-discussion.html https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-2015-05-24-...
- MichaelCrawford 11y agoIt would be a valuable contribution to publish the difference between what your tool says JS should do, and what production interpreters really do with that same JS source. I expect there is an open source test suite available. While at Apple in 1995 I came across a common in our system software that said "MacDraw needs this". Apple had a lending library with every third-party product that had ever been published, but for QA and bug isolation only. My job was mostly to isolate crashes that were stimulated by third party code. About half the time it was their fault; to the extent we possibly could we isolated it anyway by reverse-engineering their binaries. Apple Developer Tech Support would work with the developers to help them fix it. Sometimes its OK to depend on undocumented behavior, sometimes its not. Embedded systems for example might never receive new firmware so if the release firmware complies with specification then that undocumented behavior is completely cool.