|
in reply to Re^3: A great talk on Perl6
in thread A great talk on Perl6
Thank you very much for these explanations, I don't know much about compilers and virtual machines so it's a bit difficult for me to sustain my suggestion. I was just comparing Perl6 with Java and thought that as Java programs could be compiled independently of JVM, i.e. run as C or C++ executables, it would be nice if Perl6 had this possibility too. But now I have a doubt about this possibility in Java, maybe I've just interpreted wrongly some compilation steps I had to do with some Java programs.
Could NQP or another compiler produce also binary executables (not bytecode intended for virtual machines)? After listening to your link I wonder if this is possible, or if I understand enough of what is going on under the hood to continue this discussion. Sorry for everything silly then. |
Re^5: A great talk on Perl6
by LanX (Saint) on Apr 03, 2014 at 20:11 UTC
|
> Could NQP or another compiler produce also binary executables (not bytecode intended for virtual machines)?
One of the main problems with such ideas is to underestimate the dynamism of languages like Perl or JS.
Just think of the need to have the whole compiler backend to simulate eval.
Thats why one ends up using a VM with JIT compiler, like V8.
And of course those can be bundled into a stand-alone executable.
So the answer depends on the definition of "binary executable".
Cheers Rolf
( addicted to the Perl Programming Language)
| [reply] |
|
|
Right, thanks. I didn't think about eval.
| [reply] |
|
|
| [reply] |
|
|
But dynamic features such as eval could be compiled so as to target an external virtual machine or even the Perl5 interpreter.
| [reply] |
Re^5: A great talk on Perl6
by Anonymous Monk on Apr 03, 2014 at 17:38 UTC
|
Rakudo can't do that because...
Well perl-6 can't do that because you can't run perl-6 without a runtime to
figure out things like method dispatch and to manage garbage collection
and other things. Someone could write a linkable library to provide that
but that would only delay perl-6 actually coming out so GET RIGHT ON THAT #perl6!
Rakudo can't do that because it uses a modified Xeno's Paradox for its development process: every time it gets halfway to completion, someone decides to start a port to yet another backend (or rewrite something else from scratch).
| [reply] |
Re^5: A great talk on Perl6
by raiph (Deacon) on Apr 03, 2014 at 19:49 UTC
|
Java programs could be compiled independently of JVM ... now I have a doubt about this possibility in Java
I don't think you can do that. Tools like Excelsior JET or exe4j are distributed with, or install, a JVM. Afaik tools that compile to native code do so via a JVM.
Could NQP or another compiler produce also binary executables (not bytecode intended for virtual machines)?
In theory, yes, but why? I see plenty of downsides and no upsides. What would you hope such an approach would achieve?
| [reply] |
|
|
In Wikipedia I read : "There exist also compilers emitting optimized native machine code for a particular hardware/operating system combination." E.g. GCJ.
> What would you hope such an approach would achieve?
Speed.
Many thanks for your answer, but as I told you, things are beyond my understanding from now on.
| [reply] |
|
|
At least two reasons, Ralphie-boy. 1 to avoid rewriting all of your code when the perl-6 spec changes or Rakudo breaks backwards compatibility yet again. 2 to avoid having to depend on whatever the flavor du jour VM is THIS month.
Maybe that's just one reason. To prevent the beer-obsessed attention deficit development process of perl-6 from breaking your production code.
Of course that means you're right. You won't hear me say this often, Ralphie-boy, but you're right. There's no point. Why not just use a language that exists? One with developers who know how to deliver working software that doesn't break every month? Good point.
| [reply] |
|
