[erlang-questions] guard expression restriction

[Richard O'Keefe]

On 2/12/2010, at 10:34 PM, Ulf Wiger wrote:
> I interpreted Richard's point as being that it's a rather simple matter
> to write your program with user-defined tests that are not guards,
> even today. I don't think it is as elegant, but it doesn't blow up in your
> face either.

That is exactly what I meant.
> 
> I wrote in a previous mail that tackling abstract patterns, higher-order
> patterns, and parameterised receive (possibly in one single approach)
> would have a more revolutionary effect on Erlang programming than 
> user-defined guards, as it would make it possible to do things that are 
> very hard or awkward to do today.

I didn't say anything then, but I agree completely.
There certainly needs to be a syntax for match specifications
that looks more like ordinary Erlang syntax; it is good that
match specifications CAN be built as data structures but bad
that they HAVE to.

I suspect that it may be possible to unify abstract patterns and
match specifications in the sense that an abstract pattern could
have in addition to its "pattern" and "expression" faces a third
"data structure" face.

I note once again that abstract patterns solve *most* of the
goals that user-defined functions in guards do.  Kostis Sagonas
proposes safety checks that require extensive analysis;
abstract patterns provide a simple, local, syntactic safety
check, allowing you to use an abstract pattern from another
module *safely* in an abstract pattern, without requiring any
"block compilation" mode (but able to exploit it if there is one).