It’s sometimes technically inferior in that it limits your source language to things that are expressible in the target language’s abstract machine. I suspect that’s not a huge issue here because I am not sure that BEAM can express things that Erlang cannot, since BEAM is a bytecode designed as the compilation target for Erlang. It’s a limitation when targeting something like .NET because CIL is designed to support multiple languages and none of the languages fully support generating all valid sequences of CIL bytecodes. Similarly, lowering to C rather than machine code means that you cannot precisely express things like the layout of the stack or stackfull coroutines.
agreed. since you mentioned C, it’s also the case that use of C as an intermediate representation normally picks up the C calling convention, which precludes (without super perverse trickery) lambdas and closures (in the non hijacked defs thereof).
i’ve been compiling for i guess 38 years and i never heard transpiler used to imply inferiority, but rather just leverage.
score 1 · canonical
It’s sometimes technically inferior in that it limits your source language to things that are expressible in the target language’s abstract machine. I suspect that’s not a huge issue here because I am not sure that BEAM can express things that Erlang cannot, since BEAM is a bytecode designed as the compilation target for Erlang. It’s a limitation when targeting something like .NET because CIL is designed to support multiple languages and none of the languages fully support generating all valid sequences of CIL bytecodes. Similarly, lowering to C rather than machine code means that you cannot precisely express things like the layout of the stack or stackfull coroutines.
score 1 · canonical
agreed. since you mentioned C, it’s also the case that use of C as an intermediate representation normally picks up the C calling convention, which precludes (without super perverse trickery) lambdas and closures (in the non hijacked defs thereof).
score 1 · canonical