1. Message-passing framework and 'actor' objects

Hi

could someone please comment on the potentialities of OpenEuphoria or Phix for the implementation of a message-passing framework (and 'actor' objects)? In an 'actor' model the objects send and receive messages to one another, triggering actions (each message essentially being a method call on the receiving object). I know, the OE/Phix framework is quite different from all this, but still I am curious about the possibility to implement some sort of actor model or at least emulate some of its functionality in OE/Phix. The idea came to me from the Io programming language (iolanguage.org) where the only entities are 'actor' objects whose structures are not fixed and can change quite radically at runtime. They reminded me of Euphoria sequences, whose structure is equally dynamic and can freely change at runtime. Io's objects are esentially hashtables containing slots (each slot being a key/value pair, where the value associated with a key can be a function and thus serve as a method of the object). Since our sequences can already be used to implement OOP and dictionaries too are already available, I was thinking that perhaps it could be possible to make our sequences behave like actor objects. I believe the crucial step would be to implement a message-passing framework to let the objects interact with one another. And of course, objects would also have to be made to operate as semi-autonomous entities (although interacting with each other). Again, I know that this is all very far from the current OE/Phix paradigm, but optimistically I imagine that just like basic OOP was introduced in Euphoria, although not officially, a step further could be taken to also implement actors, perhaps without even too much effort. I believe it all boils down to implementing a message passing infrastructure. Hypothetically, how much effort would it take to implement such a framework? Would it be necessary to modify the language itself or could this be implemented simply as an add-on to the language, as an external library?

I would really be grateful if you guys from both the OE and the Phix user communities shared your thoughts about this idea.

Thanks

GreenEuphorian

new topic     » topic index » view message » categorize

2. Re: Message-passing framework and 'actor' objects

Here are my thoughts, based on my understanding of the actor and message-passing patterns. I'm not too familiar with them so excuse my ignorance if that's the case.

You could probably design pluggable actor library, where you can register new actor types and then assign their required functions. I'd use maps to maps to create actor objects and assign their registered actor type and other properties, and pass the actor into the message passing interface. This is basically what I'm doing in mvc/model.e for Euphoria MVC.

For a message passing interface, would something like ZeroMQ or Redis work? ZeroMQ would allow you to spin up your own services and then pass messages around in a variety of patterns (pub/sub, etc.). Redis is a little similar, and has its own server, where you could post messages to a given key (the actor or actor type, probably) and then poll for them in some client service.

-Greg

new topic     » goto parent     » topic index » view message » categorize

3. Re: Message-passing framework and 'actor' objects

GreenEuphorian said...

Hi

could someone please comment on the potentialities of OpenEuphoria or Phix for the implementation of a message passing framework (and 'actor' objects)? In an 'actor' model the objects send and receive messages to one another, triggering actions (each message essentially being a method call on the receiving object). I know, the OE/Phix framework is quite different from all this, but still I am curious about the possibility to implement some sort of actor model or at least emulate some of its functionality in OE/Phix. The idea came to me from the Io programming language (iolanguage.org) whose only entities are 'actor' objects whose structures are not fixed and can change quite radically at runtime. They reminded me of Euphoria sequences, whose structure is equally dynamic and can freely change at runtime. Io's objects are esentially hashtables containing slots (each slot being a key/value pair, where the value associated with a key can be a function and thus serve as a method of the object). Since our sequences can already be used to implement OOP and dictionaries too are already available, I was thinking that perhaps it could be possible to make our sequences behave like actor objects. I believe the crucial step would be to implement a message-passing framework to let the objects interact with one another. And of course, objects would also have to be made to operate as semi-autonomous entities (although interacting with each other). Again, I know that this is all very far from the current OE/Phix paradigm, but optimistically I imagine that just like basic OOP was introduced in Euphoria, although not officially, a step further could be taken to also implement actors too, perhaps without even too much effort. I believe it all boils down to implementing a message passing infrastructure. Hypothetically, how much effort would it take to implement such a framework? Would it be necessary to modify the language itself or could this be implemented simply as an add-on to the language, as an external library?

I would really be grateful if you guys from both the OE and the Phix user communities shared your thoughts about this idea.

Thanks

GreenEuphorian

Is there anything to be gained? I looked at iolanguage.org, And I am pretty certain that what you are looking for is achievable.

new topic     » goto parent     » topic index » view message » categorize

4. Re: Message-passing framework and 'actor' objects

Bhupen1277 said...

Is there anything to be gained? I looked at iolanguage.org, And I am pretty certain that what you are looking for is achievable.

I like Euphoria more than I like Io (more standard syntax, sequences, etc), but the idea of having actor objects passing messages amongst them is too cool and intriguing for me to just let it go. I would like to have the best of both worlds.

new topic     » goto parent     » topic index » view message » categorize

5. Re: Message-passing framework and 'actor' objects

BTW the actor model is also used by programming languages that are much more professional and popular than Io, in the field of distributed computing and/or parallel computing.

new topic     » goto parent     » topic index » view message » categorize

6. Re: Message-passing framework and 'actor' objects

GreenEuphorian said...
Bhupen1277 said...

Is there anything to be gained? I looked at iolanguage.org, And I am pretty certain that what you are looking for is achievable.

I like Euphoria more than I like Io (more standard syntax, sequences, etc), but the idea of actor objects and message passing amongst them is too cool and intriguing for me to just let it go. I would like to have the best of both worlds.

You mean you want to have your cake and eat it. You should realise that the cake you ate would be same tasting as the one in your hand.

new topic     » goto parent     » topic index » view message » categorize

7. Re: Message-passing framework and 'actor' objects

GreenEuphorian said...

could someone please comment on the potentialities of OpenEuphoria or Phix for the implementation of a message-passing framework (and 'actor' objects)? In an 'actor' model the objects send and receive messages to one another, triggering actions (each message essentially being a method call on the receiving object).

If i understand you correctly...

Some time ago i wrote a preprocessor to make a universal type, wider than global type: it shared variables between OE programs. It also shared procedures/functions between programs. This was not a welcome addition to OE.

OE has a user type check. When you assign a value to a variable, that typecheck you write is called. My preprocessor replaced the "universal" type with "global" and added a call to a included file which used window's msg passing to broadcast the variable name and contents, which the include file of the other programs would pick up and handle.

A side effect is it was possible to shut down an app of shared procedures, re-write it, and re-run it, without shutting down those programs that made calls to it. It also eliminated the bottleneck of blocking calls, such as http.e (http.e still blocked, but if your http.e hung, it need not stop your main block of code or any other program).

All this is, of course, blasphemous to the tenets of Euphoria.

I did not try this compiled, only interpreted.

Kat

new topic     » goto parent     » topic index » view message » categorize

8. Re: Message-passing framework and 'actor' objects

katsmeow said...

Some time ago i wrote a preprocessor to make a universal type, wider than global type: it shared variables between OE programs.

It also eliminated the bottleneck of blocking calls, such as http.e (http.e still blocked, but if your http.e hung, it need not stop your main block of code or any other program).

Hey, me too! It was a preprocessor based on my threads.eu library.

katsmeow said...

OE has a user type check. When you assign a value to a variable, that typecheck you write is called. My preprocessor replaced the "universal" type with "global" and added a call to a included file which used window's msg passing to broadcast the variable name and contents, which the include file of the other programs would pick up and handle.

I didn't bother with the user type check (instead manually inserting code to validate each time) and I used sockets instead of windoze msg passing, but otheriwse it sounds like we more or less had the same idea.

katsmeow said...

It also shared procedures/functions between programs.

A side effect is it was possible to shut down an app of shared procedures, re-write it, and re-run it, without shutting down those programs that made calls to it.

Mine didn't do that (since the goal was to emulate threads, all instances have the same copy of code). However, adding those features would actually be pretty straightforward - this is standard with microservice arches.

katsmeow said...

I did not try this compiled, only interpreted.

I can't think of a reason that your preprocessor+library wouldn't work compiled, though...

This isn't such a big deal. The OE group has allowed interpreted only featurs before, e.g. task_yield() not working in a compiled shared library.

katsmeow said...

This was not a welcome addition to OE.

All this is, of course, blasphemous to the tenets of Euphoria.

Well, it otherwise would have been a perfect, welcome addition to OE. I don't remember the library now but from what you've described, it does suffer from one problem:

katsmeow said...

which used window's msg passing

So it is OS specific. Stuff that goes into the OE stdlib has to be cross-platform. The only exception is if it's a low-level wrapper for a low-level OS interface.

My threads.eu also only worked on *nix due to the fact that it relied on fork(), that meant that it also could not have gone into OE proper.

I could not even get my pipeio.e library into OE alone, since it was *nix specific. Someone else had to combine it with an unrelated w32 pipe library before it was accepted into the OE stdlib as std/pipeio.e .. and it's changed quite a bit since.

A lot of excellent but platform-specific Eu libraries like win32lib don't make the cut either.

The other thing is that even stuff that makes into into the OE stdlib can later be replaced by something else. For example, look at the current Roadmap - which has std/http.e phased out by Euphoria 5.0 and completely replaced with libcurl.

Likewise, Greg is replacing the current website code (made by Jeremy and friends and up to the latest standards when it was started .. more than ten years ago) with Euphoria MVC.

Thus I could easily see your library being replaced in the stdlib with a different one that used ZeroMQ .. which has the added benefit of allowing the programs to run on different boxen, in a more distributed fashion.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu