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
