3 ms·

REPL is the interpreter isn't it? When you type the code into sbcl you are using the REPL which is the interpreter. Try running sbcl without the REPL and produ

REPL is the interpreter isn't it? When you type the code into sbcl you are using the REPL which is the interpreter. Try running sbcl without the REPL and produce an executable binary file. Maybe the binary representation changes into something with dynamic dispatch?

lispm 4y ago
REPL is a Read Eval Print Loop, which is a way to interact with a Lisp runtime. This is independent on how EVAL is implemented. A bunch of Lisp systems implement EVAL with an incremental compiler. An interpreter is a Lisp feature where code gets interpreted from source at runtime. Some implementations have one, some don't, some only have an interpreter, some only have a compiler, some have several compilers, some have both. > running sbcl without the REPL and produce an executable binary file The executable binary file in SBCL always includes the compiler. REPL: a user interface to execute Lisp code. Reads s-expressions, evaluates them and prints the results as s-expressions. EVAL: the interface to execute code. A function. Interpreter: an implementation of Lisp which interprets source code. Byte Code Interpreter: an implementation of Lisp which interprets byte code instructions. Compiler: an implementation of Lisp which can compile code to a) byte code, b) C code, c) machine code In-memory compiler: an implementation of Lisp where the compiler does not create files, but writes the executable code directly to RAM Whole-Program compiler: an implementation of Lisp, which only compiles whole programs and creates executables -> rare, but various examples exists
- terminalcommand 4y ago
  Thank you for taking the time to explain. I now get it. SBCL includes the compiler in each binary and this is called incremental compiling. That explains the expressiveness. It is kind of like a JIT when needed. Compile everything you can AoT, leave dynamic parts to runtime compilation. It makes perfect sense. Thanks . I guess the difference is that in an interpreter you don't go down to assembly, you parse and run stuff. The moment you cross the line to generate bytecode/machine code or transpile into a different language you get a compiler.
  - lispm 4y ago
    Basically all SBCL code is pre-compiled. There is mostly no runtime compilation happening. Only if the user/developer actually wants it. For example one can connect to a running SBCL and have one or more networked REPLs into it.
kazinator 4y ago
The REPL (traditionally "listener") is a kind of interpreter, because it reads textual input, and hands it off for processing. There is some definition of "interpreter" which this meets. lispm's point is that it's not a/the Lisp interpreter. An Lisp interpreter and Lisp listener are different things. The listener is more like a "command interpreter". You can write a very poorly featured listener yourself, by literally following the REPL acronym: (loop (print (eval (read)))). You have not written a Lisp interpreter in four operators; the read and eval functions are doing that. The following is a copy and paste from an actual session: [1]> (loop (print (eval (read)))) (+ 2 2) 4 (let ((x 9)) (* x x)) 81 Some other languages are the same way. When Bash runs a script, it's not going through the interactive command line processor that is used for interactive input, which has completion, recall and editing. That command line processor isn't what parses and understands Bash syntax. We can write a REPL at the Bash prompt also. We can write a loop which reads a line of input, evaluates it as shell syntax, and then repeats that ad infinitum until we hit Ctrl-C: $ while true ; do read -r command ; eval "$command" ; done echo foo foo for x in 1 2 3; do printf "[%s]\n" $x; done [1] [2] [3] uname -a Linux sun-go 4.15.0-167-generic #175-Ubuntu SMP Wed Jan 5 01:55:52 UTC 2022 i686 i686 i686 GNU/Linux ^C The shell language interpreter is in the eval command; we have not written a shell! The "for x in 1 2 3" syntax isn't coming from our "interpreter" loop. Lisp's eval isn't necessarily an interpreter. A Lisp implementation which has only a compiler will implement eval by compiling, like this: ;; insert expression into lambda expression. ;; compile lambda expression, resulting in a compiled function object ;; call function object, with no arguments. (defun eval (expr) (funcall (compile `(lambda () ,expr)))) You can write this function in any Common Lisp (just don't call it cl:eval). Thereby you obtain a compiling eval, even if the standard cl:eval is interpretive.

lispm 4y ago

REPL is a Read Eval Print Loop, which is a way to interact with a Lisp runtime. This is independent on how EVAL is implemented. A bunch of Lisp systems implement EVAL with an incremental compiler. An interpreter is a Lisp feature where code gets interpreted from source at runtime. Some implementations have one, some don't, some only have an interpreter, some only have a compiler, some have several compilers, some have both. > running sbcl without the REPL and produce an executable binary file The executable binary file in SBCL always includes the compiler. REPL: a user interface to execute Lisp code. Reads s-expressions, evaluates them and prints the results as s-expressions. EVAL: the interface to execute code. A function. Interpreter: an implementation of Lisp which interprets source code. Byte Code Interpreter: an implementation of Lisp which interprets byte code instructions. Compiler: an implementation of Lisp which can compile code to a) byte code, b) C code, c) machine code In-memory compiler: an implementation of Lisp where the compiler does not create files, but writes the executable code directly to RAM Whole-Program compiler: an implementation of Lisp, which only compiles whole programs and creates executables -> rare, but various examples exists

terminalcommand 4y ago
Thank you for taking the time to explain. I now get it. SBCL includes the compiler in each binary and this is called incremental compiling. That explains the expressiveness. It is kind of like a JIT when needed. Compile everything you can AoT, leave dynamic parts to runtime compilation. It makes perfect sense. Thanks . I guess the difference is that in an interpreter you don't go down to assembly, you parse and run stuff. The moment you cross the line to generate bytecode/machine code or transpile into a different language you get a compiler.
- lispm 4y ago
  Basically all SBCL code is pre-compiled. There is mostly no runtime compilation happening. Only if the user/developer actually wants it. For example one can connect to a running SBCL and have one or more networked REPLs into it.

kazinator 4y ago

The REPL (traditionally "listener") is a kind of interpreter, because it reads textual input, and hands it off for processing. There is some definition of "interpreter" which this meets. lispm's point is that it's not a/the Lisp interpreter. An Lisp interpreter and Lisp listener are different things. The listener is more like a "command interpreter". You can write a very poorly featured listener yourself, by literally following the REPL acronym: (loop (print (eval (read)))). You have not written a Lisp interpreter in four operators; the read and eval functions are doing that. The following is a copy and paste from an actual session: [1]> (loop (print (eval (read)))) (+ 2 2) 4 (let ((x 9)) (* x x)) 81 Some other languages are the same way. When Bash runs a script, it's not going through the interactive command line processor that is used for interactive input, which has completion, recall and editing. That command line processor isn't what parses and understands Bash syntax. We can write a REPL at the Bash prompt also. We can write a loop which reads a line of input, evaluates it as shell syntax, and then repeats that ad infinitum until we hit Ctrl-C: $ while true ; do read -r command ; eval "$command" ; done echo foo foo for x in 1 2 3; do printf "[%s]\n" $x; done [1] [2] [3] uname -a Linux sun-go 4.15.0-167-generic #175-Ubuntu SMP Wed Jan 5 01:55:52 UTC 2022 i686 i686 i686 GNU/Linux ^C The shell language interpreter is in the eval command; we have not written a shell! The "for x in 1 2 3" syntax isn't coming from our "interpreter" loop. Lisp's eval isn't necessarily an interpreter. A Lisp implementation which has only a compiler will implement eval by compiling, like this: ;; insert expression into lambda expression. ;; compile lambda expression, resulting in a compiled function object ;; call function object, with no arguments. (defun eval (expr) (funcall (compile `(lambda () ,expr)))) You can write this function in any Common Lisp (just don't call it cl:eval). Thereby you obtain a compiling eval, even if the standard cl:eval is interpretive.