Bram Moolenar works for GOogle, why won't Google Develop a text editor cloud of vim with realtime collaborative feature it would be great for Chrome OS also.
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.
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.
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).
> 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).
1. I was replying to your statement that eval() required an interpreter. My antagonism was mostly in jest since I vaguely remembered your name, but I also believe in discussions without arguments from authority.
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.
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 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.)
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 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.
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".
> 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.
