9 ms·

Isn't it limiting? Say, the language evolves and its scoping rules change, new control flow features are added etc. Now you can't ship anything in the new versi

by kgeist 3y ago

Isn't it limiting? Say, the language evolves and its scoping rules change, new control flow features are added etc. Now you can't ship anything in the new version because of the old clients. With bytecode, language implementers have more freedom to change the language without having to force everyone to use a new runtime version. I guess it's not a problem if the language implementers also control the client (say, V8 in Chrome) but in case of Juice, they were just another third-party extension to Netscape, so overall it sounds like a bad idea to me (if I understood it correctly that they serialized and shipped AST to end users).

vidarh 3y ago
You can read Franz' PhD dissertation on it here[1]. While it's reasonable to describe it as serialising an AST, most of the Oberon compilers of the time did not have an AST per se, and so what you serialize is entirely arbitrary to your choice of node types, and the operations used by the Oberon version are low-level enough that while some work would have needed to be done to be generic enough if one wanted to more easily support other languages, it's largely moot. There's no large semantic gap between what is serialized and the generated code. At that point it's no different from with Java - if you add new bytecodes, the JVM needs to support it. Same here - if you add new node types, the code generator will need to support it. Just as you wouldn't change the JVM bytecodes for every language change, you likewise wouldn't need to add new node types to support most language changes for Juice either. You could just as well choose to generate what in effect would be an intermediate representation instead. You'd only add new node types if they provide a sufficiently big win over generating more complex output, just as with the JVM That said, nothing would've prevented dynamically updating the code generator. [1] https://oberoncore.ru/_media/library/franz_m.code-generation_on-the-fly_a_key_to_portable_software.en.pdf https://oberoncore.ru/_media/library/franz_m.code-generation...

by kgeist 3y ago

vidarh 3y ago

You can read Franz' PhD dissertation on it here[1]. While it's reasonable to describe it as serialising an AST, most of the Oberon compilers of the time did not have an AST per se, and so what you serialize is entirely arbitrary to your choice of node types, and the operations used by the Oberon version are low-level enough that while some work would have needed to be done to be generic enough if one wanted to more easily support other languages, it's largely moot. There's no large semantic gap between what is serialized and the generated code. At that point it's no different from with Java - if you add new bytecodes, the JVM needs to support it. Same here - if you add new node types, the code generator will need to support it. Just as you wouldn't change the JVM bytecodes for every language change, you likewise wouldn't need to add new node types to support most language changes for Juice either. You could just as well choose to generate what in effect would be an intermediate representation instead. You'd only add new node types if they provide a sufficiently big win over generating more complex output, just as with the JVM That said, nothing would've prevented dynamically updating the code generator. [1] https://oberoncore.ru/_media/library/franz_m.code-generation_on-the-fly_a_key_to_portable_software.en.pdf https://oberoncore.ru/_media/library/franz_m.code-generation...