This switch statement RFC seems to be built on the premise that the reason to have a
switch
statement is to remove a common parameter from the following limited form conditional
expressions. For that reason, two new keywords are required: switch: to define the
common
parameter, and case: to introduce the second parameter of the matching operation. The
second
typical behavior regarding switch statements is embodied in the proposal, that of
executing
(generally) one sub-statement per switch statement.
However, while the table of 16 different ways in which two values could generate a
match is
interesting, it can only ever perform at most two operations per pair of types
(depending on
which type is found in which of the two positions). Anything else must be performed
via a
sub ref. And when sub ref's are used, the repetitive nature of specifying the implied
parameter led to another keyword "__".
I find it unlikely that the casual Perl programmer, and even many expert Perl
programmers,
will be able to usefully memorize the list of operations proposed for the type pairs.
This
inability to memorize the list will no doubt curl the corner of the switch page in the
perl
documentation.
Other posters have pointed out ideas for extending this RFC to have things other than
the
first parameter of a match operation factored out: the match op-code, both a parameter
and an
operator, etc.
I think the fundamental purpose of the switch statement is to choose one (generally)
of many
cases, and that the factoring of one of the parameters is what gets in the way of
having a
rich set of matching operations.
Hence, I think it suffices to have a single keyword for switch: not "switch", but
"case".
The block containing "case" would be the switch statement. "case" is simply a rename
of
"elsif" whose first occurrence in a block simply pretends to follow "if (0) {}". So
we have,
for example:
{ case ( 0 <= $a <= 9 ) { print "single digit\n" }
case ( 10 <= $a ) { print "digits\n" }
case ( $a == 7 ) { print "lucky seven"\n" }
}
In some sense, this is simply "syntactic sugar" around the existing if statement; the
other
features (next, statements between cases, etc.) from the original proposal could be
added to
this one, which would make it more than "syntactic sugar".
Regarding the particular implied match operations in the original proposal, if the
benefit of
the switch statement is that the implied operation is hard to express so the switch
statement
makes it easy so therefore the switch statement is good, then perhaps it would be a
good idea
to RFC the syntax of those operations to produce an easier operator syntax that could
be used
outside the context of the switch statement as well as inside a simpler switch
statement.
This is not to detract from the ideas of higher order functions or curried whatever,
but I
don't think those are or should be necessary to a powerful switch statement.
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
