January 01, 2009
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
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
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

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
"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
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
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
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
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
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