[erlang-questions] Miller's oversight

[ok]

I've just started reading Mark Miller's thesis, "Robust Composition:  
Towards a Unified Approach
to Access Control and Concurrency Control", or "all about E".  On  
page 170, writing about Erlang,
he wrote:

	Unfortunately, a process has only one processId, so the common  
convention is (sic.) for
	making a request and receiving a reply is for the client to include  
its own processId
	in the message as a reply port.  This gives the provider the  
authority, not only to
	reply to the client, but to invoke the client.  [He means that the  
receiver can not only
	send the expected reply message to the originator, but can send any  
number of messages
	of any form, at any time.]  It is not clear how to repair this  
convention within the
	overall Erlang framework.

My immediate reaction to this was "OK, how can we fix it?"  What  
would it be like to introduce
a "single-use" Pid, an atomic value which wraps a Pid so that you can  
send a message to it once
but afterwards it is useless?

My second reaction was "There is no problem: Miller has overlooked  
the fact that the process
the receiver replies to need not be the originator."

	reply() ->
	    S = self(),
	    spawn(fun () -> receive M -> S!M end end).

	reply(T) ->
	    S = self(),
	    spawn(fun () -> receive M -> S!M after T -> failed end end).

Instead of

	Untrusted!{request,self(),Data}

do

	Untrusted!{request,reply(),Data}

and all is well.  There's no point in putting this in a library,  
because in specific cases
you want tailored versions of the reply function that only accept the  
kind of response you
want to receive.

What Miller basically overlooked is just how cheap process creation  
is in Erlang.  As Erlang
programmers we should not make the same mistake:  we often think of  
processes as long-lived,
and so they may be, but we shouldn't be afraid to make processes that  
live for only a single
message.