4 ms·

So why didn't java and python made it to gcc ?

by Vidura 16y ago

deleted 16y ago
[deleted]
xtho 16y ago
Because java did make it and python doesn't compile to machine code (with the exception of using a jit compiler maybe)?
- wazoox 16y ago
  I suppose that we could retarget something like Jython to compile Python to native code?
  - spectre 16y ago
    Jython doesn't compile to JVM bytecode its just a Python interpreter/implementation written in Java that runs on the JVM.
pmjordan 16y ago
I'm trying to work out at what level your question makes sense. I'm unaware of a GCC-based Python compiler, so surely there's nothing to merge there? As for Java: http://gcc.gnu.org/java/ http://gcc.gnu.org/java/ (this has been in for years)
- froydnj 16y ago
  There was a SoC project for a Python front-end to GCC this past summer. I don't know how far it got.
jrockway 16y ago
What's gcj? Oh, the Java compiler in gcc? Hmm. 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.
- masklinn 16y ago
  Also, erm… Python is not compiled to native code, so a gcc plugin doesn't really make any sense.
  - bretthoerner 16y ago
    Java normally isn't, either. You're discussing implementation details, not laws. http://gcc.gnu.org/java/ http://gcc.gnu.org/java/
    - pbiggar 16y ago
      Sort of. Scripting languages cross a bit of a line in that their implementation details leak out into the language. It simply isn't possible to statically compile Python (or PHP, Ruby, etc), and still cover the full breadth of the language. You need to handle dynamic code generation (for example eval()) which means you need an interpreter at run-time, which means you're no longer really statically compiling it. 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.
      - jedbrown 16y ago
        Evidently you are not familiar with how many Lisp compilers work. You don't need an interpreter anywhere, just a compiler. 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).
        pbiggar 16y ago
        > Evidently you are not familiar with how many Lisp compilers work. It would be better etiquette not to assume such things. A cursory google for my name (available from my HN profile I believe) would reveal that it's very very likely that I am familiar with how Lisp compilers work. > You don't need an interpreter anywhere, just a compiler. In Lisp, sure. But Lisp is not Python. Lisp's eval is structured, making it far simpler to compile than Python(/PHP/Perl/Ruby/JavaScript)'s unstructured eval, which takes a string which is may be constructed at run-time. Even so, Python(/etc)'s semantics lazily look up imports, which means that an imported module may be changed at run-time. 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). C's dynamic loading has significantly less scope than that of Python or of Lisp. C loads already compiled code, meaning that the C implementation is not required to have a run-time compiler available (the user may decide to compile C code using a compiler already on the system, but that's for the user to implement, not for the C compiler writter). 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).

So why didn't java and python made it to gcc ?

by Vidura 16y ago

So why didn't java and python made it to gcc ?

deleted 16y ago

[deleted]

xtho 16y ago

Because java did make it and python doesn't compile to machine code (with the exception of using a jit compiler maybe)?

wazoox 16y ago
I suppose that we could retarget something like Jython to compile Python to native code?
- spectre 16y ago
  Jython doesn't compile to JVM bytecode its just a Python interpreter/implementation written in Java that runs on the JVM.

pmjordan 16y ago

I'm trying to work out at what level your question makes sense. I'm unaware of a GCC-based Python compiler, so surely there's nothing to merge there? As for Java: http://gcc.gnu.org/java/ http://gcc.gnu.org/java/ (this has been in for years)

froydnj 16y ago
There was a SoC project for a Python front-end to GCC this past summer. I don't know how far it got.

jrockway 16y ago

What's gcj? Oh, the Java compiler in gcc? Hmm. 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.

masklinn 16y ago
Also, erm… Python is not compiled to native code, so a gcc plugin doesn't really make any sense.
- bretthoerner 16y ago
  Java normally isn't, either. You're discussing implementation details, not laws. http://gcc.gnu.org/java/ http://gcc.gnu.org/java/
  - pbiggar 16y ago
    Sort of. Scripting languages cross a bit of a line in that their implementation details leak out into the language. It simply isn't possible to statically compile Python (or PHP, Ruby, etc), and still cover the full breadth of the language. You need to handle dynamic code generation (for example eval()) which means you need an interpreter at run-time, which means you're no longer really statically compiling it. 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.
    - jedbrown 16y ago
      Evidently you are not familiar with how many Lisp compilers work. You don't need an interpreter anywhere, just a compiler. 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).
      - pbiggar 16y ago
        > Evidently you are not familiar with how many Lisp compilers work. It would be better etiquette not to assume such things. A cursory google for my name (available from my HN profile I believe) would reveal that it's very very likely that I am familiar with how Lisp compilers work. > You don't need an interpreter anywhere, just a compiler. In Lisp, sure. But Lisp is not Python. Lisp's eval is structured, making it far simpler to compile than Python(/PHP/Perl/Ruby/JavaScript)'s unstructured eval, which takes a string which is may be constructed at run-time. Even so, Python(/etc)'s semantics lazily look up imports, which means that an imported module may be changed at run-time. 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). C's dynamic loading has significantly less scope than that of Python or of Lisp. C loads already compiled code, meaning that the C implementation is not required to have a run-time compiler available (the user may decide to compile C code using a compiler already on the system, but that's for the user to implement, not for the C compiler writter). 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).