Hi Sebastian, Thank you for your thoughts.
The biggest example is that the BEAM comes with a set of Data Types / Data > Structures and they can't be extended. While this is true, it doesn't mean it is not possible to implement new data structures in Erlang. There are a number of modules that implement additional data structures like array <http://erldocs.com/current/stdlib/array.html?i=32&search=array#undefined>, gb_sets <http://erldocs.com/current/stdlib/gb_sets.html?i=0&search=gb_sets#undefined> and others, which are mostly implemented using of tree like structures. Admittedly, this is not the same as being able to implement persistent data structure using mutable values, but might be enough for some (or maybe most) practical purposes. In any case, it would be a *limited subset* of Clojure (much more limited > than ClojureScript is). What makes you say this? Do you have a specific Clojure feature in mind that you think might be impossible to implement in the Erlang VM? To get a better answer, I propose to list Clojure's "features" and then > iterate through them to see if they can be reasonably implemented or if > they even make sense in the platform: I think the key phrase is *reasonably implemented*. I think your suggestion of going over each Clojure feature to consider how it could be implemented is spot-on. I have done this exercise and thought about possible implementations. For me a r*easonable implementation* is one that has good interoperability capabilities and doesn't add too much overhead because of Clojure language constructs, which is quite a challenge. What do you think? Cheers, Juan On Friday, September 18, 2015 at 11:06:53 AM UTC-3, Sebastian Bensusan wrote: > > Hi Frank, > > I've been thinking about this for some months now. The actor model is a > great fit for a number of applications and the BEAM is made for it.Though > it seems feasible, I'm afraid the result might not feel so close to > Clojure, at least with any reasonable performance. I hope I'm wrong. I got > this *impression* from attending several Erlang meetups[1] where the > language developers explain their design decisions and how they are > implemented in the BEAM. The conclusion seems to be: it's very hard to > deviate from the baked in semantics. The biggest example is that the BEAM > comes with a set of Data Types / Data Structures and they can't be > extended. On the other hand, porting the actor model to Clojure and the JVM > is within reach and Pulsar[2] is already there. > > In any case, it would be a *limited subset* of Clojure (much more limited > than ClojureScript is). > > To get a better answer, I propose to list Clojure's "features" and then > iterate through them to see if they can be reasonably implemented or if > they even make sense in the platform: > > protocols > multi-methods > lazy collections > refs (might make sense on top of mnesia) > atoms (syn > vars > etc. > > Hope this helps > > Sebastian > > [1] https://www.youtube.com/watch?v=fctrWbgbJg0 > [2] https://github.com/puniverse/pulsar > [3] https://www.youtube.com/watch?v=BvCBTpnlqs8 > > On Thursday, September 17, 2015 at 9:40:04 PM UTC+2, adrians wrote: >> >> Frank, I've also just found out about Lisp Flavored Erlang >> <http://lfe.io>, which, based on what I've read, does take some >> inspiration from Clojure, as well as Common Lisp. It seems to be more >> active compared to Joxa. >> >> On Friday, August 24, 2012 at 5:12:40 PM UTC-4, FrankS wrote: >>> >>> Just got this link "http://joxa.org"; about a new lisp-like language >>> thru prismatic: >>> >>> <quote> >>> >>> Joxa is a small semantically clean, functional lisp. It is a >>> general-purpose language encouraging interactive development and a >>> functional programming style. Joxa runs on the Erlang Virtual Machine. Like >>> other Lisps, Joxa treats code as data and has a full (unhygienic) macro >>> system. >>> >>> Joxa (pronounced 'jocksah') isn't Erlang, though its very compatible. >>> Its not Clojure though there is plenty of shared syntax. It's not Common >>> Lisp though that is the source of the macro system. While Joxa shares >>> elements of many languages, it is its own specific language. of all these >>> languages, and knowing these languages will help you get up to speed with >>> Joxa, but it is its own unique language. >>> >>> </quote> >>> >>> Just skimming the example shows a syntax that resembles clojure a little >>> bit… >>> >>> Wonder if that implementation as an example would make it easier to have >>> a clojure-on-erlang-vm implementation. >>> >>> Enjoy, Frank. >>> >>> >>> On Jul 13, 2012, at 10:15 AM, Frank Siebenlist <frank.si...@gmail.com> >>> 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.
