3 ms·
It's java source to javascript source compilation(/translation/transpilation), so you only need to follow the semantics of the language, not the actual implemen
by magicalist 10y ago
It's java source to javascript source compilation(/translation/transpilation), so you only need to follow the semantics of the language, not the actual implementation.
As a simple example, if you create an array of numbers in Java, you don't need to worry about how the memory for that is allocated as long as you get an array of numbers in javascript.
The difficulties are more in how you get around where the two languages differ widely and making sure you match the semantics (often subtle) of the source language without tanking performance in the target language.
For that example of a numeric array, Java has very different expectations when it comes to bounds checking and exactly what numeric type is in there, for instance, and that has to be enforced by the code you generate if you are going to have any sort of sanity while authoring in the source language.
- dmux 10y ago>...so you only need to follow the semantics of the language, not the actual implementation. Wouldn't you need to follow the syntax and not the semantics? Aren't the semantics what the syntax is abstracting? (I'm genuinely curious, not trying to flame.)
- z1mm32m4n 10y agoNot OP, but I'm pretty sure you care more about the semantics here. The syntax is really just one way to express an intention. What you care about are the intensions--the meanings. That's exactly what the semantics are. For example, the semantics of this statement in Java int foo = 1 / 0; are very different from the semantics of this statement in JavaScript: var foo = 1 / 0; even though the two are syntactically rather similar. (In the former, Java will throw an ArithmeticException, whereas in JavaScript it will return Infinity.) So you want to ensure that your translation is meaning preserving, that is, that the source code and the generated code are semantically the same.