Re: ClojureCLR questions
On Dec 4, 1:35 am, mac wrote: > Apologies if this has been answered, did a quick search but found only > pieces of info. > Is it possible to run ClojureCLR on Mono yet? > There was an issue with the BigDecimal dependency from J#? > > /Markus I don't know if anyone has tried running on Mono yet. ClojureCLR now has its own implementation of BigDecimal. There is no reliance on vjslib. I hope someone will give it a try and report back. -- 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
Re: ClojureCLR questions
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
Re: ClojureCLR questions
Apologies if this has been answered, did a quick search but found only pieces of info. Is it possible to run ClojureCLR on Mono yet? There was an issue with the BigDecimal dependency from J#? /Markus On Dec 3, 5:21 am, dmiller wrote: > 1. CLR Interop: Interop is the focus of development at the moment. > Work is progressing on those things that the JVM implementation > doesn't worry about: ref/out params, assembly references, generics, > etc. I haven't spent much think time on attributes yet. Do you > have some specific use cases? That would be stimulating. > > 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, ClojureCLR is almost identical to ClojureJVM. At this > point, I consider interop the bigger impediment. The game plan for > the near future: Interop, implementing the new deftype/reify/protocol > goodness, then maybe performance. deftype/&c affect IL generation, so > I'd like to get that done before coming back to look at the grungy > details of whether or not the CLR is inlining some little thing. > > 3. I'll let the folks who are better at Clojure programming style > answer this one. > > -David M > > On Dec 1, 11:41 pm, Mike K wrote: > > > > > Hi Clojurites! > > > I'm reading about Clojure and ClojureCLR with great interest. Since > > I'm a .net developer with little Java / JVM experience, I'm > > particularly interested in ClojureCLR. It seems like David M. and > > crew are doing a fantastic job with the CLR implementation! A few > > quick questions: > > > 1. Re. CLR Interop -- one thing I didn't see mentioned on the wiki > > is .net attributes (metadata). Will annotating methods, properties, > > etc with attributes be supported? > > > 2. What are the performance goals for ClojureCLR? I saw a video > > overview of Clojure by Rich in which he stated (perhaps with certain > > caveats that I don't recall) that essentially Clojure ran at speeds > > comparable to Java. Is having ClojureCLR run at speeds comparable to > > C# a realistic goal? What's the current performance story? > > > 3. I get the basic concept that native Clojure data structures are > > immutable and persistent. This is obviously an impedance mismatch > > when dealing with JVM or .net objects and APIs that are built around > > mutable state. Where can I more info regarding best practices in > > getting these two different animals to work well together within an > > app? > > > Thanks, > > Mike -- 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
Re: ClojureCLR questions
Thanks for your reply David! On Dec 2, 9:21 pm, dmiller wrote: > Do you have some specific use cases [for .net attributes]? That would be > stimulating. One (common?) use case is that a WCF service can't be implemented without support for attributes. I'm a big Python and IronPython fan, so I've been following IronPython developments in this area with some interest. IronPython only recently gained the ability to deal with attributes. My understanding is that there were two major sticking points: 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. Here's a good blog post with more details about the IronPython approach: http://ironpython-urls.blogspot.com/2009/04/addition-of-clrtype-to-ironpython.html > 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? 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? Thanks, Mike -- 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
Re: ClojureCLR questions
1. CLR Interop: Interop is the focus of development at the moment. Work is progressing on those things that the JVM implementation doesn't worry about: ref/out params, assembly references, generics, etc.I haven't spent much think time on attributes yet. Do you have some specific use cases? That would be stimulating. 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, ClojureCLR is almost identical to ClojureJVM. At this point, I consider interop the bigger impediment. The game plan for the near future: Interop, implementing the new deftype/reify/protocol goodness, then maybe performance. deftype/&c affect IL generation, so I'd like to get that done before coming back to look at the grungy details of whether or not the CLR is inlining some little thing. 3. I'll let the folks who are better at Clojure programming style answer this one. -David M On Dec 1, 11:41 pm, Mike K wrote: > Hi Clojurites! > > I'm reading about Clojure and ClojureCLR with great interest. Since > I'm a .net developer with little Java / JVM experience, I'm > particularly interested in ClojureCLR. It seems like David M. and > crew are doing a fantastic job with the CLR implementation! A few > quick questions: > > 1. Re. CLR Interop -- one thing I didn't see mentioned on the wiki > is .net attributes (metadata). Will annotating methods, properties, > etc with attributes be supported? > > 2. What are the performance goals for ClojureCLR? I saw a video > overview of Clojure by Rich in which he stated (perhaps with certain > caveats that I don't recall) that essentially Clojure ran at speeds > comparable to Java. Is having ClojureCLR run at speeds comparable to > C# a realistic goal? What's the current performance story? > > 3. I get the basic concept that native Clojure data structures are > immutable and persistent. This is obviously an impedance mismatch > when dealing with JVM or .net objects and APIs that are built around > mutable state. Where can I more info regarding best practices in > getting these two different animals to work well together within an > app? > > Thanks, > Mike -- 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
ClojureCLR questions
Hi Clojurites! I'm reading about Clojure and ClojureCLR with great interest. Since I'm a .net developer with little Java / JVM experience, I'm particularly interested in ClojureCLR. It seems like David M. and crew are doing a fantastic job with the CLR implementation! A few quick questions: 1. Re. CLR Interop -- one thing I didn't see mentioned on the wiki is .net attributes (metadata). Will annotating methods, properties, etc with attributes be supported? 2. What are the performance goals for ClojureCLR? I saw a video overview of Clojure by Rich in which he stated (perhaps with certain caveats that I don't recall) that essentially Clojure ran at speeds comparable to Java. Is having ClojureCLR run at speeds comparable to C# a realistic goal? What's the current performance story? 3. I get the basic concept that native Clojure data structures are immutable and persistent. This is obviously an impedance mismatch when dealing with JVM or .net objects and APIs that are built around mutable state. Where can I more info regarding best practices in getting these two different animals to work well together within an app? Thanks, Mike -- 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
