Hi Juan/Frank,
Elixir has taken the key features of Clojure (especially macros, protocols) and used them to build a wonderful language on the BEAM. I'd take a look at Elixir if I were you - it's just too much for too little to try shoehorning Clojure notions into a BEAM-hosted system. That being said, Francesco, CEO of Erlang Solutions was here in Dublin last week, and after our chats he'll hopefully soon be in touch with people at Cognitect about interfacing between Erlang/Elixir and Clojure/Datomic. I see a big opportunity for a ClojureScript/Om front end, a Phoenix/Elixir/Erlang server, and a Datomic persistence layer. Regards, Fergal -- Fergal Byrne, Brenter IT Author, Real Machine Intelligence with Clortex and NuPIC https://leanpub.com/realsmartmachines Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014: http://euroclojure.com/2014/ and at LambdaJam Chicago, July 2014: http://www.lambdajam.com http://inbits.com - Better Living through Thoughtful Technology http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne e:fergalbyrnedub...@gmail.com t:+353 83 4214179 Join the quest for Machine Intelligence at http://numenta.org Formerly of Adnet edi...@adnet.ie http://www.adnet.ie On Wed, Sep 16, 2015 at 3:34 PM, juan.facorro <juan.faco...@gmail.com> wrote: > Hi Frank, > I'm wondering why no one ever posted a question/comment/reponse to this > thread. Personally I think Clojure is a great language and the Erlang VM is > a feat of engineering. I would love to think what other think about this > thoughts and about the possibility of having Clojure on the Erlang VM in > general. > There are some language features that don't quite map from Clojure to > Erlang though, which are a challenge to implement. For example it is my > understanding that all of Clojure abstractions rely either on Java > interfaces (on the JVM) or on protocols (ClojureScript). So I guess a good > implementation for the protocol mechanism would be needed for Clojure's > implementation on the Erlang VM. > In my head this means: > 1. Values would need to have a type tag, in order to be able to figure > out if they do or do not implement a certain protocol. > 2. A possible implementation would be a tuple whose first element is an > atom which represents the type (i.e. {type_whatever, ...}) > 3. All functions that support this scheme and also the ones that > participate in the protocol mechanism need to "wrap/unwrap" values for > "type checking". > 4. Previous points make interop with Erlang more complicated, since > Erlang code would need to account for this wrapping & unwrapping. Although > there could be a macro that figures some of these things automatically, > but > it would still not be a seamless Erlang/Clojure interop. > There is also the matter of *namespaces* and *vars*, Clojure's bread and > butter :P. > In ClojureScript *namespaces* are not a thing you can manipulate [1] (you > can't use **ns** for example), which could be a possible workaround to > avoid maintaining runtime information about namespaces. > *Vars* on the other hand are not reified in ClojureScript [2] (they map to > regular JavaScript variables). Vars either have a *root value*, are *unbound > *or (when they are dynamic) might have a *thread bound value*. The first > two are global state related to a var while the last one is local to each > process (when talking about the Erlang VM). There are ways of implementing > this in the Erlang VM, just to name one (which is probably not be the best > one) using an ETS for global vars state and the process dictionary for the > processes bindings (maybe implementing something analogous to Clojure's > frames approach). > Anyways... > These are just a couple of challenges in a possible implementation on the > Erlang VM, which I think are key. > Cheers! > [1] At least not the last time I checked, although ClojureScript is on its > way to being self-hosted so, who knows? > [2] The *var* special symbol provides compile time information though in > ClojureScript. > On Friday, July 13, 2012 at 2:15:18 PM UTC-3, FrankS wrote: >> >> Just became aware of this effort: "http://erlangonxen.org/"; >> >> which shows off some impressive properties: >> >> * Startup time of a new instance is 100ms >> * Instances are provisioned after the request arrival - all requests get >> handled >> * No instances are running waiting for requests - the cloud footprint is >> zero >> * the size of infrastructure is proportional to the maximum load - 8 >> servers may be enough >> * … >> >> All that begs the Q: would Clojure on an Elang-VM be feasible and make >> sense? >> >> -FrankS. >> >> >> > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
