[erlang-questions] Ideas for a new Erlang

[Sven-Olof Nystr|m]

Richard A. O'Keefe writes:
 > OAs far as I can tell, your line of argument is:
 > >
 > > 1. The bounded buffer example is a useful and relevant example of
 > >    Erlang programming.
 > 
 > No, that is NOT my line of argument at all.
 > All I claim for it is that it is a SIMPLE and FAMILIAR example.

So you are *not* claiming that it is useful and relevant?

 > > Since I disagree on point 1, I don't see much reason to discuss your
 > > other points.
 > 
 > Since you are mistaken about point 1, this really doesn't carry much
 > weight.
 > >
 > >
 > > 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.
 > 
 > What's unexpected about it?  Every Erlang example I post to this list
 > uses that placement.  I've used that placement ever since Peter van Roy
 > complained in his PhD thesis about how hard it was to tell "," and ";"
 > apart at the end of a line.  (It's also where many people in the
 > Dijkstra camp put their semicolons, although in imperative languages
 > with no need to distinguish ";" and "," I do not follow them.)

OK. Please note that I was not arguing against your practice.


 > > In Erlang, none of these things are true.
 > >
 > > - there is already a mechanism for buffering (mailboxes). No need to
 > >   implement a new one.
 > 
 > That simply isn't relevant to my argument.
 > >
 > >
 > > - dynamic allocation is available
 > 
 > That simply isn't relevant to my argument.
 > >
 > >
 > > - communication is asynchronous. Granted, one can simulate
 > >   synchronous communication, but I don't see you doing that here.
 > 
 > That simply isn't relevant to my argument.
 > 
 > My argument is simplicity itself:
 >     1. A process is like a concurrent object or actor.
 >     2. Just as a concurrent object or actor can be in different
 >        states, so can a process.
 >     3. A process that is willing to accept a message in SOME
 >        states may not be willing to accept it in ALL states.
 >        [I repeat: this has NOTHING to do with buffering, NOTHING
 >         to do with dynamic allocation, and NOTHING to do with
 >         the synchronicity or otherwise of communication.  It is
 >         a local fact about the process in question.]
 >     4. The differences between states may be so large that
 >        separate 'receives' are appropriate.  On the other hand,
 >        they may not.  A 'state-senstive receive' can be
 >        exponentially more concise than a combination of
 >        separate receives.

But an Erlang process is always willing to accept messages. Unlike an
Ada process (say) there is no way an Erlang process can prevent
another process from sending it a message. The process can choose not
to look at it, but that's another matter.


 > That's it, basically.
 > 
 > I would remind readers that
 > 	Naturam expellas furca, tamen usque recurret...
 > 	(Horace, Ep.1.10)
 > The relevance here is that although Concurrent ML _starts_
 > with simple mailboxes and events, a good part of CML hacking
 > is plugging these things together with combinators to get
 > with difficulty and obscurity what Erlang gets directly.

So your argument is: Concurrent ML tried something similar. It did not
work out.


 > > \As I said in my previous reply, you haven't really implemented  
 > > bounded
 > > buffers:
 > 
 > And it doesn't MATTER, because the example is about
 > the fact that a process doesn't want to accept _exactly_ the
 > same set of messages all the time.  The inspiration was in
 > fact the Santa Clause Problem.

So we agree that it's *not* an implementation of bounded buffers????

 > > Now, it might perhaps be interesting to compare how selective receive
 > > and channels can be used to implement
 > 
 > anything at all, really.
 > 
 > > If you still insist that the above is a correct implementation of
 > > bounded buffers,
 > 
 > "Still"?  "Insist?"  How could I "stil" do something I never started
 > doing?  Why "insist" when I never insisted?
 > 
 > The onus is on the proposer of a major emasculation of Erlang
 > to provide examples showing that it is a good idea.

I was merely trying to understand your argument.

So you do *not* claim that it's an implementation of bounded buffers?

Since I came up with the channel concept, I've been looking for some
convincing example of an Erlang program that could be implemented
using selective receive, but was not possible to implement using
channels (or where the solution with channels was more complex). When
I saw your buffer example, I thought for a moment that it was the
example I was looking for.


Sven-Olof