Re:How to write Common Lisp in 2017 – an initiation manual
by juki on Wednesday March 29, 2017 @12:00AM
(#13983285)
SBCL actually does have an interpreter, but doesn't use it by default. You can set
sb-ext:*evaluator-mode*
Re:How to write Common Lisp in 2017 – an initiation manual
by lispm on Wednesday March 29, 2017 @01:02AM
(#13983550)
Though, to be fair, a 'real' Lisp interpreter often provides more interactive features. The Lisp interpreter sees the code as Lisp data and interprets that. This enables a few things.
Re:How to write Common Lisp in 2017 – an initiation manual
by lokedhs on Wednesday March 29, 2017 @05:11AM
(#13984509)
You don't need an interpreter for that. SBCL (as does other compilers) always compiles an expression prior to executing it, even when it's code as data passed to EVAL.
Re:How to write Common Lisp in 2017 – an initiation manual
by lispm on Wednesday March 29, 2017 @05:25AM
(#13984556)
> You don't need an interpreter for that.
For what?
> You don't need an interpreter for that. SBCL (as does other compilers) always compiles an expression prior to executing it, even when it's code as data passed to EVAL.
True, but that's not what a Lisp interpreter does and provides.
I was talking about the difference between an interpreter and a (possibly interactive) compiler. The interpreter works over source code as Lisp data. The compiler does not - it does not matter that the compiler compiles individual forms. At runtime the code is machine code. With an interpreter the code is Lisp data.
Think about it: What difference could that make, if the code gets actually executed by a real Lisp interpreter?
SBCL (most common CL implementation) don't have interpreter at all. It complies into machine code before execution even in REPL.