# [erlang-questions] examples for erlang with joins

Hynek Vychodil <>
Mon Mar 9 14:25:31 CET 2009

```If I understand it now, message permutations are generated in outer loop and
each one is matched against patterns.

On Mon, Mar 9, 2009 at 2:08 PM, Hubert Plociniczak <
> wrote:

> Message {test, test1, test2} is first in the message. foo is second.
> Similarly as in original receive I take the newest message and check if
> only with this message I can satisfy any of the joins.
> If that is not possible, then I go the next message and check if any of the
> joins can be satisfied using the new message (and all previous ones).
> Since {test, test1, test2} already satisfies one of the joins, then I fire
> it immediately and do not look at what else is in the message
> after {test, test1, test2} (though I might obviously look at it in the
> future, if I have any receive constructs afterwards).
>
> I hope that helps.
>
>
>
> 2009/3/9 Hynek Vychodil <>
>
> This test case is not clear for me:
>>
>> self() ! {test, test1, test2},
>> self() ! foo,
>>          _X and foo ->
>>          error;
>>          X ->
>>          {test, _, _} = X,
>>          ok
>>      end,
>>
>> Can you describe more verbosely why first pattern should not match.
>>
>> 2009/3/9 Hubert Plociniczak <>
>>
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>> >   {foo, One} and {bar, Two} when (One > Two) ->
>>>> >     expr.....;
>>>> >  ....
>>>> > end
>>>>
>>>> Thiss looks interesting, but could you please describe the semantics
>>>> of the above example? Does it match for the two messages in sequence,
>>>> does one of them have to be the first in queue, is order important?
>>>>
>>>
>>> Let's assume that in the mailbox we have messages(from oldest to newest):
>>> [ {foo, 12}, {bar, 2} ]
>>> or
>>> [ {bar, 2}, {foo, 12} ]
>>> Then both will match because I check all the possible permutations. The
>>> order is important when we have
>>> more Joins and it works in a similar way as standard selective receive,
>>> i.e. the first valid permutation will match.
>>>
>>> Here is an extract from my test cases to give you an idea of what I want
>>> to achieve (should be self-explanatory):
>>>
>>>     self() ! foo,
>>>     self() ! foo,
>>>     self() ! foo,
>>>     self() ! foo,
>>>          foo and foo and foo and foo ->
>>>          ok
>>>      end,
>>>
>>>     clear_mailbox(),  %% purge all messages
>>>     self() ! {one, 1},
>>>     self() ! {two, 3},
>>>     Z = 4,
>>>     A = 1,
>>>          {two, 3} and {one, Z} ->
>>>          error;
>>>          {two, 3} and {one, A} ->
>>>          ok
>>>      end,
>>>     self() ! {test, test1, test2},
>>>     self() ! foo,
>>>          _X and foo ->
>>>          error;
>>>          X ->
>>>          {test, _, _} = X,
>>>          ok
>>>      end,
>>>     self() ! {test1, 10},
>>>     self() ! {test2, 15},
>>>     self() ! {test3, 10},
>>>          {C, X1} and {B, X1} ->
>>>          try
>>>              C = test1,
>>>              B = test3,
>>>              ok
>>>          catch
>>>              C = test3,
>>>              B = test1,
>>>              ok
>>>          end
>>>      end.
>>>
>>> I am also working on Operational Semantics for this extended version of
>>> Erlang with Joins, but it is still work in progress.
>>>
>>> Zvi,
>>>
>>> >nice work. Does it work only inside receive or for any pattern match?
>>> >If it's supporting generic pattern matching, I would suggest, rewriting
>>> >mochiweb HTML parser, using your join patterns.
>>>
>>> This is only designed for matching on the messages in the mailbox.
>>>
>>> hubert
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>>
>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>>
>> --
>> --Hynek (Pichi) Vychodil
>>
>> Analyze your data in minutes. Share your insights instantly. Thrill your
>> boss.  Be a data hero!
>>
>
>

--
--Hynek (Pichi) Vychodil