[erlang-questions] abstract/static modules, multicast, and best practices
Richard A. O'Keefe
ok@REDACTED
Wed Apr 16 05:01:29 CEST 2008
On 16 Apr 2008, at 4:26 am, Roberto Saccon wrote:
> on behalf of: Lasaro Camargos <lasaro@REDACTED>:
> When I saw the guarded receives of erlang, it seemed like it would be
> the perfect match since in my protocols, most actions are triggered by
> a message receipt. I though would be able to write:
> loop(State) ->
> receive
> {M} when CondA(State) andalso CondB(State) ->
> StateN = doStateTransition1(State)
> loop(StateN)
> {M} when CondA(State) andalso CondC(State) ->
> StateN = doStateTransition2(State)
> loop(StateN)
> end.
I want to make a slightly different point.
There are a number of CSP-ish languages, including Occam and
arguably including Ada, where the guards on receive clauses
are tested *before* announcing willingness to accept a communication.
Ada 95 LRM 9.7.1 "Selective Accept", the "dynamic semantics" section
makes it clear that FIRST the guards are evaluated to determine
which alternatives are really on offer, and AFTER that a communication
may take place involving one of the open alternatives.
The Ada syntax makes the order relatively clear:
when Guard => accept Entry; ...
The Erlang syntax makes Erlang's order relatively clear:
Pattern when Guard -> ...
If the Guard doesn't mention any variables bound in the Pattern,
the Erlang version effectively gives you the desired result. But
this does _in principle_ still leave the pattern matched against
every message in the mailbox. I don't suppose it's likely to be
a problem.
The reason I mention this is that not knowing TLA+, and given the
"CondX(State)" mentions on the e-message, I found that I couldn't
tell whether the original poster wanted test-before-accept or
test-after-tentative-accept.
More information about the erlang-questions
mailing list