[erlang-questions] Pipe Operator in Erlang?

[Robert Virding]

On 10 July 2015 at 07:22, Éric Pailleau <eric.pailleau@REDACTED> wrote:

>
> Le 10 juil. 2015 01:18, Fred Hebert <mononcqc@REDACTED> a écrit :
> >
> > On 07/10, Éric Pailleau wrote:
> > >A = catch Pid |  {somemessage, somevalue }.
> > >This would probably need a timeout. On other hand,  ! + receive may
> wait forever. | could do the same.
> >
> > A = [catch Pid | {somemessage, somevalue}].
> >
> > Is A equal to:
> >
> > a) [Pid | {somemessage, somevalue}] (improper list)
> > b) [Result] (the received message)
> >
> Yes, you are right. But I do not request that pipe must be the operator.
> If !! Is better, I do not care. The need is more important than the syntax
> itself.
>
>
> > It also ignores that two processes may have more than two communications
> > going on at the same time, and that without a selective receive, it's
> > not obvious that anything would match properly.
> I m not sure to understand there. We are talking about synchronous
> message. When using gen_server:call you do not receive answer to another
> request,  but yours.
>

It does that because the gen_server:call wraps your message with a tagged
tuple containing for the sender pid and a unique ref. It then goes into a
receive waiting for a message containing that unique ref. The receiving end
understands this when it sends it reply it includes the unique ref so the
sender will receive the right message.

The reason for explicitly doing all this work is that all the receiving
process sees is exactly the message that was sent, no more no less. There
is no implicit information included at all. This means that if you were to
add a synchronous message then you would have to either add a new message
handling, not just in the message itself but maybe in receive as well. Or
you could say that one of these messages will have a specific format which
you can receive and you must reply with a specific format.

Another problem is that synchronous message passing is much more complex
and you need to define/handle many more things in the system than with
async messages. For example how to handle you not getting a reply, do you
use timeouts, or check if the other process has died, or a combination of
both, etc? So you either end up with a set of special case operators/calls
or a call with lots of options.

And how should it work with distribution where today it is the same.

No, I didn't like Joe's suggestion. :-)

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150714/429337c3/attachment.htm>