object-oriented concurrent programming

35 views
Skip to first unread message

Duncan McGreggor

unread,
Jul 29, 2015, 4:14:10 PM7/29/15
to Lisp Flavoured Erlang
(This is a follow-up on the recent announcement from Robert on this Flavors work as well as individual conversations not previously on the mail list.)

I like to read the subject as "concurrent programming" with "object-oriented" being a modifying, descriptive phrase ;-) I think I might prefer a different phrase altogether, though: "concurrent programming with models and state".

One of the things that Robert has recently mentioned when talking about Flavors was the possibility of this being a system for concurrent oop, where objects were conceived as safe for a distributed LFE application. Needless to say, I began to froth at the mouth a bit with the prospect of a new area to research in the context of LFE :-)

One of my heroes in the world of concurrency and the actor model is Dr. Gul Agha [1], and he's done a bunch of very interesting research into concurrency and object-oriented systems. His full list of publications is here:

Starting from the bottom up (chronological order), these look good:

I'll stop there ... his papers get more and more interesting. Dr. Agha's research is a goldmine for areas to explore in LFE; had it been available to him when he started his research, I can't even imagine what we'd be doing with it now :-)

Of particular -- and more practical -- interest for me are topics such as:
 * the separation of models and the associated data of the models
 * approaches to shared data in a functional, share-nothing language
 * object instances in a distributed application and their knowledge of each other
 * what does distributed inheritance look like
 * how do changes in object code propagate to instances
 * similarly, changes in parent classes propagating to child instances
 * if object data is moved to ETS or Mnesia, how do we redefine garbage collection

Anyway, when Robert brought up the idea of concurrency in objects, it made this whole project seem even more interesting :-) I've got some books ordered from the library, and I expect to be doing a lot of reading on this. I think it would be an enormous amount of fun to provide a sensible syntax for LFE capabilities in the realm of distributed objects, simulations, and their associated data.

d

----

[1] In my EFSF 2014 LFE talk, I quoted an excellent sentiment of his from his PhD thesis: http://dspace.mit.edu/handle/1721.1/6952. It is a special delight that research for this paper was done at the MIT AI Lab, the original home of Lisp :-)

Eric Bailey

unread,
Jul 29, 2015, 4:34:20 PM7/29/15
to lisp-flavo...@googlegroups.com
Thanks for the reading list!

Since I write Clojure >= 80% of the time, I'm biased, but maybe we could take some queues from the actor, protocol, and concurrency models therein, or at least their syntactic abstractions. I know there's been talk re: the multimethod syntax, but Clojure's CSP model (core.async) is pretty great too.

I'm still pretty new to Erlang and I know it has a strong actor/message-passing system,  but maybe this is an opportunity to wrap it in a Lisp-ier package. Pulsar could be great source of syntactic ideas too: https://github.com/puniverse/pulsar. Its Erlang-inspired API makes it all the more poetic.


PS It could be cool to implement an LFE wrapper for supervision trees à la dire: https://github.com/MichaelDrogalis/dire


Sent from my iPhone, so sorry for any typos/incoherence.
--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

Robert Virding

unread,
Jul 29, 2015, 7:17:08 PM7/29/15
to Lisp Flavoured Erlang, dun...@mcgreggor.org, dun...@mcgreggor.org
One problem with using processes for objects is that it becomes basically impossible to send messages to yourself. OO "message sending" is basically a synchronous operation which makes it impossible (you have the classic case of a gen_server doing a call to itself). Even if you made the send asynchronous you could not use it to get information back, only to tell yourself to do something later.

Maybe if you had a defined way of calling methods as functions instead of message sends would do it. But you, or the system, would then have to keep track of if the object was myself.

I don't know if this is a real problem.

I still have my idea of keep the instances in ets tables so they are global objects and anyone can call them. This would work as an object is just its instance variables and a reference to the code module. But this would be very unerlangy. And you still have the problem that the objects won't go away by themselves but must be explicitly deleted.

Robert

Eric Bailey

unread,
Jul 29, 2015, 7:53:05 PM7/29/15
to lisp-flavo...@googlegroups.com
Would it be overly/unnecessarily complicated to implement a minimal reference counting (and appropriate deletion) system for the global objects stored in ETS tables? Also, I'm not sure if it goes against LFE's core ideology but a little unerlanginess seems palatable to me, at least. Would your idea have negative implications on Erlang interop?

Storing objects in ETS tables also seems like a great opportunity to manage some metadata such as docstrings (see other thread) and the like, which is very appealing to me from a homoiconic perspective.

Sorry if my thoughts are misguided or off-topic. I'm just very enthusiastic :)

Eric
--

Raoul Duke

unread,
Jul 29, 2015, 7:55:34 PM7/29/15
to lisp-flavo...@googlegroups.com
> One problem with using processes for objects is that it becomes basically
> impossible to send messages to yourself. OO "message sending" is basically a
> synchronous operation which makes it impossible (you have the classic case
> of a gen_server doing a call to itself). Even if you made the send
> asynchronous you could not use it to get information back, only to tell
> yourself to do something later.

random related thoughts:

Some folks dislike the whole "call-return" style that most programming
languages use, because it ends up making things be more coupled than
they would like.

If I understand correctly, Continuation Passing Style would mean that
you could ask for a value and then use it. Dunno if a surface syntax
could make it palatable.

Duncan McGreggor

unread,
Jul 29, 2015, 10:32:15 PM7/29/15
to Robert Virding, Lisp Flavoured Erlang
On Wed, Jul 29, 2015 at 6:17 PM, Robert Virding <rvir...@gmail.com> wrote:
One problem with using processes for objects is that it becomes basically impossible to send messages to yourself. OO "message sending" is basically a synchronous operation which makes it impossible (you have the classic case of a gen_server doing a call to itself). Even if you made the send asynchronous you could not use it to get information back, only to tell yourself to do something later.

I think I need a concrete example to understand what you're saying ... below I've pasted a process-based implementation of Peter Norvig's classic object example from PAIP:

(defun account-class (name balance interest-rate)
  (receive
    (`#(,method name ())
     (! method `#(ok ,name))
     (account-class name balance interest-rate))
    (`#(,method balance ())
     (! method `#(ok ,balance))
     (account-class name balance interest-rate))
    (`#(,method deposit (,amt))
     (let ((new-balance (+ balance amt)))
       (! method `#(ok ,new-balance))
       (account-class name new-balance interest-rate)))
    (`#(,method apply-interest ())
     (let ((new-balance (+ balance (* balance interest-rate))))
       (! method `#(ok ,new-balance))
       (account-class name new-balance interest-rate)))
    (`#(,method withdraw (,amt))
     (let ((new-balance (- balance amt)))
       (cond ((< new-balance 0)
              (! method #(error insufficient-funds))
              (account-class name balance interest-rate))
             ('true
              (! method `#(ok ,new-balance))
              (account-class name new-balance interest-rate)))))
    (`#(,method ,method-name ,_)
     (! method `#(error #(unknown-method ,method-name)))
     (account-class name balance interest-rate))))

(defun init-account (name balance interest-rate)
  (spawn (lambda ()
           (account-class name balance interest-rate))))

(defun send (object method-name)
  (send object method-name '()))

(defun send
  ((object method-name arg) (when (not (is_list arg)))
   (send object method-name `(,arg)))
  ((object method-name args)
   (! object `#(,(self) ,method-name ,args))
   (receive
     (`#(ok ,result)
      result)
     (other
      other))))
 
Usage would be something like this:

> (set acct (init-account 'alice 1000 0.1))
<0.39.0>
> (send acct 'name)
alice
> (send acct 'balance)
1000
> (send acct 'apply-interest)
1.1e3
> (send acct 'deposit 1000)
2.1e3
> (send acct 'balance)
2.1e3
> (send acct 'withdraw 2000)
100.0
> (send acct 'withdraw 101)
#(error insufficient-funds)

So are you saying that account-class can't call itself because any call to account-class starts the loop again? (i.e., starts waiting for a message)

Or do you mean something else?

If that is what you mean, then does't using send get around that? (i.e., send could be used in the body of account-class)

Awaiting illumination,

d

Duncan McGreggor

unread,
Jul 30, 2015, 10:46:12 PM7/30/15
to Lisp Flavoured Erlang
On Wed, Jul 29, 2015 at 3:34 PM, Eric Bailey <ifsixw...@gmail.com> wrote:
Thanks for the reading list!


I've just received the Springer-Verlag lecture series "Concurrent Objects and Beyond" (2014) from the library -- it is AMAZING. 

It's fascinating reading about the history of the work in this area (spawned in Carl Hewitt's group at the MIT AI Lab), since it mirrors so strongly what happened in the Ericsson Lab a few short years later.

[about an hour later ...]

Wow, the first two papers are great -- these are for ABCL/1 and ABCL/R, respectively. If anyone is interested in this stuff, this collection of papers is some of the best material I've seen in the field.

d

Robert Virding

unread,
Jul 31, 2015, 5:42:14 PM7/31/15
to Lisp Flavoured Erlang, ifsixw...@gmail.com
Yes, this would probably work but it would support from the Erlang machine to work. There is no way of implementing this with the current machine. Unfortunately.

You have the same problem with using processes as objects, the process has to be explicitly deleted. The reason using processes as objects makes it impossible for an object to send a message to itself is that the messages are asynchronous and would block the process. You would not have this problem with ETS objects. You would however have another problem, you could have many processes accessing an object concurrently without control, there is no support for transactions in ETS. Plague or cholera (swedish saying "pest eller kolera")

Robert

Raoul Duke

unread,
Jul 31, 2015, 5:47:16 PM7/31/15
to lisp-flavo...@googlegroups.com
messages-to-self: transform to CPS.

Robert Virding

unread,
Jul 31, 2015, 5:56:06 PM7/31/15
to Lisp Flavoured Erlang, dun...@mcgreggor.org
I meant that you access an object by sending a message to it and waiting for the reply. And while you are waiting you block the sending process. If sending process is the object process itself then it cannot process that message as it is waiting for the reply *in the wrong receive*. You get the same problem if two, or more, objects access send to each other at the same time, they will block waiting for a reply. It is a classic synchronous communication problem. The only real answer is to do things which can block in this way asynchronously. That's basic Erlang message passing is asynchronous. :-)

Forget that these are "objects" think of them as processes instead. Your example works because an account object does not communicate with another object (process). Add a method in which compares itself with another object and get it to compare itself with itself.

Robert

Duncan McGreggor

unread,
Aug 1, 2015, 2:02:06 AM8/1/15
to Lisp Flavoured Erlang
Ah, if course -- now I see what you're saying. Thanks!

d

--
Reply all
Reply to author
Forward
0 new messages