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>