Hola Juan,
First, I want to stress that my Erlang skills are very weak and most of
what I say is speculation -> add AFAIK to every statement.
1. Data structures, deftype, defrecord
New data structures(deftype, defrecord) can follow the Erlang convention of
using records and then naming them with `-type`. Clojure's data structures
'(), [], {}, #{} can naively use erlang:lists, erlang:array,
erlang:map/erlang:dict, and erlang:set. The first task here is to check if
the performance guarantees and basic operations are maintained. For
example, erlang:array s can't be directly compared for equality.
2. Namespaces, symbols, and keywords
It would be desirable to keep a namespace -> module one to one mapping. In
Erlang atoms are used both as symbols and keywords and are not namespaced.
Namespacing can probably be solved either by a munging mechanism or by
using . as described here[1]. For interop, Clojure keywords should probably
be represented as plain atoms and symbols as a new type. I'm not sure how
this would work.
3. Protocols and multimethods
Erlang doesn't have type based dispatch and the concept of extending an
implementation is somewhat supported by `-behavior` and `-callback`. I
don't know enough about Erlang's module system to know if that is enough to
implement Protocols and multimethods. It is very important that they are
extensible which might be hard/impossible in Erlang. I expect somebody with
more knowledge to try. Since they would be using the same dispatch
mechanism, there would be no performance difference between them.
4. Vars, atoms, refs, and agents
In an async context only agents make sense, in the same way that only atoms
make sense in ClojureScript. The problem is that while Clojure allows
applying arbitrary functions/closures over the reference, in a message
passing context only values can be serialized and used. Therefore the set
of actions over the agent would be closed as opposed to Clojure's
agents[2]. Closed-agents could be implemented on top mnesia or similar
libraries.
5. Strings
Strings can be problematic in Erlang. I would suggest to just copy Elixir's
model wholesale[3] and then figure out how well it maps to clojure.string
and if the list of characters vs unicode string mismatch leaks out.
With those five groups there is already a lot to figure out. Then there is
the problem of integrating necessary Erlang semantics into Clojure:
1. Pattern matching
I don't know if there are any gaps between Erlang's pattern matching and
core.match. In any case, it's a good model to follow.
2. PIDs, messaging! and the actor model
Try out syntax to represent ! and receive that works in Lisp and Clojure
idioms. I would look at LFE and Pulsar for this.
Once all those points are covered through prototypes/mocks figure out if
the effort is worth it. It might as well be that LFE/Pulsar are enough to
have a Clojure-like-thing with the desired semantics or Clojure with
almost-the-desired-semantics. I don't have a burning need for Clojure on
the BEAM and no time to actively pursue it but it does interest me. It
would be cool to ask a Google Summer of Code student interested in language
design to get a prototype working.
Best
Sebastian
[1] http://stackoverflow.com/questions/10896638/erlang-atoms-and
[2] http://clojure.org/agents
[3] http://elixir-lang.org/docs/v1.0/elixir/String.html
On Friday, September 18, 2015 at 8:30:09 PM UTC+2, juan.facorro wrote:
>
> 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 <[email protected]>
>>>> 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 [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
