3 ms·
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 belie
by jedbrown 16y ago
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.
- pbiggar 16y ago1 (authority). Sure :) 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.
- jedbrown 16y ago2. 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.)
- pbiggar 16y agoWe 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.
- jedbrown 16y agoPerhaps 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".