On Mon, 12 Jul 2010 02:06:05 -0700 (PDT) Krukow <karl.kru...@gmail.com> wrote: > > On Jul 11, 11:55 am, stewart <setor...@gmail.com> wrote: > > Hi All, > > > > Has anybody considered implementing Clojure on BEAM. Are there any > > works or current attempts currently available? > > > > In your view where are the real trip ups for this to happen.
I looked into targeting a language to BEAM, and honestly the biggest obstruction for me at that time was that BEAM's bytecodes were (are currently?) not documented really at all. Maybe efforts like LFE (Lisp Flavoured Erlang) and Reia will change that as other people become interested in targeting their languages at BEAM. Currently I *believe* Reia is implemented as a cross-compiler, emitting Erlang source and immediately compiling it with the compile module, which completely sidesteps that issue. Someone else (Robert Virding?) would have to speak for LFE's compiler. It probably emits beamfiles directly but since I believe Robert, you know, wrote large portions of the emulator, he probably does not require a bytecode reference. :) Other obstacles I can see: * Implementing Clojure's shared-memory primitives like refs, agents, atoms on BEAM which AFAIK fairly strictly enforces shared-nothing. If one is willing to write Clojure in a non-shared-memory, Erlang-like style, they may simply opt to discard them, or substitute some sort of Clojure-flavored actor primitives to embrace the message-passing style of Erlang. This would not bother me that much (see [1]), but many others would argue it's not Clojure anymore and that you might as well use LFE. Or, alternatively, one might investigate using ETS or Mnesia memory tables for "shared memory", the latter already having transactional semantics. The fact that Clojure explicitly demarcates shared state makes this, on it's face, seem imminently doable, although likely with lots of performance red flags. * Data structures. BEAM does not have a native map or vector, let alone persistent ones, and ones written in Erlang/Clojure are likely to be slow. On the plus side, the data structures you do get (list and tuple) are already immutable, so no "this thing from Java-land might be mutable" wierdness that can occasionally happen on the JVM/CLR. Still, this could be a deal-breaker, I think, unless someone smarter than I am sees a good way to fit the data types together (again, see [1]). All that said, Clojure-in-Clojure (when it arrives) would make such an effort a lot easier. I'd wait for that even if I already had my mind set on porting Clojure. > > Instead you should take a look at Erjang > > /karl > My personal opinion was always that the BEAM emulator and it's process model was the really compelling part of Erlang, less so the language itself, so a JVM implementation of the Erlang language never seemed that interesting to me. But I have to admit, the performance numbers Erjang is posting took me completely by surprise. A stroke of brilliance using Kilim for the scheduler; I think my previous indifference assumed a naive JVM Erlang implementation that mapped processes onto Java threads and, you know, sucked. That said, I still think BEAM is pretty dang cool, and I continue to quietly root for implementers trying to target other languages to it. -Kyle [1] Clojure's appeal, for me, comes 95% from the fact that it's a lisp that has sane data structures as *first class members of the language*. Everything else, including a lot of what people like to brag about in Clojure like STM and being on the JVM, is icing as far as I'm concerned. I tried to learn Common Lisp, but when I found out that something as simple as a vector or a hash map was a second-rate data structure, I lost interest and went back to Python. Data structure seamlessness is frankly worth more to me than macros, because I need a vector or a hash map 100x more often than I need a macro. :) -- 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