> Because Crystal is compiled, it is impossible to have a true REPL
Impossible, or just hard?
Impossible, or just hard?
I would question what is meant by a 'true REPL'. It's certainly seems possible to build a REPL of a statically typed compiled language.
I’m hoping someone eventually makes a new one, possibly based on MIRI.
I didn't realise that SBCL is interpreted.
So compiled code can have a REPL, but a REPL needs an interpreter as well.
OTOH LispWorks uses an interpreter for the REPL interaction.
Yes, an Interpreter offers some more interactive features - but usually lacks the compile-time warnings/errors.
Now think about this in the context of a REPL, which again stands for Read, Evaluate, Print, Loop. If you write code and evaluate it right away, this whole business about checking your work won't work right. You would basically have to recompile your entire program on every REPL eval, which defeats the whole purpose of a REPL. There are lots of other tricks to getting this to work, as the article hints at, but they're all very unsatisfactory in delivering the freedom of a dynamic language.
SBCL:
* (defun foo (a) (+ a 42))
FOO
* (defun bar (b) (foo 10 20))
; in: DEFUN BAR
; (FOO 10 20)
;
; caught STYLE-WARNING:
; The function was called with two arguments, but wants exactly one.
; (SB-INT:NAMED-LAMBDA BAR
; (B)
; (BLOCK BAR (FOO 10 20)))
;
; caught STYLE-WARNING:
; The variable B is defined but never used.
;
; compilation unit finished
; caught 2 STYLE-WARNING conditions
BARLanguages like C which require header files and a pre-processor are much harder to write REPLs for. You can try to do it and you can build a thing that works kind of like a REPL (look I type code and press enter and it evaluates, yay), but the experience always falls short of using a dynamic language in a REPL. It's just not even close, and that's just due to the simple fact you're trying to use something in a way it's not intended. Compiled languages simply are not designed with a tight development loop as a major design goal.