www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - foreach ... else statement

reply Brian <digitalmars brianguertin.com> writes:
any chance we could see something like pythons else statement on 
iterative loops in D (Might be useful on regular for loops too but not as 
much)?

http://docs.python.org/tutorial/controlflow.html#break-and-continue-
statements-and-else-clauses-on-loops
Jan 03 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Brian:
 any chance we could see something like pythons else statement on 
 iterative loops in D (Might be useful on regular for loops too but not as 
 much)?
 http://docs.python.org/tutorial/controlflow.html#break-and-continue-
 statements-and-else-clauses-on-loops

It seems everyone has ignored this post, but this isn't a proposal coming from a clueless alien. Such "else" has a little but true purpose, it helps avoid gotos in some situations, and this in turn may help the optimizer, because I think gotos aren't much well digested by modern C/D compilers. More on the topic: http://leonardo-m.livejournal.com/2008/08/07/ Bye, bearophile
Jan 04 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gjqpt0$1lr5$1 digitalmars.com...
 Brian:
 any chance we could see something like pythons else statement on
 iterative loops in D (Might be useful on regular for loops too but not as
 much)?
 http://docs.python.org/tutorial/controlflow.html#break-and-continue-
 statements-and-else-clauses-on-loops

It seems everyone has ignored this post, but this isn't a proposal coming from a clueless alien. Such "else" has a little but true purpose, it helps avoid gotos in some situations, and this in turn may help the optimizer, because I think gotos aren't much well digested by modern C/D compilers. More on the topic: http://leonardo-m.livejournal.com/2008/08/07/ Bye, bearophile

I had never heard of that before, but it certainly seems like something I'd find useful. Any time I'm using for or foreach to find something, I end up having to use some sort of "isFound" flag and check that after the loop. A for...else would be much nicer, for example: bool isFound=false; foreach(char[] key, Foo f; fooAA) { if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal) { isFound = true; break; } } if(!isFound) Stdout.formatln("Missing!"); // vs: foreach(char[] key, Foo f; fooAA) { if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal) break; // found } else Stdout.formatln("Missing!"); This could also be good in conjunction with a couple things that have been discussed for the future of D: - Non-nullable references: In the above example, if I wanted to introduce a "Foo theFoo" to hold the Foo that was found, I could normally eliminate the "isFound" flag, and just encode that information into theFoo as null vs. non-null. But this means that there would be no excess variable that could be eliminated by using for..else (in fact, the *only* change made by using for...else in this case would be "if(!theFoo)" -> "else"). This would make it seem like for...else would be useless in his case, but what if we had non-nullables and you wanted theFoo to be non-nullable? Then you'd have to either reintroduce the "isFound" flag or make theFoo nullable...or use "for...else". - Increased emphasis on functional programming: Eliminating that "isFound" means one less bit (pardon the pun) of mutable state. Granted, it's a very small improvement in any case, and there are certainly plenty of features that would make a far bigger difference, but this would still be nice to have.
Jan 04 2009
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Nick,

 I had never heard of that before, but it certainly seems like
 something I'd find useful. Any time I'm using for or foreach to find
 something, I end up having to use some sort of "isFound" flag and
 check that after the loop. A for...else would be much nicer, for
 example:
 

[...]
 // vs:
 
 foreach(char[] key, Foo f; fooAA)
 {
 if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
 break; // found
 }
 else
 Stdout.formatln("Missing!");

Wait, that's not the way I would expect else to work. You (and and it would seem python) would have the else clause run if the loop is terminated by the for/foreach rater than a break/goto. I would expect that the else clause would be executed if the loop is terminated before the first iteration. I think your expectation would be a good feature but I can't really see else being the right keyword to use. How about "finally"? Or another option with scope(*) like "fallthrough"?
Jan 04 2009
parent bearophile <bearophileHUGS lycos.com> writes:
BCS:
 I think your expectation would be a good feature but I can't really see else 
 being the right keyword to use. How about "finally"? Or another option with 
 scope(*) like "fallthrough"?

The good thing of "else" is that you don't need a new keyword. But it's not intuitive. A better keyword may make the code much more readable. For example: foreach (key, f; fooAA) if (f.someFlag && key in barAA && f.someVal > barAA[key].someVal) break; unbroken writefln("Missing!"); It looks a little silly, but I think it's easy to understand the meaning :-) Bye, bearophile
Jan 05 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Daniel de Kok:
Wouldn't it be more adequate to rewrite this as a function/method that takes a
predicate?<

In my dlibs there are things that allow to do that, but the code is slower. --------------- BCS:
Wait, that's not the way I would expect else to work.<

See the answer by Guido V. R. himself to that post I have given the URL.
I think your expectation would be a good feature but I can't really see else
being the right keyword to use.<

I agree, with a better naming it can be good feature to have. (I don't like its naming in Python too). Bye, bearophile
Jan 04 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 05 Jan 2009 01:11:34 +0300, BCS <ao pathlink.com> wrote:

 Reply to Nick,

 I had never heard of that before, but it certainly seems like
 something I'd find useful. Any time I'm using for or foreach to find
 something, I end up having to use some sort of "isFound" flag and
 check that after the loop. A for...else would be much nicer, for
 example:

[...]
 // vs:
  foreach(char[] key, Foo f; fooAA)
 {
 if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
 break; // found
 }
 else
 Stdout.formatln("Missing!");

Wait, that's not the way I would expect else to work. You (and and it would seem python) would have the else clause run if the loop is terminated by the for/foreach rater than a break/goto. I would expect that the else clause would be executed if the loop is terminated before the first iteration. I think your expectation would be a good feature but I can't really see else being the right keyword to use. How about "finally"? Or another option with scope(*) like "fallthrough"?

Same here, I expected the for/else pair to work similar to if/else, i.e. only one of the branches to be executed. Perhaps I could get used to the syntax, though.
Jan 04 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Nick Sabalausky wrote:
 bool isFound=false;
 foreach(char[] key, Foo f; fooAA)
 {
     if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
     {
         isFound = true;
         break;
     }
 }
 if(!isFound)
     Stdout.formatln("Missing!");

foreach (a, b; aa) if (weLike(a, b)) goto found; // else: assert (false, "nothing we like!"); found: I think my coworkers would kill me if I tried that.
Jan 05 2009
prev sibling next sibling parent Daniel de Kok <me nowhere.nospam> writes:
On Sun, 04 Jan 2009 14:01:41 -0500, Nick Sabalausky wrote:
 bool isFound=false;
 foreach(char[] key, Foo f; fooAA)
 {
     if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
     {
         isFound = true;
         break;
     }
 }
 if(!isFound)
     Stdout.formatln("Missing!");

 // vs:

 foreach(char[] key, Foo f; fooAA)
 {
      if(f.someFlag && key in barAA && f.someVal > barAA[key].someVal)
          break; // found
 }
 else
     Stdout.formatln("Missing!");

 - Increased emphasis on functional programming: Eliminating that
 "isFound" means one less bit (pardon the pun) of mutable state.

It's a common pattern indeed, but I am not sure if this is the prettiest solution. The slightly awkward idiom in the first example is needed because a for loop is not a function you can return from. Wouldn't it be more adequate to rewrite this as a function/method that takes a predicate? if (range.exists(predicate)) {} or if (exists(range, predicate) {} -- Daniel
Jan 04 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 Brian:
 any chance we could see something like pythons else statement on 
 iterative loops in D (Might be useful on regular for loops too but not as 
 much)?
 http://docs.python.org/tutorial/controlflow.html#break-and-continue-
 statements-and-else-clauses-on-loops

It seems everyone has ignored this post, but this isn't a proposal coming from a clueless alien. Such "else" has a little but true purpose, it helps avoid gotos in some situations, and this in turn may help the optimizer, because I think gotos aren't much well digested by modern C/D compilers.

Actually Walter loves goto, so DMD copes really well with it.
Jan 05 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:
 Actually Walter loves goto, so DMD copes really well with it.

When possible it's better to use structured programming and avoid gotos. That construct can avoid gotos in some common situations. And regarding the compiler back-end, I think it's also better to start thinking what's good for LDC :-) Bye, bearophile
Jan 05 2009
next sibling parent reply grauzone <none example.net> writes:
bearophile wrote:
 Don:
 Actually Walter loves goto, so DMD copes really well with it.

When possible it's better to use structured programming and avoid gotos. That construct can avoid gotos in some common situations. And regarding the compiler back-end, I think it's also better to start thinking what's good for LDC :-)

I don't know how relevant this is, but: LLVM uses SSA for registers, and it seems to be simpler to convert code to SSA if there are no gotos: "We show that it is possible to generate SSA form in a single pass (even during parsing) if the program contains only structured control flow (i.e., no gotos). For such programs the dominator tree can be built on the fly, too." http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4503 I also think that almost all common uses of gotos could be replaced by introducing some new statements for structured control flow. Like allowing the programmer to jump to the begin or end of a block using break/continue, similar to loops. For example, in the Linux kernel, they do the following for error handling: void somefunction() { do_stuff(); if (error) goto error_exit: do_more_stuff(); return; error_exit: handle_error(); } This could be replaced by something like this: void somefunction() { error_exit: { do_stuff(); if (error) break error_exit; do_more_stuff(); return; } handle_error(); } D's scope can do the same thing.
Jan 05 2009
next sibling parent reply Don <nospam nospam.com> writes:
grauzone wrote:
 bearophile wrote:
 Don:
 Actually Walter loves goto, so DMD copes really well with it.

When possible it's better to use structured programming and avoid gotos. That construct can avoid gotos in some common situations. And regarding the compiler back-end, I think it's also better to start thinking what's good for LDC :-)

I don't know how relevant this is, but: LLVM uses SSA for registers, and it seems to be simpler to convert code to SSA if there are no gotos: "We show that it is possible to generate SSA form in a single pass (even during parsing) if the program contains only structured control flow (i.e., no gotos). For such programs the dominator tree can be built on the fly, too." http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4503

It's possible to create grotesque configurations of 'goto' which are extremely difficult to analyze. But most uses of goto are simple.
 I also think that almost all common uses of gotos could be replaced by 
 introducing some new statements for structured control flow. Like 
 allowing the programmer to jump to the begin or end of a block using 
 break/continue, similar to loops. For example, in the Linux kernel, they 
 do the following for error handling:
 
 void somefunction() {
     do_stuff();
     if (error)
         goto error_exit:
     do_more_stuff();
 
     return;
 
 error_exit:
     handle_error();
 }
 
 This could be replaced by something like this:
 
 void somefunction() {
     error_exit: {
         do_stuff();
          if (error)
             break error_exit;
         do_more_stuff();
 
         return;
     }
     handle_error();
 }
 
 D's scope can do the same thing.

Jan 05 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 It's possible to create grotesque configurations of 'goto' which are 
 extremely difficult to analyze.

For a human, yes. For well-known optimization algorithms, no.
Jan 06 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Brian wrote:
 [snip]
 
 neither of those seem necessary in that example, whats wrong with this:
 void somefunction() {
 	do_stuff();
 	if (error)
 		handle_error();
 	else
 		do_more_stuff();
 }

A few things I can think of: 1. You're mixing error handling code with the other code. This breaks the flow and makes the logic harder to follow. 2. If you've got more than one point in the function where you need to do error handling, then you're going to be duplicating code; error handlers are very rarely just a single function call. 3. The point was that execution "fell out" after the handler. If you want to use conditionals, you can end up with really deeply indented code which is a bugger to read. It's rather ironic, but one thing that struck me going from Visual Basic to Python was that VB had much nicer error handling; instead of having error handling all over the place, it was all localised to the end of the function. This is why I absolutely adore scope statements. Of course, you're technically correct; in that specific example, you could do it either way. :) -- Daniel
Jan 06 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Daniel Keep Wrote:
 It's rather ironic, but one thing that struck me going from Visual Basic 
 to Python was that VB had much nicer error handling; instead of having 
 error handling all over the place, it was all localised to the end of 
 the function.  This is why I absolutely adore scope statements.

Like "on error resume next"...? ;-P
Jan 06 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Robert Fraser wrote:
 Daniel Keep Wrote:
 It's rather ironic, but one thing that struck me going from Visual Basic 
 to Python was that VB had much nicer error handling; instead of having 
 error handling all over the place, it was all localised to the end of 
 the function.  This is why I absolutely adore scope statements.

Like "on error resume next"...? ;-P

While not the best practice, I'd take that any day over Java's insane "OMG THIS MIGHT THROW!!!!111oneoneone" mentality. Seriously, javac; some times, I just don't care. -- Daniel
Jan 07 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 bearophile wrote:
 Don:
 Actually Walter loves goto, so DMD copes really well with it.

When possible it's better to use structured programming and avoid gotos. That construct can avoid gotos in some common situations. And regarding the compiler back-end, I think it's also better to start thinking what's good for LDC :-)

I don't know how relevant this is, but: LLVM uses SSA for registers, and it seems to be simpler to convert code to SSA if there are no gotos: "We show that it is possible to generate SSA form in a single pass (even during parsing) if the program contains only structured control flow (i.e., no gotos). For such programs the dominator tree can be built on the fly, too." http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4503

I don't know what they're talking about. The D optimizer has no trouble whatsoever building dominator graphs, no matter what rat's nest of gotos are used. This technology was well understood in 1980. In fact, the front end deconstructs *everything* into gotos, and that's all the optimizer works with.
Jan 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 grauzone wrote:
 bearophile wrote:
 Don:
 Actually Walter loves goto, so DMD copes really well with it.

When possible it's better to use structured programming and avoid gotos. That construct can avoid gotos in some common situations. And regarding the compiler back-end, I think it's also better to start thinking what's good for LDC :-)

I don't know how relevant this is, but: LLVM uses SSA for registers, and it seems to be simpler to convert code to SSA if there are no gotos: "We show that it is possible to generate SSA form in a single pass (even during parsing) if the program contains only structured control flow (i.e., no gotos). For such programs the dominator tree can be built on the fly, too." http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4503

I don't know what they're talking about. The D optimizer has no trouble whatsoever building dominator graphs, no matter what rat's nest of gotos are used. This technology was well understood in 1980. In fact, the front end deconstructs *everything* into gotos, and that's all the optimizer works with.

The challenge the paper addresses is constructing the SSA form in one shot. There are indeed algorithms that build the SSA in several passes. My vague recollection from a compiler construction class is that there are a number of static analyses that need to do a fixed-point computation on loops. Such analyses can deal with any jumps except a particular one: jump forward from the outside of a loop in the middle of it. Does anyone know what analyses were those? Andrei
Jan 06 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 The challenge the paper addresses is constructing the SSA form in one 
 shot. There are indeed algorithms that build the SSA in several passes.
 
 My vague recollection from a compiler construction class is that there 
 are a number of static analyses that need to do a fixed-point 
 computation on loops. Such analyses can deal with any jumps except a 
 particular one: jump forward from the outside of a loop in the middle of 
 it. Does anyone know what analyses were those?

The two-entry-points-to-a-loop is the essential characteristic of an "irreducible flow graph". Such can be transformed into reducible ones, but it is not worth the effort because such are fairly rare, even in spaghetti goto code. <nose-in-air>I've known for 25 years that it's freaking easy to do optimizations if you can assume there are no goto's. But you wind up with a crippled compiler technology suitable only for toy languages. That's why real compilers aren't written that way.</nose-in-air> I only read part of the paper, but I don't see the point of it.
Jan 06 2009
prev sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:
 Don:
 Actually Walter loves goto, so DMD copes really well with it.

When possible it's better to use structured programming and avoid gotos.

Structured programming does not mean no gotos. You should really read the original paper "Goto considered harmful", you'll find it's actually about the evil of spaghetti code, such as in BASIC. In C family-languages, including D, there is no spaghetti goto. So actually it's nearly impossible to abuse goto in D in the way that the original paper was talking about. I still avoid goto because I was told to. But eventually I realised that it's 100% propaganda. I actually think my code would be cleaner if I used it; it would allow lots of local flag variables to be eliminated. But I still have this residual prejudice against 'goto' which is really hard to get rid of.
 That construct can avoid gotos in some common situations.

 And regarding the compiler back-end, I think it's also better to start
thinking what's good for LDC :-)

 
 Bye,
 bearophile

Jan 05 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 I still avoid goto because I was told to. But eventually I realised that 
 it's 100% propaganda. I actually think my code would be cleaner if I 
 used it; it would allow lots of local flag variables to be eliminated.
 But I still have this residual prejudice against 'goto' which is really 
 hard to get rid of.

The problem with goto is it is easy to get into a human readability problem with it. No such problem exists for optimization algorithms.
 Yes, but I doubt any compiler would have a problem with goto.

The last time I even heard of a compiler that fell over and gave up optimizing if it saw a goto was in the early 80's. I have a hard time believing LDC has problems with it, but if it does, the authors should hit the books <g>. I keep thinking I should put on a "Compiler Construction" seminar! P.S. There are problems with goto'ing out of a finally block, and there's a problem in the optimizer with goto'ing from one try block to another, but that's not the issue here.
Jan 06 2009
next sibling parent Benji Smith <dlanguage benjismith.net> writes:
Walter Bright wrote:
 I keep thinking I should put on a "Compiler Construction" seminar!

Sign me up!
Jan 06 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Walter,

 I keep thinking I should put on a "Compiler Construction" seminar!
 

That would be fun. If I could, I'd show up.
Jan 06 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Don wrote:
 I still avoid goto because I was told to. But eventually I realised that
 it's 100% propaganda. I actually think my code would be cleaner if I
 used it; it would allow lots of local flag variables to be eliminated.
 But I still have this residual prejudice against 'goto' which is really
 hard to get rid of.

problem with it. No such problem exists for optimization algorithms.
 Yes, but I doubt any compiler would have a problem with goto.

optimizing if it saw a goto was in the early 80's. I have a hard time believing LDC has problems with it, but if it does, the authors should hit the books <g>.

goto's jump to a label, so it's not like the compiler has no idea where entry points might be, anyway. And in the extreme case of languages with inline asm containing jump-to-address operations, I would think that the address would have to be computed at run-time, which is obviously after any optimization has been done. I suppose I'm failing to see the problem with goto's, assuming a structured language like D (as opposed to goto's in BASIC).
 I keep thinking I should put on a "Compiler Construction" seminar!

You should. The academic courses do a good job with theory and general application, but that isn't quite the same as one based on practical experience. Sean
Jan 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 I keep thinking I should put on a "Compiler Construction" seminar!

You should. The academic courses do a good job with theory and general application, but that isn't quite the same as one based on practical experience.

That's true. I learned the theory taking a compiler construction course at Standford, and then tried to apply it. It turns out that there's a lot they left out <g> that's needed to actually get those optimizations to work. Loop induction variables was a big one, because the theory never takes into account the fact that you're replacing a signed loop index with an unsigned loop pointer. Oops! It's like in physics class you're always dealing with frictionless brakes and pointless masses.
Jan 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Sean Kelly wrote:
 I keep thinking I should put on a "Compiler Construction" seminar!

general application, but that isn't quite the same as one based on practical experience.

Standford, and then tried to apply it. It turns out that there's a lot they left out <g> that's needed to actually get those optimizations to work. Loop induction variables was a big one, because the theory never takes into account the fact that you're replacing a signed loop index with an unsigned loop pointer. Oops! It's like in physics class you're always dealing with frictionless brakes and pointless masses.

You mean massless points? Or was that deliberate?

I think there were two jokes actually: frictionless brakes (used instead of e.g. frictionless pulleys) which is an oxymoron, and a pun on point masses (objects that can be approximated by a point). Andrei
Jan 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 On Thu, Jan 8, 2009 at 6:46 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Sean Kelly wrote:
 I keep thinking I should put on a "Compiler Construction" seminar!

general application, but that isn't quite the same as one based on practical experience.

at Standford, and then tried to apply it. It turns out that there's a lot they left out <g> that's needed to actually get those optimizations to work. Loop induction variables was a big one, because the theory never takes into account the fact that you're replacing a signed loop index with an unsigned loop pointer. Oops! It's like in physics class you're always dealing with frictionless brakes and pointless masses.


e.g. frictionless pulleys) which is an oxymoron, and a pun on point masses (objects that can be approximated by a point).

Hmmm. Oh yeh. I'm gonna claim lack of my first morning cup o coffee as my excuse for missing that. Cute.

School physics problems always start out with "assume there is no friction, and the point has no mass." Academic papers on compiler optimizations always start out with "assume there are no pointers, no references, no arrays, no exceptions, no threads, no aliasing, no overflows, no signed/unsigned, there are infinite registers available, registers are orthogonal, etc." Or they just go ahead and let you discover that they assumed that. Useful languages are a lot messier in the real world.
Jan 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 On Thu, Jan 8, 2009 at 6:46 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Sean Kelly wrote:
 I keep thinking I should put on a "Compiler Construction" seminar!

general application, but that isn't quite the same as one based on practical experience.

course at Standford, and then tried to apply it. It turns out that there's a lot they left out <g> that's needed to actually get those optimizations to work. Loop induction variables was a big one, because the theory never takes into account the fact that you're replacing a signed loop index with an unsigned loop pointer. Oops! It's like in physics class you're always dealing with frictionless brakes and pointless masses.


instead of e.g. frictionless pulleys) which is an oxymoron, and a pun on point masses (objects that can be approximated by a point).

Hmmm. Oh yeh. I'm gonna claim lack of my first morning cup o coffee as my excuse for missing that. Cute.

School physics problems always start out with "assume there is no friction, and the point has no mass." Academic papers on compiler optimizations always start out with "assume there are no pointers, no references, no arrays, no exceptions, no threads, no aliasing, no overflows, no signed/unsigned, there are infinite registers available, registers are orthogonal, etc." Or they just go ahead and let you discover that they assumed that.

Well that should be taken with the traditional grain of salt. Andrei
Jan 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Academic papers on compiler optimizations always start out with 
 "assume there are no pointers, no references, no arrays, no 
 exceptions, no threads, no aliasing, no overflows, no signed/unsigned, 
 there are infinite registers available, registers are orthogonal, 
 etc." Or they just go ahead and let you discover that they assumed that.

Well that should be taken with the traditional grain of salt.

Some are better than others, sure. I found out the hard way. But even in the paper cited in this thread: "We do not deal here with alias problems caused by assignments to array elements, to parameters passed by reference, and to variables that are referenced via pointers. These problems can be dealt with in the same way as described in [5]." and this: "This is useful for languages such as Simula[3], Modula-2 [13] or Oberon [14] that lack goto statements at all." Who uses Simula, Modula-2 or Oberon?
Jan 07 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Academic papers on compiler optimizations always start out with 
 "assume there are no pointers, no references, no arrays, no 
 exceptions, no threads, no aliasing, no overflows, no 
 signed/unsigned, there are infinite registers available, registers 
 are orthogonal, etc." Or they just go ahead and let you discover that 
 they assumed that.

Well that should be taken with the traditional grain of salt.

Some are better than others, sure. I found out the hard way. But even in the paper cited in this thread: "We do not deal here with alias problems caused by assignments to array elements, to parameters passed by reference, and to variables that are referenced via pointers. These problems can be dealt with in the same way as described in [5]." and this: "This is useful for languages such as Simula[3], Modula-2 [13] or Oberon [14] that lack goto statements at all." Who uses Simula, Modula-2 or Oberon?

Without saying anything about this paper in particular, quality of research papers has a very top-heavy distribution. Outside a few conference proceedings and journals, where only a few institutions publish, the quality of research publications decreases drastically. Andrei
Jan 07 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 It's like in physics class you're always dealing with frictionless brakes
 and pointless masses.

You mean massless points? Or was that deliberate?

I wondered if anyone would notice that (!). Yes, it's deliberate.
Jan 07 2009
parent BCS <ao pathlink.com> writes:
Reply to Walter,

 Bill Baxter wrote:
 
 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 
 It's like in physics class you're always dealing with frictionless
 brakes and pointless masses.
 



OTOH test often have their share of red harring as well!
Jan 07 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:
 On Wed, Jan 7, 2009 at 6:07 AM, Walter Bright 
     The last time I even heard of a compiler that fell over and gave up
     optimizing if it saw a goto was in the early 80's. I have a hard
     time believing LDC has problems with it, but if it does, the authors
     should hit the books <g>.
 
 
 It doesn't :P

That's good to hear!
Jan 07 2009
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright wrote:
 I keep thinking I should put on a "Compiler Construction" seminar!

*cough* NWCPP *cough*
Jan 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:
 Walter Bright wrote:
 I keep thinking I should put on a "Compiler Construction" seminar!

*cough* NWCPP *cough*

I'd like to do a paid one <g>. BTW, Bartosz has graciously offered the Jan NWCPP speaking engagement to me. I'll be talking about mixins and templates. All are welcome, of course.
Jan 07 2009
parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 Robert Fraser wrote:
 
 Walter Bright wrote:
 
 I keep thinking I should put on a "Compiler Construction" seminar!
 


BTW, Bartosz has graciously offered the Jan NWCPP speaking engagement to me. I'll be talking about mixins and templates. All are welcome, of course.

Video! Video! ?? (for those of us not in Seattle)
Jan 08 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 Reply to Walter,
 
 Robert Fraser wrote:

 Walter Bright wrote:

 I keep thinking I should put on a "Compiler Construction" seminar!


BTW, Bartosz has graciously offered the Jan NWCPP speaking engagement to me. I'll be talking about mixins and templates. All are welcome, of course.

Video! Video! ?? (for those of us not in Seattle)

See www.nwcpp.org. Ask Bartosz!
Jan 08 2009
prev sibling parent reply "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"Walter Bright" <newshound1 digitalmars.com> kirjoitti viestissä 
news:gk1dag$ptn$1 digitalmars.com...
 I keep thinking I should put on a "Compiler Construction" seminar!

A net-seminar, please, so that those of us who want to attend actually can.
Jan 08 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Rioshin an'Harthen" <rharth75 hotmail.com> wrote in message 
news:gk4kfh$ri3$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> kirjoitti viestissä 
 news:gk1dag$ptn$1 digitalmars.com...
 I keep thinking I should put on a "Compiler Construction" seminar!

A net-seminar, please, so that those of us who want to attend actually can.

Yes :). Things like this never make their way out to Cleveland (or anywhere within a three-hour drive, which is about the max I could realistically do). (Heck, *decent* programmers are never out this way.)
Jan 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 "Rioshin an'Harthen" <rharth75 hotmail.com> wrote in message 
 news:gk4kfh$ri3$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> kirjoitti viestissä 
 news:gk1dag$ptn$1 digitalmars.com...
 I keep thinking I should put on a "Compiler Construction" seminar!

can.

Yes :). Things like this never make their way out to Cleveland (or anywhere within a three-hour drive, which is about the max I could realistically do). (Heck, *decent* programmers are never out this way.)

When we did the Astoria Seminar in 2007, the consistent feedback was that what the attendees liked most was the ambiance and getting together with like-minded professionals and face time with experts. I do think that the one-on-one in person is an essential ingredient to making seminars a valuable experience.
Jan 08 2009
parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gk6150$n63$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Rioshin an'Harthen" <rharth75 hotmail.com> wrote in message 
 news:gk4kfh$ri3$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> kirjoitti viestissä 
 news:gk1dag$ptn$1 digitalmars.com...
 I keep thinking I should put on a "Compiler Construction" seminar!

can.

Yes :). Things like this never make their way out to Cleveland (or anywhere within a three-hour drive, which is about the max I could realistically do). (Heck, *decent* programmers are never out this way.)

When we did the Astoria Seminar in 2007, the consistent feedback was that what the attendees liked most was the ambiance and getting together with like-minded professionals and face time with experts. I do think that the one-on-one in person is an essential ingredient to making seminars a valuable experience.

Agreed. Which is why it's dissapointing that any good programming-related stuff is usually too far for me. I know a lot of people travel large distances for many of these things, but I'm rarely able spend the money on the travel and lodging. But videos are better than nothing though.
Jan 08 2009
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Jan 8, 2009 at 10:28 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Walter Bright wrote:
 Bill Baxter wrote:
 On Thu, Jan 8, 2009 at 6:46 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Sean Kelly wrote:
 I keep thinking I should put on a "Compiler Construction" seminar!

You should. The academic courses do a good job with theory and general application, but that isn't quite the same as one based on practical experience.

That's true. I learned the theory taking a compiler construction course at Standford, and then tried to apply it. It turns out that there's a lot they left out <g> that's needed to actually get those optimizations to work. Loop induction variables was a big one, because the theory never takes into account the fact that you're replacing a signed loop index with an unsigned loop pointer. Oops! It's like in physics class you're always dealing with frictionless brakes and pointless masses.

You mean massless points? Or was that deliberate?

I think there were two jokes actually: frictionless brakes (used instead of e.g. frictionless pulleys) which is an oxymoron, and a pun on point masses (objects that can be approximated by a point).

Hmmm. Oh yeh. I'm gonna claim lack of my first morning cup o coffee as my excuse for missing that. Cute.

School physics problems always start out with "assume there is no friction, and the point has no mass." Academic papers on compiler optimizations always start out with "assume there are no pointers, no references, no arrays, no exceptions, no threads, no aliasing, no overflows, no signed/unsigned, there are infinite registers available, registers are orthogonal, etc." Or they just go ahead and let you discover that they assumed that.

Well that should be taken with the traditional grain of salt.

In my experience just about any academic paper has to be digest with a large grain of salt. Most of the ones I have become intimately familiar with have big limitations not mentioned by the authors that only become apparent once you start trying to repeat what they did. But maybe graphics papers are particularly susceptible to this phenomenon. A typical graphics paper shows three or four nice results, and says "see look! it works!", but unfortunately that's no proof of general effectiveness. It just proves it works for those 3-4 images. --bb
Jan 07 2009
prev sibling next sibling parent "Danny Wilson" <bluezenix gmail.com> writes:
foreach(languageStatement; AllProgrammingLanguages)
   Stdout.format(
     "It's possible to create grotesque configurations of '{}' which are "~
     "extremely difficult to analyze. But most uses of {} are simple.",
     languageStatement
   ).newline;
Jan 05 2009
prev sibling next sibling parent Brian <digitalmars brianguertin.com> writes:
On Mon, 05 Jan 2009 11:13:49 +0100, grauzone wrote:
 void somefunction() {
 	do_stuff();
 	if (error)
 		goto error_exit:
 	do_more_stuff();
 
 	return;
 
 error_exit:
 	handle_error();
 }
 
 This could be replaced by something like this:
 
 void somefunction() {
 	error_exit: {
 		do_stuff();
   		if (error)
 			break error_exit;
 		do_more_stuff();
 
 		return;
 	}
 	handle_error();
 }
 
 D's scope can do the same thing.

neither of those seem necessary in that example, whats wrong with this: void somefunction() { do_stuff(); if (error) handle_error(); else do_more_stuff(); }
Jan 06 2009
prev sibling next sibling parent "Tomas Lindquist Olsen" <tomas.l.olsen gmail.com> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Wed, Jan 7, 2009 at 6:07 AM, Walter Bright <newshound1 digitalmars.com>wrote:

 Don wrote:

 I still avoid goto because I was told to. But eventually I realised that
 it's 100% propaganda. I actually think my code would be cleaner if I used
 it; it would allow lots of local flag variables to be eliminated.
 But I still have this residual prejudice against 'goto' which is really
 hard to get rid of.

The problem with goto is it is easy to get into a human readability problem with it. No such problem exists for optimization algorithms. Yes, but I doubt any compiler would have a problem with goto.

The last time I even heard of a compiler that fell over and gave up optimizing if it saw a goto was in the early 80's. I have a hard time believing LDC has problems with it, but if it does, the authors should hit the books <g>.

It doesn't :P
 I keep thinking I should put on a "Compiler Construction" seminar!

 P.S. There are problems with goto'ing out of a finally block, and there's a
 problem in the optimizer with goto'ing from one try block to another, but
 that's not the issue here.

Jan 07 2009
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Sean Kelly wrote:
 I keep thinking I should put on a "Compiler Construction" seminar!

You should. The academic courses do a good job with theory and general application, but that isn't quite the same as one based on practical experience.

That's true. I learned the theory taking a compiler construction course at Standford, and then tried to apply it. It turns out that there's a lot they left out <g> that's needed to actually get those optimizations to work. Loop induction variables was a big one, because the theory never takes into account the fact that you're replacing a signed loop index with an unsigned loop pointer. Oops! It's like in physics class you're always dealing with frictionless brakes and pointless masses.

You mean massless points? Or was that deliberate? --bb
Jan 07 2009
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Jan 8, 2009 at 6:46 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Bill Baxter wrote:
 On Thu, Jan 8, 2009 at 5:54 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Sean Kelly wrote:
 I keep thinking I should put on a "Compiler Construction" seminar!

You should. The academic courses do a good job with theory and general application, but that isn't quite the same as one based on practical experience.

That's true. I learned the theory taking a compiler construction course at Standford, and then tried to apply it. It turns out that there's a lot they left out <g> that's needed to actually get those optimizations to work. Loop induction variables was a big one, because the theory never takes into account the fact that you're replacing a signed loop index with an unsigned loop pointer. Oops! It's like in physics class you're always dealing with frictionless brakes and pointless masses.

You mean massless points? Or was that deliberate?

I think there were two jokes actually: frictionless brakes (used instead of e.g. frictionless pulleys) which is an oxymoron, and a pun on point masses (objects that can be approximated by a point).

Hmmm. Oh yeh. I'm gonna claim lack of my first morning cup o coffee as my excuse for missing that. Cute. --bb
Jan 07 2009