[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?


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