[erlang-questions] Parse-transforming !! to a function call

[Richard Carlsson]

Kenneth Lundin wrote:
> The !! operator as described by Joe is however something that we have
>  no plans to introduce in the standard language since we think it has
>  so many problems and questionmarks and does not offer anything but 
> syntactic sugar. A !! B instead of rpc(A,B) . Example of problem is 
> that a synchronous rpc can fail in various ways, for example if the 
> server does not respond at all. For how long shall the client wait? 
> If we want a timeout , how should that be specified with that syntax
>  etc. etc.?

Hear, hear! The !! syntax looks alluringly simple, but it is far from
clear what the details of its semantics ought to be. There are many
possible variations of RPC, in particular with respect to what it
guarantees in the presence of failure. Furthermore, it would be
necessary to standardize the format of messages, and that is another
area where that which is sufficient for some applications, e.g.
{ok, Value}, would be too brittle for other applications that might
want to include a special tag or a unique reference in requests, to be
part of the replies, e.g. {reply, From, MsgID, Value}.

I'm not saying that it's impossible to come up with a straightforward
behaviour that matches what most people need most of the time, but it
really needs to be worked out properly before a new operator is
dedicated to it. Meanwhile, stick to plain old function calls, please.

To end this on a more positive note, I'd like to encourage everyone on
this list to keep thinking about how Erlang process communication could
be made even simpler and more streamlined. Plain asynchronous message
passing (with selective receive) is a powerful yet simple building block
but it is still rather primitive, and often, Erlang programmers (myself
included) will neglect to think too far about what might happen if
messages are lost, timeouts occur, or messages arrive in an unexpected
order. We tend to go back and fix those bugs when they bite us, but it
would be better if we were using communication constructs that came with
certain guarantees to begin with; like the difference between goto-
programming and structured language constructs like while/for/case.

     /Richard