I did some investigations on the code in Compiler.java. There is an IPersistentMap called 'specials' (line 95, Clojure 1.2) that maps symbols like 'if' to parsers like IfExpr.Parser(); obviously, these are the parsers recognizing special forms.
Method analyzeSeq (line 5347) tries macro expansion first and gets the operator of a sequence form next. There is some special behavior if the operator is FN (namely 'fn*' for which no parser is associated in 'specials'; I don't know why 'fn*' gets special treatment here), then special parsers are activated if the operator is a special symbol, otherwise InvokeExpr.parse() is run. All this works as expected. Method analyze (line 5154) analyzes a given expression. If its a symbol, then analyzeSymbol (line 5556) is called, if its a form of kind ISeq, then analyzeSeq is called. There are more checks, of course. As one can see in analyzeSymbol, bindings are resolved but there is no check whether a special symbol like 'if' is used or not. The analysis of the code confirms the behavior of a "redefined" i.e. bound 'if' symbol. In favor of a consistent user experience (as described in the previous post), it simply shouldn't be possible to bind special symbols like 'if' to values at all. I guess that some few lines in Compiler.java could fix that. I don't know how Lisp treats this case. Dominikus On 14 Mrz., 22:09, Timothy Baldridge <tbaldri...@gmail.com> wrote: > Yes, I think if you dig down into the Compiler.java code (that's where > I assume this issue comes from) you'll probably find your answer. > > Recently in a blog entry Eric Lippert (one of the developers of C#) > handled this exact subject. There are some 'bugs' in languages that > exist, not because the developers don't know that they exist, but > because actually reproducing the bug results in code that would never > be used in production code. Sure this could be viewed as a bug, but > who cares? > > Timothy > > > > > > > > >> 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? -- 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
