For that matter, even C compilers often translate the code to an intermediate langauge before outputting the executable.

It doesn't interpret the intermediate language - by the time runtime starts, the intermediate language is gone.

Abigail

The Java people will tell you (rightly or wrongly) that Java compiles to bytecode so that it's cross-platform. Which is still an effort to solve an N*M problem. There are other benefits to this, too (such as runtime optimization via JIT), but for the Java commmunity, at least, the primary goal seems to be cross-platform support. The difference between that and gcc's IL is when the compile to machine code is done.

Also, some compilers (like the gcc suite) support many languages, so we have to add another term to the equation: L*N*M, where L is the number of languages you want to support. Which just makes the use of an internal IL that much more important. Ignore that bit. Misread Abigail-II's post.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Also, some compilers (like the gcc suite) support many languages, so we have to add another term to the equation: L*N*M

L * N * M? Then what is N? I said N languages, and M platforms. You say L languages, but don't say what N is (or M).

Abigail

I don't write scripts - I write application frameworks. I just happen to use a language that once was a scripting language.

I would agree with what you say except that I know there's an incorrect and harmful prevailing attitude out there that "scripting" languages are in some way inferior, because they don't create "real" programs. Honestly, I don't think we'll get the C/C++ people to stop looking crosseyed at us until we have an optimizing compiler that produces platform-specific native binaries, and I don't think a bundlemonkey approach (binding the interpreter and the bytecode together into an executable package) will do the trick. It's stupid, something that's only needed because of misconceptions that people have, but I'm pretty sure it's necessary, politically, for at least one major VHLL to have this before we'll be able to finally do away with the whole issue.

Whichever VHLL does this will lack eval, which will make it distinctly less HL...

Whichever VHLL does this will lack eval, which will make it distinctly less HL...

Not necessarily so. You just need to include your compiler with the binary. Languages like Lisp and Pop-11 have been doing that for years.

Whichever VHLL does this will lack eval, which will make it distinctly less HL...

There are ways around this. First, some of the things we currently do in Perl via eval can be done in other ways. *Almost* anything you can do with the block form of eval could be done another way; Perl6 is adding some features in this regard. The string form of eval of course can do some things that would break this, so a solution is still needed for eval. There are a couple of options, and a hybrid approach that I would personally favour. The first approach is to provide an optimizing compiler for a subset of the language that does not provide the string form of eval. Thus, any program that doesn't use that could be compiled. The second approach is to compile all the rest of the code in the usual way but *also* then bundle an interpreter or JIT compiler, so that string eval and things like it would be possible. The hybrid approach is to only bundle the compiler or interpreter if the code being compiled uses the string eval.

I favor the hybrid approach, but really I don't think this is a big deal. The real problem is convincing anyone (well, anyone capable of doing anything about it) that political reasons and the views of C/C++ programmers are good reasons to write _and maintain_ an optimizing compiler despite that for almost the entire existing userbase the existing vm-based solution is the way to go.

---

;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print