I've thought about this a bit, and I am not sure whether I disagree. I think I do. "But honestly, if ClojureScript programs are composed of data forms directly

I've thought about this a bit, and I am not sure whether I disagree. I think I do. "But honestly, if ClojureScript programs are composed of data forms directly manipulable by the language itself then why not just provide eval anyway? The answer can be found, as many answers in life, in the tradeoffs." This seems to beat around the bush a lot so here's the problem as I see it: When the code hits the browser, ClojureScript programs are not composed of Data Structures. They are composed of Java script, which acts as an assembly code. In a normal lisp, you would have the compiler right along side the generated assembly, so there would be no big deal... you want to eval something, just compile it and link it in to the run-time. In this case, the compiler is on the server, the code is in the browser... to provide an 'eval', you would have to send an RPC from the server to the browser... It is disingenuous to say that you cannot support an optimizing compiler and maintain the presence of eval in the language. This is simply not true. What you cannot do is: 1.) Separate the compiler from the runtime. 2.) Aggressively ELIMINATE code that is not being used. "You cannot effectively leverage these libraries without an optimizing compiler utilizing dead-code elimination. You cannot have the optimizing compiler if you wish to support eval. Q.E.D." Note that it is 'the optimizing compiler' not 'an optimizing compiler'. It would be possible to have an optimizing compiler without dead code elimination, or even the same optimizing compiler with dead code elimination turned off (no idea of that is possible). I think that claim number 1 is the questionable one. It seems like it would be relatively easy to decide the level of dead code elimination by indicating whether eval is available to the language. It may just mean you have to declare what functions/packages are to be made available to eval (which from a security standpoint makes a lot of sense; actually). --- Thinking about it, A possible repl implementation would actually be fairly simple: 1.) Create a hashtable 2.) Fill hash-table with desirable functions to execute 3.) Write an interpreter that recursively applies the head symbol of a list to the tail of a list (by looking up the symbol in the hash table). (Edit: There may be another wrinkle, like looking up variable symbols).This is basically what eval does. 4.) Create a loop that parses a lisp list into a javascript list, and applies the interpreter. The hole here is that there is no way to define 'new' functions. This may be possible by having a function returning a function which calls our interpreter (and adding that to the hash table as a new function). The question I have about this is being able to use arguments.. but even that may be possible. In fact, the above seems to allow for dead code elimination, as you have declared exactly which functions you want accessible to the user. edit: Sorry if I offended, but what is wrong with my post?