[erlang-questions] erlang sucks

[Robert Virding]

On 13/03/2008, David Holz <david_holz@REDACTED> wrote:
>
>
> 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. ;)


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.

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.

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.

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.

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.

"It is impossible to make something foolproof because fools are so
ingenuous."

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.

Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080313/351aaf20/attachment.htm>