guidance

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

guidance

Fredrik Linder-2
> -----Original Message-----
> From: owner-erlang-questions
> [mailto:owner-erlang-questions]On Behalf Of Dustin Sallings
> Sent: den 28 april 2004 10:49
>
> On Apr 28, 2004, at 0:50, Vance Shipley wrote:
>
> > If you're new to Erlang and you're using the process dictionary
> > you're probably doing the wrong thing.  I have never used the
> > process dictionary and I've been writing Erlang for seven years.
> > The closest I've come to using it is recently in dealing with shell
> > sessions.  The command history uses the process dictionary.  With
> > the shell you need to have some persistence.  In all other cases
> > you pass accumulated state around in function arguments.
>
> I'm not using the process dictionary (I haven't found
> any reason I'd
> want to yet).  I have a getdict and getval are functions inside my
> module that send messages to my process and receive a response.  My
> concern is that I'm trying to do FP but it feels like OO with all the
> message sending and stuff.
>
> I'm not complaining, it is just a bit surprising.

Imo it is not at all surpricing that you get this feeling, especially since processes in fact are objects in one sense. Objects that has a thread of execution within them, so sending messages between two processes could be viewed as one object using the other.

A difference though is that OO in itself do not cover execution, as the erlang model does (with its processes). In many OO languages/systems one needs to handle semafors and critical sections, wheras in erlang one only needs to concern about processes.

And now I want to take the opportunety to thank those who created the concurrency part of erlang: I just *love* the concurrency solution -- the best I've seen so far!

/Fredrik


Reply | Threaded
Open this post in threaded view
|

guidance

Thomas Lindgren-5

--- Fredrik Linder <fredrik.linder>
wrote:

> Imo it is not at all surpricing that you get this
> feeling, especially since processes in fact are
> objects in one sense. Objects that has a thread of
> execution within them, so sending messages between
> two processes could be viewed as one object using
> the other.

Note furthermore that erlang processes are more
general than ordinary objects: the response to a
message can change by using gen_fsm or multiple
receives inside a single process. In a class, you have
one set of method implementations per method name. In
a process, the response depends on which receive you
(or which state) you are in.

The closest correspondence to this in OO, that I know
of, is "predicate classes".

Best,
Thomas



       
               
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


Reply | Threaded
Open this post in threaded view
|

guidance

Matthias Lang-2
Thomas Lindgren writes:

 > Note furthermore that erlang processes are more
 > general than ordinary objects: the response to a
 > message can change by using gen_fsm or multiple
 > receives inside a single process. In a class, you have
 > one set of method implementations per method name. In
 > a process, the response depends on which receive you
 > (or which state) you are in.

Am I completely misunderstanding something? Surely you're
not arguing that OO doesn't allow side effects?!

If I rewrite your last sentence. "In a class, the response [can]
depend[s] on which state you are in", that doesn't seem unnatural
in many popular OO languages.

Matthias


Reply | Threaded
Open this post in threaded view
|

guidance

Thomas Lindgren-5

--- Matthias Lang <matthias> wrote:

> Am I completely misunderstanding something? Surely
> you're
> not arguing that OO doesn't allow side effects?!
>
> If I rewrite your last sentence. "In a class, the
> response [can]
> depend[s] on which state you are in", that doesn't
> seem unnatural
> in many popular OO languages.

That's right, both processes and objects are stateful.
The difference is I am thinking of is what code is
executed when a method is invoked (or a message is
sent). Note also that this is a question of
convenience rather than expressive power. (Both are
Turing complete, right?)

Let me take a silly example to illustrate: consider an
object with two states (as in a state machine), open
and closed. The methods/messages vary in
implementation with the state and there are perhaps
many methods. We implement this object as a process.

In naive Erlang, using a single receive (corresponding
to a single set of methods in a class):

process(St) ->
   receive
     {From, is_open} ->
        case is_open(St) of
           true -> From ! true;
           false -> From ! false
        end, process(St);
     {From, flip_state} ->
        case get_state(St) of
           open -> process(set_state(closed, St));
           closed -> process(set_state(open, St));
        end;
     ... lots more methods ...
    end.

That is, you need to look in your explicit state and
modify it as you get messages/method calls. The state
is encoded in the instance variables. If you have a
lot of state variables, you may need to update a lot
of them when the state changes. Adding new states can
become tedious and error-prone, etc.

In naive Erlang with one state per receive:

open(St) ->
   receive
     {From, is_open} -> From ! true, open(St);
     {From, flip_state} -> closed(St);
     ... etc ...
   end.

closed(St) ->
   receive
      {From, is_open} -> From ! false, closed(St);
      {From, flip_state} -> open(St);
      ... lots of other methods ...
   end.

Adding a new state now means (a) a new state function,
and (b) transitions to/from the new state. In
Erlang/OTP, the difference between gen_server and
gen_fsm, if you will.

A similar construct for OO, "predicate classes", was
proposed by Craig Chambers in 1993. (That paper was
what made me think along these lines.)

<http://www.cs.washington.edu/research/projects/cecil/www/pubs/predicate-classes.html>

Anyway, I hope I have illustrated how standard OO
method calls (without inheritance) differs from
message passing to Erlang processes.

Best,
Thomas



       
               
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover