The story so far:<br>
I proposed something; Richard O'Keefe and Michael Truog provided 
feedback; I gave my immediate responses; I went back to thinking (and 
rereading the plan for abstract patterns).<br>
<br>
Particularly noteworthy objections were that<br>
 1) the problems motivating my EEP are addressed by EEP 29 ("Abstract Patterns");<br>
 2) the issue is already regarded as being covered by EEP 14 ("Guard clarification and extension) --<br>
     when EEP 29 ("Abstract Patterns") says that it is depending on 
pattern matching in guards being implemented, it is apparently EEP 14 
which is meant, although that is not spelled out (and EEP 29 does not 
have a "Requires:" metadata field indicating that dependency);<br>
 3) there is some concern over guards "leaking" by being able to bind variables which are visible in the guarded expression.<br>
<br>
Here's how I see the issue presently.<br>
- I fully agree with (1) above. There is a great deal of overlap between the motivations.<br>
- I still view a dedicated pattern-test operator as a better solution 
than simply allowing '=' in guards, for the reasons stated in my EEP.  
Also, i maintain that I'd prefer expression-before-pattern, however 
"unforgivable" that may seem.<br>
- MT is correct when he points out that the leaking-binding part of the 
proposal is not necessary to solve the problems described in the 
motivation.<br>
- MT's concern (3) can equally well be applied to EEP 14.<br>
<br>
Consequently,<br>
a) I was in half a mind (as stated earlier) to simply do the 
implementation part that's necessary in order to make abstract patterns 
possible.<br>
b) I'm in half a mind to reduce the binding semantics to only cover the "(E1 ~ P) andalso E2" case.<br>
<br>
Why past tense in a) and present tense in b)?<br>
Well,<br>
- cutting down on the binding generality (while perhaps surprising) does
 make things simpler. In fact, this reduces the implementation part more
 or less to what I've already done (although the 'andalso' part has not 
yet been cleaned up and committed), save for presumably marking some 
variables as unsafe.<br>
More to the point, the reduced semantics is easy to implement as local 
changes in the transformation from Erlang to Core Erlang.  I haven't yet
 looked at making guard bindings visible in guarded expressions, but I 
believe that that might either entail some suboptimal translations 
("first check, then check again to bind"), or changes to Core Erlang (we
 wouldn't want that).<br>
- Abstract patterns, actually needs pattern tests in guards at the 
syntactic level. At least for some kinds of abstract patterns.<br>
- And abstract patterns actually needs guards to be allowed to bind variables with scope in the guarded expression.<br>
I.e. what they need is the part I haven't got yet and is less certain of how to implement best.<br>
Thus a) doesn't make much sense.<br>
<br>
As for b), it would still provide a solution to the problems specified 
in my EEP; in particular, it would deal with the "pattern-with-guard 
can't be abstracted through macros" issue, in a quite light-weight way.<br>
Such patterns would still be macro-based, of course, with all the drawbacks that EEP 29 describes.<br>
(Note, however, that that would not be a "nickle-and-diming attack on     
isolated cases postponing the Real Thing" of abstract patterns; it is on
 par with EEP 14 in that respect.)<br>
<br>
(Richard: I'll have to get back to you on the rest of the reply you just sent; sorry about the "buggers" -- I'm not a native...)<br>
<br>
/Erik<br>
<br>