This was also my best guess, Timothy and Stuart, but it does not explain why a redefined 'if' (or a competing symbol binding, Stuart?) in the REPL leads to
user=> if #<user$if user$if@118d189> while 'if' within a list form does not: user=> (if 3) java.lang.Exception: Too few arguments to if (NO_SOURCE_FILE:74) I think this is an inconsistent interaction model -- it might even hint towards an implementation flaw. If I manually decompose a list form and analyze its elements in isolation (first evaluate 'if' and then '3' in the REPL), the composite list form should behave accordingly, shouldn't it? I come up with this scenario in order to understand the precise behavior of Clojure's evaluation strategy regarding symbol bindings and special forms. As I said, I'm fully aware that it's no good idea to change 'if' or any other special forms in production code. Dominikus On 14 Mrz., 18:26, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: > Yes, with one correction: Clojure is not an interpreter. The Clojure > compiler treats certain symbols specially, such as `if`, `do`, and `def`. > You cannot redefine these symbols. > > -Stuart Sierra > clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
