On 13/03/2008, <b class="gmail_sendername">David Holz</b> <<a href="mailto:david_holz@hotmail.com">david_holz@hotmail.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br> Yeah, I'm a little irate about the guard issue, simply because it seems it's clung to purely because of stick-in-the-mud attitude.  Yes, I know that guard BIFs compile into BEAM directly and have their own optimization strategy, but function calls are still BEAM code you can generate.  I don't care if it's a bit slower.  We use code generation from spec DSLs for all event types and now full protocol specifications, so the ability to defer "is this a Hello message?" decisions to external generated functions is a basic requirement.  Right now, we have to try to hack it into ?IS_HELLO style macros which expand to only guard BIFs where it can fit and mess with .hrl files.  If you say that that's a decent solution, I might have more irate words to dispense. ;)</blockquote>
<div><br>I don't definitely don't think that the main problem with user defined guards is efficiency or anything like that. It is not difficult to make a user function used in a guard as fast as the same function outside a guard.<br>
<br>The main problem is semantic! What does it mean when you call a general function inside a guard. The example which Richard gives is a good one. Assume I am in a receive and in the guard of testing one message I call a function which also receives messages. What happens to the message queue? Does the guard receive "see" the original message? Will the original receive "see" any messages removed by the guard receive? What happens if the guard receive takes the message the top receive is processing? Etc... Do I have logical message queue handling where each receive sees the complete queue it had when it was called? This problem is similar to the handling of the Prolog database which now are logical, but that does lead to some strange effects.<br>
<br>This is not just a matter of choosing any solution and running with it as you have to be able to explain it to people so it is understandable, consistent and USABLE.<br><br>One suggestion which has been made is to "turn off" using any unsafe BIF calls and have them cause the function to exit. But that would mean that user functions would behave differently if they are used normally or within a guard. Which could be difficult if you are calling functions from someone else's libraries.<br>
<br>The trouble with adding a feature like this, or any feature for that matter, is that you have to be able to handle all cases, and I mean *ALL* cases, not just the reasonable ones which you had in mind when planning the feature. And give meaning to all cases as well.<br>
<br>"It is impossible to make something foolproof because fools are so ingenuous."<br><br>Forgot about 'cond'. We should add that and allow any user code in the tests. We can either catch errors in tests and treat them as false or just let them generate a normal error. The latter I think.<br>
<br>Robert<br><br></div></div>