[erlang-questions] examples for erlang with joins
Hynek Vychodil
vychodil.hynek@REDACTED
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 <
hubert.plociniczak@REDACTED> 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 <vychodil.hynek@REDACTED>
>
> This test case is not clear for me:
>>
>> self() ! {test, test1, test2},
>> self() ! foo,
>> ok = receive
>> _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 <hubert.plociniczak@REDACTED>
>>
>>>
>>>
>>> 2009/3/8 Vlad Dumitrescu <vladdu55@REDACTED>
>>>
>>>> Hi,
>>>>
>>>> > receive
>>>> > {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,
>>> ok = receive
>>> foo and foo and foo and foo ->
>>> ok
>>> end,
>>>
>>> clear_mailbox(), %% purge all messages
>>> self() ! {one, 1},
>>> self() ! {two, 3},
>>> Z = 4,
>>> A = 1,
>>> ok = receive
>>> {two, 3} and {one, Z} ->
>>> error;
>>> {two, 3} and {one, A} ->
>>> ok
>>> end,
>>> self() ! {test, test1, test2},
>>> self() ! foo,
>>> ok = receive
>>> _X and foo ->
>>> error;
>>> X ->
>>> {test, _, _} = X,
>>> ok
>>> end,
>>> self() ! {test1, 10},
>>> self() ! {test2, 15},
>>> self() ! {test3, 10},
>>> ok = receive
>>> {C, X1} and {B, X1} ->
>>> try
>>> C = test1,
>>> B = test3,
>>> ok
>>> catch
>>> error:{badmatch, _} ->
>>> 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
>>> erlang-questions@REDACTED
>>> 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!
>> Try Good Data now for free: www.gooddata.com
>>
>
>
--
--Hynek (Pichi) Vychodil
Analyze your data in minutes. Share your insights instantly. Thrill your
boss. Be a data hero!
Try Good Data now for free: www.gooddata.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090309/ac281d71/attachment.htm>
More information about the erlang-questions
mailing list