May 01, 2006
kris wrote:
> Walter Bright wrote:
>> kris wrote:
>>
>>> Alternate design strategies aside, I was always told that goto, in general, lead to *less* efficient code. Didn't compilers (perhaps in the past) disable the optimizer for functions with one or more instances of goto? Doesn't it mess with flow analysis, or something?
>>
>>
>> I don't think any compiler built since 1982 had such limitations. In fact, the way the DM optimizer works is by converting all constructs to goto's and *then* operating on it. The algorithms to do this are well known, and are even in the Dragon Book (vintage 1979). Goto's will not adversely affect optimization at all.
> 
> hehe ;)
> 
> Obviously been a while since I looked then ... I recall MWC being like that, and also the, umm, Lattice or Aztec -- a bit foggy now.

Those compilers, to my knowledge, never did data flow analysis or had a true optimizer in them.
May 01, 2006
Derek Parnell wrote:
> On Mon, 01 May 2006 05:18:11 +1000, Sean Kelly <sean@f4.ca> wrote:
> 
>> Bruno Medeiros wrote:
>>>  I was thinking of an example which used continues and retries in the same for, as yours can be cleanly rewritten as the example in my later post.
>>> Anyway, Derek's example serves as a good example of the keyword's usage, but for "foreach", for "for" I'm still finding it a bit odd.
>>
>> I think it's more useful for "foreach" because there's no way to avoid progressing with each iteration.  However, goto still works here as in Walter's example.  "retry" is handy, but it's more a convenience than anything.
> 
> And *expressive*. That is, it signals the coder's intent more clearly than a goto can because in theory the goto can go to anywhere but that is not the case with 'retry'. Thus the use of 'retry' is more likely to lead to less misunderstanding and bugs. So even though it is a 'goto' in disguise, it is a controlled goto.
> 
> 
> 
> --Derek Parnell
> Melbourne, Australia

Hum, now that you mention it, what if goto could only jump to labels that are lexically visible in the current scope, using the same rules as  variables. Seems to me it would make goto more safe, but is such behavior acceptable? I mean, is there a reasonable use scenario for goto that requires a cross-scope jump? (I wonder if any of the cases presented by Walter would require such thing)


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 01, 2006
Walter Bright wrote:
 > A goto is also useful:
> 
> 1) to avoid excessive diffs caused by refactoring code
> 

I too didn't quite get this one.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 01, 2006
On Mon, 01 May 2006 05:36:56 -0400, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:

> Hum, now that you mention it, what if goto could only jump to labels that are lexically visible in the current scope, using the same rules as   variables. Seems to me it would make goto more safe, but is such behavior acceptable? I mean, is there a reasonable use scenario for goto that requires a cross-scope jump? (I wonder if any of the cases presented by Walter would require such thing)
>

C# has a restriction similar to this and it's pretty annoying.

if(something)
   goto mylabel;   // error, mylabel not in scope.
stuff();
if(somethingelse)
{
   mylabel:
   morestuff();
}
May 01, 2006
Chris Miller wrote:
> On Mon, 01 May 2006 05:36:56 -0400, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:
> 
>> Hum, now that you mention it, what if goto could only jump to labels that are lexically visible in the current scope, using the same rules as   variables. Seems to me it would make goto more safe, but is such behavior acceptable? I mean, is there a reasonable use scenario for goto that requires a cross-scope jump? (I wonder if any of the cases presented by Walter would require such thing)
>>
> 
> C# has a restriction similar to this and it's pretty annoying.
> 
> if(something)
>    goto mylabel;   // error, mylabel not in scope.
> stuff();
> if(somethingelse)
> {
>    mylabel:
>    morestuff();
> }
How about:

if ( !something ) {
	stuff( );
} else if ( somethingelse ) {
	morestuff( );
}

?
May 01, 2006
Derek Parnell wrote:
> On Sun, 30 Apr 2006 20:06:34 -0700, Walter Bright wrote:
> [snip]
>>6) to, for instance, collect all error handling code in one spot in a function
> 
> Yes, this is a very common usage for goto statements. Not so much as a
> performance enhancer because errors are supposed to be infrequent, but to
> improve source code maintainability. However, I believe that the benefit of
> goto usage here is lost due to the 'uncontrolled' nature of it. It
> introduces labels that can theoretically be reached from places other than
> the error handlers. In spite of that, I feel that this is a prime candidate
> for new syntax to deal with the problem of consolidating error handling
> code. It could be thought of an extension to D's 'try-catch' and 'scope'
> constructs, so I would encourage you to consider further evolving D into a
> language to delight code authors and maintainers, and also compiler
> writers.

In my own language I've come up with the try/failure block in combination with the 'fail' statement.  It's basically like this:

try {
	if (conditionA) fail;
	if (conditionB) fail;
	if (conditionC) fail;

	success;
} failure {
	writef("An error occurred!  Cannot proceed.\n");
}

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

James Dunne
May 01, 2006
On Mon, 01 May 2006 09:30:26 -0400, Alexander Panek <alexander.panek@brainsware.org> wrote:

> Chris Miller wrote:
>> On Mon, 01 May 2006 05:36:56 -0400, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:
>>
>>> Hum, now that you mention it, what if goto could only jump to labels that are lexically visible in the current scope, using the same rules as   variables. Seems to me it would make goto more safe, but is such behavior acceptable? I mean, is there a reasonable use scenario for goto that requires a cross-scope jump? (I wonder if any of the cases presented by Walter would require such thing)
>>>
>>  C# has a restriction similar to this and it's pretty annoying.
>>  if(something)
>>    goto mylabel;   // error, mylabel not in scope.
>> stuff();
>> if(somethingelse)
>> {
>>    mylabel:
>>    morestuff();
>> }
> How about:
>
> if ( !something ) {
> 	stuff( );
> } else if ( somethingelse ) {
> 	morestuff( );
> }
>

Not the point, this is a small example that isn't real; besides, check your logic (something=false; somethingelse=true;)
May 03, 2006
Chris Miller wrote:
> On Mon, 01 May 2006 05:36:56 -0400, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:
> 
>> Hum, now that you mention it, what if goto could only jump to labels that are lexically visible in the current scope, using the same rules as   variables. Seems to me it would make goto more safe, but is such behavior acceptable? I mean, is there a reasonable use scenario for goto that requires a cross-scope jump? (I wonder if any of the cases presented by Walter would require such thing)
>>
> 
> C# has a restriction similar to this and it's pretty annoying.
> 
> if(something)
>    goto mylabel;   // error, mylabel not in scope.
> stuff();
> if(somethingelse)
> {
>    mylabel:
>    morestuff();
> }

Actually, based on some previous notion that I don't where I got it from, and from Derek's comments, I thought /goto/ (in both D and C) could jump anywhere in the code, even across functions :o I've only found out now that that is not the case, and that was the most of the idea of my restriction.


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 03, 2006
Derek Parnell wrote:
> 
> The problem, IMHO, with this is not the 'goto' per se, but the label. 
> 
> The existence of a label opens the possibility that somewhere *else* in the
> code is a reference to that label and so as a code maintainer, I must
> examine all the code for such a reference. This takes time (even though it
> might only be a seconds using a good editor) it does add further
> maintenance cost. And if I do find other references, I need to examine the
> implications of any change I make to the local area around the label to
> ensure there are no unintended side-effects due to code jumping to the
> label ... more time used up!
> 

Based on some previous notion that I don't where I got it from, and from your comments, I thought /goto/ (in both D and C) could jump anywhere in the code, even across functions, but that is not so. So there isn't such label problem as you mention.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 03, 2006
I'm all for the addition of 'retry' statement for all loops (while, for, foreach).  In fact, I think it would even be nifty in switch statements:

# switch (something) {
#   case foo:
#     doStuff();
#     break;
#
#   case bar:
#     doOtherStuff();
#     break;
#
#   default:
#     something = doAnotherThing();
#     retry;
# }

The 'restart' statement I'm not entirely convinced about, though.  For two reasons. Reason one, its just too common/likely a name for variables/fields & functions/methods. Who hasn't written a class with a .restart() method before?

Reason two:

# { bool _sentinel; do { _sentinel = false;
#   foreach (i, x; some_collection) {
#     /*...do stuff...*/
#     if (/*...some condition...*/) {
#       _sentinel = true;
#       break;
#     }
#   }
# } while (_sentinel); }

Not particularly pretty, no, but it gets the job done and (IMHO) reads decently enough. If 'restart' adds some optimization ability this convention does not, then fine, so be it... just, can we please find another name, because Reason One is the big one to me.

-- Chris Nicholson-Sauls