[erlang-questions] illegal guard expression for IF illegal guard expression for "if"
Daniel Dormont
dan@REDACTED
Mon Dec 5 03:57:43 CET 2011
In my experience with Erlang so far, this is perhaps the weirdest
feature for me from a language standpoint. I understand the
motivations, but at least from where I sit, it's a weird mental leap
from there to "we allow these few functions, but not others." In fact,
not even all of the allowed functions are "pure" in the sense that,
say, a Haskell programmer would recognize. I'm specifically thinking
of node/0 and self/0. Still, I put this in the category of things not
to worry about, just accept and move on.
What are abstract patterns?
dan
On Sun, Dec 4, 2011 at 8:50 PM, Richard O'Keefe <ok@REDACTED> wrote:
> The essential point is that guards are part of pattern matching,
> and that to make pattern matching efficient you want the compiler
> to be able to move stuff around a fair bit. Now consider
>
> f(X, Y) when g(X), X > 0 -> ...
>
> This has the *same* meaning and effect as
>
> f(X, Y) when X > 0, g(X) -> ...
>
> but it wouldn't have if g(_) could be an arbitrary function.
>
> Back when I was still at RMIT I proposed stealing an idea from
> NU Prolog, which had ":- pure <predicate name>" declarations to
> inform the compiler that <predicate name> had no side effects &c.
> That's not quite strong enough: for a guard expression we want
> to know that it is pure and *bounded*. In the presence of bignum
> arithmetic, "bounded" is a little hard to define, but
> "time and temporary workspace polynominal in the inputs" gets close.
>
> Abstract patterns turn out to provide *exactly* the right mixture of
> expressiveness to handle most I-wish-I-could-call-this-in-a-guard
> needs and limitation to make it safe.
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list