|
|
| Author |
Message |
< Erlang ~ Getting around the "illegal guard expression" |
| fikre |
 Posted: Fri Mar 06, 2009 4:44 pm |
 |
|
|
Joined: 07 Nov 2008
Posts: 5
|
is there a way around the restriction that disallows functions from being included into guard expressions?
I'd like to implements something of this sort
loop(State) ->
receive
Any when check(Any, State) =:= true ->
ok, % process the request
loop(State)
end.
check(Value) ->
%some checks
true.
in order to 'filter' the requests based on the current state of the process leaving some of the requests in the mailbox waiting for the process to be in the desired state.
One solution would be to forward the requests back to the mailbox, but i would like to preserve the order of the requests.
I can also have the process keep track of the requests itself but i'de rather use the mailbox as its a cleaner solution.
Most solutions I've seen involve computing the function beforehand, but that is not possible in this case as far as I can see.
Is there any way around this? |
|
|
| Back to top |
 
|
| uwiger |
| Posted: Fri Mar 06, 2009 5:44 pm |
|
|
|
User
Joined: 03 Jul 2006
Posts: 604
Location: Sweden
|
fikre wrote: is there a way around the restriction that disallows functions from being included into guard expressions?
Not really, but what types of checks to you have in mind?
fikre wrote: I'd like to implements something of this sort
loop(State) ->
receive
Any when check(Any, State) =:= true ->
ok, % process the request
loop(State)
end.
check(Value) ->
%some checks
true.
It might help to have separate receive functions depending on state. In essence, the name of the function doing the receive denotes the state of the process. This is the textbook Erlang approach.
In general, your type of problem is a sign that you really might want to consider the textbook Erlang approach and submit to the restrictions of selective receive.
If pre-processing of the message is required, you can consider having a middle-man process in front of your state machine. This can make it possible for you to pattern-match on the message without complex processing. I've done this on occasion, where the message was XML, and my middle-man parsed and normalized it in a way that I could pattern-match on the type of XML structure.
fikre wrote: Is there any way around this?
If you want to be really sacreligious, you can call process_info(self(), messages), then iterate through the messages, calculating which one you want to receive, and pass the whole message as a variable for the receive to match on. 
Note that I'm not in any way recommending this, but the operation at least doesn't involve copying, since you're retrieving your own message queue, which is on the heap already (at least I think that this is the case.)
BR,
Ulf W |
|
|
| Back to top |
|
| fikre |
| Posted: Sat Mar 07, 2009 5:35 pm |
|
|
|
Joined: 07 Nov 2008
Posts: 5
|
I want this to be as generic as possible. I want to turn this into a behaviour (I'm trying to model some common design patterns for concurrency using behaviours: in this particular case I'm working on the guarded suspension pattern).
The process has no idea of what state it can be in as the state would be initialized and altered by the callback module's functions (similar to the gen_server behaviour).
the checker function will be created by the callback module aswell so we dont know what types of checks are going to be done.
process_info(self(), messages) might actually do the trick in my case. I will try it out and see exactly how dirty it gets.
Thanks for the advice uwiger |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
