Mike K, > 1. IronPython needs to be syntactically compatible with Python, so > there were struggles over an attribute syntax that would be valid > Python syntax > > 2. Python class (type) semantics are more flexible than .net type > semantics, so classes in IronPython are not real .net types. > > I would suspect that point 1 would not be much of an issue for > ClojureCLR. I have no idea about point 2 but would like to hear your > take.
Regarding (1), we have a lot more flexibility in how to hack syntax, but where it goes and how it looks are still going to require some thought. A careful analysis of where Clojure defines new JVM/CLR classes, such as proxy, is required. It is probably best to defer this until deftype/reify and other goodies in the 'new' branch settle down. Regarding (2). Clojure-defined types, as in proxy/deftype/etc. exist directly as JVM/CLR types, unlike IronPython, so this should not be a problem for us. Thanks for the links to the IronPython/attributes material. > > 2. Performance goals: Clojure:Java::ClojureCLR:C#. Not there yet, > > but no reason why this is not achievable. If you look at the IL > > generated,ClojureCLRis almost identical to ClojureJVM. > > This comes as a pleasant surprise to me. I know very little about > Clojure, but based on my naive understanding that it's a dynamic > language implemented on top of the DLR, I would have thought that C#- > like performance would be a bridge too far. Isn't there a significant > cost to be paid for the late binding and runtime checks > (notwithstanding partial amelioration of the issues via the DLR's > support for caching the results of method binding, etc.)? Nobody > really talks about C#-like performance goals for IronPython or > IronRuby. Is Clojure in any sense "less dynamic" than those > languages? My proportionality equattion (Clojure:Java::ClojureCLR:C#) was an attempt to say that I hope to make ClojureCLR performance relative to the more static languages on the CLR close to the performance of Clojure relative to Java. Note that I'm making no statement about the actual perf of Clojure relative to Java. Look around this group's archives and you will find plenty of discussion of that topic. ClojureCLR will pay pretty much the same price as ClojureJVM for late binding and runtime checks. The implementations are pretty much identical. I am about to put in code to take advantange of the DLR's call sites and the caching that comes with that for host expressions (CLR interop). I may get some avoidance of reflection that ClojureJVM *currently* does not enjoy. The most significant difference I know of in the implementations is an extra indirection through a static field that takes place during Clojure function invocation. It could well be that that can be inlined by the CLR optimizer, but I haven't had time to check it. (This difference is caused by a limitation of the DLR--it can only generate static methods into AOT-compiled code.) My equations was also designed to sidestep any issues of JVM versus CLR performance. > Also, while I have your attention, another question: I think the CLR > provides support for optimized tail calls. Does / will ClojureCLR > take advantage of this capability? Not in a direct way. When you write Clojure code, you will still want to use recur properly. That sidesteps the issue. (There may be some effect on some very internal implementation details, but nothing that would effect the Clojure application programmer.) -David -- 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
