[erlang-questions] Ideas for a new Erlang

[Richard A. O'Keefe]

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.
>

> 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.)

> 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.

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.

> \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.

>

> 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.