Rebol / Red also have a reader though in its terminology it could be called a "loader". See LOAD function - http://rebol.com/docs/words/wload.html

Could you expand on that? I've searched a bit but the Lisp read doesn't sound too different from what other languages do.

This is probably the best blog post I've seen on the topic:

https://vvvvalvalval.github.io/posts/what-makes-a-good-repl....

> If you're not familiar with Clojure, you may be surprised that I describe the REPL as Clojure's most differentiating feature: after all, most industrial programming languages come with REPLs or 'shells' these days (including Python, Ruby, Javascript, PHP, Scala, Haskell, ...). However, I've never managed to reproduced the productive REPL workflow I had in Clojure with those languages; the truth is that not all REPLs are created equal.

Basically, the "REPL" you usually call a REPL is in fact a shell, and not a REPL as normally used in lisp languages.

I think FORTH has something very similar to the lisp REPL, if I'm understanding it properly. I know little of lisp, but everything I've read makes it seem that it and FORTH are almost evil twins of each other. Opposite but equal.

Thanks, from what I understand the difference I made between having a REPL and being able to do REPL-driven development is the one you make between a shell and a REPL.

Unlike most languages, Lisp defines how strings can be transformed to Lisp ASTs (s-expressions). In Scheme (which doesn't allow reader macros) this is a safe operation: you can read untrusted input without worry.

By contrast, most other languages only have eval() - which takes a string and parses and executes it as code. In Lisp, eval() takes a Lisp list object and executes that.

Ditto for Rebol & Red.

For eg.

  >> code: load "foreach n [1 2 3 4] [print n * 2]"
  == [foreach n [1 2 3 4] [print n * 2]
  ]

  >> type? code
  == block!

  >> do code
  2
  4
  6
  8