Go compiler now committed to gcc mainline (to be gcc 4.6) • Hacker News Board

Re: Go compiler now committed to gcc mainline (to be gcc 4.6)

#31

Post by pbiggar » Sat, Dec 04, 2010, 8:05 PM UTC

jedbrown wrote: post #22

pbiggar wrote: post #21

Earlier quoted context omitted.

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 gc…

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).

> You don't need an interpreter anywhere, just a compiler.

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.

Re: Go compiler now committed to gcc mainline (to be gcc 4.6)

#32

Post by jedbrown » Sat, Dec 04, 2010, 8:29 PM UTC

pbiggar wrote: post #30

jedbrown wrote: post #29

Earlier quoted context omitted.

2. How is a string read from the terminal fundamentally different in Lisp than in Python? How is (eval (read-from-string "(anything here)")) different from Python's eval('anything(here)') ? Just because it's possible to build the arguments of eval without using strings in Lisp does not mean that they are somehow less arbitrary. 3. I don't see how Python's import is different, the SBCL runtime, for example, locates an…

We are not discussing the difference between Python and Lisp (that is merely a short detour into something I know little about). 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 knowledg…

Perhaps we disagree about the term "static compilation". SBCL and other lisp compilers read a source file and produce native code which is then executed. If certain dynamic features are not executed, then the compiler (also part of the runtime in much the same way as libc is part of a C executable) is not invoked at runtime. If dynamic features are needed, then the expression is eval'ed by compiling it to native code and executing it. This is lighter and more powerful (for language reasons) than spawning a process to invoke a C compiler that produces a shared library which is dlopen'd on the spot, but I claim it is a closer analogy to what is happening than a JIT.

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".

Re: Go compiler now committed to gcc mainline (to be gcc 4.6)

#33

Post by pbiggar » Sat, Dec 04, 2010, 8:35 PM UTC

jedbrown wrote: post #32

pbiggar wrote: post #30

Earlier quoted context omitted.

We are not discussing the difference between Python and Lisp (that is merely a short detour into something I know little about). 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 knowledg…

Perhaps we disagree about the term "static compilation". SBCL and other lisp compilers read a source file and produce native code which is then executed. If certain dynamic features are not executed, then the compiler (also part of the runtime in much the same way as libc is part of a C executable) is not invoked at runtime. If dynamic features are needed, then the expression is eval'ed by compiling it to native code…

How about this:

(i) to compile python into an executable, you must include the entire compiler in the run-time (ii) this is inappropriate for gcc

Re: Go compiler now committed to gcc mainline (to be gcc 4.6)

#34

Post by jedbrown » Sat, Dec 04, 2010, 8:42 PM UTC

pbiggar wrote: post #33

jedbrown wrote: post #32

Earlier quoted context omitted.

Perhaps we disagree about the term "static compilation". SBCL and other lisp compilers read a source file and produce native code which is then executed. If certain dynamic features are not executed, then the compiler (also part of the runtime in much the same way as libc is part of a C executable) is not invoked at runtime. If dynamic features are needed, then the expression is eval'ed by compiling it to native code…

How about this: (i) to compile python into an executable, you must include the entire compiler in the run-time (ii) this is inappropriate for gcc

I agree completely. :-)

Re: Go compiler now committed to gcc mainline (to be gcc 4.6)

#35

Post by spectre » Sat, Dec 04, 2010, 8:49 PM UTC

wazoox wrote: post #18

xtho wrote: post #4

Earlier quoted context omitted.

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

I suppose that we could retarget something like Jython to compile Python to native code?

Jython doesn't compile to JVM bytecode its just a Python interpreter/implementation written in Java that runs on the JVM.