View mode: basic / threaded / horizontal-split · Log in · Help
January 01, 2009
Re: Improvement to switch-case statement
Hello Michel,

> On 2008-12-31 18:22:32 -0500, "Adam D. Ruppe"
> <destructionator@gmail.com> said:
> 
>> This wouldn't be any less efficient than any other switch statement;
>> writing
>> 
>> case 2..5:
>> code;
>> break;
>> could just be magically converted into
>> 
>> case 2:
>> case 3:
>> case 4:
>> case 5:
>> code;
>> break;
> Except that if you want to keep consistency with array slices, 2..5
> should probably not include 5 in the range, thus should be equivalent
> "case 2,3,4". Unfortunatly, that's generally not what you want when
> creating such cases. Imagine writting:
> 
> case 'a'..'{':
> case 'A'..'[':
> Concistent, yes; but not very appealing. What you want to be able to
> write is this:
> 
> case 'a'..'z':
> case 'A'..'Z':
> But then it doesn't work as elsewhere in the language anymore.
> 


Good point.  So while the '..' is potentially useful, it may just be simpler 
to implement something like a range macro rather than suffer the risk of 
such an inconsistancy.

-JJR
January 01, 2009
Re: Improvement to switch-case statement
Hello John,

> Hello Michel,
> 
>> On 2008-12-31 18:22:32 -0500, "Adam D. Ruppe"
>> <destructionator@gmail.com> said:
>>> This wouldn't be any less efficient than any other switch statement;
>>> writing
>>> 
>>> case 2..5:
>>> code;
>>> break;
>>> could just be magically converted into
>>> case 2:
>>> case 3:
>>> case 4:
>>> case 5:
>>> code;
>>> break;
>> Except that if you want to keep consistency with array slices, 2..5
>> should probably not include 5 in the range, thus should be equivalent
>> "case 2,3,4". Unfortunatly, that's generally not what you want when
>> creating such cases. Imagine writting:
>> 
>> case 'a'..'{':
>> case 'A'..'[':
>> Concistent, yes; but not very appealing. What you want to be able to
>> write is this:
>> case 'a'..'z':
>> case 'A'..'Z':
>> But then it doesn't work as elsewhere in the language anymore.
> Good point.  So while the '..' is potentially useful, it may just be
> simpler to implement something like a range macro rather than suffer
> the risk of such an inconsistancy.
> 
> -JJR
> 


Of course, here it seems we're starting to enter the domain of regular expression 
parsing anyway, so it leaves one wondering if it's worth fixing up the switch 
statement too much for this. :)   Very likely better to pursue a macro-like 
epression here.

-JJR
January 01, 2009
Re: Improvement to switch-case statement
Michel Fortin Wrote:
> Imagine writting:
> 
> 	case 'a'..'{':
> 	case 'A'..'[':
> 
> Concistent, yes; but not very appealing. What you want to be able to 
> write is this:
> 
> 	case 'a'..'z':
> 	case 'A'..'Z':
> 
> But then it doesn't work as elsewhere in the language anymore.

Ruby solves the problem having two different syntaxed, .. and ... for open and closed intervals. But I don't like it much, it's easy to miss the extra point.

An easy solution:

   case 'a' .. 'z'+1:
   case 'A' .. 'Z'+1:

Bye,
bearophile
January 01, 2009
Re: Improvement to switch-case statement
Michel Fortin wrote:
> On 2008-12-31 18:22:32 -0500, "Adam D. Ruppe" 
> <destructionator@gmail.com> said:
> 
>> This wouldn't be any less efficient than any other switch statement; 
>> writing
>>
>> case 2..5:
>>   code;
>>   break;
>>
>> could just be magically converted into
>>
>> case 2:
>> case 3:
>> case 4:
>> case 5:
>>   code;
>>   break;
> 
> Except that if you want to keep consistency with array slices, 2..5 
> should probably not include 5 in the range, thus should be equivalent 
> "case 2,3,4". Unfortunatly, that's generally not what you want when 
> creating such cases. Imagine writting:
> 
>     case 'a'..'{':
>     case 'A'..'[':
> 
> Concistent, yes; but not very appealing. What you want to be able to 
> write is this:
> 
>     case 'a'..'z':
>     case 'A'..'Z':
> 
> But then it doesn't work as elsewhere in the language anymore.
> 

Python solves this rather elegantly; instead of

  if( chr in 2..5 ) ...

you can just do this:

  if( 2 <= chr <= 5 ) ...

which allows you to explicitly control which ends are inclusive/exclusive.

  -- Daniel
January 01, 2009
Re: Improvement to switch-case statement
"Daniel Keep" <daniel.keep.lists@gmail.com> wrote in message 
news:gjhapq$171v$1@digitalmars.com...
>
>
> Michel Fortin wrote:
>> On 2008-12-31 18:22:32 -0500, "Adam D. Ruppe" <destructionator@gmail.com> 
>> said:
>>
>>> This wouldn't be any less efficient than any other switch statement; 
>>> writing
>>>
>>> case 2..5:
>>>   code;
>>>   break;
>>>
>>> could just be magically converted into
>>>
>>> case 2:
>>> case 3:
>>> case 4:
>>> case 5:
>>>   code;
>>>   break;
>>
>> Except that if you want to keep consistency with array slices, 2..5 
>> should probably not include 5 in the range, thus should be equivalent 
>> "case 2,3,4". Unfortunatly, that's generally not what you want when 
>> creating such cases. Imagine writting:
>>
>>     case 'a'..'{':
>>     case 'A'..'[':
>>
>> Concistent, yes; but not very appealing. What you want to be able to 
>> write is this:
>>
>>     case 'a'..'z':
>>     case 'A'..'Z':
>>
>> But then it doesn't work as elsewhere in the language anymore.
>>
>
> Python solves this rather elegantly; instead of
>
>   if( chr in 2..5 ) ...
>
> you can just do this:
>
>   if( 2 <= chr <= 5 ) ...
>
> which allows you to explicitly control which ends are inclusive/exclusive.
>

Not a bad idea. How does it handle something like this:

if( a > b < c)

Is that an error? Or does it get split into:

if( a > b && b < c)
January 01, 2009
Re: Improvement to switch-case statement
On Thu, Jan 1, 2009 at 12:45 PM, Nick Sabalausky <a@a.a> wrote:
>
> Not a bad idea. How does it handle something like this:
>
> if( a > b < c)
>
> Is that an error? Or does it get split into:
>
> if( a > b && b < c)

From the Python docs:

"Formally, if a, b, c, ..., y, z are expressions and opa, opb, ...,
opy are comparison operators, then a opa b opb c ...y opy z is
equivalent to a opa b and b opb c and ... y opy z, except that each
expression is evaluated at most once.

Note that a opa b opb c doesn't imply any kind of comparison between a
and c, so that, e.g., x < y > z is perfectly legal (though perhaps not
pretty). "
January 02, 2009
Re: Improvement to switch-case statement
Yigal Chripun wrote:
<snip>
> IMO, either the switch statement should remain the low level 
> (effiecient) construct as in C, or replaced by a general mechanism of 
> pattern matching. your solution is kinda between the two above options 
> and I don't see the point of it.

What would a "general mechanism of pattern matching" involve, and how 
would it replace switch?  Would it replace if as well?

> I'd personally prefer pattern matching to be added to D and the switch 
> to be deprecated and eventually removed from the language.

I'd personally prefer my proposal from years ago to be taken seriously:
http://www.digitalmars.com/d/archives/22722.html

ISTM silly to improve switch but at the same time keep it restricted to 
the same old arcane syntax.

Stewart.
January 02, 2009
Re: Improvement to switch-case statement
Reply to Stewart,

> Yigal Chripun wrote:
> <snip>
>> IMO, either the switch statement should remain the low level
>> (effiecient) construct as in C, or replaced by a general mechanism of
>> pattern matching. your solution is kinda between the two above
>> options and I don't see the point of it.
>> 
> What would a "general mechanism of pattern matching" involve, and how
> would it replace switch?  Would it replace if as well?
> 
>> I'd personally prefer pattern matching to be added to D and the
>> switch to be deprecated and eventually removed from the language.
>> 
> I'd personally prefer my proposal from years ago to be taken
> seriously: http://www.digitalmars.com/d/archives/22722.html
> 
> ISTM silly to improve switch but at the same time keep it restricted
> to the same old arcane syntax.
> 
> Stewart.
> 

I for one don't like that proposal for a few reasons:

Because it looses fall through and adding it back in with "goto case n;" 
gets messy in generated code. I use fall through an some of my template code.
Because it can lead to hard to understand code. you need to examine all cases 
to find the code path rather than just find a single case with the given 
value.
Allowing the same case in more than one place could lead to some extremely 
hard to find bugs where the same case is added more than once in error.
January 02, 2009
Re: Improvement to switch-case statement
Stewart Gordon wrote:
> Yigal Chripun wrote:
> <snip>
>> IMO, either the switch statement should remain the low level
>> (effiecient) construct as in C, or replaced by a general mechanism of
>> pattern matching. your solution is kinda between the two above options
>> and I don't see the point of it.
>
> What would a "general mechanism of pattern matching" involve, and how
> would it replace switch? Would it replace if as well?
>
>> I'd personally prefer pattern matching to be added to D and the switch
>> to be deprecated and eventually removed from the language.
>
> I'd personally prefer my proposal from years ago to be taken seriously:
> http://www.digitalmars.com/d/archives/22722.html
>
> ISTM silly to improve switch but at the same time keep it restricted to
> the same old arcane syntax.
>
> Stewart.

I have several idea on this, nothing finished though:

the only reason for switch in the first place is an optimization in the 
compiler, besides that, there is no need for it at all and everything 
can be done with a bunch of if statements.

we basically need a way to group several if/case statements together and 
make them refer the same variable.

here's a first attempt:

match (value) {
  case(1) foo();
  case(2..4) { foo(); case(3) foo3(); bar(); continue; }
  case(5) {...}
  case() {...} // this is the default case
}

to get the old switch behavior of fall through you use continue. and 
cases can be nested. I'd say that making cases overlap should be 
compiler error. the only way it makes sense to me to have overlapping 
cases is in concurrent code but than the code will need to be marked for 
that anyway.

another related thing,  the catch list is also a switch. so instead of 
the current:
try {
// put code here
} catch (ExceptionA e) {
} catch (ExceptionB e) {
} catch (ExceptionC e) {}

we can extend "case" like this:

try {
// put code here
} catch (e) {
  case(ExceptionA) handleA(e);
  case(ExceptionB) handleB(e);
  case(ExceptionC) handleC(e);
  case()           handleDefault(e);
}

also, some thought should be spent on getting rid of the ternary op 
syntax since it interferes with other things that could be added to the 
language (nullable types, for instance)
January 02, 2009
Re: Improvement to switch-case statement
Yigal Chripun:
> also, some thought should be spent on getting rid of the ternary op 
> syntax since it interferes with other things that could be added to the 
> language (nullable types, for instance)

But a ternary operator is sometimes handy: when used judiciously it may help the mind of the person that reads the code to form a "chunk", improving code readability a little.

And if you want to modify/remove it you have to remember that D is usually designed to act as C when a C syntax is accepted (even if this leads to some bad things, see the syntax of the "switch" statement or the casting mess).

There are many possible alternative syntaxes for the ternary operator. Python in the end has accepted this one:
z = 1 if x else y
That for example can be used like this:
print n, "item" + ("" if a == 1 else "s")

Bye,
bearophile
1 2 3 4
Top | Discussion index | About this forum | D home