5 ms·

> A large advantage of lisp like languages is the data-as-code paradigm. To give up eval is to give up this. Code as data is about (among other things) program

> A large advantage of lisp like languages is the data-as-code paradigm. To give up eval is to give up this. Code as data is about (among other things) programs writing programs, the majority of which (compilers and macros) don't need runtime eval, i.e. the program that writes the program isn't the program that's running it. Neither I, nor anyone I know, needs runtime eval of ClojureScript code in the browser. As the post states, it's certainly not needed for REPL interaction with a browser, something we intend to support. Why should we spend time writing something with no demonstrated need, other than to satisfy peoples' abstract notions of what constitutes a Lisp? Whole program optimization: "Optimizer, here is my entire program, do whatever you can in pursuit of size and speed: renaming, moving and eliminating as you see fit." Runtime eval: "Oh, wait, here's more program!" You can't do the former well and support the latter. If you think having the choice is important, write the code. Here's some of what's required: A ClojureScript port of the compiler (when multimethods are finished, not too bad) Syntax quote Runtime representation of namespaces, vars etc What you'll end up with is something that generates huge, slow JavaScript programs. Make sure to emphasize to your users "But it has eval, and is written in a real Lisp!". Seriously, I'm sure someone somewhere might actually require this, but they'll have to satisfy their own needs.

seles 15y ago
"As the post states, it's certainly not needed for REPL interaction with a browser" Ok, it is not needed per se, but how can it be done without also writing your own parser and evalulator? I didn't see mention of the how in the article. Also it's not Runtime eval: "Oh, wait, here's more program!" It's: "Oh, you forgot this part of the program, that I already gave you an exact description of". I'm not advocating any sort of complicated change, just evaluating simple independent expressions that generate the input to evals. I hypothosize that in most cases this is possible. Maybe eval is more often used in ways that does depend on input (REPL is such a case).
- JoelMcCracken 15y ago
  I'm not sure exactly how this would be implemented, but the repl action would be to send your browser clojurescript to a server, which then compiles it, which then replies to you, which you then append to the dom in a script() (or, eval it). This seems tricky, though, because it seems as though you'd need a to evaluate it within the context of the previously compiled environment, and ideally you would want to return /only/ the newly required code + libs. You wouldnt want to return code that re-initializes the dom, for example. https://github.com/ibdknox/brepl https://github.com/ibdknox/brepl has that repl implementation.
apgwoz 15y ago
Honestly, an in-browser REPL isn't compelling to me. What's compelling is an on the fly compiler / evaluator so that I can run Clojure code via node directly (or some other JS via the CLI) without starting up the JVM.
billstclair 15y ago
Simple Lisp READ and EVAL are very small programs. Supporting all of Clojure would be a bigger project, but enough for a useful REPL is a quick undergraduate project. Unless for some odd reason ClojureScript doesn't have APPLY.

seles 15y ago

"As the post states, it's certainly not needed for REPL interaction with a browser" Ok, it is not needed per se, but how can it be done without also writing your own parser and evalulator? I didn't see mention of the how in the article. Also it's not Runtime eval: "Oh, wait, here's more program!" It's: "Oh, you forgot this part of the program, that I already gave you an exact description of". I'm not advocating any sort of complicated change, just evaluating simple independent expressions that generate the input to evals. I hypothosize that in most cases this is possible. Maybe eval is more often used in ways that does depend on input (REPL is such a case).

JoelMcCracken 15y ago
I'm not sure exactly how this would be implemented, but the repl action would be to send your browser clojurescript to a server, which then compiles it, which then replies to you, which you then append to the dom in a script() (or, eval it). This seems tricky, though, because it seems as though you'd need a to evaluate it within the context of the previously compiled environment, and ideally you would want to return /only/ the newly required code + libs. You wouldnt want to return code that re-initializes the dom, for example. https://github.com/ibdknox/brepl https://github.com/ibdknox/brepl has that repl implementation.

apgwoz 15y ago

Honestly, an in-browser REPL isn't compelling to me. What's compelling is an on the fly compiler / evaluator so that I can run Clojure code via node directly (or some other JS via the CLI) without starting up the JVM.

billstclair 15y ago

Simple Lisp READ and EVAL are very small programs. Supporting all of Clojure would be a bigger project, but enough for a useful REPL is a quick undergraduate project. Unless for some odd reason ClojureScript doesn't have APPLY.