[e-lang] Killing the MatchBindExpr

[Chip Morningstar]

MarkM proposes:
>1) if-match:
>
>    e ::= if (e1) =~ p1 {e2} else {e3}

This is really surprising looking to someone used to a conventional 'if'
statement.  Despite all the discussion, I'm still fuzzy about why

    e ::= if (e1 =~ p1) {e2} else {e3}

is problematic.  Why can't you have the semantics of the first form above
with the syntax of the second?


>2) extended-switch:
>
>    e ::= switch (e1,e2) { <match pi {ei}>* }

>Since E already contains the switch expression, adding extended-switch to E
>and Kernel-E does not really increase the size of E. If we also remove
>MatchBindExpr from E and Kernel-E, then Kernel-E stays about the same size and
>E actually gets smaller.

You knew, of course, that I'd like that!

>Many languages (such as C and Java) have constant-time switch constructs (at
>least when the case values are dense). Currently, if the E programmer writes a
>simple switch which should be compiled to a constant time dispatch, this is
>first  expanded to an 'else if' chain. Although Dan reports that gcc will
>actually optimize some 'else if' chains to constant time dispatches, that's a
>lot to ask of an optimizer. But if the switch is passed through directly to
>Kernel-E, then it should be easier for reasonable E implementations to
>recognize some of the simple cases they can turn into constant time dispatches

The compilation benefits of recognizing 'switch' directly are clear, but I've
always assumed that any production-grade implementation of E is going to
compile E directly anyway.  But then, I've always regarded Kernel-E as
primarily a pedagogical and descriptive tool rather than as an implementation
vehicle.


>Because of these issues, initially I wanted to just add the extended-switch to
>E and Kernel-E, and forget about the if-match. However, this fantasy did not
>survive the first two actual examples I tried to convert, which are shown
>below. For each, their conversion to if-match is trivial, and the resulting
>code is just as readable and concise. OTOH, their conversion to
>extended-switch is fine as a Kernel-E expansion, but is too verbose to impose
>on the E programmer.
>
> ...<examples>...

I agree that the examples using 'switch' are kind of clunky.  I'm not sure I
care (of course, if it were up to me, I'd go way, way, way back up E's
evolutionary tree and prune out all the pattern matching stuff entirely).

Chip