4 ms·

Could you though? I mean the semantics are so different that the code you generate is probably going to need to be the equivalent of Perl's VM at that point any

Could you though? I mean the semantics are so different that the code you generate is probably going to need to be the equivalent of Perl's VM at that point anyway.

hardwaresofton 8y ago
I think you could -- you'd have to just translate all those semantics down to rust as well. I can't think of any perl semantics/sugar that can't be compiled out. Even the famous default variable ($_) could be naively transpiled out with just a variable binding. Also, if I'm understanding the original post right, they want the VM itself to be swappable -- that with the desire to reach C speed makes me think that they want to make it optional all-together.
- tasty_freeze 8y ago
  Your reasoning is kind of like saying we only need a 6502 and a large bank of ram because, hey, that is turing equivalent, and a modern x86 with the same amount of ram is turing equivalent, so it should be complete. Imagine a perl program which asks the user for input. Based on the user's input, the perl program does "do a.pl" or "do b.pl". Hell, maybe the user's input is actually executable code that is thrown in the mix too. Then the original program does "print $a + $b;". What should the rust transpiler do? Are they floats? Are they ints? Or strings? Do they have values already? Yes, you could create a transpiled version that used hashes to look up symbols, and based on what the hash returned it would execute code to add two (boxed) ints, or floats, or float and int, or throw an error, but then what you've done is rewritten the perl interpreter in rust.
  - hardwaresofton 8y ago
    > Your reasoning is kind of like saying we only need a 6502 and a large bank of ram because, hey, that is turing equivalent, and a modern x86 with the same amount of ram is turing equivalent, so it should be complete. Yes, this is literally the case, I didn't say it would be easy or that it should be done. Maybe I should have been more clear, but it was just a silly joke, lighten up. Also, analogging perl and c/c++ style languages to the modern x86 and 6502 is a bit hyperbolic. If I'm understanding your point correctly, you're saying that dynamic interpretation (via code loading or `eval`) is an important perl feature you want to retain. In a world in which someone was crazy enough to write a perl->rust transpiler, they could just not support eval for v0.1, and figure out how they want to deal with it in the future. One option is to compile in a runtime + interpreter that could be used if the code being built uses eval. Any other difficulties you can forsee? or areas where there's a 6502-x86 style feature disparity?
    - rileyphone 8y ago
      Having eval is a part of the language, and without it you aren't transpiling perl, just perl-- or whatever you want to call it.
mamcx 8y ago
In fact, I ask about this: https://www.reddit.com/r/rust/comments/94c4m9/is_possible_to_ship_rust_compiler_like_a/ https://www.reddit.com/r/rust/comments/94c4m9/is_possible_to... So, in short, the answer is no. Rust currently lack a clean way to do this. The semantics are hard to translate also. I'm doing a little lang in rust and is HARD. However, is possible? Yes. But I think rust need to be able to run from a shared lib and compile to memory, like https://en.wikipedia.org/wiki/Tiny_C_Compiler https://en.wikipedia.org/wiki/Tiny_C_Compiler

Could you though? I mean the semantics are so different that the code you generate is probably going to need to be the equivalent of Perl's VM at that point anyway.

hardwaresofton 8y ago

I think you could -- you'd have to just translate all those semantics down to rust as well. I can't think of any perl semantics/sugar that can't be compiled out. Even the famous default variable ($_) could be naively transpiled out with just a variable binding. Also, if I'm understanding the original post right, they want the VM itself to be swappable -- that with the desire to reach C speed makes me think that they want to make it optional all-together.

tasty_freeze 8y ago
Your reasoning is kind of like saying we only need a 6502 and a large bank of ram because, hey, that is turing equivalent, and a modern x86 with the same amount of ram is turing equivalent, so it should be complete. Imagine a perl program which asks the user for input. Based on the user's input, the perl program does "do a.pl" or "do b.pl". Hell, maybe the user's input is actually executable code that is thrown in the mix too. Then the original program does "print $a + $b;". What should the rust transpiler do? Are they floats? Are they ints? Or strings? Do they have values already? Yes, you could create a transpiled version that used hashes to look up symbols, and based on what the hash returned it would execute code to add two (boxed) ints, or floats, or float and int, or throw an error, but then what you've done is rewritten the perl interpreter in rust.
- hardwaresofton 8y ago
  > Your reasoning is kind of like saying we only need a 6502 and a large bank of ram because, hey, that is turing equivalent, and a modern x86 with the same amount of ram is turing equivalent, so it should be complete. Yes, this is literally the case, I didn't say it would be easy or that it should be done. Maybe I should have been more clear, but it was just a silly joke, lighten up. Also, analogging perl and c/c++ style languages to the modern x86 and 6502 is a bit hyperbolic. If I'm understanding your point correctly, you're saying that dynamic interpretation (via code loading or `eval`) is an important perl feature you want to retain. In a world in which someone was crazy enough to write a perl->rust transpiler, they could just not support eval for v0.1, and figure out how they want to deal with it in the future. One option is to compile in a runtime + interpreter that could be used if the code being built uses eval. Any other difficulties you can forsee? or areas where there's a 6502-x86 style feature disparity?
  - rileyphone 8y ago
    Having eval is a part of the language, and without it you aren't transpiling perl, just perl-- or whatever you want to call it.

mamcx 8y ago

In fact, I ask about this: https://www.reddit.com/r/rust/comments/94c4m9/is_possible_to_ship_rust_compiler_like_a/ https://www.reddit.com/r/rust/comments/94c4m9/is_possible_to... So, in short, the answer is no. Rust currently lack a clean way to do this. The semantics are hard to translate also. I'm doing a little lang in rust and is HARD. However, is possible? Yes. But I think rust need to be able to run from a shared lib and compile to memory, like https://en.wikipedia.org/wiki/Tiny_C_Compiler https://en.wikipedia.org/wiki/Tiny_C_Compiler