+1<br><br><div class="gmail_quote">On Thu, May 15, 2008 at 3:27 AM, Richard A. O'Keefe <<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I feel that this proposal is a step in the wrong direction,<br>
and has "hack" written all over it.<br>
<br>
Let's start with the pattern-match operator,<br>
<br>
        pattern ~= expression<br>
<br>
I already feel slightly queasy at the fact that pattern matching<br>
is associated with guards everywhere EXCEPT pattern = expression;<br>
adding another construction that will work some but only some of<br>
the time does not appeal to me.  Right now, I can do<br>
<br>
        1 = f()<br>
<br>
but I cannot do<br>
<br>
        (X when X > 1) = f()<br>
<br>
Right now, any instance of<br>
        case E1 of P1 -> B1 end         % just one clause!<br>
can be rewritten as<br>
        (P1 = E1, B1).<br>
Why not extend this to allow<br>
        case E1 of P1 when G1 -> B1 end<br>
to be written as<br>
        ((P1 when G1) = E1, B1)<br>
<br>
I'm not pushing _hard_ for this, you understand, just<br>
noting that there is a nasty and apparently unmotivated<br>
gap in the language, and suggesting that something<br>
should be done about it.  Abstract patterns are, of<br>
course, a far better solution to the same issue.<br>
<br>
Of course the same idea can be extended to ~=, and if ~=<br>
were to be extended, it should be.<br>
<br>
The draft EEP notes that the ~= construction adds no<br>
real power (and, if we consider macros, no extra power<br>
at all) in ordinary expressions.  It is ONLY useful in<br>
guards.  But WHY is it useful?<br>
<br>
~= is only useful because = is not allowed in guards.<br>
<br>
Between a pattern match test that doesn't bind any<br>
variables and a pattern match test that only binds<br>
variables that happen not to be used anywhere else<br>
there is no real difference.  ~= is a special case of<br>
= .  So if we are willing to consider ~= in guards,<br>
why not consider = in guards?<br>
<br>
Indeed, why not?  If I can write<br>
<br>
        f(L) when hd(L) > 0, hd(L) < 10 -><br>
<br>
why can't I write<br>
<br>
        f(L) when N = hd(L), N > 0, N < 10 -><br>
<br>
In the past I have strongly defended the distinction<br>
between guards and expressions, and I have not changed<br>
my mind.  But allowing = in guards does not destroy any<br>
of the properties of guards that have ever concerned me.<br>
<br>
So instead of adding a new "crippled-bind" called ~=,<br>
I suggest that it would be better to allow<br>
Pattern = Expression as a guard.<br>
<br>
What about the intended uses of ~= where the fact that<br>
it does not bind variables is important?  Why then,<br>
just restrict the corresponding = to not bind variables.<br>
{foo,_,27} = hd(X) would have the same effect in a guard<br>
as {foo,_,27} ~= hd(X) would have, so if we allowed =,<br>
there would be no point in having ~= as well, while if<br>
we had ~= we would still be left lamenting the<br>
inexplicable prohibition on =.<br>
<br>
Do I need to mention that the similarity between = and<br>
~= would lead to errors when one was used but the other<br>
intended?  No, I thought not.  ~= is something we are<br>
better off without.  But its use in guards _is_ something<br>
we could do with, only the existing = would be far better.<br>
<br>
That's enough for one message, I think.<br>
<br>
Maybe not.<br>
<br>
I don't like vague suggestions that<br>
"It is rather common to check the value of an expression with a<br>
     case expression and do the same actions in some of the cases."<br>
I want to see *actual cases*.<br>
<br>
Oh, and did I point out that abstract patterns can solve the<br>
"multiple patterns" problem neatly and clearly?<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>--Hynek (Pichi) Vychodil