I'm a Facebook engineer who works on the HipHop compiler and HipHop virtual machine. It's in PHP, absolutely full stop.
It's amazing how much the fact that g++ is involved somewhere in the toolchain confuses people in this matter. C++ is just an intermediate representation; the source language really is warts-and-all PHP.
IIRC Facebook engineers must use HipHop for all their development, with PHP.net's php being now incompatible (hence the push to speed up the interpreter.) Wouldn't that make the language-supported-by-HipHop a PHP flavoured superset at the very least?
In the absence of a standard, saying what is and is not PHP is necessarily a practical matter: useful PHP implementations are those that run non-trivial PHP applications. HipHop qualifies.
FB's dependence on HipHop is because of backwards-compatible extensions to the language (like yield, e.g.). These extensions don't prevent HipHop from running normal PHP programs, though our use of them does prevent us from using Zend. The extensions are under flags that default off, if you don't want to use them.
Or a compiler at run-time.
eval does have one huge, honking problem though: it permits text to be interpreted as code. This is just asking for code injection attacks.
If you really need incremental/multi-stage evaluation, see MetaOCaml (http://www.metaocaml.org/) for the proper way to do it (without exposing yourself to injection vulnerabilities). It's a consequence of PHP's by-the-seat-of-your-pants approach to language design that the PHP devs settled for eval instead.
User input of code. It's hard to implement a REPL without it. Even if you do implement without it there's still an "exec" implementation hiding in there somewhere.
Also, on rare occasions, it is actually an optimization when used carefully, like the Python nametuple example mentioned nearby.
I'm just answering your challenge. I totally agree that in general it's a bad idea and that's an unusual case. While for it to work properly it has to ship with the interpreter, if I were designing a language I would move it out of the global namespace at least, and require some sort of explicit module import with lots of dire warnings in the documentation.
The problem with using eval for a REPL is that you want an interpreter, but eval gives you unprincipled incremental compilation.
Javascript (and I'm sure other languages) is moving in the right direction with sandboxed evals, but those are very difficult to get right in an imperative language, where a lot of code relies on global state (e.g. the DOM). Purely functional languages solve this problem well by disallowing side-effects. Of course there remain the issue of unconstrained resource usage but this is much easier to solve.
I use this in my Python data processing scripts. That is, when I generate data, I generate it as Python literals, either lists or dictionaries. When I have to process it, minimal parsing needed, I just eval it into my code.
def parse_and_append(line, seq, str):
if str in line:
seq.append(eval(line[line.find(str) + len(str):]))
nums = []
mappings = {}
for line in data_file:
parse_and_append(line, nums, "nums: ")
parse_and_append(line, mappings, "mappings: ")
If you write code in Java, but compile it to native format (using gcj, for instance) instead of using the JVM, is it still Java? In doing so, you lose what is probably the language's biggest selling feature.
Or, perhaps less relevant now, but I remember the days where people would go on about how Ruby didn't support native threads. Except there were interpreters that did use native threads with the exact same Ruby code. Was Ruby code running under one of those other interpreters still a Ruby application?
PHP too comes with expectations about the environment, like how it integrates into the web server stack, which if not met, is it still PHP? I'm not really familiar with HipHop, but, for instance, if you have to compile your code before deployment, you're not meeting one very prominent expectation of PHP: The ability to edit the code in-place on the live server (best practices notwithstanding).
So, what does define a language? Is a language just the syntax? Standard library APIs? Standard library behaviour (see Ruby example)? Runtime environment? I'm not sure you will find a generally accepted answer.
But the lines got very much blurred by the rise of scripting languages, in which - typically - the language was defined by the implementation. So for a few years there, it really was difficult to tell whether this was Python or CPython.
Fortunately, nearly all the languages to which this applies matured and got new implementations. Rubyists often to refer to the C ruby implementation as MRI (Matz' ruby interpreter), and there are lots of different Ruby implementations now. Python went out of its way to document behaviour which was specific to CPython, and put a lot of weight behind Unladen Swallow and Pypy.
But your Java example is bonkers. Compiling Java to native is still Java, its just not JVM. Compiling clojure to JVM is just JVM. The language feature is not the language. In Java's case, the language is specified, the VM is specified, the bytecode is specified. There really should be no ambiguity at all there.
Most people without a proper CS background mix the language with the implementation.
A language is defined by:
- syntax
- semantics
- libraries
Everything above can be made available as:
- bytecode interpreter
- text parser based interpreter (like the earlier BASICs)
- compiler
- JIT
That is why it is absurd to discuss language A vs language B in regard to implementations, because any language can have all types of implementations.
It is always a matter of cost/benefit which type of implementation is used as default for a given language.
Of course, I'll trust what an actual engineer from Facebook is saying over some article that I can't even cite. Is this not the case?
Well, you're the authority, but is that really a fair assessment? Has HipHop diverged from PHP enough to really still be considered PHP?
From the free dictionary:
poetic license n. The liberty taken by an artist or a writer in deviating from conventional form or fact to achieve a desired effect.