Damian Conway wrote:
> > 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.
>
> Yes. As I point out in the paper, that's the *nature* of a switch statement.
> To distribute a test spatially, by factoring.
One could quibble quite extensively about whether that's the nature of the
switch statement, or whether that is a characteristic found in a broad class of
switch statement implementations. To me the nature of the switch statement is
the selection operation, not the factoring.
> > 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).
>
> Not so:
Yes so...
> switch ($value) {
> case 1 {...} # numeric equality
> case "a" {...} # string equality
> case $obj {...} # referential equality
> case /pat/ {...} # pattern match
> case %hash {...} # hash lookup
> case [1..10] {...} # list inclusion
> case __<100 {...} # subroutine return
> }
None of these perform more than one operation per pair of types. By doing the
factoring, you are constraining the type and specific value of the left hand
expression in your matching operation, limiting the set of operations that can
be performed quite severely.
> > 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.
>
> No. The whole point is that they just DWIM.
Well, they might DWDM, but most of them wouldn't DWIM.
(DWDM=do what Damian means).
That said, there are some useful operations in your list that are complex to
express otherwise; something should be done to make them more easily expressable
if they are common.
> > 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.
>
> Just selecting one from many alternatives is a cascaded if's job.
That's one way to do it, at least in Perl we don't get "endif" bloat.
> The defining characteristic of a switch the the factoring of some part
> of the comparisons. And it's an important characteristic, because it
> focussed the reader's mind on the commonality of the test.
In this proposal, it would be the commonality of the parameter, not the
commonality of the test. The test includes parameters and matching operation.
The type of the second parameter must be determined before the matching
operation can be determined.
> > 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) {}".
>
> If that's the consensus, let's just have elsif.
> But I don't think that's the consensus.
elsif makes some of the other features of your proposal harder to do: next would
have to be done with goto/label, for example. And inter-case statements wind up
requiring cascading blocks, because of the need to separate the else from the
if. So there is room to beautify a common operation of the language with a
switch statement, without the factoring.
> I appreciate your comments, but I certainly intend to push ahead with
> the proposed syntax -- as I proposed it. A very large number of people
> like it as it is. If I'm wrong, let Larry kill it.
Well, it could be that a very large number of people like it as it is. Or it
could be that a very large number of people think it is clever, and like the
new, simpler, implicit operators that you've added in your big table of
operators, and haven't thought about how confusing it will be to determine what
is actually happening in a multi-type switch. The new operations could be
achieved in more flexible ways, rather than only implicitly via the switch
statement.
For instance,
if ( $v == @foo )
is clearly testing the size of foo against the value of $v. But
switch ( $v ) {
case 1: { ... }
case 2: { ... }
case @foo { ... }
}
does not! You can argue all day that it is more powerful, and you can even
mention that "case scalar(@foo)" would achieve that goal, but it isn't DWIM.
> Damian
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
