How would one implement an actor-based concurrent language in ruby? My thought is that only the correct way of creating programs is using actors, but I'm not entirely sure on how this could be done, and how the syntax/grammar could be, but I'm fond of the idea. I will use Ruby together with rdparser and celluloid (for actor implementation). My point is not to make it really "useful" or implement my own version of actors, more trying to create a functioning language based on concurrency with actors. Looking for examples, point to the right direction if this is even plausible.
6
-
When you talk about programming you should never say "the correct way of creating programs is..." There are always more then x ways to skin a foo.– coteyrMar 1, 2017 at 16:55
-
Have you looked at the existing actor languages? The original one (PLASMA), Act-1, Act-2, Act-3, Acttalk, Ani, Cantor, Rosette, for example? Reia, an actor language inspired by Ruby and Erlang? Erlang, an independent re-discovery of the actor model?– Jörg W MittagMar 1, 2017 at 20:22
-
@JörgWMittag Don't know if I'm not finding the correct one but the docs i found for PLASMA doesn't have a implementation of concurrency.– GrimboxMar 1, 2017 at 21:10
-
Ah, yes, there are two languages called PLASMA. I think the paper is called: "PLASMA: PLAnner-like System Modelled on Actors" by Carl Hewitt (the original author of the Actor Model), written in 1975. The language was originally called Planner-73, I believe. Gul Agha was one of the first researchers to join Carl Hewitt, he has written many papers on the Actor Model as well, and also designed the SALSA language (Simple Actor Language System and Architecture) and the Salsa-lite language. His PhD thesis is the reference on the Actor Model, it is one of the most cited computer science books …– Jörg W MittagMar 2, 2017 at 0:09
-
… of all time. There are also some papers out of France, e.g. "Plasma-II: an actor approach to concurrent programming", describing a minimal extension to PLASMA. And then there are myriads of Actor libraries, although most of them deviate substantially from the Actor Model as described by Hewitt and Agha.– Jörg W MittagMar 2, 2017 at 0:10
|
Show 1 more comment
1 Answer
First I am pretty biased against institutionally taught programming, and this is one of the reasons why. Now I just wanted to state that, so you can take this answer with a grain of salt.
Actors are a theoretical construct. They "can" mean what ever you want. At it's core actors are things that do things. Usually in a program focused on concurrency, an "actor" is an analogy for a unit of work that can be segmented off from the other units of work in such a way that the program will still function rather or not the actor is called, what order it's called in, or if it takes a really long time to do it's unit of work.
Take an import process. An actor could
- open the file
- read it line by line
- Transform the data
- close the file
This may be the import actor.
The read it line by line may be another actor, as well as the transform "unit of work" may be an actor. However, the open, and close calls can not be "separate" actors. You can not close the file, then read it line by line.
In other words. Actor is just a thing. A name for a way of doing things. It's a theory, a way of modeling a process to do stuff in a way we humans can understand. It may help us understand and "flesh out" what we are trying to do, but in the end it's just a "do-hickey" A construct that you as the programmer can implement.
Now that said, there are some tools that can help with concurrency. https://github.com/celluloid/celluloid for example helps. https://github.com/ntl/actor may be something to look at. But keep in mind, that actors are not a real thing, they are a pattern, or a model and while some gems may help you with messaging or threading, there is no single hard and fast setup that is an "actor".
-
Wouldn't it be possible to create a reasonable language that only consists of these actors then? Something like the program consists of actors, actors consists of functions and/or classes and you create the program by communicating between actors.– GrimboxMar 1, 2017 at 17:41
-
3I couldn't resist: en.wikipedia.org/wiki/Shakespeare_Programming_Language Mar 1, 2017 at 19:21
-
Sure why not, you can create anything you want. Actors are just a theoretical construct. One could argue that notepad.exe is an actor, with many sub-actors. You could create a language that focused on concurrency. Just keep in mind that a computer can still only process one instruction at a time (per CPU anyway)– coteyrMar 1, 2017 at 19:44