On: Show HN: I wrote a maze traversal program in Cloju...

[lispm]

> interpreted languages like Python, Ruby, or the Lisp family

Lisp isn't an 'interpreted language'.

> have to be interpreted by an interpreter capable of doing the evaluation (which Lisp, Python, etc. are—they have REPLs after all)

SBCL, a Common Lisp implementation...

  * (mapcar #'disassemble (list (lambda (a) (print a))))
  ; disassembly for (LAMBDA (A))
  ; Size: 28 bytes. Origin: #x226B7580
  ; 80:       498B4510         MOV RAX, [R13+16]                ; no-arg-parsing entry point
                                                                ; thread.binding-stack-pointer
  ; 84:       488945F8         MOV [RBP-8], RAX
  ; 88:       488BD3           MOV RDX, RBX
  ; 8B:       B902000000       MOV ECX, 2
  ; 90:       FF7508           PUSH QWORD PTR [RBP+8]
  ; 93:       B8D8C35222       MOV EAX, #x2252C3D8              ; #<FDEFN PRINT>
  ; 98:       FFE0             JMP RAX
  ; 9A:       CC0F             BREAK 15                         ; Invalid argument count trap
  (NIL)

To me that looks like machine code...

A bunch of Lisp implementations use compilers for evaluation in the Read-Eval-Print-Loop.

[todd8 → lispm]

I wasn’t trying to insult Lisp.

Compilers for Lisp have been around in some form for many years—I can remember hearing Patrick Winston talking about them when I first learned Lisp in his class in 1973. There are both interpreters and compilers for many languages and translators that are in between that use JIT compilation at run time.

Lisp and it’s offshoots (Scheme, Dylan, Common Lisp, Clojure, etc.) have a wider range of compilation and interpretation strategies used in their implementations than other programming languages. Perhaps this is due to the fact that Lisp has been around longer than almost any other important language or perhaps its due to its homoiconicity.

However my point was really about the availability of eval at run time, however it is implemented, and particularly eval that runs in the program’s address space and security context.

It’s true that the SBCL implementation of Common Lisp, by default, compiles eval’s arguments at runtime, but it may also use interpretation at runtime depending on the value of the a global variable. Other implementations of Common Lisp always use interpretation, like CLISP. Also, Common Lisp has eval-when which affects the compile vs interpret decision [1].

Readers interested in interpretation vs compilation can find introductory coverage of the topic in Wikipedia, see [2]. Lisp has an interesting and important history to computer science as the first interpreted high level language, see it’s Wikipedia entry at [3].

[1] http://www.lispworks.com/documentation/lw50/CLHS/Body/s_eval...

[2] https://en.m.wikipedia.org/wiki/Interpreter_(computing)

[3] https://en.m.wikipedia.org/wiki/Lisp_(programming_language)

[lispm → todd8]

> I wasn’t trying to insult Lisp.

Sure, just categorizing Lisp as an interpreted languages isn't correct.

> However my point was really about the availability of eval at run time, however it is implemented, and particularly eval that runs in the program’s address space and security context.

Right, but technically Common Lisp doesn't requite eval to use a compiler and it can also load compiled code from the file system, at runtime.

> Other implementations of Common Lisp always use interpretation, like CLISP.

CLISP also provides a virtual machine with a byte code compiler (also optionally a JIT native code compiler), though the compiler needs to be called explicitly.

> Also, Common Lisp has eval-when which affects the compile vs interpret decision [1].

Depends. In an implementation like SBCL or CCL, which use compilation for EVAL, it has no effect on such a decision.