So why didn't java and python made it to gcc ?
As for Java: http://gcc.gnu.org/java/ (this has been in for years)
As for why Python isn't in gcc... it's because nobody has sent a patch. There is no conspiracy here; Google wrote Go and sent the gcc folks a patch to add it to gcc. Simple.
In gcj, they added a java interpreter, and statically compile what they can. This works great when you have all the source code. It doesn't work great for things like Eclipse, where there are tons of dynamically loaded plugins which are then slow because they're interpreted.
Note that eval(), as much as it makes sense in the C language, can be implemented in C too (inject the text into a stub, compile it into a shared library, dlopen(), dlsym(), call it).
> Evidently you are not familiar with how many Lisp compilers work.
> You don't need an interpreter anywhere, just a compiler.
The crux of the issue is that in Python the dynamicism is actually used by lots of modules and programs.
> Note that eval(), as much as it makes sense in the C language, can be implemented in C too (inject the text into a stub, compile it into a shared library, dlopen(), dlsym(), call it).
Furthermore, almost none of the work of the compiler writer is affected by dynamic loading. Sure, it means they might not know all the entry points of some externally exported symbols, or they might not have a complete call-graph, or they might not be able to statically-infer all the run-time types or aliases of some static name. However, this limits the scope of optimization, it does not hamper implementation. And even then it rarely hampers local optimization, which the Python dynamic loading does (see my PhD chapter 6 for a discussion).
2. Lisp can eval a string that has been constructed at runtime. That's kind of the point of a repl, for example, which can be implemented by compiling each unit of input to native code before executing it.
3. The Python community shuns the use of eval. Are you really claiming that Python's eval is used in fundamentally more dynamic ways than Lisp's? Or is it that Lisp's eval usually operates on input that is constructed differently? Or that Lispers tend not to put eval in an inner loop, but some important Python programs do? I understand that there are attributes of Python that make compilation hard compared to a Lisp, but I'm not aware of something that makes it impossible or guarantees that compilation cannot be performant. Maybe I need to read chapter 6 of your thesis.
1 (eval). eval() is different in Python and Lisp. I was talking about Python eval(), which requires an interpreter.
2. Lisp "strings" aren't really strings in the way they are in python, which is what I was trying to say by "structured".
3. They may shun eval, but they don't shun import, which is the same thing.
What I'm saying is that the techniques Lisp compilers use do not apply to Python (or at least, no-one has ever shown how they do apply). I don't know enough Lisp to be confident as to why that is, but I believe it's because they don't do such massively dynamic things at run-time (that is, they can, but don't). Or perhaps they do, in which case their programs can't really be statically compiled in a gcc-like manner, which brings us back to our original point.
(eval (read-from-string "(anything here)"))
eval('anything(here)')
3. I don't see how Python's import is different, the SBCL runtime, for example, locates and reads the source file when you import it, compiles it to native code (if a cached copy is not available), and runs it.
4. I missed the (apparently) implicit "that easily fits into GCC's present compilation model" in your earlier comment. I'm have no arguments with that statement, and indeed, I don't think GCC would be a good place to work on static compilation for Python. Rather, my argument is with a claim (intended or not) that Python is just too dynamic to ever be compiled, for which I think Lisp compilers are a living counter-example. From the sbcl man page:
SBCL compiles by default: even functions entered in the read-eval-print
loop are compiled to native code, unless the evaluator has been explicitly
turned on. (Even today, some 30 years after the MacLisp compiler, people
will tell you that Lisp is an interpreted language. Ignore them.)The argument is whether we can compile Python with gcc. We cannot, because of eval(). Can Lisp compile eval()? Yes, for a different value of 'compile' and a different value of 'eval'. You argue that the values of 'eval' are the same in Lisp and Python - I honestly don't have enough knowledge to evaluate that. All I know is that if they are, then Lisp compilers are not static compilers, in which case the argument has no bearing on the discussion about python and gcc.
You have implied that you can statically compile python eval()-statements, but you have not backed that up.
In summary, I submit that (i) Python eval is no more dynamic than Lisp eval and (ii) it is acceptable to use the term "statically compiled" even if the standard library includes "compile".
(i) to compile python into an executable, you must include the entire compiler in the run-time (ii) this is inappropriate for gcc
This is one of those claims that is technically true, but is misleading. Really, there isn't an interpreter/compiler dichotomy, they are just variations on a theme. Or, standard definitions of them are variations on a theme, but often the line between them is very blurred (especially when just-in-time compilers come into it).
People typically consider 'compiler' to mean 'static compiler'. It generates native code into an executable, and then the 'program' is the executable. Lisp compilers are clearly very different to this, but GCC falls clean into it.
So it's wrong of you to allege that "you don't need an interpreter". You need a run-time component. Sure, this can be a compiler, rather than an interpreter, but its wrong to imply that you can support eval() simply with a static compiler such as gcc.