Hi!

Have you ever tried to use the thumb for alt-gr and pressing 7/0 with the middle finger? Works well for me. I had an english keyboard some time, was nice for coding, but writing emails or forum posts (in german) without umlauts was just irritating.

Anyway, I thought a bit about that.
I'd really like the switch to look like that:

' switch (bar)
' {
'     case (1) writefln("case 1");
'     case (2, 3)
'     {
'         writefln("case 1");
'         writefln("or case 3");
'     }
'     case (4)
'     {
'         writefln("case 4 - need to fall through to 5");
'         continue(5);                           // continue is used instead of falling through
'     }
'     case (5)
'     {
'         writefln("case 5 - checking for foo");
'         if (!foo()) break;                     // breaks out of the switch
'         writefln("foo is true");
'     }
'     default
'     {
'         writefln("default");
'         throw new Exception("Don't do that!");
'     }
' }

With the parenthesis and the continue. But if you try to mix that with the current switch syntax, like

' switch (bar)
' {
'     case (1) writefln("case 1");
'     case 2: evil_flag = true; // fall through
'     case (3) if (evil_flag) { ... }
' }

it's getting ugly. What about allowing my proposed syntax and aborting compilation when one tries to mix C-style switches with what I have in mind?

-Mike


Am 22.08.2006, 14:39 Uhr, schrieb Kristian <kjkilpi@gmail.com>:

> I too think that curly brackets in switch fits nively to the syntax of the language, as Mike here demostrated. And I also understand, as Chad said, why a new switch statement is a bit too extreme.
>
> Well now, currently there are four solutions:
>
> 1) A new switch statement (e.g. jump or branch).
> 2) The switch statement using different notation (curly brackets).
> 3) The compiler forces to use breaks etc at the end of cases.
> 4) A combination of the solutions 2 and 3.
>
> Solution 1:
> Pros:
> - No breaking through bugs.
> - Does not break old code.
> - Does not require breaks etc at the end of cases.
> - You'll instantly know that breaking always happen at the end of cases (if not defined otherwise) when looking at code.
> - Does not require brackets (some people don't like them).
> - Allows doing complex case structures easily (usually a bad thing, but sometimes necessary, maybe).
> Cons:
> - Two statements that do similar tasks yet differently. (Personally I don't think this is a problem though.)
> - Allows doing complex case structures easily (sometimes a good thing, maybe).
>
> Solution 2:
> Pros:
> - Does not break old code.
> - Fits to the language syntax nicely.
> - Only one statement doing switching/jumping/branching.
> - Allows doing complex case structures easily (usually a bad thing, but sometimes necessary, maybe).
> Cons:
> - You have to be a little more careful when using it. You may end up allowing a break through when not wanted. Will people accustomed to old switch syntax adapt to use the new one?
> - Uses brackets (some people don't like them). (Personally I don't mind using them.)
> - Allows doing complex case structures easily (sometimes a good thing, maybe).
>
> Solution 3:
> Pros:
> - No breaking through bugs.
> - Does not break old code as _itself_ (see the cons).
> - You know instantly that breaking etc always happen at the end of cases when looking at code.
> - Complex case structures are somewhat harder to do (sometimes a bad thing, maybe).
> Cons:
> - In old code, where breaking through is required, you have to modify the code to keep it compiling. This can be considered as "breaking old code". And changing old code may introduce new bugs.
> - Takes more typing. If you forget a break statement, then you have to edit the code and recompile.
> - Complex case structures are somewhat harder to do (usually a good thing, though).
>
>
> The simplest and safest solution seems to be 1. The solution 2 is more 'beautiful' syntaxically (well, at least people who don't like curly brackets may disagree with this). However, it's not so safe to use than the solution 1, I think. Solution 3 is also safe. However, it requires more typing and it may 'break' old code.
>
> Maybe we could have both the solutions 1 and 2? (Or not...) ;)
> I think solutions 3 and 2+3 are not accepted (by public) because of this old code breaking issue... but maybe it's not an issue at all in practice.
>
>
> Btw, it's quite funny/sad that (quite) many seem to hate curly brackets. C/C++, D, etc, are so called curly brackets languages after all.
>
> Well, I am not fond of them either, pressing AltGr + 7 and AltGr + 0 is not so fast/easy as it should be (usually pressing AltGr + 7 requires two hands). Fortunately my text editor's macro will add { and } to a statement by pressing Ctrl + Enter. Usually it works fine, even.
>
>
> On Tue, 22 Aug 2006 04:56:40 +0300, Chad J <gamerChad@_spamIsBad_gmail.com> wrote:
>> Kristian wrote:
>>> It would be nice if there was a new statement that acts like 'switch'  except that 'break' will be automatically added at the end of the case  statements. (We don't want to change the behavior of 'switch' because  it'll break old code and confuse people familiar with C/C++.)
>>>  Let call this new statement 'jump' (or something), for example:
>>>  void func(int val) {
>>>     jump(val) {
>>>         case 1:
>>>             doX();
>>>         case 2, 3:
>>>             doY();
>>>         default:
>>>             doZ();
>>>     }
>>> }
>>>  Using 'switch', 'func()' would look, of course, as follows:
>>>  void func(int val) {
>>>     switch(val) {
>>>         case 1:
>>>             doX();
>>>             break;
>>>         case 2, 3:
>>>             doY();
>>>             break;
>>>         default:
>>>             doZ();
>>>             break;
>>>     }
>>> }
>>>  You could use a 'unbreak' (or something) to allow execution to fall  through to the next case statement.
>>>  In addition, falling through should be allowed in the following case:
>>>      case 1:
>>>     case 2:
>>>  which is a longer way to write "case 1, 2:", of course.
>>>   I think breaking after a case is (a lot) more common than falling through.  So this will reduce bugs (a programmer can easily forget to put the break  statement at the end of a case). Also, it'll make code shorter and easier  to read.
>>
>> Creating a new type of switch statement just to change some default
>> behavior seems a bit excessive.
>>
>> At the same time, I can't stand the fall-through default behavior!  It
>> is a source of bugs, and I've already been hit by it a few times in D
>> and spent hours trying to find the bug in a switch statement that
>> behaves subtly different than what I expected.
>>
>> I've read that this is maintained in D to keep it easy to port C code
>> over to D.  That's understandable, especially if you want to make break
>> the default, which would change the meaning of code without any warning.
>>
>> I'd suggest though, that you don't allow a default ending for case
>> blocks at all.  Mandate that each case block be followed by an escape
>> like 'break', 'return', 'goto', 'throw', etc.  That way, the compiler
>> would throw an error when C code that uses fallthroughs is inadvertently
>> used as D code.  Also, this is one of those things from C/C++ that is
>> bad.  D is supposed to get rid of those bad things even if it means
>> losing backwards compatibility, so please get rid of this bad thing that
>> comes from C.
>>
>> I also like Mike's suggestion on this thread a lot.  It could even be combined with my suggestion.  I'd say use Mike's suggestion, and only apply my suggestion to the colon blocks.  Since the brackets and one-liners are not valid C syntax AFAIK, the compiler won't need to mandate anything about them to flush out bugs from incoming C code.  On the developer side, this trades nasty runtime bugs for some small amount of hunting down compiler errors and fixing them.  A good trade IMO.  Not sure what the cost would be to compiler writers like Walter, but please at least implement the mandatory ending on the current case blocks, or something just as good.
>



-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

On Tue, 22 Aug 2006 18:55:29 +0300, mike <vertex@gmx.at> wrote:
> Hi!
>
> Have you ever tried to use the thumb for alt-gr and pressing 7/0 with the middle finger?

I do that also sometimes. Pressing AltGr+7 with the middle finger happens, um, maybe 10-20% of the cases, at maximum, though. Pressing AltGr with a right hand's thumb and 7 with the left hand's middle finger does not involve lifting my right elbow. Which seems to happen when using one hand only... Hey, that must be a reason why I have adopted the two hand style... :)


>
> Anyway, I thought a bit about that.
> I'd really like the switch to look like that:
>
> ' switch (bar)
> ' {
> '     case (1) writefln("case 1");
> '     case (2, 3)
> '     {
> '         writefln("case 1");
> '         writefln("or case 3");
> '     }
> '     case (4)
> '     {
> '         writefln("case 4 - need to fall through to 5");
> '         continue(5);                           // continue is used instead of falling through
> '     }
> '     case (5)
> '     {
> '         writefln("case 5 - checking for foo");
> '         if (!foo()) break;                     // breaks out of the switch
> '         writefln("foo is true");
> '     }
> '     default
> '     {
> '         writefln("default");
> '         throw new Exception("Don't do that!");
> '     }
> ' }
>
> With the parenthesis and the continue. But if you try to mix that with the current switch syntax, like
>
> ' switch (bar)
> ' {
> '     case (1) writefln("case 1");
> '     case 2: evil_flag = true; // fall through
> '     case (3) if (evil_flag) { ... }
> ' }
>
> it's getting ugly. What about allowing my proposed syntax and aborting compilation when one tries to mix C-style switches with what I have in mind?
>
> -Mike

Yeah, mixing the different syntaxes could make a mess. I guess compiler could produce error messages in such situations. Importantly it wouldn't break old code.

Now this syntax will indeed fit to the overall syntax ("if() {}" <=> "case() {}"). When I read my first book of C I wondered why the syntax of the switch statement was different and not like this one. I guess that's because it will allow you to write some complex code. But this hybrid style would allow that also.

Am 23.08.2006, 15:09 Uhr, schrieb Kristian <kjkilpi@gmail.com>:

> I do that also sometimes. Pressing AltGr+7 with the middle finger happens, um, maybe 10-20% of the cases, at maximum, though. Pressing AltGr with a right hand's thumb and 7 with the left hand's middle finger does not involve lifting my right elbow. Which seems to happen when using one hand only... Hey, that must be a reason why I have adopted the two hand style... :)

Hehe ... I never noticed that I actually do lift my right elbow every time I write curly braces. Now that's interesting :-)

Writing code with a german keyboard layout is sometimes very interesting. Did you ever program in Turbo Pascal on DOS? Linked lists? My keyboard driver was beeping every 10-20 seconds when I was programming (since you declare a pointer with the ^ character) :-)

> Yeah, mixing the different syntaxes could make a mess. I guess compiler could produce error messages in such situations. Importantly it wouldn't break old code.
>
> Now this syntax will indeed fit to the overall syntax ("if() {}" <=> "case() {}"). When I read my first book of C I wondered why the syntax of the switch statement was different and not like this one. I guess that's because it will allow you to write some complex code. But this hybrid style would allow that also.

To me that syntax looks and feels like D. It would also allow some pretty advanced control flow through the switch, like

case (6) if (foo()) continue(7); else continue(8);

Anyway: I'm kinda glad you brought this topic up, since I'm currently toying aroung with designing a scripting language, and I hadn't yet implemented a switch statement. Now that you've brought that up, I'll toss the C-style switch out and implement it that way. Thanks!

-Mike

-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

Jeff wrote:
> How about allowing:
> 
> switch (val) {
>     case (1) {
>     doX();
>     } case (2, 3) {
>         doY();
>     } default {
>         doZ();
>     }
> )
> 
> Or would this create some horrible syntactic ambiguities? Or, on the other hand, it could just be too damn ugly. ;)

Please see my proposal of the same thing from years ago:

http://www.digitalmars.com/d/archives/22722.html

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

On Thu, 24 Aug 2006 21:12:31 +0300, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> Jeff wrote:
>> How about allowing:
>>  switch (val) {
>>     case (1) {
>>     doX();
>>     } case (2, 3) {
>>         doY();
>>     } default {
>>         doZ();
>>     }
>> )
>>  Or would this create some horrible syntactic ambiguities? Or, on the other hand, it could just be too damn ugly. ;)
>
> Please see my proposal of the same thing from years ago:
>
> http://www.digitalmars.com/d/archives/22722.html
>
> Stewart.
>

Grhm, that was over 2.5 years ago... :(

I know there are much important things to get right and working, but I sure do hope that Walter will someday (after 1.0?) improve the syntax for some parts.

But yes, range definitions would be good to have indeed. It never occured to me that cases could have else statements, that could be nice also. :)

mike wrote:
> Hi!
> 
> If I may comment on that - I think that fits perfectly into the syntax. Think of that:
> 
> ' class foo
> ' {
> '     // you can write public in 3 different ways
> '     public int x;
> '     public
> '     {
> '         int y;
> '     }
> '     public:
> '         int z;
> ' }
> 
> Why not something similar with switch?
> 
> ' switch (i)
> ' {
> '     // you could write case in 3 different ways too
> '     case 1 writefln("case 1");
<snip>

Allowing {} to be omitted would create parsing ambiguities.

    case qwert (yuiop) (asdfg());

Is this equivalent to

    case qwert:
        yuiop(asdfg());
        break;

or

    case qwert(yuiop):
        asdfg();
        break;

?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.