[eeps] EEP XXX: Pattern-test operator - status

[Erik Søe Sørensen]

The story so far:
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).

Particularly noteworthy objections were that
 1) the problems motivating my EEP are addressed by EEP 29 ("Abstract
Patterns");
 2) the issue is already regarded as being covered by EEP 14 ("Guard
clarification and extension) --
     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);
 3) there is some concern over guards "leaking" by being able to bind
variables which are visible in the guarded expression.

Here's how I see the issue presently.
- I fully agree with (1) above. There is a great deal of overlap between
the motivations.
- 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.
- 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.
- MT's concern (3) can equally well be applied to EEP 14.

Consequently,
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.
b) I'm in half a mind to reduce the binding semantics to only cover the
"(E1 ~ P) andalso E2" case.

Why past tense in a) and present tense in b)?
Well,
- 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.
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).
- Abstract patterns, actually needs pattern tests in guards at the
syntactic level. At least for some kinds of abstract patterns.
- And abstract patterns actually needs guards to be allowed to bind
variables with scope in the guarded expression.
I.e. what they need is the part I haven't got yet and is less certain of
how to implement best.
Thus a) doesn't make much sense.

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.
Such patterns would still be macro-based, of course, with all the drawbacks
that EEP 29 describes.
(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.)

(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...)

/Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20120416/14dd19b5/attachment.htm>