[erlang-questions] Ideas for a new Erlang

[Sven-Olof Nystr|m]

Richard A. O'Keefe writes:
 > The mail you say you have commented on included the
 > selective receive version first.  It's an absolutely standard
 > bounded buffer that accepts 'get' requests only when the buffer
 > is not empty and 'put' requests only when the buffer is not full.
 > Because there are two kinds of requests, under your scheme there
 > have to be two channels.
 
I'll focus on your bounded buffer example, since the other points in
your argumentation seem to be based on it.

As far as I can tell, your line of argument is:

 1. The bounded buffer example is a useful and relevant example of
    Erlang programming.

 2. The bounded buffer example is difficult or impossible to express
    using channels.

Since I disagree on point 1, I don't see much reason to discuss your
other points.

Let's take a second look at your buffer example:

 > 	buffer(Status, Contents) ->
 > 	    receive
 > 	        {put,Msg} when Status /= full ->
 > 		    {Status1, Contents1} = add(Contents, Msg)
 > 	      ; {get,Who} when Status /= empty ->
 > 		    {Status1, Contents1, Msg} = pop(Contents),
 > 		    Who ! Msg
 > 	    end,
 > 	    buffer(Status1, Contents1).

At first, I thought it looked pretty elegant, including the somewhat
unexpected placement of the semicolon. However, a moment's reflection
changed my opinion.

Now, I can see why one would want to write something similar in a
language with synchronous communication such as Ada. 

 - There is no implicit buffering, so buffering has to be implemented.

 - There is no dynamic allocation of memory (maybe that's changed?),
   so buffers must be bounded.

 - Synchronous communication implies that if the receiver refuses to
   accept a message, the sender will be suspended.  Thus, when the
   buffer is full, senders will have to wait until there is room in
   the buffer.

In Erlang, none of these things are true.

 - there is already a mechanism for buffering (mailboxes). No need to
   implement a new one.

 - dynamic allocation is available

 - communication is asynchronous. Granted, one can simulate
   synchronous communication, but I don't see you doing that here.


As I said in my previous reply, you haven't really implemented bounded
buffers:

 > When the buffer is full, incoming 'put' messages will be kept in
 > the mailbox instead of stored in the buffer, so they will still
 > require approximately the same amount of memory on the heap. For an
 > outside observer, there will be no difference between this buffer
 > and one that uses an unbounded data structure, except that it is
 > easier to overflow the mailbox of the bounded buffer.


Now, it might perhaps be interesting to compare how selective receive
and channels can be used to implement either

 a) a correct implementation of bounded buffers or 

 b) an implementation of unbounded buffers.

If you supply one using selective receive, I'll try to give the other.


If you still insist that the above is a correct implementation of
bounded buffers, I suggest that you show a context where the "bounded
buffer" behaves differently from an unbounded one.


Sven-Olof